Debian Bug report logs - #401916
initramfs-tools: [powerpc64] i-t tries to mount RAID/LVM stuff before the disk are up -> unbootable

version graph

Package: initramfs-tools; Maintainer for initramfs-tools is Debian kernel team <debian-kernel@lists.debian.org>; Source for initramfs-tools is src:initramfs-tools.

Reported by: Sven Luther <luther@debian.org>

Date: Wed, 6 Dec 2006 20:03:07 UTC

Severity: important

Tags: help

Merged with 366175, 381351, 432534, 433905, 434138

Found in versions initramfs-tools/0.60, initramfs-tools/0.73, initramfs-tools/0.88, initramfs-tools/0.89, udev/0.105-3, initramfs-tools/0.92j

Done: Michael Prokop <mika@debian.org>

Bug is archived. No further changes may be made.

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to debian-bugs-dist@lists.debian.org, Debian kernel team <debian-kernel@lists.debian.org>:
Bug#401916; Package initramfs-tools. Full text and rfc822 format available.

Acknowledgement sent to Sven Luther <luther@debian.org>:
New Bug report received and forwarded. Copy sent to Debian kernel team <debian-kernel@lists.debian.org>. Full text and rfc822 format available.

Message #5 received at submit@bugs.debian.org (full text, mbox):

From: Sven Luther <luther@debian.org>
To: Debian Bug Tracking System <submit@bugs.debian.org>
Subject: initramfs-tools: [powerpc64] i-t tries to mount RAID/LVM stuff before the disk are up -> unbootable
Date: Wed, 06 Dec 2006 20:52:30 +0100
Package: initramfs-tools
Severity: critical
Justification: breaks the whole system


Sorry maks for this RC bug, but i think the severity is deserved.

Today i went to the datacenter to reboot the xserve G5 i have there, for some
random reason, and what was not my surprise to notice that the box didn't come
up anymore.

After some dmesg examination, i noticed that the sata disks did come up only
after i-t tried to bring up the RAID and LVM stuff, which is really not nice.

on this machine, root is on a LVM, inside a RAID1 on two physical disks.

Furthermore, playing offline without any info with the box, i was not able to
convince i-t to mount the partition and investigate, but well, i guess i would
have been able to do so if i had the code available, or more time to
investigate.

The box is currently switched off until i can come back with a fix to this
issue (oh, and it refused to eject the CDROM i put in it to try to boot the
debian-installer in resuce mode :).

Friendly,

Sven Luther

-- System Information:
Debian Release: 4.0
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: powerpc (ppc)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-2-powerpc
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)



Information forwarded to debian-bugs-dist@lists.debian.org, Debian kernel team <debian-kernel@lists.debian.org>:
Bug#401916; Package initramfs-tools. Full text and rfc822 format available.

Acknowledgement sent to maximilian attems <maks@sternwelten.at>:
Extra info received and forwarded to list. Copy sent to Debian kernel team <debian-kernel@lists.debian.org>. Full text and rfc822 format available.

Message #10 received at 401916@bugs.debian.org (full text, mbox):

From: maximilian attems <maks@sternwelten.at>
To: Sven Luther <luther@debian.org>, 401916@bugs.debian.org
Subject: Re: Bug#401916: initramfs-tools: [powerpc64] i-t tries to mount RAID/LVM stuff before the disk are up -> unbootable
Date: Sun, 10 Dec 2006 10:39:45 +0100
On Wed, 06 Dec 2006, Sven Luther wrote:

> Package: initramfs-tools
> Severity: critical
> Justification: breaks the whole system

hmm yes i know of that situation it affects a certain range of roots.
 
 
> Today i went to the datacenter to reboot the xserve G5 i have there, for some
> random reason, and what was not my surprise to notice that the box didn't come
> up anymore.
> 
> After some dmesg examination, i noticed that the sata disks did come up only
> after i-t tried to bring up the RAID and LVM stuff, which is really not nice.

the trouble is that udevsellte exists to early that mean when
the scsi/usb discs are not up yet.
hitting raid/lvm2 roots on those devices and more general lilo boots
as there you have no root dev to wait for.
i notified udev upstream for it, but got no response i'll reask privately.
http://marc.theaimsgroup.com/?l=linux-scsi&m=116189244404693&w=2
 
> Furthermore, playing offline without any info with the box, i was not able to
> convince i-t to mount the partition and investigate, but well, i guess i would
> have been able to do so if i had the code available, or more time to
> investigate.

you should have rerun the early initramfs-tools stages, see init.
than it works.
 

best regards

-- 
maks



Information forwarded to debian-bugs-dist@lists.debian.org, Debian kernel team <debian-kernel@lists.debian.org>:
Bug#401916; Package initramfs-tools. Full text and rfc822 format available.

Acknowledgement sent to Sven Luther <sven.luther@wanadoo.fr>:
Extra info received and forwarded to list. Copy sent to Debian kernel team <debian-kernel@lists.debian.org>. Full text and rfc822 format available.

Message #15 received at 401916@bugs.debian.org (full text, mbox):

From: Sven Luther <sven.luther@wanadoo.fr>
To: maximilian attems <maks@sternwelten.at>, 401916@bugs.debian.org
Cc: Sven Luther <luther@debian.org>
Subject: Re: Bug#401916: initramfs-tools: [powerpc64] i-t tries to mount RAID/LVM stuff before the disk are up -> unbootable
Date: Mon, 11 Dec 2006 10:12:35 +0100
On Sun, Dec 10, 2006 at 10:39:45AM +0100, maximilian attems wrote:
> On Wed, 06 Dec 2006, Sven Luther wrote:
> 
> > Package: initramfs-tools
> > Severity: critical
> > Justification: breaks the whole system
> 
> hmm yes i know of that situation it affects a certain range of roots.
>  
>  
> > Today i went to the datacenter to reboot the xserve G5 i have there, for some
> > random reason, and what was not my surprise to notice that the box didn't come
> > up anymore.
> > 
> > After some dmesg examination, i noticed that the sata disks did come up only
> > after i-t tried to bring up the RAID and LVM stuff, which is really not nice.
> 
> the trouble is that udevsellte exists to early that mean when
> the scsi/usb discs are not up yet.
> hitting raid/lvm2 roots on those devices and more general lilo boots
> as there you have no root dev to wait for.
> i notified udev upstream for it, but got no response i'll reask privately.
> http://marc.theaimsgroup.com/?l=linux-scsi&m=116189244404693&w=2

Yeah, please do, we really need to fix this before etch is out, i don't think
that having a server who cannot reboot sometimes is something we want to ship
in etch.

> > Furthermore, playing offline without any info with the box, i was not able to
> > convince i-t to mount the partition and investigate, but well, i guess i would
> > have been able to do so if i had the code available, or more time to
> > investigate.
> 
> you should have rerun the early initramfs-tools stages, see init.
> than it works.

Ah, that was the missing info. I searched a bit, but didn't find easily what
to do, and then i had to leave. I will be at the box on thursday again.

Now, as a temporary workaround, maybe one solution, if RAID/LVM was not found
is to delay for a given time (1/2 minute ? a configurable time ?), and then
try again.

Another nice thing would be able to rerun the early initramfs-tools stages, or
maybe even have a stamp of each completed stage, and a single command which
allow to restart the detection from there ? 

Friendly,

Sven Luther



Information forwarded to debian-bugs-dist@lists.debian.org, Debian kernel team <debian-kernel@lists.debian.org>:
Bug#401916; Package initramfs-tools. Full text and rfc822 format available.

Acknowledgement sent to David Härdeman <david@hardeman.nu>:
Extra info received and forwarded to list. Copy sent to Debian kernel team <debian-kernel@lists.debian.org>. Full text and rfc822 format available.

Message #20 received at 401916@bugs.debian.org (full text, mbox):

From: David Härdeman <david@hardeman.nu>
To: 401916@bugs.debian.org
Cc: 401916-submitter@bugs.debian.org
Date: Thu, 1 Feb 2007 16:38:03 +0100 (CET)
Looking at:
http://cvs.mandriva.com/cgi-bin/viewvc.cgi/gi/tools/draklive?revision=1.116&view=markup

there's an interesting line which sleeps while the usb storage scanning
kernel thread is running (search the page for usb-stor-scan).

The usb scanning thread is called usb-stor-scan and the scsi scanning
threads are called scsi_scan_NUM (AFAIK).

So, as a workaround for Etch until this is fixed (presumably by upstream
changes to udev and/or the kernel), how about changing the following lines
in the udev initramfs script:

  udevtrigger
  udevsettle || true

to something like this:

  udevtrigger
  udevsettle || true
  while ps | grep -q "[usb-stor-scan]"; do
      sleep 1;
  done
  while ps | grep -q "[scsi_scan_.*]"; do
      sleep 1;
  done
  udevsettle || true


-- 
David Härdeman




Message sent on to Sven Luther <luther@debian.org>:
Bug#401916. Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian kernel team <debian-kernel@lists.debian.org>:
Bug#401916; Package initramfs-tools. Full text and rfc822 format available.

Acknowledgement sent to maximilian attems <maks@sternwelten.at>:
Extra info received and forwarded to list. Copy sent to Debian kernel team <debian-kernel@lists.debian.org>. Full text and rfc822 format available.

Message #28 received at 401916@bugs.debian.org (full text, mbox):

From: maximilian attems <maks@sternwelten.at>
To: David Härdeman <david@hardeman.nu>
Cc: Michael Prokop <mika@grml.org>, 401916@bugs.debian.org, 401916-submitter@bugs.debian.org
Subject: Re: Bug#401916:
Date: Thu, 1 Feb 2007 17:16:11 +0100
[ adding mika on cc ]

On Thu, Feb 01, 2007 at 04:38:03PM +0100, David Härdeman wrote:
> Looking at:
> http://cvs.mandriva.com/cgi-bin/viewvc.cgi/gi/tools/draklive?revision=1.116&view=markup
> 
> there's an interesting line which sleeps while the usb storage scanning
> kernel thread is running (search the page for usb-stor-scan).
> 
> The usb scanning thread is called usb-stor-scan and the scsi scanning
> threads are called scsi_scan_NUM (AFAIK).
> 
> So, as a workaround for Etch until this is fixed (presumably by upstream
> changes to udev and/or the kernel), how about changing the following lines
> in the udev initramfs script:
> 
>   udevtrigger
>   udevsettle || true
> 
> to something like this:
> 
>   udevtrigger
>   udevsettle || true
>   while ps | grep -q "[usb-stor-scan]"; do
>       sleep 1;
>   done
>   while ps | grep -q "[scsi_scan_.*]"; do
>       sleep 1;
>   done
>   udevsettle || true

mika, you could reliable trigger that race by using
grml2hd with lilo.
could you please test aboves proposed solution
and tell us how it works out?

thanks a lot for your patience and big kudos for David!!!

--
maks



Message sent on to Sven Luther <luther@debian.org>:
Bug#401916. Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian kernel team <debian-kernel@lists.debian.org>:
Bug#401916; Package initramfs-tools. Full text and rfc822 format available.

Acknowledgement sent to David Härdeman <david@hardeman.nu>:
Extra info received and forwarded to list. Copy sent to Debian kernel team <debian-kernel@lists.debian.org>. Full text and rfc822 format available.

Message #36 received at 401916@bugs.debian.org (full text, mbox):

