Hi,

We performed an FC3 installation and installed GRUB in mbr
of the disk. The installation went fine and only after the
first reboot we got the following message.

root (hd0,0)
filesystem type is ext2fs, partition type 0x83

kernel /vmlinuz2.6.9.1-667FC3 ro root=LABEL=/1
[Linux-bzImage, setup=0x1400, size=0x155da5]

initrd /initrd2.6.9-1.667FC3.img
[Linux-initrd @ 0x7f8c000, 0x60f8c]
-

that's it. No further booting process, it stops here.

Using grub command line we found out that installation was fine, filesystems were intact fully. We also reinstalled grub in the mbr but no difference.

We shall be thankful for any assitance in this problem. Are
there any logs that can be examined?

What is your hardware?

The initrd is an "initial ramdisk," containing startup files used by some distributions. Initially, it sounds like that wasn't built properly. To begin with, I would do a complete re-make of the kernel, and reinstall...

just seen this so do not know if its resolved

2 things

1....get a live cd such as kanotix or knoppix and boot that to see your filesystem and the /boot/grub stuff

by right hand clicking the appropiate partition (hda1?) you can edit the menu.lst etc

2....your hd0,0 tells me you have installed FC into the first partition but with the missing /boot/vmlinuz as per my tut you have a separate /boot partition......if this is incorrect the fix is to put /boot b4 the kernel and initrd commands.

anyhow try the troubleshooter to see more kernel options if you wish


good luck

Thankyou all for your kind attention. Let me give you a more detailed view of the picture. We are upgrading from RH6.1 to FC3 on old p3 intel 440 bx boards. We have somewhat 60 clients to be upgraded through kickstart and we use nfs server for installation. To boot the installation kernel, we copy the FC3Cd#1 kernel and initrd image to client machine, modify and reinstall its lilo and reboot.
1. Some of the machines (not all) refuse to boot the new CD kernel in the same way as described above, but continue to boot the previous RH6.1 kernel. So we boot the installation from CD player but the same machines refuse to boot the FC3 kernel after the complete installation withe filesystems etc intact.
2. We usually install FC3 on 6 to 9 machines in a working day. One day, a machine had stopped at the point after grub, as shown in the first post. One of us hit something to the machine accidently and the machine started to boot very normally, e.g.
Uncompressing Linux .... booting the kernel

and so on.
3. So now we adopted the habit of smacking the PCs which refused to boot the way we liked them to. But this obviously wasn't any solution. So, we took 2 exactly similar machines, one normal and other abnormal and interchanged their hard-disks, since we thought the hard disks might have been too old. But the hard disk of abnormal machine worked fine with the normal machine and the hard disk of normal machine failed to boot on the abnormal machine. So, it looks like there is a problem near the motherboard, but we still need to conduct a few more similar swaps until we are able to get the idea of exact problem. We shall update you people soon after the weekend.

regards
amber and fahad

I am not a network person but at first glance grub does not appear to be the culprit.

hitting the machine may work if you have a loose connection. Have you had a chance to open up and push all ribbons into the mobo and drives to confirm?

i am not a tech.....but a crack in the solder on the mobo could be another suggestion but then you would have reported that the machine fails after some use.....after it got hot

This may point to a possible problem with your harddisk as aus9 has said. why don't u just reset the BIOS and configure it from scratch and see if it clears the problem. I once had such problems after adding/moving harddisks around ide channels 1 and 2. every time the system stopped at uncompressing linux stage. Usually it got solved after a BIOS reset. So u can give it a try.

Your suggestion is good and we shall try it but currently
all the ill machines are working fine with a 'software disk warm up' if I can call it; we have added a few warm up grub instructions before real grub instructions which are:
debug
root (hd0,1)
cmp /vmlinuz... /vmlinux...
cmp /grub/stage2 /grub/stage2
normal grub instructions from here
and have remove 'quiet' from kernel parameters

The files have been selected for there big size so that
comparison becomes a bit of an activity. This again is not
reasonable but better than physical smacking. But again, your suggestion sounds good, there might be some problem with disk controller, for example.
thankyou
amber