Re: lenny regression initrd/lvm/ rootfs detection timeout
Stephen Gran <sgran@debian.org> writes:
> 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...
>
> 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.
It isn't always a modprobe issue. For example iSCSI can create new
block devices long after the modules are loaded, depending on network
delays (it may not be the case here, I'm not sure what iscsistart
does). But you can also think CONFIG_SCSI_SCAN_ASYNC... Events can
arrive any time (when you plug in your pendrive), udevsettle can only
wait for the event queue to empty, not for future events.
> Ferenc, since you are affected, can you test?
Using udevsettle (udevadm settle) instead of sleep? Sure, but only
tomorrow. Actually, that may be the best fix for the open-iscsi
initramfs script, if iscsistart provides the timing guarrantees the
kernel does not. :) Thanks for the suggestion!
--
Cheers,
Feri.
Reply to: