networking script does not wait for udev to settle

[Matthias Urlichs]

Binary package hint: casper

scripts/casper-bottom/23networking calls udevtrigger. It then enumerates all existing interfaces, and then adds a few well-known ones if they do not exist already.

The problem is that there is no "udevsettle" after the "udevtrigger". If you're unlucky, the first part does not find eth0 (because it has not appeared yet). Then the module loads and finds the card -- and after that, the add-well-known-devices part skips eth0 because it is already present and thus should have been created in the first step. :-/

Ths simple solution is to add an "udevsettle":

udevtrigger -Bpci -Iclass="0x02*"
udevsettle

This problem happens to be 95% reproducible in my qemu setup.

[Colin Watson (cjwatson)]

Thanks, committed.

[robepisc (robepisc)]

Matthias, are you sure the absence of udevsettle was the origin of the problem?
Did the committed (in casper 1.79) fix actually solve your issue?

It seems to me that udevtrigger doesn't really understand the -B and -I command line options (see man udevtrigger).
And for this reason it returns an error, without actually doing nothing!

So the udevsettle fix (which is needed anyway) is useless unless the udevtrigger line is fixed too (by removing the ' -Bpci -Iclass="0x02*" ' part, I think).

Am I wrong?

[Matthias Urlichs (smurf)]

Hi,

robepisc:
> Matthias, are you sure the absence of udevsettle was the origin of the
> problem? Did the committed (in casper 1.79) fix actually solve your
> issue?
>
I have manually added the required udevsettle call to my startup script
at that position -- and yes, the issue went away.

> It seems to me that udevtrigger doesn't really understand the -B and
> -I command line options (see man udevtrigger). And for this reason it
> returns an error, without actually doing nothing!
>
Yeah, that appears to be a problem. However, I'm using Edgy here.
Edgy's udevtrigger *does* understand those options.

Seems that in Feisty, s/-B /--subsystem-match=/ and s/-I /--attr-match=/
 -- which is kindof annoying, esp. as that change wasn't even documented
in the changelogs AFAICS.

--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | <email address hidden>
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
 - -
To mortal men great loads allotted be; But of all packs no pack like poverty.
     -- Herrick

[Scott James Remnant (Canonical) (canonical-scott)]

On Thu, 2007-01-11 at 22:21 +0100, Matthias Urlichs wrote:

> robepisc:
> > Matthias, are you sure the absence of udevsettle was the origin of the
> > problem? Did the committed (in casper 1.79) fix actually solve your
> > issue?
> >
> I have manually added the required udevsettle call to my startup script
> at that position -- and yes, the issue went away.
>
udevsettle has been dropped from the initramfs, the script that needs
hardware should either be run from a udev rule, or spin until the
hardware is available.

> > It seems to me that udevtrigger doesn't really understand the -B and
> > -I command line options (see man udevtrigger). And for this reason it
> > returns an error, without actually doing nothing!
> >
> Yeah, that appears to be a problem. However, I'm using Edgy here.
> Edgy's udevtrigger *does* understand those options.
>
> Seems that in Feisty, s/-B /--subsystem-match=/ and s/-I /--attr-match=/
> -- which is kindof annoying, esp. as that change wasn't even documented
> in the changelogs AFAICS.
>
Yes it was ...

  * Update patches:
    - 40-udevtrigger-filters.patch: dropped, the spirit of this patch is
      merged upstream and we don't need most of it anymore.

The -B, -I, etc. stuff was always an Ubuntu patch. Now that udevtrigger
is reliable, and takes less than a nano-second to complete; there was no
point having the filter options anymore.

In addition, now we're going for a completely event-driven boot, we
don't need to call settle either -- we won't be calling it in either the
initramfs or main boot sequence.

Scott
--
Scott James Remnant
<email address hidden>

[Matthias Urlichs (smurf)]

Hi,

Scott James Remnant:
> * Update patches:
> - 40-udevtrigger-filters.patch: dropped, the spirit of this patch is
> merged upstream and we don't need most of it anymore.
>
Ah. OK.

> In addition, now we're going for a completely event-driven boot, we
> don't need to call settle either -- we won't be calling it in either the
> initramfs or main boot sequence.

IMHO you should have conflicted with the old initramfs utils.

Right now my boot is broken even after installing the new version
(can't find /dev/root). I'll investigate.

NB: debugging an initramfs is kindof difficult if one doesn't have a PS2
keyboard handy. It would be nice for USB keyboards to work during bootup ...

--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | <email address hidden>
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
 - -
Q: How many mathematicians does it take to screw in a light bulb?
A: One. He gives it to six Californians, thereby reducing the problem
 to the earlier joke.

[Scott James Remnant (Canonical) (canonical-scott)]

On Fri, 2007-01-12 at 10:45 +0100, Matthias Urlichs wrote:

> Scott James Remnant:
> > In addition, now we're going for a completely event-driven boot, we
> > don't need to call settle either -- we won't be calling it in either the
> > initramfs or main boot sequence.
>
> IMHO you should have conflicted with the old initramfs utils.
>
initramfs-tools shouldn't contain anything that refers to udev?

The scripts that call udevtrigger/udevsettle are contained inside the
udev package.

It's possible that your initramfs wasn't updated possible; either way,
please take that up with the kernel team.

Scott
--
Scott James Remnant
<email address hidden>

[robepisc (robepisc)]

Scott James Remnant:
> initramfs-tools shouldn't contain anything that refers to udev?
>
> The scripts that call udevtrigger/udevsettle are contained inside the
> udev package.
But, in Herd 2, /scripts/casper-bottom/23networking uses udevtrigger (with the broken "-B" and "-I" parameters!) and comes from casper, not udev.

The fix Matthias proposed and tested against Edgy has been applied by Colin agaist Feisty.
But it has no effect in Feisty unless, first, the invocation of udevtrigger is fixed.

The fact that udevtrigger/udevsettle is called from a script provided by casper instead of the udev package itself is not important here, IMHO. (However it probably means that casper should depend on udev, or be fixed not to use udevtrigger/udevsettle at all).

> It's possible that your initramfs wasn't updated possible; either way,
> please take that up with the kernel team.
Matthias uses Edgy and was making an hypothesis about an issue I found on Feisty. So no non-updated initramfs on his side. (Matthias, please correct me if I'm wrong)

To summarize: /scripts/casper-bottom/23networking is broken in Herd2 since it calls udevtrigger with unknown parameters and, hence, fails. This has not been fixed by the patch committed for this bug.

PS: Anyway, if all these scripts are being refactored before Feisty release to be more event oriented, then this discussion has little meaning :-)

[Brian Murray (brian-murray)]

casper (1.79) feisty; urgency=low

  [ Colin Watson ]
  * ubiquity-hooks/30accessibility: Change /root to /target in kderc_addtoprefixes (thanks, Jani Monoses).
  * Call udevsettle after udevtrigger (thanks, Matthias Urlichs; LP: #77438).
  * Send casper-reconfigure error messages to stderr rather than stdout to avoid interfering with debconf.