On Fri, 5 Aug 2011 01:06:52 -0700, Nathan Coulson <conat...@gmail.com> wrote:
> On Fri, Aug 5, 2011 at 12:12 AM, Matthew Burgess <
> matt...@linuxfromscratch.org> wrote:
>
>> On 05/08/2011 03:41, Bryan Kadzban wrote:
>> > 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.
>>
>> OK, that seems a valid thing for us to be doing.
>>
>> > 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.
>>
>> Then the alsa bootscript just needs moving to come after the mountfs
>> script surely? What use case is there for needing to restore volume,
>> etc. *before* you've even managed to mount /usr?
>>
>
> Alsa volumes are restored when the device appears on the system via udev,
> not the bootscript anymore. (no S##alsa in rc*.d). and this does make
> sense for hotplugging devices. on my system, nothing calls
> /etc/rc.d/init.d/alsa start
Ah, right. Yes, it makes complete sense, but then without an initrd we've
got seemingly conflicting requirements:
1) The detection of the alsa device will trigger the bootscript which
requires /usr & /var to be mounted, but they may not be available
because mountfs hasn't been run yet
2) If we revert back to a bootscript, we lose the ability to hotplug
devices.
>> > Their solution is to require an initramfs (SIGH), which mounts all
>> > filesystems before transferring control to /sbin/init on the rootfs.
>>
>> Yes, I've noticed their leanings toward such a configuration, and also
>> think its overkill, especially for LFS.
But now I really don't think we have a choice if we want to support
fully hotplugging devices with scripts being called from udev's RUN+=
mechanism. Or, we simply state that if you want a correctly configured
system, either ensure that you put everything on a single partition
(which LFS would default to), or create an initrd (and point to a
relevant hint on how to do so).
>> > 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.)
>>
>> Hmm, I'll give it a shot this evening, although heaven knows what might
>> be going on in the VM world I'm running LFS in - my VM may end up having
>> some smarts that picks the time up from the host...we'll see.
>>
>
> By default, it does not set the time.
>
> There is a optional kernel option (Introduced in the last 10-20 kernel
> releases, can't recall when), CONFIG_RTC_HCTOSYS that will set the system
> time to the hwclock time.
Nice, and it looks like I must have turned that on since it became available.
So, with that option set, one wouldn't need the setclock script at all then;
the kernel will read the BIOS clock by itself at startup, and there's no point
in saving the system time to the BIOS clock unless you have something like NTP
running.
Regards,
Matt.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
