Matthew Burgess wrote: > 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.
Yes. It exists for two reasons:
1) To copy the temporary newly-created rules from wherever
write_{cd,net}_rules put them, into /etc/udev/rules.d so they persist
after the next reboot. The rule itself can't necessarily write them to
/etc because the rootfs is readonly until mountfs.
2) To rerun rules like the ALSA one (which runs alsactl, which is
installed in /usr/sbin, and as of the most recent alsa-utils release,
requires a /var/lib/alsa/asound.state file), which will fail if either
/usr or /var is on a separate partition.
It looks like magic, but it's not; this script is simply numbered after
mountfs. The only thing it really supports retrying (via trigger) is
events that failed due to a missing filesystem. At one point that was
even in the comments in the script, though I haven't looked at it in a
while, so I don't know if it's still there.
OTOH, freedesktop ... people ... have started to insist that a setup
like that is broken as well:
http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken
although I note that their list of known-broken packages is utterly
devoid of *anything* relevant to LFS, except ALSA (and even that only
requires one workaround). Everything in there is an enormous desktop
package (heck, half of them require GNOME).
Their solution is to require an initramfs (SIGH), which mounts all
filesystems before transferring control to /sbin/init on the rootfs.
> So, which of our rules may require such a retry attempt then?
setclock (as you stated), alsactl from BLFS, and write_{cd,net}_rules
are the ones I know of that require the udev_retry script.
> 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.
Sigh. I hate shortsightedness.
You need *something* to start with. NTP is not a magic fix-everything.
If the clock is too far off at boot time, NTP will fail to start up
until the clock gets less far off at boot time. NTP will also utterly
fail to save the clock across a reboot.
The ntpd package has a way to do a one-time sync of the system clock
from the configured ntp servers, except that it takes *many* seconds to
run; last time I did that in the ntpd bootscript, it doubled my boot
time. What needs to happen is a simple, short "I know this isn't
perfect but it's close enough that ntpd won't choke" synchronization of
the system time to some other time source, and ntpd doesn't provide it.
hwclock does, since the /dev/rtc clock was synced at shutdown.
> 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.
This is true (the system time coming from the BIOS) with hwclock.
That's what "hwclock --hctosys" reads from, after all. I do not believe
it's true without it; last I knew, without hwclock, the system would
start at time zero. (But it's been many years since I tried it.)
signature.asc
Description: OpenPGP digital signature
-- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
