Desktop CD fails to find media

This oddly seems to be tied to udev and the amount of time it takes to create the device node. If I interrupt the process with "break=mount" wait until I see /dev/scd0 created and then exit, everything works as expected.
It is strange, though, that a second drive helped. When checking with the second drive, it also takes some time until the device nodes are created.

Thanks for your report. Does this still happen in Intrepid? If so, please see https://wiki.ubuntu.com/DebuggingCasper and attach the logs here.

We are closing this bug report because it lacks the information we need to investigate the problem, as described in the previous comments. Please reopen it if you can give us the missing information, and don't hesitate to submit bug reports in the future. To reopen the bug report you can click on the current status, under the Status column, and change the Status back to "New". Thanks again!

Ubuntu 9.04 version 1.173 Trace of casper shows mountroot()->find_livefs()->get_fstype will return the error:
    /init: line 1: cannot open /dev/sda: no such file

When I add "/sbin/udevadm settle" before the loop "for sysblock in $(echo /sys/block/* ... " this goes away. Not sure if this is the right fix or the right place for it. I'll leave that to someone with more experience here.

Thx,

/Dion

Dion, can you please attach your casper.log (for the failing case)?

> It is strange, though, that a second drive helped. When checking with the second drive, it also takes some time until the > device nodes are created.

Stefan, this is because the "timeout" is not based on time, but on number of iterations. More devices to check extends the time to run the given (20?) cycles and gives more time for the root device to appear. This is also why this regressed in Hardy, since the floppy modules was not loaded any longer and this shortened each checking cycle tremendously.

Attached is a casper.log before I added the "udevadm settle"

The difference between before and after is:

# diff casper.log-nosettle casper.log-settle
1,4d0
< /init: line 1: cannot open /dev/sda: no such file
< /init: line 1: cannot open /dev/sda: no such file
< /init: line 1: cannot open /dev/sr0: no such file
< /init: line 1: cannot open /dev/sr0: no such file

Here is a run with "set -x" at the top of the /scripts/casper

Was there a result or response here? I'm not sure if the "udevadm settle" is actually a fix or just masking the problem. And, I saw in some other code that the "udevadm settle" command was put in a loop structure after a call to cryptsetup. It didn't seem right there, but I don't understand udev enough to know. I wonder if the developer didn't do the same thing I did and put it in "just in case"

/Dion

In my understanding, using udevadm settle would be the right thing to do. This makes sure udev has done all the processing and device nodes have been created for the existing devices. I have not looked at the current installer code but I think it should go there if it isn't already. I have not run into this problem lately, but that is probably because things go slightly faster or because floppy has been loaded again.

From the comments above, it seems like there is enough information for a developer to take a look and confirm that this is fixed in current releases, though its doubtful that we would update Hardy's desktop CD's with an SRU, given that the desktop install is only supported for about 8 more months, and there is a workaround available.

Setting Importance to Low, as this problem seems quite uncommon.

Could you see if your bug match this one:
    https://bugs.launchpad.net/ubuntu/+source/linux/+bug/543875

Marking incomplete, can you please retry on 12.04 or 12.10, I'm pretty sure that part of the code changed a lot these past few years ;)

Thanks

[Expired for casper (Ubuntu) because there has been no activity for 60 days.]