Re: udevadm settle persistently failing

[Nix <nix@esperi.org.uk>]

On 16 May 2011, Kay Sievers stated:

> On Sun, May 15, 2011 at 20:19, Nix <nix@esperi.org.uk> wrote:
>> ,----
>> | Creating initial device nodes...
>> | [    2.035253] <30>udevd[297]: starting version 168
>> | udevd[297]: specified group 'audio' unknown
>> |
>> | [    2.151279] <30>udevd[297]: converting old udev database
>> | udevd[316]: failed to execute '/sbin/modprobe' '/sbin/modprobe -bv pci:v00001022d00002080sv00001022sd00002080bc06sc00i00': No such file or directory
>> |
>> | umount: /run: device is busy.
>
> What's 'umount /run' during bootup? That sounds really strange.

Hm, I didn't notice that. Yes, that does seem very odd indeed.

I'll have a look soon, if probably not on that system (it's a headless
system that does my firewalling so quite hard to reboot). I see the
symptoms on other systems too.

>> | udevd[339]: failed to execute '/sbin/modprobe' '/sbin/modprobe -bv platform:rtc_cmos': No such file or directory
>> |
>> | fsck.ext2: No such file or directory while trying to open /dev/sda1
>> | Possibly non-existent device?
>> `----
>>
>> I have no clue why udev is trying to run modprobe when this is a
>> non-modular kernel with all necessary devices built in. But that's not
>> important.
>
> Udev has no idea what the kernel supports, it calls modprobe for all
> devices with a 'modalias' but no attached driver.

Yeah, it's not terribly important (though why they even have a modalias
if this kernel does not have modules built in is also unclear. Anyway,
it can do no harm, since modprobe doesn't even exist on that system.)

>> fold:~# ls -l /dev/sda1
>> brw-rw---- 1 root disk 8, 1 May 15 18:56 /dev/sda1
>>
>> it's there. udevadm settle just didn't bother to wait for it to appear.
>> (This is not a device on a bus for which enumeration takes some time:
>> it's an SD card on an IDE-lookalike cs5535 bus. I've also seen this
>> on LVM-atop-RAID-atop-SATA and on ordinary LVM-atop-SATA, so it doesn't
>> require anything particularly unusual.)
>
> Sounds weird. Settle should not return at that point.

Agreed! (This is why I suspect the timeout stuff is simply timing out
immediately.)

>                                                       You are not
> altering the content of /run/udev/ or /dev/.udev/ in any way right?

Gods, no. Recipe for disaster.

> And you provide the /run tmpfs before you start udevd and don't touch
> it again, right?

ooo! possible bug. Here's my udev startup script:

mount -n /proc
mount -n /sys
mount -n /run
[...]
mount_tmpfs
mkdir -p $udev_root/.udev/db $udev_root/.udev/queue $udev_root/.udev/failed
echo "Creating initial device nodes..."
udevd --daemon
udevadm trigger --action­d --type=subsystems
udevadm trigger --action­d --typeÞvices
udevadm settle
sleep 1

*That* is going to cause udev to try to convert from the old to the new
udev database format every single time it starts, even though there *is*
no old udev database there, just skeletal directories. I wonder if
that's causing it?

(I've ripped that mkdir out. Let's see if that fixes things. If it does,
this suggests that udev needs further bulletproofing, because my udev
startup script was derived directly from one provided by earlier
versions of udev: a *lot* of people will have scripts like it.)

>> Other things seem to have failed too. I have renaming rules:
>>
>> SUBSYSTEM="net", ATTR{address}="00:00:24:cb:c6:a0", NAME="gordianet"
>> SUBSYSTEM="net", ATTR{address}="00:00:24:cb:c6:a1", NAME="adsl"
>> SUBSYSTEM="net", ATTR{address}="00:00:24:cb:c6:a3", NAME="wireless"
>>
>> yet the devices were not renamed:
>
> Hmm, that should be unrelated to the possible settle problem

Yeah. The rename-failure only seems to happen when the settle failure
happens, so perhaps it's related to parts of the startup script messing
with the interfaces and causing the kernel to ban renames because
they're in use. Obviously this doesn't happen if we're still sitting in
'udevadm settle' when this takes place.

>> 2: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
>>    link/ether 00:00:24:cb:c6:a0 brd ff:ff:ff:ff:ff:ff
>> 3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
>>    link/ether 00:00:24:cb:c6:a1 brd ff:ff:ff:ff:ff:ff
>> 5: eth3: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
>>    link/ether 00:00:24:cb:c6:a3 brd ff:ff:ff:ff:ff:ff
>>
>> Put a 'sleep 1' after the udev call, and everything works.
>
> Which call? The trigger?

See above: it was right after the settle call.

Anyway, more tomorrow sometime after more testing. (It's past midnight
here.)

-- 
NULL && (void)