Description of problem: FC7T4 Live 386 fails to boot because it can't find the root device Version-Release number of selected component (if applicable): FC7T4 Live 386 How reproducible: Every boot - unless there is a usb stick plugged in, when it works perfectly. Steps to Reproduce: 1. Insert CD and power up 2. Select run from image 3. Wait for timeout that drops you into the nash shell asking for a root device Actual results: Timeout drops you into the nash shell asking for a root device Expected results: Switch to root device and completion of boot Additional info: Sounds a bit like bugs 227281 and 238095. My case: motherboard ide handled by nvidia MCP2A with CD on ide0secondary DVD on ide1primary, and Silicon Image 0680 pic with HDs on ide0p and ide1p. Initial boot hardware scan finds both ide devices (pata_amd and pata_sil680) and the drives themselves, allocates scsi0 - scsi3 and ata1 - ata4, but only creates /dev/sda and /dev/sdb for the HDs. Naturaly the boot process hangs for lack of a root device, since the CD has no device. I found that having a usb stick at boot time gave a normal boot. Log files to come shortly (this is coming from the test box itself).
Created attachment 154471
Created attachment 154472 [details] log for successfully booting (forced to stop at single user)
If adding usb caused it to work, it's probably a delay issue in the initrd.
If it is in initrd, would that also affect the DVD version? I'm currently downloading it via wet string. Will test and report when done.
Looked at the DVD - totally different initrd that doesn't have the problem.
When it fails, can you see if /sys/block/sr0 exists and if sr_mod is loaded?
Created attachment 154701 [details] logs for the fail case - again Bloody Murphy- Bugzilla ate the previous copy and I didn't notice until I went to refer to it. In answer, no sr0 sr1, or sr_mod until I manually modprobed - see tail of fail.txt for that. By chance I added a sata drive last night, and now the trick of a usb stick making it boot doesn't work. Disable sata in the bios and back to previous behaviour. Looks much the same as before, just another drive added.
For some reason, udev isn't loading sr_mod... this is the same thing that davej's machine hit I think, but then I wasn't able to reproduce it anywhere else.
Any further data I can extract? I might be able to create a hacked initrd with some debug, given the odd pointer. (I've done it on an HD, creating the CD is a little more adventurous).
Created attachment 155045 [details] A tweak to init in initrd.img to modprobe sr_mod I hacked init in initrd.img to add a line to modprobe sr_mod that causes the udev cascade to load sr0 and sr1 etc, and hence make /dev/root to appear. Whether the location I selected is optimal I can't say. As a hack it works on this box - not finding the real cause, but a workaround.
Similar hack applied to the repo for livecd-creator; that'll at least avoid this being a blocker for F7 although we should still resolve it
*** Bug 240859 has been marked as a duplicate of this bug. ***
no udev in initrd running... reassigning...
This is the livecd; udev _is_ running in the initrd