From Bugzilla Helper: User-Agent: Mozilla/5.0 Galeon/1.0.3 (X11; Linux i686; U;) Gecko/20020205 Description of problem: the linuxrc script that gets generated by mkinitrd uses LABEL for root disk -> mount of root fails -> no init found message. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1.install with root on DAC960 volume 2.reboot Actual Results: 3.no init found Expected Results: boot fresh installation Additional info: I can work around the problem by adding the device nodes for the DAC960 volumes to the dev directory of the initrd image and specifying the root partition's /dev/rd/c?d?p? on the mount line in linuxrc. $ ls -l /mnt/loop/dev brw-rw---- 1 root disk 48, 0 Mar 28 14:11 c0d0 brw-rw---- 1 root disk 48, 1 Mar 28 14:10 c0d0p1 brw-rw---- 1 root disk 48, 2 Mar 28 14:10 c0d0p2 brw-rw---- 1 root disk 48, 3 Mar 28 14:10 c0d0p3 brw-rw---- 1 root disk 48, 4 Mar 28 14:10 c0d0p4 brw-rw---- 1 root disk 48, 5 Mar 28 14:10 c0d0p5 brw-rw---- 1 root disk 48, 6 Mar 28 14:10 c0d0p6 brw-rw---- 1 root disk 48, 7 Mar 28 14:10 c0d0p7 example linuxrc: #!/bin/nash echo "Loading scsi_mod module" insmod /lib/scsi_mod.o echo "Loading sd_mod module" insmod /lib/sd_mod.o echo "Loading aic7xxx module" insmod /lib/aic7xxx.o echo "Loading DAC960 module" insmod /lib/DAC960.o echo "Loading jbd module" insmod /lib/jbd.o echo "Loading ext3 module" insmod /lib/ext3.o echo Mounting /proc filesystem mount -t proc /proc /proc echo 0x0100 > /proc/sys/kernel/real-root-dev echo Mounting root filesystem mount --ro -t ext3 /dev/rd/c0d0p2 /sysroot umount /proc pivot_root /sysroot /sysroot/initrd
Jeremy, is this fixed in the new mkinitrd?
Yeah, fixing cciss should have fixed DAC960 as well
Created attachment 51344 [details] mknod feedback patch
I've used nash from mkinitrd 3.3.6 and it seems to work. Maybe it would be a good idea to check to return value of mknod in the uuidcache_init function of mount_by_label.c and provide some feedback as this would make diagnosing the problem more easy. I've attached a patch for this. Something that could (should) be fixed in a later version is the hardcoded 1 subdirectory of /dev detection. The way it's implemented today only devices 1 level deep in /dev will work. If someting like /devices/block would be used instead of /dev this code will fail. I suppose this could be a future problem with devfs.
*** Bug 62336 has been marked as a duplicate of this bug. ***
*** Bug 60147 has been marked as a duplicate of this bug. ***
I opened what was deemed as a duplicated bug, 62336, but I don't understand the solution based on the comments here. I want the system to boot properly after the install without having to make modifications-- am I going to have to wait for a later beta release? thanks, James
This does not seem to be fixed in RHL 7.3 (which includes mkinitrd-3.3.10-1), c.f. bug 64736
Symptom is the same. Root problem is unrelated. We're not mounting by label in the initrd anymore, so this bug doesn't apply. Reclosing