Bug#401916: Bug #401916 - any progress?
On Fri, February 23, 2007 14:16, maximilian attems said:
> On Fri, Feb 23, 2007 at 01:46:08PM +0100, David Härdeman wrote:
>> On Fri, February 23, 2007 12:11, maximilian attems said:
>> > On Fri, 23 Feb 2007, David Härdeman wrote:
> <snipp>
>> > mika's case is general enough, it affects lilo on almost any
>> > root beside ide and quick sata controller
>> > and grub for lvm2, evms and mdadm on those too.
>>
>> Sorry, I don't follow, what does lilo and grub have to do with waiting
>> in
>> the initramfs for the root blockdev to appear? Was that a reference to
>> bug
>> 409820?
>
> for grub we can wait for the root dev to appear,
> for lilo we create it by hand, so it's always there
> and you fall into the rescue shell for async root drivers.
Ah yes, now I follow, with lilo we get a numeric root dev which is passed
to parse_numeric() and used for /dev/root.
> so this is the topic of this particular bug and afaik
> the grml-2hd test case is precisely done on an usb stick
> with lilo bootloader.
>
>> > all the other distribution add some bandaid aka stupid sleep
>> > for the case of usb, ..
>> > and for a quick glance over those initramfs generators
>> > this would be done on mkinitramfs time.
>> > right?
>>
>> Yes, initramfs-based fixed sleep for a couple of seconds (which may
>> still
>> break in some scenarios) or a hardcoded root device (which allows the
>> initramfs script to wait until that root device node appears) are the
>> two
>> solution I've seen from a quick survey.
>>
>> I still think a user-configurable sleep (and/or a user configurable
>> device
>> node to wait for) would be the best option at this point followed by a
>> more complete solution later.
>
> yes the user configured sleep should override the stupid bandaid sleep.
> and i would like that band aid sleep only for the known trouble
> cases like usb-storage and ieee1394.
> we don't have too _many_ complaints, so we aren't doing that badly.
Exactly, considering the low amount of complaints, I'd say there's a tiny
minority that is actually affected by this bug.
Secondly, there is no way to have the bandaid-wait for usb-storage users
only, instead it would hit every computer with usb port (i.e. the vast
majority).
That's why I think it would be enough to: not include the bandaid at all,
implement the rootwait parameter and let the small minority who are
affected use it.
>>> sorry, really busy on a physics workshop so no code right now.
>>> but happy about your ping!
>>
>> Good luck with your workshop
>
> thanks, pretty intersting but lots of work..
Since you're busy, I'll do another patch which implements the rootwait
parameter during the weekend. Question is, should I completely remove the
wait from the premount stage (where it is now) and move it to the udev
stage, or should it be duplicated?
>> > salutations amicales
>>
>> Med vänliga hälsningar.
>
> zut babelfish lacks danish features.
Swedish
> switching back ;)
Mit freundlichen Grüßen :)
--
David Härdeman
Reply to: