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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
