[lug] Flakey Hardware?

Stephen Queen svqueen at gmail.com
Fri Feb 10 07:19:45 MST 2006


On 2/10/06, Stephen Queen <svqueen at gmail.com> wrote:
> On 2/10/06, John Hernandez <John.Hernandez at noaa.gov> wrote:
> > I would be inclined to try a different OS before concluding it's faulty
> > hardware.  Can you, for example, install and boot a BSD variant?  I
> > won't even mention the other logical choice for a test OS.  If those
> > work fine, it may then be advisable to try a different Linux distribution.
> >
> > If other OS's fail similarly, running memtest86 from a bootable CD might
> > be a logical next step.
> >
> > Lee Woodworth wrote:
> > > Steve Sullivan <Steve Sullivan wrote:
> > >> Hi,
> > >>
> > >> I recently bought a dual opteron system, with a Tyan motherboard
> > > I recall reading that there were issues with the BIOS and/or SATA
> > > chipset on some amd64 motherboards about a year ago (gentoo amd64
> > > topics in the support forums). You may want to do research on the
> > > issue.
> > >> and SATA drives from monarchCompter.com.
> > >> It wouldn't boot, so after many many attempts to contact
> > >> their tech support, by phone and by email, I finally got
> > >> an RMA and sent it back.
>
> Did Monarch sell this system as being Linux compatible? If they did,
> maybe the kernel you are loading needs a driver installed that is not
> being installed. Try booting a  cd distribution such as Knoppix. If it
> does boot, do an lsmod and see which modules have been loaded. Try a
> command like
> lsmod | grep scsi
> or
> lsmod | grep sata
> .
>
> Then maybe add the modules you think are missing to your
> /etc/modules
> file. At least that would be where you would add them if you were
> using debian. If suse doesn't use /etc/modules (not etc/modules.conf)
> it probably has some sort of similar mechanism. That is, a mechanism
> that adds modules to load at boot time.
>
> Hope that helps,
> Stephen Queen
>
I've been thinking further about this. If the kernel panic is
occurrring  even before the / disk is mounted, in other words if / is
mounted on the hard drive that is causing the problem, you can get
into the initrd.img file and modify it so that it loads the proper
modules.

On debian you can see the contents of the initrd and modify it by using

cramfsck -x new_initrd_dir /boot/initrd.img

The script that is run is called linuxrc.

to recommpress it you would simply

mkcramfs new_initrd_dir /boot/initrd.img

In other distributions it may be slightly different. In slackware it
was a little more complicated. I think you had to first create a file
system. Associate it with a loop dev, then mount it, then decompress
your initrd into it. It was something like this

dd if=/dev/zero of=new_initrd_file bs=1024 count=100

That would get you a 100K of space for your file system.

Then you would have to make sure the module loop has been inserted

modprobe loop

then

losetup /dev/loop0 new_initrd_file

then

mkfs.ext3 /dev/loop0

then mount it

mount /dev/loop0 new_initrd_dir

Expand your initrd.img into it and modify it

Good Luck,
Stephen Queen



More information about the LUG mailing list