Creating initial device nodes

[art.gibbens]

Hi all,

I'm putting a server together and have run into a boot up problem. (I thought about putting this in the server forum, but it might be a more generic problem that others have seen and know how to rectify.) The install seems to have gone just fine. I have the /boot partition on an internal IDE drive. The rest of that drive and another are mirrored in a Raid0 configuration (using the Linux software to do that) for data storage. The swap partition is a part of the Raid5 SCSI array that also has the / (root) partition on it.

After installation it would not finish the booting process. I suspected that GRUB didn't like all the Raid arrays and such, but it seems to be fine. I can say that because the machine will boot into rescue mode with the GUI splash screen and I have access to the whole directory tree.

I have already searched on-line and following prudent advice, ran the yum update while in the chroot /mnt/sysimage mode. That only took overnight to download and most of this morning to complete. Still no dice. Used vim to delete the rhgb quiet commands in the grub.conf file so I could see where the kernel seems to be hanging.

So right after the "Creating initial device nodes" is a line about my generic PS2 wheel mouse. So I tried a USB mouse. Got more output so tried swapping out to a USB keyboard. Got a little further with more information about input devices, but still stops. Also, I tried a PCI video card just to make sure the onboard video wasn't the problem - no change.

So, if someone in the Fedora community knows what loads up or is configured right after the mouse and keyboard, I might be able to figure out what's causing the computer to hang during the boot process. Or if there is something else I need to do, please let me know.

Thanx for listening,

Art

[Gödel]

Can you boot into init 1 or init 3? (Append 1 or 3 to the end of the grub line)

[art.gibbens]

No and no.

[art.gibbens]

Anybody else have any ideas?

[art.gibbens]

I'm going to re-post this on the Server and Startup Forums as well to see if I get any more suggestions.

[glennzo]

Please don't post the same thing in other forums. Familiarize yourself with the posting guidelines first.

[art.gibbens]

fpmurphy from the servers forum suggested this: "Suggest you try rebuilding your initrd image. Use mkinitrd to do that."

Apparently I didn't read the fine print about multiple posts on this forum - mea culpa. So I am putting here what has been shared already. I'll post back here how rebuilding the init file goes.

Art

[art.gibbens]

Update: making progress

Recreating the initrd did not seem to make any difference. However, found some other documentation on the RedHat Forum in the Documentation site/pages. As I went back over my install I found this: http://kbase/redhat.com/faq/docs/DOC-2879 concerning the GRUB device.map file.

Also found this: http://forums/fedoraforum.org/showthread.php?t=153679. Not sure if what I've found confirms what stoat wrote or not.

What I found is that my old device.map had this inside:
(hd0) /dev/sda
(hd2) /dev/rd/c0d0

After running the GRUB executable from the first link, my device.map now looks like this:
(fd0) /dev/fd0
(hd0) /dev/sda
(hd1) /dev/sdb
(hd2) /dev/rd/c0d0

So, noticing the difference I went back into my grub.conf file and noticed this:

root (hd0,0)

I suspected that wasn't right, so I changed it to

root (hd2,0)

And now I get an error message saying

"Error 17: Cannot mount selected partition
Press any key to continue..."

