This one time, at band camp, Ferenc Wagner said: > maximilian attems <max@stro.at> writes: > > > On Tue, Oct 07, 2008 at 03:54:59PM +0200, Florian Lohoff wrote: > >> On Tue, Oct 07, 2008 at 03:10:47PM +0200, maximilian attems wrote: > >>>>> standard answer boot with > >>>>> rootdelay=X > >>>> > >>>> It worked with etch without that parameter and the upgraded did not add > >>>> it so its a lenny regression - isnt it? > >>> > >>> no it was just luck that it didn't hit you previously. > >>> kernel gives no guarantee on timing. > >> > >> This renders the argument with "rootdelay=" moot - When the kernel gives > >> no guarantee on timing ANY rootdelay works just by luck. So coming back > >> to this issue i consider this still a bug - When a block device comes > >> available the lvm code needs to scan it in case the rootfs is an lvm. > >> > >> The whole issue with finding the rootfs in the initrd needs to be > >> triggered and not waited for base on the statement of yours. > > > > too late for such changements and no that is not the solution either. > > Care to elaborate why not? The principle surely sounds better: > instead of fragile arbitrary delays, wait until the event we're > interested in happens. Actually, I always dreamed of a system where > every dependency is encoded as udev rules, and the boot process only > has to wait for the root device to appear. And I'm stuck now with a > problem even rootdelay can't help: local-top/iscsi finishes before > /dev/sda appears, so local-top/lvm has nothing to activate. And > there's no rootdelay in between... (I have nothing to do with any of the affected software, just a comment as an interested person). If modprobe returns before the device is actually initialized and has created sysfs entries, this is probably not fixable in shell scripts. If, as I suspect, modprobe does not return immediately, this is probably a bug in the scripts that don't call udevsettle and wait for the sysfs entries to be turned into block devices for the next script to act on. Ferenc, since you are affected, can you test? Cheers, -- ----------------------------------------------------------------- | ,''`. Stephen Gran | | : :' : sgran@debian.org | | `. `' Debian user, admin, and developer | | `- http://www.debian.org | -----------------------------------------------------------------
Attachment:
signature.asc
Description: Digital signature