Hi all, With the upgrade to Udev-173, we now see a warning that the call to 'udevadm trigger --type=failed --action=add' from S10udev is deprecated. The thread starting at http://www.spinics.net/lists/hotplug/msg05039.html goes into more detail about the issues involved, but in effect, Udev's tracking of failed events will be going away in some unspecified future release (though I'd expect it to be sooner rather than later).
That feature removal is easily dealt with by simply removing the udev_retry bootscript from the bootscripts tarball. But that raises the question of what that bootscript was trying to do in the first place? So, it turns out that the actions specified by 'RUN+=' udev rules can fail for any of a variety of reasons, and this script was simply there to retry such failed actions in the hope that something had (almost magically) changed since the rules were first triggered. I say "almost magically" because there's no smarts in the script at all, it just assumes that because it's being run later in the boot sequence, enough things will have been started up/mounted etc. to make the rules work again. So, which of our rules may require such a retry attempt then? The only one I can see is the setclock script which could fail if /var is on a separate partition. This is because the /dev/rtc related rule will be triggered in S10udev. That rule calls the setclock script, which in turn calls hwclock, which in turn requires /var/lib/hwclock/adjtime. Now, /var could be on a separate partition that hasn't been mounted by the time that rule is triggered, because filesystems aren't mounted until S40mountfs. We can fix that up in a couple of ways though. Firstly, just ignore the FHS, and leave adjtime in its default location of /etc. Secondly, as Kay Sievers recommends in the thread above, never trust the hwclock at all; if you need an accurate system time, use NTP. I'm personally in favour of that approach and therefore would suggest we remove the setclock script and change the rtc related udev rule to not run it. The book could then either include the NTP daemon, moving it from BLFS, or alternatively, just explain that the system time is going to come from the BIOS and if that's not accurate enough for folks, point them to the NTP package in BLFS. Regards, Matt. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
