[lfs-dev] problem of bootscript setclock

DJ Lucas dj at linuxfromscratch.org
Sun May 13 11:48:37 PDT 2012


On 05/13/2012 01:16 PM, Bruce Dubbs wrote:
> DJ Lucas wrote:
>> On 05/13/2012 11:33 AM, Bryan Kadzban wrote:
>>> xinglp wrote:
>>>> Now, It is the job of udev to start /etc/init.d/setclock .
>>>>
>>>> When I use initd-tools to install somethings else, it was installed
>>>> for depended.
>>> Is there a way in these newfangled headers to say that setclock is
>>> really an alias for udev?  That's what's happening in the scripts, anyway...
>>>
>>>> And I THINK , ntpd and checkfs should not depend on $time.
>>> Not sure on ntpd (although I wouldn't be surprised if it was because
>>> ntpd refuses to do anything if the clock is far-enough off from what
>>> it's getting from the upstream servers).
>>>
>>> But checkfs does depend on the time.  It checks whether the current time
>>> is before or after the last-full-fsck-time plus the days-between-mounts
>>> value stored in the ext3 (and probably 4, and perhaps 2) superblock.  If
>>> it's after, then it forces a full fsck run.
>>>
>>> (It also checks whether the mount count stored in the superblock is more
>>> or less than the number-of-mounts-between-full-fsck-runs value in the
>>> superblock, and forces a full fsck if it's more.  Of course, that
>>> doesn't depend on knowing the current time.)
>>>
>>> "tune2fs -t" will change the number of days between checks, and "tune2fs
>>> -c" will change the number of mounts.  "tune2fs -T<timestamp>" will set
>>> the last-checked time (can be done live), and "tune2fs -C<integer>"
>>> will set the current mount count (can also be done live).
>>>
>>> All that said, if there's no way in this extra-abstraction setup to
>>> express an alias, then we should change the other scripts to depend on
>>> udev instead of setclock.
>> After a quick review of the scripts, here is my take: a quick fix would
>> be to add $time to the provides of the udev script headers. That's
>> probably not exactly the right thing to do. The setclock script should
>> probably be renamed hwclock and provide hwclock (at shutdown). Scripts
>> that need a close time source (hwclock) should depend on udev for
>> startup. The RTC will always be available to the hwclock program on x86
>> or x86_64 even if /dev is not mounted (the same is not true of other
>> archs though). I believe there is a way to set the system time by way of
>> kernel config now too so that the udev rule could go...been a while
>> since I looked at it. $time should probably be provided by the ntpd
>> script, and then a $time dependency should never appear in any script
>> that is installed into the rcS.d/, rc1.d/, or rc2.d/ directories.
> For LFS, we can't rely on ntpd because we can't assume a network connection.
>
>     -- Bruce
Correct, no scripts in the base LFS should have a hard dependency on 
$time for startup. You could still use should-* if desired, but no 
examples immediately come to mind where that would be appropriate (and 
that's not even necessary if the kernel is configured to set the system 
time). Scripts that need to have semi-accurate time (obtained from the 
RTC) should depend only on udev for start-up. A provides of hwclock for 
shutdown would be made available, though the only use of hwclock I can 
see is as a Required-Stop for the ntpd script. Few things should have a 
hard dep for $time, in fact, MIT Krb5 is the only one I can think of 
ATM  for BLFS (and Heimdal if it goes back in).

BTW, OT but just curiosity, why was MIT chosen to be kept over Heimdal? 
I would have thought Heimdal to clearly be the more capable of the two, 
though the extra functionality provided by Heimdal should be handled by 
PAM anyway, so no *real* loss. Heimdal will be the default krb5 provider 
for Samba 4 in the future (and included in the distribution, though you 
can still use a system instance of either if desired).

-- DJ Lucas


-- 
This message has been scanned for viruses and
dangerous content, and is believed to be clean.




More information about the lfs-dev mailing list