Moving 'setclock' to earlier in the boot sequence
bruce.dubbs at gmail.com
Tue May 27 13:13:30 PDT 2008
Nathan Coulson wrote:
> On Sun, May 25, 2008 at 8:07 PM, Gerard Beekmans
> <gerard at beekmansworld.com> wrote:
>> Please see http://wiki.linuxfromscratch.org/lfs/ticket/2160
>> The ticket is about a potential issue with bootscripts and from it came
>> a suggestion to move the setclock call to earlier in the sequence. It
>> would help to address the issue but also having the system clock set
>> accurately earlier is good for other things.
>> Is there any reason why we wouldn't want the system clock set properly
>> using the 'setclock' script right after modules are loaded and udev is
>> If there are no technical objections this will become a new Trac ticket.
> -The setclock script depends on /etc/sysconfig/clock, and possibly the
> udev system being loaded.
> We wish to address the issue of cleanfs not doing it's job,
> preferrably by checking against the mounting date of /proc.
> Resolution Suggestion:
> -I was taking a closer look at this issue, and I think moving it
> before mountkernfs would be an ideal time. I dont recall if setclock
> needed a devicenode or not, but I cant see any reason why we cant add
> a static devicenode for this. This is where we mount /proc, and that
> is what cleanfs decides to check against.
> - possible creation of a static devicenode.
Use the source Luke...
setclock is based on hwclock
hwclock needs to write to /var/lib/lastdate and /etc/adjtime. Could /var/lib be
remotely mounted? It doen't look like a good idea to me.
hwclock probes for a system clock:
if directisa is on the command line
probe_for_cmos_clock() -> may use /dev/port (Alpha?), but usually does
direct io for std Intel architecture
probe_for_rtc_clock() -> uses /dev/rtc or on 64-bit systems /dev/efirtc
if rtc is not found:
probe_for_kd_clock() -> uses /dev/tty1 and if not exists /dev/vc/1
finally, if nothing is found, it falls back to probe_for_cmos_clock()
For most LFS systems /dev/rtc is what is needed.
More information about the lfs-dev