Moving 'setclock' to earlier in the boot sequence

Dan Nicholson dbn.lists at
Tue May 27 12:30:43 PDT 2008

On Tue, May 27, 2008 at 12:10 PM, Nathan Coulson <conathan at> wrote:
> On Sun, May 25, 2008 at 8:07 PM, Gerard Beekmans
> <gerard at> wrote:
>> Please see
>> 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
>> setup?
>> If there are no technical objections this will become a new Trac ticket.
>> Gerard
> Dependencies:
> -The setclock script depends on /etc/sysconfig/clock, and possibly the
> udev system being loaded.

I think setclock has to come after udev for /dev/rtc. From hwclock(8):

hwclock Uses many different ways to get and set Hardware Clock values.
The most normal way is to do I/O to the device special file /dev/rtc,
which is presumed to be driven by the rtc device driver. However, this
method is not always available.

> Problem:
> 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.
> Impact:
> - possible creation of a static devicenode.

I think it's always the right thing to get the kernel file systems
mounted, modules loaded and devices created as soon as possible. I
don't believe the cleanfs issue is important enough to merit wedging
the setclock script in front of those steps. I'd personally rather
change cleanfs to operate in a different way that's independent of
those 3 services.


More information about the lfs-dev mailing list