And when you do that you get the splash screen - hallelujah! The latest kernel is listed (as I used the # to REM out the older kernel) so I know for sure it is not a hardware issue.

If I change it to

root (hd0,2)

I get the error "Error 22: No such partition. Press any key to continue..."

When I go into my /etc/fstab I see this:

UUID= /boot ext3 defaults 1 2
UUID= / ext4 defaults 1 1
/dev/md0 /media/raid ext4 defaults 1 2
UUID= swap swap defaults 0 0
tmpfs /dev/shm tmpfs defaults 0 0
devpts /dev/pts devpts defaults 0 0
sysfs /sys sysfs defaults 0 0
proc /proc proc defaults 0 0

If I remove the # signs in the grub.conf file I see both kernel options in the splash screen.

I know I am this close to getting this thing to fire, I think I just need someone to look over my shoulder and give a couple of pointers concerning how to set the grub.conf file correctly or something along those lines.

[art.gibbens]

Taken from chapter 33 of RedHat documentation (Sorry if I seem redundant):

A boot loader for the x86 platform is broken into at least two stages. The first stage is a small machine code binary on the MBR. Its sole job is to locate the second stage boot loader and load the first part of it into memory.

GRUB has the advantage of being able to read ext2 and ext3 [13] partitions and load its configuration file — /boot/grub/grub.conf — at boot time. Refer to Section 9.7, “GRUB Menu Configuration File” for information on how to edit this file.

Once the second stage boot loader is in memory, it presents the user with a graphical screen showing the different operating systems or kernels it has been configured to boot. On this screen a user can use the arrow keys to choose which operating system or kernel they wish to boot and press Enter. If no key is pressed, the boot loader loads the default selection after a configurable period of time has passed.

Once the second stage boot loader has determined which kernel to boot, it locates the corresponding kernel binary in the /boot/ directory. The kernel binary is named using the following format — /boot/vmlinuz-<kernel-version> file (where <kernel-version> corresponds to the kernel version specified in the boot loader's settings).

For instructions on using the boot loader to supply command line arguments to the kernel, refer to Chapter 9, The GRUB Boot Loader. For information on changing the runlevel at the boot loader prompt, refer Section 9.8, “Changing Runlevels at Boot Time”.

The boot loader then places one or more appropriate initramfs images into memory. Next, the kernel decompresses these images from memory to /sysroot/, a RAM-based virtual file system, via cpio. The initramfs is used by the kernel to load drivers and modules necessary to boot the system. This is particularly important if SCSI hard drives are present or if the systems use the ext3 file system.
Once the kernel and the initramfs image(s) are loaded into memory, the boot loader hands control of the boot process to the kernel."



So I'm past the second stage because I get prompted to choose which kernel to load if I put a 10 second timeout in the grub.conf. I've put everything back the way it was in the beginning. If I go to /boot/* I see both versions of the kernel vmlinuz files, as well as the initrd files.

Can initramfs files be accessed in any way to see what the hangup might be? I still have my original problem, that is if I delete rhgb and quiet from the grub.conf file the startup process stops right after loading the generic scroll PS2 mouse.

I'm pretty confident that the hardware and install are good, in that all the files seem to be where they belong and the correct versions.

Has anybody got any more ideas? I'm starting to think I have a reportable BUG for this install of Fedora 11.

[art.gibbens]

Well, is this machine down for the count or is there any hope of getting it to fire up?

[glennzo]

Art. I don't see mention of (hd1,0). What happened to that? What happens if you try it in the boot configuration? If that doesn't work can you boot with a live disk and post the output of fdisk? Mind you I'm not at all familiar with raid but booting a system with raid can't be all that different.

[art.gibbens]

glennzo and others,

Here's the output from using fdisk:

/dev/sda1 (boot)
/dev/sda2 (Linux Raid) - mirror storage
/dev/sdb1 (Linux Raid) - mirror storage
/dev/rd/c0d0p1 (swap)
/dev/rd/c0d0p2 (/) - where the OS is

The last two are both on the physical Raid 5 comprised of 5 drives so if one drive dies I can just replace it. It's about 67 Gigs all told. The mirror raid is being handled via Fedora 11 as a software raid and is going to be just for storage. It's just under 250 Gigs.

The only place "hd" is mentioned is in the /boot/grub/device.map where it says:

(fd0) /dev/fd0
(hd0) /dev/sda
(hd1) /dev/sdb
(hd2) /dev/rd/c0d0

and in the /boot/grub/grun.conf file where is says:

spalshimage=(hd0,0)
root (hd0,0)

It feels like something is not being "handed off" correctly and once that is figured out I think it will be off to the races.

Art

[art.gibbens]

oops that should have been /boot/grub/grub.conf not grun.conf

[art.gibbens]

And I'm not sure what "the boot configuration" means. If I boot from the install DVD and choose recovery mode, then chroot I have complete access to the entire directory structure. I was even able to run the yum update without a hitch. However, if I let it boot with no DVD in the tray, it stops at the point earlier mentioned, right after my generic wheel mouse is discovered.

[Gödel]

how did you run the mkinitrd? the initrd is probably missing the drivers for your physical raid array. Which model is it? If you can access the raid array from rescue mode then running mkinitrd should include the required modules, or you can force it with --preload or --with options. run lsmod in rescue mode to look for the required raid modules that need to be loaded.

You can check which modules are included in the current initrd by unpacking it and looking in the lib/modules dir.

mkdir /tmp/initrd
cd /tmp/initrd
gzip -dc /boot/initrd-<version>.img | cpio -idv
ls lib/modules/<version>/*.ko