From: David Härdeman <david@hardeman.nu>
To: maximilian attems <maks@sternwelten.at>
Cc: Michael Prokop <mika@grml.org>, 401916@bugs.debian.org, 401916-submitter@bugs.debian.org
Subject: Re: Bug#401916:
Date: Thu, 1 Feb 2007 17:31:35 +0100
On Thu, Feb 01, 2007 at 05:16:11PM +0100, maximilian attems wrote:
>On Thu, Feb 01, 2007 at 04:38:03PM +0100, David Härdeman wrote:
>> So, as a workaround for Etch until this is fixed (presumably by upstream
>> changes to udev and/or the kernel), how about changing the following lines
>> in the udev initramfs script:
>> 
>>   udevtrigger
>>   udevsettle || true
>> 
>> to something like this:
>> 
>>   udevtrigger
>>   udevsettle || true
>>   while ps | grep -q "[usb-stor-scan]"; do
>>       sleep 1;
>>   done
>>   while ps | grep -q "[scsi_scan_.*]"; do
>>       sleep 1;
>>   done
>>   udevsettle || true
>
>mika, you could reliable trigger that race by using
>grml2hd with lilo.
>could you please test aboves proposed solution
>and tell us how it works out?

And if you do, please make sure to change the greps to use "\[...\]" 
instead of "[...]"

The file to edit is:
/usr/share/initramfs-tools/scripts/init-premount/udev

-- 
David Härdeman



Message sent on to Sven Luther <luther@debian.org>:
Bug#401916. Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian kernel team <debian-kernel@lists.debian.org>:
Bug#401916; Package initramfs-tools. Full text and rfc822 format available.

Acknowledgement sent to Michael Prokop <mika@grml.org>:
Extra info received and forwarded to list. Copy sent to Debian kernel team <debian-kernel@lists.debian.org>. Full text and rfc822 format available.

Message #44 received at 401916@bugs.debian.org (full text, mbox):

From: Michael Prokop <mika@grml.org>
To: David Härdeman <david@hardeman.nu>
Cc: maximilian attems <maks@sternwelten.at>, 401916@bugs.debian.org, 401916-submitter@bugs.debian.org
Subject: Re: Bug#401916:
Date: Tue, 6 Feb 2007 11:14:34 +0100
[Message part 1 (text/plain, inline)]
* David Härdeman <david@hardeman.nu> [20070201 18:08]:
>  On Thu, Feb 01, 2007 at 05:16:11PM +0100, maximilian attems wrote:
> > On Thu, Feb 01, 2007 at 04:38:03PM +0100, David Härdeman wrote:

> >> So, as a workaround for Etch until this is fixed (presumably by upstream
> >> changes to udev and/or the kernel), how about changing the following lines
> >> in the udev initramfs script:
> >>   udevtrigger
> >>   udevsettle || true
> >> to something like this:
> >>   udevtrigger
> >>   udevsettle || true
> >>   while ps | grep -q "[usb-stor-scan]"; do
> >>       sleep 1;
> >>   done
> >>   while ps | grep -q "[scsi_scan_.*]"; do
> >>       sleep 1;
> >>   done
> >>   udevsettle || true

> > mika, you could reliable trigger that race by using
> > grml2hd with lilo.
> > could you please test aboves proposed solution
> > and tell us how it works out?

>  And if you do, please make sure to change the greps to use "\[...\]" instead 
>  of "[...]"

>  The file to edit is:
>  /usr/share/initramfs-tools/scripts/init-premount/udev

