Nathan Coulson wrote:
Lets trim a little...
> One thought though, all of our problems stem from udev running before
> mountfs. I have not dug into udev's behavior too much, but I imagine it is
> the --trigger command that populates /dev/{sd*,sr*,hd*}
>
> It looks like we can do something like the following...
> --udev, only trigger block devices
> --mountfs
> --udev remaining
>
> that way, devices have a fully mounted system before they attempt to run
I've thought for a while that there should be a location that is
accessible across boots that is always available (not a mountpoint).
It's a catch-22 though. How do you mount / read only (for security) and
still be able to write this persistent data? The clock/ntp data is only
one area. Alsa and pci.ids/usb.ids are other areas of concern, although
they can certainly come after mountfs. This data probably should be in
an optionally mountable /var partition.
For transient data, we now have /run. That helps, but is not a complete
solution.
The first script to run is mountvirtfs. Perhaps we could have that
create a /dev device like /dev/sda? and mount that as /var before udev
ever starts.
>>>>> 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.
>>
>
> wonder if it uses utc or not... seems like if it works in all cases that it
> would solve some headaches.
I believe the system clock is a HW device and has a small battery
keeping time while the system is off/unplugged. Whether is is
interpreted as UTC or not is a convention of the OS. Windows, for
instance, always assumes it is local time. (Shortsighted as usual).
In Linux, the CONFIG_RTC_HCTOSYS option needs a device (rtc0 by default)
and always assumes UTC. It won't work properly in a system that dual
boots to Windows. There may be a way to work around that.
-- Bruce
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
