On Mon, May 16, 2011 at 01:38, Nix <nix@xxxxxxxxxxxxx> wrote:
> On 16 May 2011, Kay Sievers stated:
>> 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
>>>
>>> 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.)
Yeah, you could #ifdef the modalias export if the kernel does not
support module loading. This is not optimized.
It' probably just easier to delete the default udev rule that calls
modprobe, if you don't need it. :)
>>> 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.)
Yeah, that could happen too, if /run/udev/queue.bin would be deleted
by some cleanup script, after udevd is started.
>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â You are not
>> altering the content of /run/udev/ or /dev/.udev/ in any way right?
>
> Gods, no. Recipe for disaster.
Ok, fine.
>> 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
Yeah, never create any private directories of udevd. Most of them do
not even exist anymore in today's udev.
> echo "Creating initial device nodes..."
> udevd --daemon
> udevadm trigger --action=add --type=subsystems
> udevadm trigger --action=add --type=devices
> 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.)
Yeah, not a good idea to fiddle around with udev internals. The
existence of the old directory names indicates a need to convert. It
should not really break anything, just waste some time during udevd
startup.
>>> 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.
Yeah, that could explain it. A soon as the netif is up, we can not
rename it anymore.
>>> Put a 'sleep 1' after the udev call, and everything works.
>>
>> Which call? The trigger?
>
> See above: it was right after the settle call.
I see. Hmm, no good idea why this would be.
> Anyway, more tomorrow sometime after more testing. (It's past midnight
> here.)
Sounds good, let me know, if you find something out.
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