Ok, after running several different tests: nope, this does not fix
the problem. The usb stuff is running very asynchron. :(

I did lots of tests, the only version which lets me boot is
something like the following code inside scripts/init-premount/udev:

,---- [ snippet of scripts/init-premount/udev ]
| if grep usb_storage /proc/modules ; then
|    sleep 2
| fi
|
| udevsettle || true
|
| if grep -e ehci_hcd -e uhci_hcd /proc/modules ; then
|    sleep 4
| fi
`----

This works for usb at least. But I'm not really happy with the
solution either, because it does not take care of other subsystems
like firewire, scsi,...

I tried to find out what other distributions do and I like the
approaches of for example OLPC and SuSE. They use an udev rule for
creating the /dev/root device as an symlink to the main device,
like:

  SUBSYSTEM=="block", SYSFS{dev}=="$major:$minor", SYMLINK+="root"

I tried to adopt the code for Debian's initramfs-tools but udev does
not work as I expect it to (I do not find any devices inside /dev
created by udev - huh?!) so I could not resolve the issue so far. :(

More details about above implementation can be found in the mkinitrd
code of SuSE and /init of OLPC, I've uploaded it for you:

  http://grml.org/tmp/mkinitrd.suse
  http://grml.org/tmp/init.olpc

Some questions so I can go on in debugging:

Who is responsible for creating /dev/root right now in
initramfs-tools if parse_numeric code isn't used (the code is
executed only when lilo is used and then /dev/root is created
manually by mknod)?

Are udev rules in /etc/udev/udev.rules or
/etc/udev/rules.d/010-foobar.rules supposed to work? How do I add my
own rules (like the SYMLINK+="root" code) so they are used?  When
booting fails and I'm dropped to busybox, /dev is a tmpfs but nearly
empty (only the code stuff like /dev/null and /dev/tty* is present,
so no udev generated devices around). Is this by intention or not?
What might be wrong here?

Any further tips, hints,... what I could try?

regards,
-mika-
-- 
 ,'"`.         http://www.michael-prokop.at/
(  grml.org -» Linux Live-CD for texttool-users and sysadmins
 `._,'         http://www.grml.org/
[Message part 2 (application/pgp-signature, inline)]

Message sent on to Sven Luther <luther@debian.org>:
Bug#401916. Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian kernel team <debian-kernel@lists.debian.org>:
Bug#401916; Package initramfs-tools. Full text and rfc822 format available.

Acknowledgement sent to David Härdeman <david@hardeman.nu>:
Extra info received and forwarded to list. Copy sent to Debian kernel team <debian-kernel@lists.debian.org>. Full text and rfc822 format available.

Message #52 received at 401916@bugs.debian.org (full text, mbox):

From: David Härdeman <david@hardeman.nu>
To: Michael Prokop <mika@grml.org>
Cc: maximilian attems <maks@sternwelten.at>, 401916@bugs.debian.org, 401916-submitter@bugs.debian.org
Subject: Re: Bug#401916:
Date: Tue, 6 Feb 2007 19:09:33 +0100
On Tue, Feb 06, 2007 at 11:14:34AM +0100, Michael Prokop wrote:
>* David Härdeman <david@hardeman.nu> [20070201 18:08]:
>>  On Thu, Feb 01, 2007 at 05:16:11PM +0100, maximilian attems wrote:
>> > On Thu, Feb 01, 2007 at 04:38:03PM +0100, David Härdeman wrote:
>> >> So, as a workaround for Etch until this is fixed (presumably by upstream
>> >> changes to udev and/or the kernel), how about changing the following lines
>> >> in the udev initramfs script:
>> >>   udevtrigger
>> >>   udevsettle || true
>> >> to something like this:
>> >>   udevtrigger
>> >>   udevsettle || true
>> >>   while ps | grep -q "[usb-stor-scan]"; do
>> >>       sleep 1;
>> >>   done
>> >>   while ps | grep -q "[scsi_scan_.*]"; do
>> >>       sleep 1;
>> >>   done
>> >>   udevsettle || true
>
>Ok, after running several different tests: nope, this does not fix
>the problem. The usb stuff is running very asynchron. :(
>...
>I tried to find out what other distributions do and I like the
>approaches of for example OLPC and SuSE. They use an udev rule for
>creating the /dev/root device as an symlink to the main device,
>like:
>
>  SUBSYSTEM=="block", SYSFS{dev}=="$major:$minor", SYMLINK+="root"
>
>I tried to adopt the code for Debian's initramfs-tools but udev does
>not work as I expect it to (I do not find any devices inside /dev
>created by udev - huh?!) so I could not resolve the issue so far. :(

Unfortunately this wouldn't work because scripts which are independent 
of udev might also bring up the root partition (e.g. lvm, evms, 
cryptsetup). At least that is my understanding...

>...
>Any further tips, hints,... what I could try?

Could you try these lines in the udev script and then mail the contents 
of /begin.ps, /middle.ps and /finish.ps? It would be interesting to see 
if we can find out why the previously suggested approach didn't work:

udevtrigger
udevsettle || true
ps > /begin.ps
while ps | grep -q "usb-stor-scan"; do
 sleep 1;
done
while ps | grep -q "scsi_scan_"; do
 sleep 1;
done
ps > /middle.ps
udevsettle || true
ps > /finish.ps


-- 
David Härdeman



Message sent on to Sven Luther <luther@debian.org>:
Bug#401916. Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian kernel team <debian-kernel@lists.debian.org>:
Bug#401916; Package initramfs-tools. Full text and rfc822 format available.

Acknowledgement sent to David Härdeman <david@hardeman.nu>:
Extra info received and forwarded to list. Copy sent to Debian kernel team <debian-kernel@lists.debian.org>. Full text and rfc822 format available.

Message #60 received at 401916@bugs.debian.org (full text, mbox):

From: David Härdeman <david@hardeman.nu>
To: 401916@bugs.debian.org
Cc: mika@grml.org, 401916-submitter@bugs.debian.org
Subject: Re: bug #401916
Date: Wed, 14 Feb 2007 10:08:10 +0100 (CET)
Have any of you guys who can reproduce this been able to do the additional
tests suggested in the bug report yet? This is one of the few remaining RC
bugs which is present in both Etch and Sid so it would be nice to make
some progress...

-- 
David Härdeman




Message sent on to Sven Luther <luther@debian.org>:
Bug#401916. Full text and rfc822 format available.

Forcibly Merged 366175 401916. Request was from David Härdeman <david@hardeman.nu> to control@bugs.debian.org. Full text and rfc822 format available.

Tags removed: moreinfo Request was from David Härdeman <david@hardeman.nu> to control@bugs.debian.org. Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian kernel team <debian-kernel@lists.debian.org>:
Bug#401916; Package initramfs-tools. Full text and rfc822 format available.

Acknowledgement sent to Michael Prokop <mika@grml.org>:
Extra info received and forwarded to list. Copy sent to Debian kernel team <debian-kernel@lists.debian.org>. Full text and rfc822 format available.

Message #72 received at 401916@bugs.debian.org (full text, mbox):

From: Michael Prokop <mika@grml.org>
To: David Härdeman <david@hardeman.nu>
Cc: maximilian attems <maks@sternwelten.at>, 401916@bugs.debian.org, 401916-submitter@bugs.debian.org
Subject: Re: Bug#401916:
Date: Wed, 14 Feb 2007 11:02:12 +0100
[Message part 1 (text/plain, inline)]
* David Härdeman <david@hardeman.nu> [20070206 19:15]:
>  On Tue, Feb 06, 2007 at 11:14:34AM +0100, Michael Prokop wrote:

> > Any further tips, hints,... what I could try?

>  Could you try these lines in the udev script and then mail the contents of 
>  /begin.ps, /middle.ps and /finish.ps? It would be interesting to see if we can 
>  find out why the previously suggested approach didn't work:

>  udevtrigger
>  udevsettle || true
>  ps > /begin.ps
>  while ps | grep -q "usb-stor-scan"; do
>    sleep 1;
>  done
>  while ps | grep -q "scsi_scan_"; do
>    sleep 1;
>  done
>  ps > /middle.ps
>  udevsettle || true
>  ps > /finish.ps

Done that. I've taken screenshots with the digicam (sorry, was the
easiest way for me and I'm a little bit in a hurry right now):

  http://dufo.tugraz.at/~prokop/initramfs/

regards,
-mika-
[Message part 2 (application/pgp-signature, inline)]

Message sent on to Sven Luther <luther@debian.org>:
Bug#401916. Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian kernel team <debian-kernel@lists.debian.org>:
Bug#401916; Package initramfs-tools. Full text and rfc822 format available.

Acknowledgement sent to David Härdeman <david@hardeman.nu>:
Extra info received and forwarded to list. Copy sent to Debian kernel team <debian-kernel@lists.debian.org>. Full text and rfc822 format available.

Message #80 received at 401916@bugs.debian.org (full text, mbox):

From: David Härdeman <david@hardeman.nu>
To: "Michael Prokop" <mika@grml.org>
Cc: "maximilian attems" <maks@sternwelten.at>, 401916@bugs.debian.org, 401916-submitter@bugs.debian.org
Subject: Re: Bug#401916:
Date: Wed, 14 Feb 2007 14:25:21 +0100 (CET)
On Wed, February 14, 2007 11:02, Michael Prokop said:
> * David Härdeman <david@hardeman.nu> [20070206 19:15]:
>>  udevtrigger
>>  udevsettle || true
>>  ps > /begin.ps
>>  while ps | grep -q "usb-stor-scan"; do
>>    sleep 1;
>>  done
>>  while ps | grep -q "scsi_scan_"; do
>>    sleep 1;
>>  done
>>  ps > /middle.ps
>>  udevsettle || true
>>  ps > /finish.ps
>
> Done that. I've taken screenshots with the digicam (sorry, was the
> easiest way for me and I'm a little bit in a hurry right now):
>
>   http://dufo.tugraz.at/~prokop/initramfs/

Images is fine, thanks. Unfortunately the ps ax output is the same each
time so it is no surprise that my approach doesn't work. I do however have
another theory, it seems that it can take a sec or two between the loading
of usb-storage and the usb-stor-scan thread to be created...in order to
test this further, could you please replace the above parts with:

udevtrigger
udevsettle || true
cat /proc/modules > /modules.txt

And provide me with the contents of modules.txt (the digicam method is fine)

Could you also provide the output of "ps ax" once the system is up and
running?

-- 
David Härdeman




Message sent on to Sven Luther <luther@debian.org>:
Bug#401916. Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian kernel team <debian-kernel@lists.debian.org>:
Bug#401916; Package initramfs-tools. Full text and rfc822 format available.

Acknowledgement sent to David Härdeman <david@hardeman.nu>:
Extra info received and forwarded to list. Copy sent to Debian kernel team <debian-kernel@lists.debian.org>. Full text and rfc822 format available.

Message #88 received at 401916@bugs.debian.org (full text, mbox):

From: David Härdeman <david@hardeman.nu>
To: 401916@bugs.debian.org
Subject: Bug 401916: analysis and suggested solution
Date: Fri, 16 Feb 2007 16:28:07 +0100 (CET)
I've spent more time researching this by reading kernel code, checking the
boot process of other distros and trolling through mailing list archives
and I think I have a pretty good picture of the problem now.



Description:

Basically udevsettle will return once all modules have been loaded and no
more uevents are pending. "all modules" include e.g. scsi host drivers and
usb host drivers. The problem is that even if a module has been loaded for
a usb host which has a storage device attached, the usb host driver will
not emit uevents for the device immediately. Instead the scanning is done
asynchronously and might take an arbitrary amount of time (based on things
like the reset-time of the storage device, which can be several seconds,
the number of hubs between the host and the device, etc).

The same goes for several other buses (e.g. SCSI, Firewire, fibre-channel,
etc), and we won't be able to solve it completely by watching kernel
threads (the approach that I tried in earlier mails to the same BR).



Short-term solution:

Therefore, I think the best short-term solution (considering the
ever-impending Etch release) would be to add the "root_wait=" boot
parameter so that affected users can set the timeout value manually. If
that parameter was added, and documented in the release docs, the severity
of these bugs could be downgraded (imho).

Alternatively, or additionally, the scripts could check whether one of
several "problematic" modules have been loaded when udevsettle returns and
if so, sleep a couple of extra seconds (most other distros that take this
approach seem to wait around 6 - 10 seconds). The problem is that the list
of problematic modules is potentially huge (see list of buses above)



Long-term solution:

In the long term (post-Etch), I think something like the following might
be a good solution:

Take all scripts under /usr/share/initramfs-tools/scripts/local-top/ that
setup block devices (i.e. cryptsetup, lvm, evms, etc), and split them in
two, a udev rule snippet and a script.

The udev rule snippet would list the devices that this particular script
is interested in, and tell udev to call the script whenever such a device
node is created.

The script is basically the old script with minor changes so that it takes
a device node as argument, and also so that it doesn't preserve any state
between invocations.

Then the main init script is changed to sleep until $ROOT (not /dev/root
but whatever is set as the $ROOT variable) appears



Advantages of the long-term approach:

there will be no more sleeping than necessary
everything will be asynchronous
there will be no need to specify dependencies between the
/usr/share/initramfs-tools/scripts/local-top/ scripts

The last one might seem minor, but it actually makes the system much
simpler. Right now it is not possible to support both crypto-on-lvm and
lvm-on-crypto without duplicating the lvm functionality in the cryptsetup
initramfs script (as you can tell initramfs to run lvm before or after
cryptsetup, but not both).



Example:

Let's say we have the scripts "lvm", "cryptsetup" and "md" in
/usr/share/initramfs-tools/scripts/blockdev-scripts/

Each script has a udev rule snippet in
/usr/share/initramfs-tools/scripts/blockdev-rules/

Most probably these rule snippets would be something like (this is
probably not a valid udev rule, I can't check the syntax right now):
KERNEL="[sh]d[a-z]",
PROGRAM="/usr/share/initramfs-tools/scripts/blockdev-rules/md"

Let's say that /dev/sda1 is detected.

udev will then use its rules to execute
/usr/share/initramfs-tools/scripts/blockdev-scripts/lvm which will check
the device, realize it's no lvm pv and exit

the same thing then happens for the cryptsetup script

the md script recognizes /dev/sda1 as a raid partition, but it is missing
an additional device, so no action is taken

Later, /dev/sdb1 is detected.

udev calls the lvm script again, which exits again

the same thing then happends for the cryptsetup script

the md script recognizes /dev/sdb1 as a raid partition, and /dev/sda1 is
the other part of the raid device, so the device is setup and a new uevent
is triggered

in response, udev creates /dev/md1 and starts going through the scripts again

udev calls the lvm script again, which exits again

udev calls the cryptsetup script which recognizes /dev/md1 as a crypto
device, prompts for the password and sets it up, this generates another
uevent

in response, udev creates /dev/mapper/cryptroot and starts going through
the scripts again

udev calls the lvm script again, which recognizes /dev/mapper/cryptroot as
a lvm pv and sets up the vg and its lv's

the lv's generate new uevents

in response, udev creates (among others) /dev/mapper/mainvg-mainlv

init notices this and boot continues



Phew, this mail became much longer than expected....so whaddaya think Maks?

-- 
David Härdeman





Information forwarded to debian-bugs-dist@lists.debian.org, Debian kernel team <debian-kernel@lists.debian.org>:
Bug#401916; Package initramfs-tools. Full text and rfc822 format available.

Acknowledgement sent to Michael Prokop <mika@grml.org>:
Extra info received and forwarded to list. Copy sent to Debian kernel team <debian-kernel@lists.debian.org>. Full text and rfc822 format available.

Message #93 received at 401916@bugs.debian.org (full text, mbox):

From: Michael Prokop <mika@grml.org>
To: David Härdeman <david@hardeman.nu>
Cc: maximilian attems <maks@sternwelten.at>, 401916@bugs.debian.org, 401916-submitter@bugs.debian.org
Subject: Re: Bug#401916:
Date: Sun, 18 Feb 2007 23:31:58 +0100
[Message part 1 (text/plain, inline)]
* David Härdeman <david@hardeman.nu> [20070214 15:15]:

> Images is fine, thanks. Unfortunately the ps ax output is the same each
> time so it is no surprise that my approach doesn't work. I do however have
> another theory, it seems that it can take a sec or two between the loading
> of usb-storage and the usb-stor-scan thread to be created...in order to
> test this further, could you please replace the above parts with:

> udevtrigger
> udevsettle || true
> cat /proc/modules > /modules.txt

> And provide me with the contents of modules.txt (the digicam method is fine)

> Could you also provide the output of "ps ax" once the system is up and
> running?

Sure. There we go:

  http://grml.org/initramfs/

regards,
-mika-
[Message part 2 (application/pgp-signature, inline)]

Message sent on to Sven Luther <luther@debian.org>:
Bug#401916. Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian kernel team <debian-kernel@lists.debian.org>:
Bug#401916; Package initramfs-tools. Full text and rfc822 format available.

Acknowledgement sent to maximilian attems <maks@stro.at>:
Extra info received and forwarded to list. Copy sent to Debian kernel team <debian-kernel@lists.debian.org>. Full text and rfc822 format available.

Message #101 received at 401916@bugs.debian.org (full text, mbox):

From: maximilian attems <maks@stro.at>
To: David Härdeman <david@hardeman.nu>, 401916@bugs.debian.org
Subject: Re: Bug#401916: Bug 401916: analysis and suggested solution
Date: Mon, 19 Feb 2007 19:21:08 +0100
heya david,

thanks for your excellent writeup.
yes i fully agree with your analysis,
will just followup on small nits..

On Fri, 16 Feb 2007, David Härdeman wrote:

> Short-term solution:
> 
> Therefore, I think the best short-term solution (considering the
> ever-impending Etch release) would be to add the "root_wait=" boot
> parameter so that affected users can set the timeout value manually. If
> that parameter was added, and documented in the release docs, the severity
> of these bugs could be downgraded (imho).

well we already check the rootdelay variable and it could easily be
exported and checked by the udev hook.
please no new boot variables. also aboves is the original meaning of
rootdelay, just currently "perverted" it's usage.
so yes this can be done easily.
 
> Alternatively, or additionally, the scripts could check whether one of
> several "problematic" modules have been loaded when udevsettle returns and
> if so, sleep a couple of extra seconds (most other distros that take this
> approach seem to wait around 6 - 10 seconds). The problem is that the list
> of problematic modules is potentially huge (see list of buses above)

additionally sounds like a good idea, plus an extra udevsettle call.
please cook up a patch for mika.
 
> Long-term solution:
> 
> In the long term (post-Etch), I think something like the following might
> be a good solution:
> 
> Take all scripts under /usr/share/initramfs-tools/scripts/local-top/ that
> setup block devices (i.e. cryptsetup, lvm, evms, etc), and split them in
> two, a udev rule snippet and a script.
> 
> The udev rule snippet would list the devices that this particular script
> is interested in, and tell udev to call the script whenever such a device
> node is created.
> 
> The script is basically the old script with minor changes so that it takes
> a device node as argument, and also so that it doesn't preserve any state
> between invocations.
> 
> Then the main init script is changed to sleep until $ROOT (not /dev/root
> but whatever is set as the $ROOT variable) appears

i agree that this was a possible and probable plan i thought of.
disadvantage currently you can exchange udev with some simple hotplug
script out of initramfs-tools and everything will work fine.
also the idea is to have an MODULES=MOST target that would
just add/run the needed modules and thus not include udev,
than aboves approach is in trouble.
so i'd put that up for discussion and we'll have enough time
to figure that out postetch.
 
happy to read you soon Alphix!
beeing on a conference didn't let me respond to your mail
immediately, sorry.

all the best
maks



Information forwarded to debian-bugs-dist@lists.debian.org, Debian kernel team <debian-kernel@lists.debian.org>:
Bug#401916; Package initramfs-tools. Full text and rfc822 format available.

Acknowledgement sent to David Härdeman <david@hardeman.nu>:
Extra info received and forwarded to list. Copy sent to Debian kernel team <debian-kernel@lists.debian.org>. Full text and rfc822 format available.

Message #106 received at 401916@bugs.debian.org (full text, mbox):

From: David Härdeman <david@hardeman.nu>
To: maximilian attems <maks@stro.at>
Cc: 401916@bugs.debian.org, mika@grml.org
Subject: Re: Bug#401916: Bug 401916: analysis and suggested solution
Date: Mon, 19 Feb 2007 21:22:55 +0100
[Message part 1 (text/plain, inline)]
On Mon, Feb 19, 2007 at 07:21:08PM +0100, maximilian attems wrote:
>heya david,

Hey Maks :)

>On Fri, 16 Feb 2007, David Härdeman wrote:
>> Short-term solution:
>> 
>> Therefore, I think the best short-term solution (considering the
>> ever-impending Etch release) would be to add the "root_wait=" boot
>> parameter so that affected users can set the timeout value manually. If
>> that parameter was added, and documented in the release docs, the severity
>> of these bugs could be downgraded (imho).
>
>well we already check the rootdelay variable and it could easily be
>exported and checked by the udev hook.
>please no new boot variables. also aboves is the original meaning of
>rootdelay, just currently "perverted" it's usage.
>so yes this can be done easily.

Oh, I missed that variable...I've written a patch now to export it.

>> Alternatively, or additionally, the scripts could check whether one of
>> several "problematic" modules have been loaded when udevsettle returns and
>> if so, sleep a couple of extra seconds (most other distros that take this
>> approach seem to wait around 6 - 10 seconds). The problem is that the list
>> of problematic modules is potentially huge (see list of buses above)
>
>additionally sounds like a good idea, plus an extra udevsettle call.
>please cook up a patch for mika.

I've attached a patch against the udev and initramfs-tools source 
packages that implement the following changes...please review:

1) ROOTDELAY is exported by initramfs-tools and used in udev if set

2) Checks in udev for scsi/firewire/usb have been added and will add 10 
  seconds of sleep if found

3) The module scsi_wait_scan will be loaded by udev if scsi is detected, 
  modprobe should only return from loading that module once all scsi 
  busses have been scanned (I found that module yesterday...pretty 
  nifty band-aid solution to the problem, does not help with 
  usb/firewire though).

The only problem with the approach is that a large majority of all 
machines have usb which means that we'll slow down the boot for all 
those machines even though a small minority are affected.

Thanks to Mika for the preliminary testing done so far, it has helped my 
understanding of the underlying problem...

>> Long-term solution:
>>...
>> Take all scripts under /usr/share/initramfs-tools/scripts/local-top/ that
>> setup block devices (i.e. cryptsetup, lvm, evms, etc), and split them in
>> two, a udev rule snippet and a script.
>>...
>> Then the main init script is changed to sleep until $ROOT (not /dev/root
>> but whatever is set as the $ROOT variable) appears
>
>i agree that this was a possible and probable plan i thought of.
>disadvantage currently you can exchange udev with some simple hotplug
>script out of initramfs-tools and everything will work fine.

If you want a static setup you could still call all those scripts with 
some static arguments (e.g. /dev/hda, /dev/sda)

>also the idea is to have an MODULES=MOST target that would
>just add/run the needed modules and thus not include udev,
>than aboves approach is in trouble.

How would MODULES=MOST create stuff under /dev then? 

>so i'd put that up for discussion and we'll have enough time
>to figure that out postetch.

Agreed.

-- 
David Härdeman
[401916-initramfs-tools-v1.patch (text/x-diff, attachment)]
[401916-udev-v1.patch (text/x-diff, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian kernel team <debian-kernel@lists.debian.org>:
Bug#401916; Package initramfs-tools. Full text and rfc822 format available.

Acknowledgement sent to Frans Pop <elendil@planet.nl>:
Extra info received and forwarded to list. Copy sent to Debian kernel team <debian-kernel@lists.debian.org>. Full text and rfc822 format available.

Message #111 received at 401916@bugs.debian.org (full text, mbox):

From: Frans Pop <elendil@planet.nl>
To: 401916@bugs.debian.org
Subject: Re: Bug#401916: Bug 401916: analysis and suggested solution
Date: Mon, 19 Feb 2007 21:41:47 +0100
[Message part 1 (text/plain, inline)]
On Monday 19 February 2007 21:22, David Härdeman wrote:
> The only problem with the approach is that a large majority of all
> machines have usb which means that we'll slow down the boot for all
> those machines even though a small minority are affected.

That's a very, very ugly solution then. I'd almost say it's unacceptable 
to add more than 1, maybe 2 seconds for something like this.
Is there really no way to avoid that?

Note that you will get loads of bug reports complaining about "long pause 
during boot" if you do this. I know from experience how completely 
annoying such pauses are (see #401352).
[Message part 2 (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian kernel team <debian-kernel@lists.debian.org>:
Bug#401916; Package initramfs-tools. Full text and rfc822 format available.

Acknowledgement sent to David Härdeman <david@hardeman.nu>:
Extra info received and forwarded to list. Copy sent to Debian kernel team <debian-kernel@lists.debian.org>. Full text and rfc822 format available.

Message #116 received at 401916@bugs.debian.org (full text, mbox):

From: David Härdeman <david@hardeman.nu>
To: 401916@bugs.debian.org
Cc: elendil@planet.nl
Subject: Re: Bug#401916: Bug 401916: analysis and suggested solution
Date: Mon, 19 Feb 2007 21:59:00 +0100
Frans Pop wrote:
>On Monday 19 February 2007 21:22, David Härdeman wrote:
>> The only problem with the approach is that a large majority of all
>> machines have usb which means that we'll slow down the boot for all
>> those machines even though a small minority are affected.
> 
> That's a very, very ugly solution then. I'd almost say it's unacceptable 
> to add more than 1, maybe 2 seconds for something like this.
> Is there really no way to avoid that?

Of course there is, I described it earlier in the bug log - do not add 
any timeout but document the "rootdelay" parameter in the release notes 
and let affected users set it to an appropriate value themselves (and 
there's a good long-term solution as well...but you'll have to read the 
BR for that one :))

-- 
David Härdeman



Information forwarded to debian-bugs-dist@lists.debian.org, Debian kernel team <debian-kernel@lists.debian.org>:
Bug#401916; Package initramfs-tools. Full text and rfc822 format available.

Acknowledgement sent to maximilian attems <max@stro.at>:
Extra info received and forwarded to list. Copy sent to Debian kernel team <debian-kernel@lists.debian.org>. Full text and rfc822 format available.

Message #121 received at 401916@bugs.debian.org (full text, mbox):

From: maximilian attems <max@stro.at>
To: Frans Pop <elendil@planet.nl>, 401916@bugs.debian.org
Cc: David Härdeman <david@hardeman.nu>
Subject: Re: Bug#401916: Bug 401916: analysis and suggested solution
Date: Mon, 19 Feb 2007 22:44:10 +0100
Quoting Frans Pop <elendil@planet.nl>:

> On Monday 19 February 2007 21:22, David Härdeman wrote:
> > The only problem with the approach is that a large majority of all
> > machines have usb which means that we'll slow down the boot for all
> > those machines even though a small minority are affected.
>
> That's a very, very ugly solution then. I'd almost say it's unacceptable
> to add more than 1, maybe 2 seconds for something like this.
> Is there really no way to avoid that?
>
> Note that you will get loads of bug reports complaining about "long pause
> during boot" if you do this. I know from experience how completely
> annoying such pauses are (see #401352).
>


quickly replying via a strange webinterface from a strange "internet" access.
anyway you must have misunderstood David, the timeout would only happen
if you have usb||firewire storage plugged in.

and i agree that 10 seconds is long but other distro do the same apparently.
we might cut it to 6 or 7.

best regards

-- 
maks



Information forwarded to debian-bugs-dist@lists.debian.org, Debian kernel team <debian-kernel@lists.debian.org>:
Bug#401916; Package initramfs-tools. Full text and rfc822 format available.

Acknowledgement sent to maximilian attems <max@stro.at>:
Extra info received and forwarded to list. Copy sent to Debian kernel team <debian-kernel@lists.debian.org>. Full text and rfc822 format available.

Message #126 received at 401916@bugs.debian.org (full text, mbox):

From: maximilian attems <max@stro.at>
To: David Härdeman <david@hardeman.nu>, 401916@bugs.debian.org
Subject: Re: Bug#401916: Bug 401916: analysis and suggested solution
Date: Mon, 19 Feb 2007 23:02:10 +0100
Bonsoir David!

ok back after reading some code. :)


Quoting David Härdeman <david@hardeman.nu>:

> Oh, I missed that variable...I've written a patch now to export it.

yup ack.

> I've attached a patch against the udev and initramfs-tools source
> packages that implement the following changes...please review:
>
> 1) ROOTDELAY is exported by initramfs-tools and used in udev if set

cool.
i'll apply tomorrow and look to push that for 0.85f

> 2) Checks in udev for scsi/firewire/usb have been added and will add 10
>    seconds of sleep if found

hmm this seems to affect any modern board,
so urrgs.
but your grep on the usb_storage thread was not successfull,
so maybe we need here build depend logic?!?

> 3) The module scsi_wait_scan will be loaded by udev if scsi is detected,
>    modprobe should only return from loading that module once all scsi
>    busses have been scanned (I found that module yesterday...pretty
>    nifty band-aid solution to the problem, does not help with
>    usb/firewire though).

ack, but not for etch:
The relevant commit happend for 2.6.20 with the note:
    "This patch only handles drivers which call scsi_scan_host.
     Fibre Channel, SAS, SATA, USB and Firewire all need additional work."

so it would already be of a help for uname = 2.6.20.
willy was pushing this work, so we'd have the expertise for a postetch
kernel fixes.

> How would MODULES=MOST create stuff under /dev then?
oot
what about static dev.. ;)


happy night
maks



Information forwarded to debian-bugs-dist@lists.debian.org, Debian kernel team <debian-kernel@lists.debian.org>:
Bug#401916; Package initramfs-tools. Full text and rfc822 format available.

Acknowledgement sent to Michael Prokop <mika@grml.org>:
Extra info received and forwarded to list. Copy sent to Debian kernel team <debian-kernel@lists.debian.org>. Full text and rfc822 format available.

Message #131 received at 401916@bugs.debian.org (full text, mbox):

From: Michael Prokop <mika@grml.org>
To: David Härdeman <david@hardeman.nu>
Cc: maximilian attems <maks@stro.at>, 401916@bugs.debian.org
Subject: Re: Bug#401916: Bug 401916: analysis and suggested solution
Date: Mon, 19 Feb 2007 23:36:29 +0100
[Message part 1 (text/plain, inline)]
* David Härdeman <david@hardeman.nu> [20070219 22:15]:

>  I've attached a patch against the udev and initramfs-tools source packages 
>  that implement the following changes...please review:

>  1) ROOTDELAY is exported by initramfs-tools and used in udev if set

>  2) Checks in udev for scsi/firewire/usb have been added and will add 10   
>  seconds of sleep if found

>  3) The module scsi_wait_scan will be loaded by udev if scsi is detected,   
>  modprobe should only return from loading that module once all scsi   busses 
>  have been scanned (I found that module yesterday...pretty   nifty band-aid 
>  solution to the problem, does not help with   usb/firewire though).

>  The only problem with the approach is that a large majority of all machines 
>  have usb which means that we'll slow down the boot for all those machines even 
>  though a small minority are affected.

ACK

>  Thanks to Mika for the preliminary testing done so far, it has helped my 
>  understanding of the underlying problem...

You are welcome.

[...]
> +# Check for problematic devices
> +problem=0
> +
> +# USB / FireWire
> +if $(grep -q "usb\|ieee1394" /proc/devices); then
> +	problem=1
> +fi

How about:

if $(ps | grep -q usb-storage); then
   problem=1
fi

This way only boxes with usb-storage are affected by the booting
delay and not all the boxes with for example an usb input device
like an usb mouse.

I just verified my "ps...usb-storage"-code: works as intented and
booting from usb works fine then.

I'm not sure about the firewire testcase, but the

  if $(grep -q "ieee1394" /proc/devices); then...

should be ok. (JFTR: I can test booting via firewire as well once,
just running out of time right now.)

[...]
> +if [ ${slumber} -gt 0 ]; then
> +       log_begin_msg "Waiting for additional devices..."

The log_begin_msg call fails (don't ask me why, had no time for
further debugging and locating this bug costed me some minutes
already) and booting failed due to use of 'set -e' in the script
then. Changing the "log_begin_msg" to "echo" fixed the problem.

regards,
-mika-
[Message part 2 (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian kernel team <debian-kernel@lists.debian.org>:
Bug#401916; Package initramfs-tools. Full text and rfc822 format available.

Acknowledgement sent to David Härdeman <david@hardeman.nu>:
Extra info received and forwarded to list. Copy sent to Debian kernel team <debian-kernel@lists.debian.org>. Full text and rfc822 format available.

Message #136 received at 401916@bugs.debian.org (full text, mbox):

From: David Härdeman <david@hardeman.nu>
To: maximilian attems <max@stro.at>
Cc: 401916@bugs.debian.org
Subject: Re: Bug#401916: Bug 401916: analysis and suggested solution
Date: Tue, 20 Feb 2007 00:29:20 +0100
On Mon, Feb 19, 2007 at 11:02:10PM +0100, maximilian attems wrote:
>Quoting David Härdeman <david@hardeman.nu>:
>> I've attached a patch against the udev and initramfs-tools source
>> packages that implement the following changes...please review:
>>...
>> 2) Checks in udev for scsi/firewire/usb have been added and will add 10
>>    seconds of sleep if found
>
>hmm this seems to affect any modern board,
>so urrgs.

Yes...urgh

>but your grep on the usb_storage thread was not successfull,
>so maybe we need here build depend logic?!?

I've realised that usb_storage thread grepping / usb_storage module 
grepping will not work because the usb-storage module is loaded 
asynchronously and udevsettle will return when the usb host driver 
is loaded, not when the usb_storage driver has been loaded. The 
usb-storage driver might be loaded at an arbitrary time later...and the 
same goes for the kernel scanning threads.

On most machines with most usb devices this apparently takes place fast 
enought to work, on Mika's it doesn't.

In addition, the grepping would not solve the more generic case 
(firewire, sas, fibre channel, you name it).

I'm still seeing three possible short-term fixes:

Auto-decide that scsi/usb/whatever is in use and sleep a couple of 
seconds

Let the affected users specify the sleep interval using the rootdelay 
parameter

Add another parameter in addition to rootdelay...let's call it 
rootdelaydev, then affected users can set that parameter to something 
sane (e.g. /dev/sdb) and the udev script can sleep until that dev 
appears.

None of the three options are magic bullets but rather bandaids...and 
all of them would need some documentation

>> 3) The module scsi_wait_scan will be loaded by udev if scsi is detected,
>>    modprobe should only return from loading that module once all scsi
>>    busses have been scanned (I found that module yesterday...pretty
>>    nifty band-aid solution to the problem, does not help with
>>    usb/firewire though).
>
>ack, but not for etch:
>The relevant commit happend for 2.6.20 with the note:
>    "This patch only handles drivers which call scsi_scan_host.
>     Fibre Channel, SAS, SATA, USB and Firewire all need additional work."

Oh, I missed that...darn

>so it would already be of a help for uname = 2.6.20.
>willy was pushing this work, so we'd have the expertise for a postetch
>kernel fixes.

Postetch we won't need that, since we'll implement a udev-driven 
asynchronous wait-for-root-dev-on-boot...right? :)

>> How would MODULES=MOST create stuff under /dev then?
>oot
>what about static dev.. ;)

Yuck :)

-- 
David Härdeman



Information forwarded to debian-bugs-dist@lists.debian.org, Debian kernel team <debian-kernel@lists.debian.org>:
Bug#401916; Package initramfs-tools. Full text and rfc822 format available.

Acknowledgement sent to David Härdeman <david@hardeman.nu>:
Extra info received and forwarded to list. Copy sent to Debian kernel team <debian-kernel@lists.debian.org>. Full text and rfc822 format available.

Message #141 received at 401916@bugs.debian.org (full text, mbox):

From: David Härdeman <david@hardeman.nu>
To: Michael Prokop <mika@grml.org>
Cc: maximilian attems <maks@stro.at>, 401916@bugs.debian.org
Subject: Re: Bug#401916: Bug 401916: analysis and suggested solution
Date: Tue, 20 Feb 2007 00:36:53 +0100
On Mon, Feb 19, 2007 at 11:36:29PM +0100, Michael Prokop wrote:
>* David Härdeman <david@hardeman.nu> [20070219 22:15]:
>> +# Check for problematic devices
>> +problem=0
>> +
>> +# USB / FireWire
>> +if $(grep -q "usb\|ieee1394" /proc/devices); then
>> +	problem=1
>> +fi
>
>How about:
>
>if $(ps | grep -q usb-storage); then
>   problem=1
>fi
>
>This way only boxes with usb-storage are affected by the booting
>delay and not all the boxes with for example an usb input device
>like an usb mouse.
>
>I just verified my "ps...usb-storage"-code: works as intented and
>booting from usb works fine then.

It won't work reliably because only the usb host driver is loaded once 
udevsettle exits (your screenshot at http://grml.org/initramfs/ shows 
this quite well). I'm leaning towards the rootdelay/rootdelaydev + 
documentation solution (see my mail to the BR a few minutes ago).

Let's see what maks says...

>> +if [ ${slumber} -gt 0 ]; then
>> +       log_begin_msg "Waiting for additional devices..."
>
>The log_begin_msg call fails (don't ask me why, had no time for
>further debugging and locating this bug costed me some minutes
>already) and booting failed due to use of 'set -e' in the script
>then. Changing the "log_begin_msg" to "echo" fixed the problem.

Mea culpa...the udev script needs to source /scripts/functions at the 
beginning to be able to use the log_begin_msg function

-- 
David Härdeman



Information forwarded to debian-bugs-dist@lists.debian.org, Debian kernel team <debian-kernel@lists.debian.org>:
Bug#401916; Package initramfs-tools. Full text and rfc822 format available.

Acknowledgement sent to David Härdeman <david@hardeman.nu>:
Extra info received and forwarded to list. Copy sent to Debian kernel team <debian-kernel@lists.debian.org>. Full text and rfc822 format available.

Message #146 received at 401916@bugs.debian.org (full text, mbox):

From: David Härdeman <david@hardeman.nu>
To: 401916@bugs.debian.org
Subject: Bug #401916 - any progress?
Date: Fri, 23 Feb 2007 09:20:22 +0100 (CET)
maks...any progress on this bug?

A new package which exports ROOTDELAY would be nice, then the rest can be
fixed in udev...

-- 
David Härdeman




Information forwarded to debian-bugs-dist@lists.debian.org, Debian kernel team <debian-kernel@lists.debian.org>:
Bug#401916; Package initramfs-tools. Full text and rfc822 format available.

Acknowledgement sent to maximilian attems <maks@stro.at>:
Extra info received and forwarded to list. Copy sent to Debian kernel team <debian-kernel@lists.debian.org>. Full text and rfc822 format available.

Message #151 received at 401916@bugs.debian.org (full text, mbox):

From: maximilian attems <maks@stro.at>
To: David Härdeman <david@hardeman.nu>, 401916@bugs.debian.org
Subject: Re: Bug#401916: Bug #401916 - any progress?
Date: Fri, 23 Feb 2007 12:11:46 +0100
On Fri, 23 Feb 2007, David Härdeman wrote:

> maks...any progress on this bug?

no.
latest initramfs-tools is on mentors without any #401916 yet.
 
> A new package which exports ROOTDELAY would be nice, then the rest can be
> fixed in udev...

well i don't feel that is enough.
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.

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?


sorry, really busy on a physics workshop so no code right now.
but happy about your ping!

salutations amicales
 
-- 
maks



Information forwarded to debian-bugs-dist@lists.debian.org, Debian kernel team <debian-kernel@lists.debian.org>:
Bug#401916; Package initramfs-tools. Full text and rfc822 format available.

Acknowledgement sent to David Härdeman <david@hardeman.nu>:
Extra info received and forwarded to list. Copy sent to Debian kernel team <debian-kernel@lists.debian.org>. Full text and rfc822 format available.

Message #156 received at 401916@bugs.debian.org (full text, mbox):

From: David Härdeman <david@hardeman.nu>
To: "maximilian attems" <maks@stro.at>
Cc: 401916@bugs.debian.org
Subject: Re: Bug#401916: Bug #401916 - any progress?
Date: Fri, 23 Feb 2007 13:46:08 +0100 (CET)
On Fri, February 23, 2007 12:11, maximilian attems said:
> On Fri, 23 Feb 2007, David Härdeman wrote:
>
>> maks...any progress on this bug?
>
> no.
> latest initramfs-tools is on mentors without any #401916 yet.
>
>> A new package which exports ROOTDELAY would be nice, then the rest can
>> be fixed in udev...
>
> well i don't feel that is enough.

That what is enough? Just having a sleep boot arg?

> 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?

> 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.

> sorry, really busy on a physics workshop so no code right now.
> but happy about your ping!

Good luck with your workshop

> salutations amicales

Med vänliga hälsningar.

-- 
David Härdeman




Information forwarded to debian-bugs-dist@lists.debian.org, Debian kernel team <debian-kernel@lists.debian.org>:
Bug#401916; Package initramfs-tools. Full text and rfc822 format available.

Acknowledgement sent to maximilian attems <maks@sternwelten.at>:
Extra info received and forwarded to list. Copy sent to Debian kernel team <debian-kernel@lists.debian.org>. Full text and rfc822 format available.

Message #161 received at 401916@bugs.debian.org (full text, mbox):

From: maximilian attems <maks@sternwelten.at>
To: David Härdeman <david@hardeman.nu>, 401916@bugs.debian.org
Cc: maximilian attems <maks@stro.at>
Subject: Re: Bug#401916: Bug #401916 - any progress?
Date: Fri, 23 Feb 2007 14:16:00 +0100
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.

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.
 
> > 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..
 
> > salutations amicales
> 
> Med vänliga hälsningar.

zut babelfish lacks danish features.
switching back ;)

happy greetings
maks 



Information forwarded to debian-bugs-dist@lists.debian.org, Debian kernel team <debian-kernel@lists.debian.org>:
Bug#401916; Package initramfs-tools. Full text and rfc822 format available.

Acknowledgement sent to David Härdeman <david@hardeman.nu>:
Extra info received and forwarded to list. Copy sent to Debian kernel team <debian-kernel@lists.debian.org>. Full text and rfc822 format available.

Message #166 received at 401916@bugs.debian.org (full text, mbox):

From: David Härdeman <david@hardeman.nu>
To: "maximilian attems" <maks@sternwelten.at>
Cc: 401916@bugs.debian.org
Subject: Re: Bug#401916: Bug #401916 - any progress?
Date: Fri, 23 Feb 2007 15:05:44 +0100 (CET)
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




Information forwarded to debian-bugs-dist@lists.debian.org, Debian kernel team <debian-kernel@lists.debian.org>:
Bug#401916; Package initramfs-tools. Full text and rfc822 format available.

Acknowledgement sent to maximilian attems <maks@sternwelten.at>:
Extra info received and forwarded to list. Copy sent to Debian kernel team <debian-kernel@lists.debian.org>. Full text and rfc822 format available.

Message #171 received at 401916@bugs.debian.org (full text, mbox):

From: maximilian attems <maks@sternwelten.at>
To: David Härdeman <david@hardeman.nu>
Cc: 401916@bugs.debian.org
Subject: Re: Bug#401916: Bug #401916 - any progress?
Date: Fri, 23 Feb 2007 16:28:36 +0100
On Fri, Feb 23, 2007 at 03:05:44PM +0100, David Härdeman wrote:
> 
> 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).

hmm i thought there was just from looking at the init scripts
you or mikap posted..
 
> 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?

don't remove it as the udev rootdelay is optional as bootparam.
we want a small diff too ;)
 
uups always confusing the .nu domain to the language,
bad geoip matching :-P

cya maks



Information forwarded to debian-bugs-dist@lists.debian.org, Debian kernel team <debian-kernel@lists.debian.org>:
Bug#401916; Package initramfs-tools. Full text and rfc822 format available.

Acknowledgement sent to David Härdeman <david@hardeman.nu>:
Extra info received and forwarded to list. Copy sent to Debian kernel team <debian-kernel@lists.debian.org>. Full text and rfc822 format available.

Message #176 received at 401916@bugs.debian.org (full text, mbox):

From: David Härdeman <david@hardeman.nu>
To: "maximilian attems" <maks@sternwelten.at>
Cc: 401916@bugs.debian.org
Subject: Re: Bug#401916: Bug #401916 - any progress?
Date: Fri, 23 Feb 2007 16:39:52 +0100 (CET)
On Fri, February 23, 2007 16:28, maximilian attems said:
> On Fri, Feb 23, 2007 at 03:05:44PM +0100, David Härdeman wrote:
>> 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).
>
> hmm i thought there was just from looking at the init scripts
> you or mikap posted..

No, unfortunately it seems that the times between loading the usb host
controller, loading usb-storage and spawning the usb-storage-scan thread
are all asynchronous. So we can't really know how long time we need to
wait for any of those stages.

>> 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?
>
> don't remove it as the udev rootdelay is optional as bootparam.
> we want a small diff too ;)

So just to make sure: you want the use of the rootdelay parameter to be
added to the udev script and kept in the initramfs script (i.e. used
twice)?

In that case if you specify "rootdelay=5", the boot will pause in the udev
stage and then again after the premount stage (before the actual mount).

The dual wait is probably no big deal of course...since it adds a few
seconds to some exotic boot scenarios only. I'll start working on this...

-- 
David Härdeman




Information forwarded to debian-bugs-dist@lists.debian.org, Debian kernel team <debian-kernel@lists.debian.org>:
Bug#401916; Package initramfs-tools. Full text and rfc822 format available.

Acknowledgement sent to maximilian attems <maks@sternwelten.at>:
Extra info received and forwarded to list. Copy sent to Debian kernel team <debian-kernel@lists.debian.org>. Full text and rfc822 format available.

Message #181 received at 401916@bugs.debian.org (full text, mbox):

From: maximilian attems <maks@sternwelten.at>
To: David Härdeman <david@hardeman.nu>
Cc: 401916@bugs.debian.org
Subject: Re: Bug#401916: Bug #401916 - any progress?
Date: Fri, 23 Feb 2007 16:55:00 +0100
On Fri, Feb 23, 2007 at 04:39:52PM +0100, David Härdeman wrote:
> On Fri, February 23, 2007 16:28, maximilian attems said:
> 
> No, unfortunately it seems that the times between loading the usb host
> controller, loading usb-storage and spawning the usb-storage-scan thread
> are all asynchronous. So we can't really know how long time we need to
> wait for any of those stages.

zut they were only pasted to irc it seems,
no you had the mandrake one posted, so this one might not
been on the radar yet
http://david.woodhou.se/olpc-init.txt

my current statement is that other distribution add some stupid
sleep inside on the case of some async drivers.
afair that the heuristic for the choice is done on build time.
 
> So just to make sure: you want the use of the rootdelay parameter to be
> added to the udev script and kept in the initramfs script (i.e. used
> twice)?
> 
> In that case if you specify "rootdelay=5", the boot will pause in the udev
> stage and then again after the premount stage (before the actual mount).
> 
> The dual wait is probably no big deal of course...since it adds a few
> seconds to some exotic boot scenarios only. I'll start working on this...

the dual wait only comes to play if your root doesn't show off yet
after the first round. see scripts/local:
if [ ! -e "${ROOT}" ]; then


--
maks



Information forwarded to debian-bugs-dist@lists.debian.org, Debian kernel team <debian-kernel@lists.debian.org>:
Bug#401916; Package initramfs-tools. Full text and rfc822 format available.

Acknowledgement sent to David Härdeman <david@hardeman.nu>:
Extra info received and forwarded to list. Copy sent to Debian kernel team <debian-kernel@lists.debian.org>. Full text and rfc822 format available.

Message #186 received at 401916@bugs.debian.org (full text, mbox):

From: David Härdeman <david@hardeman.nu>
To: maximilian attems <maks@sternwelten.at>
Cc: 401916@bugs.debian.org
Subject: Re: Bug#401916: Bug #401916 - any progress?
Date: Wed, 28 Feb 2007 01:35:35 +0100
[Message part 1 (text/plain, inline)]
On Fri, Feb 23, 2007 at 04:55:00PM +0100, maximilian attems wrote:
>On Fri, Feb 23, 2007 at 04:39:52PM +0100, David Härdeman wrote:
>> On Fri, February 23, 2007 16:28, maximilian attems said:
>> No, unfortunately it seems that the times between loading the usb host
>> controller, loading usb-storage and spawning the usb-storage-scan thread
>> are all asynchronous. So we can't really know how long time we need to
>> wait for any of those stages.
>
>zut they were only pasted to irc it seems,
>no you had the mandrake one posted, so this one might not
>been on the radar yet
>http://david.woodhou.se/olpc-init.txt

I've looked at it, and it also has a static sleep of a couple of seconds 
(not to mention that their target of possible boot devices is smaller)

Anyways, attached you'll find a new version of the rootdelay patch. This 
one has two improvements, first it doesn't require any changes to udev, 
second, the rootdelay parameter can now be passed as a number (of 
seconds to wait) or a device node (to wait for).

The secondary sleep (after udev, lvm, raid, etc have executed) has been 
given a static 180 seconds sleep (there really isn't that much to do 
there, either sleep or panic).

You should hopefully find this patch to be better...

-- 
David Härdeman
[initramfs-tools-0.85e-rootwait4.patch (text/x-diff, inline)]
diff -Nur initramfs-tools-0.85e-orig/init initramfs-tools-0.85e-hack/init
--- initramfs-tools-0.85e-orig/init	2006-11-03 09:03:44.000000000 +0100
+++ initramfs-tools-0.85e-hack/init	2007-02-25 19:01:16.000000000 +0100
@@ -46,6 +46,7 @@
 export debug=
 export cryptopts=${CRYPTOPTS}
 export panic
+export ROOTDELAY
 
 for x in $(cat /proc/cmdline); do
 	case $x in
diff -Nur initramfs-tools-0.85e-orig/scripts/local initramfs-tools-0.85e-hack/scripts/local
--- initramfs-tools-0.85e-orig/scripts/local	2006-10-17 09:26:59.000000000 +0200
+++ initramfs-tools-0.85e-hack/scripts/local	2007-02-25 19:42:54.000000000 +0100
@@ -13,11 +13,7 @@
 		log_begin_msg "Waiting for root file system..."
 
 		# Default delay is 180s
-		if [ -z "${ROOTDELAY}" ]; then
-			slumber=180
-		else
-			slumber=${ROOTDELAY}
-		fi
+		slumber=180
 		if [ -x /sbin/usplash_write ]; then
 			/sbin/usplash_write "TIMEOUT ${slumber}" || true
 		fi
diff -Nur initramfs-tools-0.85e-orig/scripts/local-top/lvm initramfs-tools-0.85e-hack/scripts/local-top/lvm
--- initramfs-tools-0.85e-orig/scripts/local-top/lvm	2006-08-25 15:09:28.000000000 +0200
+++ initramfs-tools-0.85e-hack/scripts/local-top/lvm	2007-02-25 19:55:56.000000000 +0100
@@ -1,6 +1,6 @@
 #!/bin/sh
 
-PREREQ="mdadm mdrun lvm2"
+PREREQ="udev_helper mdadm mdrun lvm2"
 
 prereqs()
 {
diff -Nur initramfs-tools-0.85e-orig/scripts/local-top/rootdelay initramfs-tools-0.85e-hack/scripts/local-top/rootdelay
--- initramfs-tools-0.85e-orig/scripts/local-top/rootdelay	1970-01-01 01:00:00.000000000 +0100
+++ initramfs-tools-0.85e-hack/scripts/local-top/rootdelay	2007-02-28 01:28:53.000000000 +0100
@@ -0,0 +1,49 @@
+#!/bin/sh
+
+PREREQ=""
+
+prereqs()
+{
+	echo "$PREREQ"
+}
+
+case $1 in
+# get pre-requisites
+prereqs)
+	prereqs
+	exit 0
+	;;
+esac
+
+if [ -z "$ROOTDELAY" ]; then
+	exit 0
+fi
+
+. /scripts/functions
+# If the user wants us to, we'll wait for removable devices, etc...
+# (this is after udev has been executed, but not the other scripts such as LVM)
+if [ -x /sbin/usplash_write ]; then
+	# Some versions of udev seem to wrongly treat 0 as immediate timeout
+	/sbin/usplash_write "TIMEOUT 900" || true
+fi
+
+# The rootdelay parameter can be interpreted in two ways
+if [ "${ROOTDELAY%%[^0-9]*}" = "$ROOTDELAY" ]; then
+	# 1) As a number of seconds to wait
+	log_begin_msg "Delaying setup for ${ROOTDELAY} seconds..."
+	sleep $ROOTDELAY
+	log_end_msg
+else
+	# 2) As a device node to wait for
+	if [ ! -e "$ROOTDELAY" ]; then
+		log_begin_msg "Delaying setup until ${ROOTDELAY} is present..."
+		while [ ! -e "$ROOTDELAY" ]; do
+			sleep 1
+		done
+		log_end_msg
+	fi
+fi
+
+if [ -x /sbin/usplash_write ]; then
+	/sbin/usplash_write "TIMEOUT 15" || true
+fi
diff -Nur initramfs-tools-0.85e-orig/scripts/local-top/udev_helper initramfs-tools-0.85e-hack/scripts/local-top/udev_helper
--- initramfs-tools-0.85e-orig/scripts/local-top/udev_helper	2006-07-16 21:20:10.000000000 +0200
+++ initramfs-tools-0.85e-hack/scripts/local-top/udev_helper	2007-02-25 19:32:35.000000000 +0100
@@ -1,6 +1,6 @@
 #!/bin/sh
 
-PREREQ=""
+PREREQ="rootdelay"
 
 prereqs()
 {

Tags added: patch Request was from David Härdeman <david@hardeman.nu> to control@bugs.debian.org. Full text and rfc822 format available.

Tags added: patch Request was from David Härdeman <david@hardeman.nu> to control@bugs.debian.org. Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian kernel team <debian-kernel@lists.debian.org>:
Bug#401916; Package initramfs-tools. Full text and rfc822 format available.

Acknowledgement sent to Hugo Vanwoerkom <nayabei@prodigy.net.mx>:
Extra info received and forwarded to list. Copy sent to Debian kernel team <debian-kernel@lists.debian.org>. Full text and rfc822 format available.

Message #195 received at 401916@bugs.debian.org (full text, mbox):

From: Hugo Vanwoerkom <nayabei@prodigy.net.mx>
To: 401916@bugs.debian.org
Subject: PANIC: Circular dependency
Date: Fri, 02 Mar 2007 06:30:03 -0600
Hi,

I applied initramfs-tools-0.85e-rootwait4.patch to 0.85 on Sid. 
<http://bugs.debian.org/cgi-bin/bugreport.cgi/initramfs-tools-0.85e-rootwait4.patch?bug=401916;msg=186;att=1>

I am having problems booting either with or from a USB disk and 
linux-image-2.6.18-4-486, it works about half the time.

After patching (no probs) and 'update-initramfs -u' and booting, I get 
'PANIC: Circular dependency. Exiting.' from the functions script #167.

The description of the bug and the patch sounded like it would solve my 
problem.

I don't have the problem with my own compiled 2.6.20-ck1 + yaird kernel. 
But Yaird is another story.

Regards,

Hugo Vanwoerkom



Information forwarded to debian-bugs-dist@lists.debian.org, Debian kernel team <debian-kernel@lists.debian.org>:
Bug#401916; Package initramfs-tools. Full text and rfc822 format available.

Acknowledgement sent to David Härdeman <david@hardeman.nu>:
Extra info received and forwarded to list. Copy sent to Debian kernel team <debian-kernel@lists.debian.org>. Full text and rfc822 format available.

Message #200 received at 401916@bugs.debian.org (full text, mbox):

From: David Härdeman <david@hardeman.nu>
To: nayabei@prodigy.net.mx
Cc: 401916@bugs.debian.org
Subject: Re: PANIC: Circular dependency
Date: Sun, 04 Mar 2007 01:08:58 +0100
Hugo Vanwoerkom wrote:
> After patching (no probs) and 'update-initramfs -u' and booting, I get 
> 'PANIC: Circular dependency. Exiting.' from the functions script #167.

Could you provide me with the output from 
"grep PREREQ= /usr/share/initramfs-tools/scripts/local-top/*"

-- 
David Härdeman




Information forwarded to debian-bugs-dist@lists.debian.org, Debian kernel team <debian-kernel@lists.debian.org>:
Bug#401916; Package initramfs-tools. Full text and rfc822 format available.

Acknowledgement sent to Hugo Vanwoerkom <nayabei@prodigy.net.mx>:
Extra info received and forwarded to list. Copy sent to Debian kernel team <debian-kernel@lists.debian.org>. Full text and rfc822 format available.

Message #205 received at 401916@bugs.debian.org (full text, mbox):

From: Hugo Vanwoerkom <nayabei@prodigy.net.mx>
To: 401916@bugs.debian.org
Subject: grep PREREQ=
Date: Sun, 04 Mar 2007 15:59:56 -0600
Could you provide me with the output from 
"grep PREREQ= /usr/share/initramfs-tools/scripts/local-top/*"


Script started on Sun 04 Mar 2007 03:54:57 PM CST
executing /root/.bashrc
/hdb1/usr/share/initramfs-tools/scripts/local-topSun Mar 
04-15:54:57SDA6# grep PREREQ= *
lvm:PREREQ="udev_helper mdadm mdrun lvm2"
mdrun:PREREQ="udev_helper"
rootdelay:+ PREREQ=""
udev_helper:PREREQ="rootdelay"
/hdb1/usr/share/initramfs-tools/scripts/local-topSun Mar 
04-15:55:08SDA6# exit
Script done on Sun 04 Mar 2007 03:55:34 PM CST

Hugo Vanwoerkom



Information forwarded to debian-bugs-dist@lists.debian.org, Debian kernel team <debian-kernel@lists.debian.org>:
Bug#401916; Package initramfs-tools. Full text and rfc822 format available.

Acknowledgement sent to David Härdeman <david@hardeman.nu>:
Extra info received and forwarded to list. Copy sent to Debian kernel team <debian-kernel@lists.debian.org>. Full text and rfc822 format available.

Message #210 received at 401916@bugs.debian.org (full text, mbox):

From: David Härdeman <david@hardeman.nu>
To: nayabei@prodigy.net.mx
Cc: 401916@bugs.debian.org
Subject: Re: grep PREREQ=
Date: Mon, 5 Mar 2007 12:11:53 +0100 (CET)
Hugo wrote:
> 04-15:54:57SDA6# grep PREREQ= *
> lvm:PREREQ="udev_helper mdadm mdrun lvm2"
> mdrun:PREREQ="udev_helper"
> rootdelay:+ PREREQ=""

It seems that the patch has not been applied correctly, the rootdelay line
reads '+ PREREQ=""' (i.e. still in patch format) while it should read
'PREREQ=""'.

Could you please try the patching again, and make sure that the rootdelay
file looks ok afterwards.

-- 
David Härdeman




Information forwarded to debian-bugs-dist@lists.debian.org, Debian kernel team <debian-kernel@lists.debian.org>:
Bug#401916; Package initramfs-tools. Full text and rfc822 format available.

Acknowledgement sent to David Härdeman <david@hardeman.nu>:
Extra info received and forwarded to list. Copy sent to Debian kernel team <debian-kernel@lists.debian.org>. Full text and rfc822 format available.

Message #215 received at 401916@bugs.debian.org (full text, mbox):

From: David Härdeman <david@hardeman.nu>
To: 401916@bugs.debian.org
Subject: Invalid email address?
Date: Mon, 5 Mar 2007 13:27:13 +0100 (CET)
Just for the record, mail to nayabei@prodigy.net.mx is refused with the
message "550 5.1.1 unknown or illegal alias", I hope Hugo reads the bug
report log.

-- 
David Härdeman




Information forwarded to debian-bugs-dist@lists.debian.org, Debian kernel team <debian-kernel@lists.debian.org>:
Bug#401916; Package initramfs-tools. Full text and rfc822 format available.

Acknowledgement sent to Hugo Vanwoerkom <nayabei@prodigy.net.mx>:
Extra info received and forwarded to list. Copy sent to Debian kernel team <debian-kernel@lists.debian.org>. Full text and rfc822 format available.

Message #220 received at 401916@bugs.debian.org (full text, mbox):

From: Hugo Vanwoerkom <nayabei@prodigy.net.mx>
To: 401916@bugs.debian.org
Subject: Try patching again
Date: Mon, 05 Mar 2007 14:19:20 -0600
David,

Thanks for your attention. I will patch again.
And I just noticed the email address is wrong: I changed ISP's. Sorry.
BTW To get things running with the USB disk I hardcoded a wait of 15s in 
the beginning of mountroot in /usr/share/initramfs-tools/scripts/local
That fixed things and I am up and running.

Regards,


Hugo Vanwoerkom




Severity set to `important' from `critical' Request was from maximilian attems <maks@stro.at> to control@bugs.debian.org. Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian kernel team <debian-kernel@lists.debian.org>:
Bug#401916; Package initramfs-tools. Full text and rfc822 format available.

Acknowledgement sent to David Härdeman <david@hardeman.nu>:
Extra info received and forwarded to list. Copy sent to Debian kernel team <debian-kernel@lists.debian.org>. Full text and rfc822 format available.

Message #227 received at 401916@bugs.debian.org (full text, mbox):

From: David Härdeman <david@hardeman.nu>
To: submit@bugs.debian.org
Cc: debian-release@bugs.debian.org, maks@sternwelten.at, 401916@bugs.debian.org
Subject: udev: Add support for the ROOTDELAY parameter
Date: Wed, 14 Mar 2007 02:00:38 +0100
[Message part 1 (text/plain, inline)]
Package: udev
Version: 0.105-3
Severity: normal
Tags: patch

Hi,

maks downgraded #401916 (and #366175) from RC severity with the 
understanding that something like the attached patch would be applied 
to the udev initramfs script before the release of Etch to allow people 
with affected systems some kind of manual workaround at least.

I'm not setting the severity to R-C, but I'd like to know whether others 
(maks, Marco, RM's) think this should go in?

-- 
David Härdeman

[udev-support_rootdelay.patch (text/x-diff, inline)]
diff -ur ./udev-0.105.orig/extra/initramfs.premount ./udev-0.105/extra/initramfs.premount
--- ./udev-0.105.orig/extra/initramfs.premount	2007-03-14 01:48:20.000000000 +0100
+++ ./udev-0.105/extra/initramfs.premount	2007-03-14 01:55:12.000000000 +0100
@@ -20,5 +20,17 @@
 udevtrigger
 udevsettle || true
 
+# If the rootdelay parameter has been set, we wait a bit for devices
+# like usb/firewire disks to settle
+if [ -n "$ROOTDELAY" ]; then
+	if [ -x /sbin/usplash_write ]; then
+		/sbin/usplash_write "TIMEOUT $(($ROOTDELAY + 5))"
+	fi
+	sleep $ROOTDELAY
+	if [ -x /sbin/usplash_write ]; then
+		/sbin/usplash_write "TIMEOUT 15"
+	fi
+fi
+
 # Leave udev running to process events that come in out-of-band (like USB
 # connections)


Information forwarded to debian-bugs-dist@lists.debian.org, Debian kernel team <debian-kernel@lists.debian.org>:
Bug#401916; Package initramfs-tools. Full text and rfc822 format available.

Acknowledgement sent to maximilian attems <maks@sternwelten.at>:
Extra info received and forwarded to list. Copy sent to Debian kernel team <debian-kernel@lists.debian.org>. Full text and rfc822 format available.

Message #232 received at 401916@bugs.debian.org (full text, mbox):

From: maximilian attems <maks@sternwelten.at>
To: David Härdeman <david@hardeman.nu>
Cc: debian-release@bugs.debian.org, 401916@bugs.debian.org
Subject: Re: udev: Add support for the ROOTDELAY parameter
Date: Wed, 14 Mar 2007 15:47:01 +0100
On Wed, Mar 14, 2007 at 02:00:38AM +0100, David Härdeman wrote:
> Package: udev
> Version: 0.105-3
> Severity: normal
> Tags: patch

important at least.
retitle udev: Add support for very early ROOTDELAY parameter

 
> Hi,
> 
> maks downgraded #401916 (and #366175) from RC severity with the 
> understanding that something like the attached patch would be applied 
> to the udev initramfs script before the release of Etch to allow people 
> with affected systems some kind of manual workaround at least.
> 
> I'm not setting the severity to R-C, but I'd like to know whether others 
> (maks, Marco, RM's) think this should go in?

ack
for belows patch.

the purpose is that udev is run very early and if there is an
async driver to be loaded the user has a powerful bootparam
to keep his box up.

current rootdelay kicks in to late (on root mount) and doesn't
work for lilo or md/evms/lvm root settings.

hope aboves explanation make the job for the decision to
put that in easier.

best regards
maks
 

> diff -ur ./udev-0.105.orig/extra/initramfs.premount ./udev-0.105/extra/initramfs.premount
> --- ./udev-0.105.orig/extra/initramfs.premount	2007-03-14 01:48:20.000000000 +0100
> +++ ./udev-0.105/extra/initramfs.premount	2007-03-14 01:55:12.000000000 +0100
> @@ -20,5 +20,17 @@
>  udevtrigger
>  udevsettle || true
>  
> +# If the rootdelay parameter has been set, we wait a bit for devices
> +# like usb/firewire disks to settle
> +if [ -n "$ROOTDELAY" ]; then
> +	if [ -x /sbin/usplash_write ]; then
> +		/sbin/usplash_write "TIMEOUT $(($ROOTDELAY + 5))"
> +	fi
> +	sleep $ROOTDELAY
> +	if [ -x /sbin/usplash_write ]; then
> +		/sbin/usplash_write "TIMEOUT 15"
> +	fi
> +fi
> +
>  # Leave udev running to process events that come in out-of-band (like USB
>  # connections)




Information forwarded to debian-bugs-dist@lists.debian.org, Debian kernel team <debian-kernel@lists.debian.org>:
Bug#401916; Package initramfs-tools. Full text and rfc822 format available.

Acknowledgement sent to Michael Prokop <mika@grml.org>:
Extra info received and forwarded to list. Copy sent to Debian kernel team <debian-kernel@lists.debian.org>. Full text and rfc822 format available.

Message #237 received at 401916@bugs.debian.org (full text, mbox):

From: Michael Prokop <mika@grml.org>
To: David Härdeman <david@hardeman.nu>
Cc: 401916@bugs.debian.org, 414842@bugs.debian.org
Subject: Re: Bug 401916
Date: Thu, 15 Mar 2007 00:17:33 +0100
[Message part 1 (text/plain, inline)]
* David Härdeman <david@hardeman.nu> [20070314 20:58]:

>  Feel free to install the new initramfs-tools, then apply the
>  above patch to udev, install, regenerate the initramfs image and
>  try booting with rootdelay=20 and see if it pauses 20 secs at the
>  right stage of the boot.

Ok, just verified it:

Using current version of initramfs-tools (0.85f) with current udev
and lilo plus udev-support_rootdelay.patch applied works when using
something like "rootdelay=7" as bootoption on my external USB
harddisk installation. *Without* the rootdelay option the system
definitely fails to boot (as documented in #401916 in more detail),
*with* the rootdelay option it works as expected.

JFTR: $KERNELSOURCE/Documentation/kernel-parameters.txt documents
the option as well:

|   rootdelay=  [KNL] Delay (in seconds) to pause before
|               attempting to mount the root filesystem

.. so this feature should hit Etch anyway.

Further suggestions:

It would be fine to provide some output while running the "sleep
$ROOTDELAY" so users without usplash_write are notified about this
issue as well.

If mounting the rootdevice *fails* there should be some basic
documentation available on the screen how to fix this issue.  The
rootdelay stuff should be mentioned as well as using features like
root=UUID=$UUID_OF_DEVICE (which works fine as well).

regards,
-mika-
[Message part 2 (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian kernel team <debian-kernel@lists.debian.org>:
Bug#401916; Package initramfs-tools. Full text and rfc822 format available.

Acknowledgement sent to maximilian attems <maks@sternwelten.at>:
Extra info received and forwarded to list. Copy sent to Debian kernel team <debian-kernel@lists.debian.org>. Full text and rfc822 format available.

Message #242 received at 401916@bugs.debian.org (full text, mbox):

From: maximilian attems <maks@sternwelten.at>
To: Michael Prokop <mika@grml.org>, 401916@bugs.debian.org
Cc: David Härdeman <david@hardeman.nu>, 414842@bugs.debian.org
Subject: Re: Bug#401916: Bug 401916
Date: Thu, 15 Mar 2007 00:31:40 +0100
On Thu, Mar 15, 2007 at 12:17:33AM +0100, Michael Prokop wrote:
> * David Härdeman <david@hardeman.nu> [20070314 20:58]:
> 
> >  Feel free to install the new initramfs-tools, then apply the
> >  above patch to udev, install, regenerate the initramfs image and
> >  try booting with rootdelay=20 and see if it pauses 20 secs at the
> >  right stage of the boot.
> 
> Ok, just verified it:
> 
> Using current version of initramfs-tools (0.85f) with current udev
> and lilo plus udev-support_rootdelay.patch applied works when using
> something like "rootdelay=7" as bootoption on my external USB
> harddisk installation. *Without* the rootdelay option the system
> definitely fails to boot (as documented in #401916 in more detail),
> *with* the rootdelay option it works as expected.

cool.
 
> JFTR: $KERNELSOURCE/Documentation/kernel-parameters.txt documents
> the option as well:
> 
> |   rootdelay=  [KNL] Delay (in seconds) to pause before
> |               attempting to mount the root filesystem
> 
> .. so this feature should hit Etch anyway.

yeah i know it's an official bootparam.
 
> Further suggestions:
> 
> It would be fine to provide some output while running the "sleep
> $ROOTDELAY" so users without usplash_write are notified about this
> issue as well.

well that is nice to have,
but not a killer feature we just do what the user asked aka sleep.
 
> If mounting the rootdevice *fails* there should be some basic
> documentation available on the screen how to fix this issue.  The
> rootdelay stuff should be mentioned as well as using features like
> root=UUID=$UUID_OF_DEVICE (which works fine as well).

you are overshooting here,
that is support request on some irc or mailing list.
also d-i will soon install by uuid by default.
we provide already a help message when someone gets dropped to
shell and the message gets improved for 0.87.
also we can't put too much text there otherwise the interesting
error info scrolls off, yes nobody uses serial anymore..

thanks + best regards
maks





Information forwarded to debian-bugs-dist@lists.debian.org, Debian kernel team <debian-kernel@lists.debian.org>:
Bug#401916; Package initramfs-tools. Full text and rfc822 format available.

Acknowledgement sent to Michael Prokop <mika@grml.org>:
Extra info received and forwarded to list. Copy sent to Debian kernel team <debian-kernel@lists.debian.org>. Full text and rfc822 format available.

Message #247 received at 401916@bugs.debian.org (full text, mbox):

From: Michael Prokop <mika@grml.org>
To: maximilian attems <maks@sternwelten.at>
Cc: 401916@bugs.debian.org, David Härdeman <david@hardeman.nu>, 414842@bugs.debian.org
Subject: Re: Bug#401916: Bug 401916
Date: Thu, 15 Mar 2007 08:36:59 +0100
[Message part 1 (text/plain, inline)]
* maximilian attems <maks@sternwelten.at> [20070315 01:15]:
> On Thu, Mar 15, 2007 at 12:17:33AM +0100, Michael Prokop wrote:
> > * David Härdeman <david@hardeman.nu> [20070314 20:58]:

[...]

> > It would be fine to provide some output while running the "sleep
> > $ROOTDELAY" so users without usplash_write are notified about this
> > issue as well.

> well that is nice to have,
> but not a killer feature we just do what the user asked aka sleep.

Sure, but inform the user that it's sleeping *now* for $ROOTDELAY
seconds. That's a simple "echo Delaying booting as requested via
bootoption rootdelay for $ROOTDELAY seconds now" or something like
that. Doesn't hurt anyone but informs the user what's going on
*now*.

> > If mounting the rootdevice *fails* there should be some basic
> > documentation available on the screen how to fix this issue.  The
> > rootdelay stuff should be mentioned as well as using features like
> > root=UUID=$UUID_OF_DEVICE (which works fine as well).

> you are overshooting here,
> that is support request on some irc or mailing list.
> also d-i will soon install by uuid by default.
> we provide already a help message when someone gets dropped to
> shell and the message gets improved for 0.87.
> also we can't put too much text there otherwise the interesting
> error info scrolls off, yes nobody uses serial anymore..

I'm aware of that. But "the message gets improved for 0.87" is
exactly what I requested. ;-) I don't expect to find tons of
information in the booting sequence, but *if* it fails just give the
appropriate hints how to start debugging and solving the problem in
one or two short sentences.  A system that does not boot because the
rootdevice can't be mounted is definitely a serious problem for the
user.

regards,
-mika-
[Message part 2 (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian kernel team <debian-kernel@lists.debian.org>:
Bug#401916; Package initramfs-tools. Full text and rfc822 format available.

Acknowledgement sent to "Gordon Farquharson" <gordonfarquharson@gmail.com>:
Extra info received and forwarded to list. Copy sent to Debian kernel team <debian-kernel@lists.debian.org>. Full text and rfc822 format available.

Message #252 received at 401916@bugs.debian.org (full text, mbox):

From: "Gordon Farquharson" <gordonfarquharson@gmail.com>
To: "David Härdeman" <david@hardeman.nu>
Cc: 401916@bugs.debian.org
Subject: #401916
Date: Thu, 22 Mar 2007 00:42:52 -0600
Hi David

Do you know if your patch [1] you posted to #401916 is going to make
it into etch? A few users have been asking about whether it is
possible to use an LVM root partition with an external USB drive on
the Linksys/NSLU2. I haven't tested your patch on the NSLU2, but I do
know that adding a delay before the call to vgchange in
/scripts/local-top/lvm in the initramfs allows the NSLU2 to use an LVM
root partition on a USB disk.

It is not critical because there are other issues with LVM on the
NSLU2, such as the installer runs out of memory when setting up the
LVM partitions, and one needs to recompile the second stage boot
loader to add the rootdelay parameter to the kernel command line.

Gordon

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=401916;msg=227;filename=udev-support_rootdelay.patch;att=1

-- 
Gordon Farquharson



Information forwarded to debian-bugs-dist@lists.debian.org, Debian kernel team <debian-kernel@lists.debian.org>:
Bug#401916; Package initramfs-tools. Full text and rfc822 format available.

Acknowledgement sent to David Härdeman <david@hardeman.nu>:
Extra info received and forwarded to list. Copy sent to Debian kernel team <debian-kernel@lists.debian.org>. Full text and rfc822 format available.

Message #257 received at 401916@bugs.debian.org (full text, mbox):

From: David Härdeman <david@hardeman.nu>
To: "Gordon Farquharson" <gordonfarquharson@gmail.com>
Cc: 401916@bugs.debian.org, 414842@bugs.debian.org
Subject: Re: #401916
Date: Thu, 22 Mar 2007 08:35:35 +0100 (CET)
On Thu, March 22, 2007 7:42, Gordon Farquharson said:
> Do you know if your patch [1] you posted to #401916 is going to make
> it into etch?

That patch really belongs to #414842 since it is a change to udev's scripts.

I do expect that a version of udev which fixes #414842 will make it into
Etch since #414842 is RC and the release managers seemed to agree when I
asked them. I'm not a DD so I can't take responsibility for NMU'ing udev
myself.

And for anyone following these bug reports: the rootdelay parameter is
more of a bandaid for #401916 (thus allowing its severity to be
downgraded) but it's the best we can do so shortly before release, maks
and I have been discussing some better solutions to implement post-Etch.

-- 
David Härdeman




Information forwarded to debian-bugs-dist@lists.debian.org, Debian kernel team <debian-kernel@lists.debian.org>:
Bug#401916; Package initramfs-tools. Full text and rfc822 format available.

Acknowledgement sent to md@Linux.IT (Marco d'Itri):
Extra info received and forwarded to list. Copy sent to Debian kernel team <debian-kernel@lists.debian.org>. Full text and rfc822 format available.

Message #262 received at 401916@bugs.debian.org (full text, mbox):

From: md@Linux.IT (Marco d'Itri)
To: David Härdeman <david@hardeman.nu>, 414842@bugs.debian.org
Cc: Gordon Farquharson <gordonfarquharson@gmail.com>, 401916@bugs.debian.org
Subject: Re: Bug#414842: #401916
Date: Thu, 22 Mar 2007 11:07:53 +0100
[Message part 1 (text/plain, inline)]
On Mar 22, David Härdeman <david@hardeman.nu> wrote:

> I do expect that a version of udev which fixes #414842 will make it into
> Etch since #414842 is RC and the release managers seemed to agree when I
I will upload a new package in one or two days.

-- 
ciao,
Marco
[signature.asc (application/pgp-signature, inline)]

Tags removed: patch Request was from maximilian attems <maks@debian.org> to control@bugs.debian.org. (Thu, 05 Apr 2007 17:39:02 GMT) Full text and rfc822 format available.

Merged 366175 381351 401916. Request was from maximilian attems <maks@debian.org> to control@bugs.debian.org. (Fri, 06 Apr 2007 20:33:03 GMT) Full text and rfc822 format available.

Merged 366175 381351 401916 433905 434138. Request was from maximilian attems <maks@debian.org> to control@bugs.debian.org. (Thu, 09 Aug 2007 19:27:05 GMT) Full text and rfc822 format available.

Tags removed: patch Request was from maximilian attems <maks@debian.org> to control@bugs.debian.org. (Thu, 09 Aug 2007 20:03:09 GMT) Full text and rfc822 format available.

Merged 366175 381351 401916 432534 433905 434138. Request was from maximilian attems <maks@debian.org> to control@bugs.debian.org. (Thu, 09 Aug 2007 20:03:13 GMT) Full text and rfc822 format available.

Bug marked as found in version 0.92j. Request was from Wagner Bruna <wbruna@yahoo.com> to control@bugs.debian.org. (Mon, 24 Nov 2008 16:15:08 GMT) Full text and rfc822 format available.

Bug archived. Request was from Debbugs Internal Request <owner@bugs.debian.org> to internal_control@bugs.debian.org. (Wed, 07 Jul 2010 07:30:15 GMT) Full text and rfc822 format available.

Send a report that this bug log contains spam.


Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Thu Apr 17 13:38:08 2014; Machine Name: beach.debian.org

Debian Bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.