Redhat 9 system displays "Boot Failed"
 

I have a relatively new Redhat 9 system that was working just great for 6 months until the last time I started it.

Now tonight, I press the power button, I see the BIOS splash screen, then "Boot Failed" instead of the Grub loader screen asking which version to boot.

I put in my Redhate boot diskette and try again. Among the text scrolling by the screen I see things like:

hda: read_intr: 0x04 { Drive Status Error }
end_request: I/O error, dev 03:02 (hda) sector 2
EXT-fs: unable to read superblock

and many more. Then:

Kernel panic: no init found. Try passing init= option to kernel.


Has my disk died?

Any suggestions? If dead, any other way to get the data off of it?

Thanks

Phil

Boot a standalone disk, then try to mount.

My disk looks okay. It is a 30GB Maxtor ATA. I used the Maxtor diagnostic tool diskette and the drive passed all non destructive tests.

So what might be happening?

Could my boot area have become corrupted?

If so how would one recover?

Should I attempt a reinstall from the Redhat 9 installation disks?

Would this destroy may application data?

Well I tried a live boot CD (DamnSmallLinux) and tried to mount the partitions on the disk: hda1, hda2, hda3. I think hda2 is the root filesystem and I am pretty sure I used the default ext2 filesystem when I originally installed Redhat 9. The message I got was:

> sudo mount -t ext3 /dev/hda2 /mnt/hda2
mount : wrong fs type, bad option, dad superblock on /dev/hda2
or too many mounted file systems.

The bad superblock was in an error message I got when I tried the boot diskette.

Could my "superblock" have become corrupted? How would I repair that?

Reading around the forum some more, it looks like you use e2fsck to fix superblocks. As in the thread: http://www.linuxquestions.org/questions/history/140535

Well this yields a:

e2fsck: Attempt to read block from filesystem resulted in short read while trying to open /dev/hda2
Could this be a zero length partition.

The thread goes on to suggest the partition table is bad. Here is mine:

Command (m for help): p

Disk /dev/hda: 30.7 GB, 30750031872 bytes
240 heads, 63 sectors/track, 3972 cylinders
Units = cylinders of 15120 * 512 = 7741440 bytes

Device Boot Start End Blocks Id System
/dev/hda1 ? 267666 49364 497115833 29 Unknown
Partition 1 does not end on cylinder boundary.
/dev/hda2 ? 204081 49219 976730017 3 XENIX usr
Partition 2 does not end on cylinder boundary.
/dev/hda3 ? 1 1 0 6c Unknown
Partition 3 does not end on cylinder boundary.
/dev/hda4 92485 160850 516843863+ 49 Unknown
Partition 4 does not end on cylinder boundary.

Partition table entries are not in disk order


--------

Supposedly this is very bad. Since I do not have my original partition settings, attempting repair is unlikely to be successful.

So before I start anew on my Redhat 9 re-install from scratch, I appeal to the community two more questions:

1. Is my prognosis correct? The partition is bad, start over.

2. What could have corrupted it? I do not recall any "abnormal" event that might have caused this. The disk diagnostics all pass, no power failure, or the such. I did have DVD-ROM on the secondary IDE bus that was "bad" and causing syslog errors, but that was all.

hi

I have a new red hat 9 system, but while booting the service sendmail takes a 3-4 minutes to start. So I don't want the sendmail service to start at boot time. But since I am not much familiar with linux I don't know how to do it... ?

Is there anybody who can help me to solve this problem?

Thanks

Well I ended up re-installing and forgetting about recovery.

As for rsj0719's problem, I am not sure why he/she posted it here.

I did have this problem and determined that sendmail wanted a hostname.domainname for its host in the /etc/hosts file. After adding that, it starts up very quickly.

not sure why rsj posted here either...

But to turn off send mail all together chkconfig sendmail off should do it.

Hi friends...
Thank you pwalden and reelwylde....

as a newbie i was not knowing where to post my questions..... sorry for that...

once again thank you....