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

Bug #258432 reported by Ryan Lovett on 2008-08-15
Affects Status Importance Assigned to Milestone
casper (Ubuntu)

Bug Description

Binary package hint: casper

I tried booting an IBM IntelliStation A Pro off of intrepid-desktop-amd64.iso but it drops to a BusyBox initramfs prompt.

Ryan Lovett (ryan-spacecoaster) wrote :
Ryan Lovett (ryan-spacecoaster) wrote :
Tormod Volden (tormodvolden) wrote :

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*

Changed in casper:
assignee: nobody → tormodvolden
status: New → Incomplete

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?

Steve Beattie (sbeattie) wrote :

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 @@
           # 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

and boot with that in the modified initrd (via grub off the discs) as described in , 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.

Steve Beattie (sbeattie) wrote :
Steve Beattie (sbeattie) wrote :
Steve Beattie (sbeattie) wrote :

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

Steve Beattie (sbeattie) wrote :

Marking as confirmed.

Changed in casper:
status: Incomplete → Confirmed
Steve Beattie (sbeattie) wrote :

@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)

Tormod Volden (tormodvolden) wrote :

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.

Changed in casper:
assignee: tormodvolden → nobody
Simon Strandman (nejsimon) wrote :

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.

Steve Beattie (sbeattie) wrote :

@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.

Tormod Volden (tormodvolden) wrote :

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.

Peter Cordes (peter-cordes) wrote :

This is a dupe of, 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.

Tormod Volden (tormodvolden) wrote :

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.

Changed in casper:
importance: Undecided → High
Launchpad Janitor (janitor) wrote :

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

Changed in casper:
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers