Hi all,

The errors above are pretty common and I've found plenty of info and/or solutions to the problem. The twist is that I have tried a host of possible solutions and nothing has worked.

I have referenced RH docs which describe the rescue process. The catch is that it cannot find the system and fails to mount anything in /mnt/sysimage What I have done is choose 'skip' then mounted them myself. This is how I tried the things listed below.

I am on the verge of reinstalling the system :-( and preserving the important dirs (/home, /var) which would save data and speed the rebuild process. I post here in the hope that someone can point me to a solution I've yet to try as I think this is a case of a confused mapping or similar.

The system: PIII 500, .5 GB RAM, RedHat 7.2 (2.4.18-3 kernel)
It was set up Dec 17 and ran fine until a reboot, then all hell broke loose... this was early yesterday morning.

Me: Know my way around, used linux as desktop for 2 years. First time facing such a problem though, relative newbie re: sysadmin

What I have tried:
// Boot with linux rescue
Edit /etc/fstab
if you have labels like:
LABEL=/ remove this and use the device instead
/dev/hda1

// from another src, run this from grub cmd line
grub> root (hd0,0) <enter>
grub> kernel /vmlinuz root=/dev/hda2 <enter>
grub> boot <enter>

// still another possible
replace /sbin/init with one from the redhat CD, this one is likely corrupted

// when editing the grub entry put single at the end of the line kernel /vmlinuz-2.4.7-1 ro root=/dev/hda2 single

pass the string "init=/dev/hda2/sbin/init" inside of grub.

// boot off install CD using:
linux root=/dev/hda2 ro

// again, in grub editing the entry
// remove this line (or similar)
initrd /initrd-2.4.18-7.img

// still another suggestion
edit /etc/fstab and replace ext3 with ext2

// tried replacing grub with lilo, but when I try running /sbin/lilo it can't find lilo.conf because it's mounted in the rescue shell so /etc is not really the /etc I want.

// yes, I do have /etc/initrd

I respectfully ask for help!!

tia,
Jay B

oops, that should read RedHat 7.3... sry

Jay

The exact message prior to kernel panic is important.

However you may try adding the kernel options nomce at the end of the kernel line

ex for my kernel:
kernel /vmlinuz-2.4.18-14 ro root=LABEL=/ hdc=ide-scsi pci=off nomce

or in your case:
kernel /vmlinuz root=/dev/hda2 nomce
nomce - no machine check

Whatever option works you have to edit the grub.conf or lilo.conf file eventually.

Initially boot with the boot disk and at the boot prompt type
Hope you have one

boot: linux nomce rescue

You should be able to logon as root

If you have a list of options you can only try them out on a trial and error basis:

other options are
noisapnp, nodma, nopentium, nobiospnp, noauto, nousb
and so on

// tried replacing grub with lilo, but when I try running /sbin/lilo it can't find lilo.conf because it's mounted in the rescue shell so /etc is not really the /etc I want.

Boot up from the rescue cd.

/sbin/fsck.ext3

chroot /mnt/<mountpoint> /bin/bash --login

will create a new shell with your linux root partition as pseudo-root. That should help you with lilo.

What makes you think the init is corrupted?

Thx for responding.

smartes:
kernel panic: no init found. try passing init= option to kernel
Today, I can only get Warning: unable to open initial console error. I'd have to mess around more to reproduce the kernel panic. I've googled a whole lot lately and tried many things.

Yup, have the boot disk, but the nomce rescue arg did nothing. "unable to open..." error

nxny:
I suspected the init file was corrupt based on one of many solutions I found. Replacing it did nothing.

I think I may have neglected to chroot my mounted dir prior to setting up lilo. Aha... here is how I came to this: http://bugzilla.redhat.com/bugzilla/...?buglist=65207
While the specific hardware is not relevant, it appears it uncovered a bug in pre-2.4.19 kernels.

I'll try again to install lilo.

Thank you for your time. I'll post the resolution when I find one.

Jay

in 99.99% of the cases I've seen, if the kernel cant find init it is because init is not where someone told the kernel to look for it.

If you're getting kernel panics like these, I'd suggest to keep away from initrd unless you *know* what you're using it for...eg ext3-modules, raid modules etc.

Hey nxny,

Believe me, I am not happy about this venture and would far prefer to not be doing this at all. I just set up an old P100 to get into kernel building, etc. and would not choose to do this on a production box.

I have verified (repeatedly) the existence of init and have tried various means to pass its location to the kernel. I do understand this and can easily see how it would be a show-stopper. I don't know wtf I'm supposed to do! Would it make any diff if I put it somewhere else and tried a new path?

There was one post I came across that suggested something like this might be caused by an unsuccessful hack attempt. Does that seem reasonable? I had planned to run chkrootkit once I got it up again.

More fun and games following up the suggestions.

/sbin/fsck.ext3 gave me cmd not found, so I ran e2fsck /dev/hda and got a verbose error:
Couldn't find ext2 superblock, trying backup blocks...
e2fsck: Bad magic number in super-block while trying to open /dev/hda

It went on talking about a corrupt superblock, if the device actually has ext2 fs. It suggested I run it again and specify a different superblock. I'm really out of my depth here!

I did run e2fsck successfully on /dev/hda2 (after unmounting it), no errors

Moving along... boot up in rescue mode, get chrooted to my /boot partition

/sbin/lilo produces: Fatal: open /dev/hda: No such file or directory
I examine the dev dir and it has only: initctl (red [means broken symlink to me]), null, pts/ & shm/ (dirs are empty) there are no device pointers.

Thanks again,
Jay

>I have verified (repeatedly) the existence of init and have tried various means to pass its location to the kernel. I do understand this and can easily see how it would be a show-stopper. I don't know wtf I'm supposed to do! Would it make any diff if I put it somewhere else and tried a new path?

From my experience, the primary cause of "init not found" is that the kernel cannot find/mount the root filesystem as specified by the boot loader/command line. Would you post the output( from the rescue prompt ) to /sbin/fdisk -l /dev/hda? That should list your partition table. Also post (outside the chroot shell) cat /proc/mounts

where the hell are your device files?? download the MAKEDEV script that would create the rudimentary character/block devices. Availiable at http://ftp.no.linuxfromscratch.org/l...AKEDEV-1.7.bz2

bunzip2 it, move the unpacked script to as /dev/MAKEDEV and from the /dev directory, run
chmod 744 MAKEDEV && ./MAKEDEV -v generic

Ya, the missing device files really threw me too. I could read my partition table fine, mounted any partition I wanted. I decided it was best to re-install so I backed up what was important (mounting all the partitions in rescue mode and dumping to the 2nd HD) and re-installed the entire system. This time I used lilo per the reported grub bug. It's running and I'm back at home where I can complete the apache, etc. remotely.

Ultimately, I decided I had pursued all reasonable solutions to their end. Given that my issue so closely matched so many others yet none of the solutions yielded any results whatsoever, it was time to take a new approach. I also knew that had I simply reinstalled Monday, it would be all over now ;-)

The upside is I know a whole lot more about handling this type of situation than before. I am truly grateful for your assistance. I saved the system logs so I can go back and try to figure out wtf happened. My LogWatch from Sunday reported an ftp login that I didn't recognize. I had been in there Sunday am, then come Monday it was hooped. That precipitated a remote restart then it never came back... I'm rather suspicious of this whole affair, there's just no reasonable explanation.

Anyhow, I'm rambling... live long and prosper:-) This forum rocks!

Jay

FWIW, I had that same problem. The kernel option was pointing at the wrong partition. I'm on debian (sid) on a 2.4.21-pre3 kernel at the moment.

title Debian GNU/Linux, kernel 2.4.21-pre3
root (hd0,1)
#--- the next line had the wrong partition -- root=/dev/hda1
kernel /boot/vmlinuz-2.4.21-pre3 root=/dev/hda2 ro
savedefault
boot

HTH

Shadow_7