Intrepid 4 live cd drops to busybox, needs more time to find CD livefs

Thanks for your report. It seems like find_livefs does not look at your CD drives. At the busybox prompt, can you please try these things:
 ls /dev/sr*
 ls /dev/scd*
 ls /sys/block/sr*
 ls /sys/block/scd*

Possibly related to bug #196063. Can you also try booting with "break=mount" then wait some seconds at the busybox prompt before you enter "exit" to let it continue?

I have an older Dell 530 MT workstation that has had the same problem with all of the Intrepid alphas up to and including alpha 5. What's happening is that the scanning loop inside casper's mountroot() function is cycling through it's loop before all of the device probing is finished and the cd drive is ready. When I modified the loop in casper like so:

  --- a/scripts/casper 2008-09-05 15:28:19.000000000 -0700
  +++ b/scripts/casper 2008-09-05 21:38:29.000000000 -0700
  @@ -550,7 +550,7 @@
           fi
       else
           # Scan local devices for the image
  - for i in 0 1 2 3 4 5 6 7 8 9 a b c d e f 10 11 12 13; do
  + for i in 0 1 2 3 4 5 6 7 8 9 a b c d e f 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f 30; do
               livefs_root=$(find_livefs $i)
               if [ "${livefs_root}" ]; then
                   break

and boot with that in the modified initrd (via grub off the discs) as described in https://wiki.ubuntu.com/CustomizeLiveInitrd , then the live cd successfully boots.

(as an aside, using faux hex values in the loop is bogus, because within find_livefs(), the passed value is tested against the value of $LIVEMEDIA_TIMEOUT if the latter's been defined using a [ -lt ] test which only works with decimal numbers. The resulting error is silently ignored.)

I'll attach casper and dmesg logs for both successful and failing runs. Note that for this hardware, the loop is finishing and dropping into busybox just before the cd drive is ready. Looking at the dmesg timestamps in Ryan's log, that may not be the case for his hardware.

As I mentioned, this hardware has been unable to boot any of the Intrepid alphas since alpha2 (the first I tried), so this is not due to the 2.6.26 -> 2.6.27 transition. However, Hardy, Gutsy, and Dapper all successfully install on this hardware (it's a crashbox I use), so it's possible that a kernel change somewhere in between 2.6.24 -> 2.6.26 lengthened the hardware initialization time.

Bah, uploaded the wrong casper.log the second time, sorry for the noise. This should be the correct one.

Marking as confirmed.

@Tormod: to answer your question, using "break=mount" and then waiting for the kernel to finish getting the devices ready before exiting busybox also results in a successful boot of the live cd.

(for the record, my attempts tonight were with the Ubuntu Intrepid ia32 livecd, build 20080904, which is slightly newer than the alpha 5 image)

Thanks for the logs. I am surprised it takes more than 20 seconds (timeout 0x13 + overhead) to detect the CD. Anyway, I have a suspicion the timeout goes much faster than before since the floppy module is not loaded (bug #255651). Therefore the floppy drive is not probed 20 times, which added considerable time.

I would like to see the floppy probing go away in all cases (bug #97306) and maybe the timeout has to be raised, like you did in your modification.

It would be nice if the detection of the CD can be faster. But it's not of great importance since the live CD booting doesn't have to be so fast.

I have the same problem. Whatever i choose from the menu: try ubuntu, install or test cd only gives me a busybox shell. The computer is an ordinary x86 (core 2 duo) with sata drives. I'm using the 32 bit x86 Alpha5 CD.

@Tormod: note that both the original reporter's system and mine both have real SCSI cards in them. SCSI tends to take a while to initialize and complete its bus probes. For example, looking through the dmesg log I uploaded, it takes roughly 15 seconds for my SCSI card to set up and recognize the devices on it. In the original reporter's dmesg, there's two seperate SCSI devices, a symbios card and an Adaptec card, each of which take 10-15 seconds to initialiaze and is a serialized process.

While it would be nice if the detection of the CD was faster, having it fail and drop to busybox prematurely will lead people to mistakenly believe that Ubuntu does not work on their hardware, when it very well could.

nxsty, does using "break=mount" and then waiting for the kernel to finish getting the devices ready before exiting busybox also work for you? Otherwise please file a new bug and subscribe me.

This is a dupe of https://bugs.launchpad.net/ubuntu/+source/casper/+bug/158976, which also has some comments. e.g. I posted there about the device list to scan not being updated as new devices are discovered. My USB stick has break=mount in my syslinux.cfg, and I wait for it to be detected before continuing the boot.

 I hope marking this as a dupe doesn't hamper you guys corresponding about this bug. Let me know if I shouldn't have done this.

No, it's not the same bug. Here, the problem is that the timeout (waiting for root fs) is too short. In the other report (bug #158976) there is a race condition, the root fs has been already been found and the system goes too far without waiting for other needed disks, like for instance the persistant media where casper-rw is residing.

This bug was fixed in the package casper - 1.144

---------------
casper (1.144) intrepid; urgency=low

  * Bump media detection timeout to a minute; thanks to Tormod Volden and
    Steve Beattie for analysis (LP: #258432).
  * Note that this changes (fixes?) the semantics of LIVEMEDIA_TIMEOUT due
    to not using hex values in a for loop which aren't understood by test
    -lt (thanks, Steve Beattie).

 -- Colin Watson <email address hidden> Fri, 26 Sep 2008 18:35:13 +0100