I know that you're not supposed to rely on 'udevadm settle' anymore, but
I rely on it across the board for systems with root filesystems that
aren't expected to move around (i.e. all of them), because massively
reengineering working systems' boot processes is generally considered a
bad thing. And it's stopped working. Given how many things expect /dev
to be populated, this has fairly serious effects.
I can be certain that as of somewhere between udev 164 and 167, 'udevadm
settle' has stopped waiting for block devices to appear (though I
suspect others have vanished too). I'm booting udev as recommended in
the release notes, via
udevd --daemon
udevadm trigger --action=add --type=subsystems
udevadm trigger --action=add --type=devices
udevadm settle
but this is what I now see:
,----
| 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.
| (In some cases useful info about processes that use
| the device is found by lsof(8) or fuser(1))
| Cannot find device "gordianet"
| fsck from util-linux 2.19
| udevd[334]: failed to exec[ 2.457619] EXT2-fs (sda1): warning: mounting unchecked fs, running e2fsck is recommended
| ute '/sbin/modprobe' '/sbin/modprobe -bv platform:cs5535-gpio': No such file or directory
|
| udevd[333]: failed to execute '/sbin/modprobe' '/sbin/modprobe -bv platform:cs5535-acpi': No such file or directory
|
| udevd[335]: failed to execute '/sbin/modprobe' '/sbin/modprobe -bv platform:cs5535-pms': No such file or directory
|
| udevd[336]: failed to execute '/sbin/modprobe' '/sbin/modprobe -bv sg': No such file or directory
|
| 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.
By the time of that 'umount', 'udevadm settle' has returned. Shortly
afterwards you see fsck claiming that devices don't exist. Look at
it the filesystem after the resulting failed half-boot and you see:
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.)
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:
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.
Anyone know what's going on? I haven't bisected yet (the problem is
intermittent), but I strongly suspect that
commit ead7c62ab7641e150c6d668f939c102a6771ce60
Author: Kay Sievers <kay.sievers@xxxxxxxx>
Date: Wed Apr 20 02:18:22 2011 +0200
udevadm: settle - kill alarm()
commit 2181d30a342dd9fb168b7077ae5095849e328689
Author: Kay Sievers <kay.sievers@xxxxxxxx>
Date: Wed Apr 20 01:53:03 2011 +0200
timeout handling without alarm()
has broken udevadm settle and caused it to not wait at all. I'll
check that next time I reboot (with my heart in my mouth).
--
NULL && (void)
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
