On Sun, May 15, 2011 at 20:19, Nix <nix@xxxxxxxxxxxxx> wrote:
> 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.
What's 'umount /run' during bootup? That sounds really strange.
> | Â Â Â Â (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.
Udev has no idea what the kernel supports, it calls modprobe for all
devices with a 'modalias' but no attached driver.
> 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.)
Sounds weird. Settle should not return at that point. You are not
altering the content of /run/udev/ or /dev/.udev/ in any way right?
And you provide the /run tmpfs before you start udevd and don't touch
it again, right?
> 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
> 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?
Kay
--
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
