On some laptops the livecd initrd is unable to mount an USB cdrom. This results in linuxrc dropping to a shell instead of continuing with the installation. The problem occurs because either devfsd or the hardware doesn't get enough time to get initialized. I can hear the CDROM get initialized _after_ the shell prompt appears. SOLUTION: replacing "sleep 1" with "sleep 10" right after the line that says "devfsd /newroot/dev -np" in linuxrc fixes the problem for me and allows me to install. Reproducible: Always Steps to Reproduce: 1. 2. 3. This is for the 2004.1 LiveCD.
Hrrrmn... I'm not sure how well another 9-second increase in boot time will be percieved. Perhaps we can work out some way to get this going without forcing a delay on everyone. I'm going to add genkernel to this, since they're the ones that actually create the initrd. I'm also upping the severity and priority, since this is something that we need to have fixed for 2004.2.
Unfortunately, I am not sure why this delay is necessary. I suspect this is because I have to turn on "Legacy USB emulation" in the BIOS to boot from the CDROM, and when subsequently uhci gets loaded, the CD needs to reinitialize completely, which takes time. Or it could be that this CD-ROM is just slow. I guess an alternative way would be to poll for CD-ROM devices and proceed only once they are ready (we can't proceed without them anyway, right?)
Can you try using my -test4 and -test5 CDs? You can find them at /experimental/x86/livecd on your local Gentoo mirror. If -test5 isn't there, it should be in the next 6-12 hours.
I have tried -test5 and it exhibits the same behavior (e.g. fails in the same way). BTW, it might be a good idea to add a way to identify LiveCD snapshots -- I know it's 2004.2, but I don't see in the boot process that it's the "-test5".
I don't want it to be identified, simply because once I finalize it, I'll probably just rename it. Saves me from having to rebuild an identical CD just for a name change. By the way, what device names does the system give for the CDROM when it is detected? I am looking for something that wouldn't be on the system otherwise, so I can add the delay in the initrd.
Well, it just appears as /newroot/dev/cdroms/cdrom0, which points to ../scsi/host0/bus0/target0/lun0/cd.
Boot the CD with "gentoo doscsi" and see what it comes up with...
It hangs with "Scanning for aic7xxx ..." as the last message.
Just out of curiousity... has anything changed when using 2004.2 proper?
Is there a reason for anything to change? I can retest, but it *does* take significant effort. Value your testers -- tell me to do the work if you're sure there's a reason for it.
Folks, the problem still exists in 2004.2 bootcd. I find it rather sad that we have wasted so much time on these discussions and the problem still isn't fixed, while I have provided a simple workaround in the bugreport itself, 3.5 months ago. In the absence of a proper solution, the 10 second wait won't hurt anyone much, and it will make gentoo cds work with slower systems and slower USB cdroms.
Look, man. You're bitching at the one person trying to solve your problem. Now, we've pretty much already said that we don't want to go about mucking with the timeout and would much rather *fix* the problem rather than mask it. I am sorry if this is not acceptable to you, but that is how I like to do things. Now... Tim, can you check this out and get me something into the next genkernel release? We really need USB CDROM support to work.
Motto: the way you treat your bug reporters determines the quality of the bug reports you get... First, I have fixed my problem. I have no interest whatsoever in "bitching" about it, except to make Gentoo better, which I thought was our common goal. Second, in my humble opinion, I would suggest to sort the priorities this way: 1. Get the thing working. 2. Get it working The Right Way. (especially since the bug is of the showstopper kind). But, I promise not to "bitch" about this anymore. I'm certainly capable of fixing my install CDs.
Semi-random-keep-everybody-happy-solution: Add a "usbdelay" boot option which sleeps for 10 seconds. If you can provide a method [ via dmesg or otherwise ] that says that a USB cdrom is present, then we can also use that instead for better usability. Any issues with that? Oh, and can we reproduce this with udev?
Sure. But that will require documenting. I still fail to see the reasons for opposing the 10s delay. Even emerge delays unmerging packages by 5s. And mind you, installing from a CD isn't really the common-case scenario. But really, anything that makes the CD work is fine.
I'm just curious, but does 5 seconds work for a delay?
We added a scandelay boot option to genkernel. It isn't listed (yet) but it is there. It adds a 10 second sleep. Enjoy.
