ABCD <[email protected]> posted [email protected], excerpted
below, on Thu, 05 Feb 2009 01:21:54 -0500:
> If you have your CMOS clock set to local time, reboot the machine (or
> power it down, and wait an amount of time less than the offset between
> local time and UTC), *and* are in the Western Hemisphere (as in your
> timezone is UTC-####, as opposed to UTC+####), then, unless "clock" or
> "hwclock" is set to start *before* "fsck" (or its baselayout-1
> equivalent, which I do not remember), you will always see this message.
> I don't think that it was easily fixed in baselayout-1, but if you use
> baselayout-2/openrc, you can make hwclock start before fsck if you set
> clock_adjfile=no (or leave it unset) in /etc/conf.d/hwclock.
>
> If *any* of those conditions are not met, then this issue should go
> away.
It has been quite awhile since I dealt with baselayout-1, but I actually
just redownloaded the baselayout-1.12.11.1 (latest stable) sources and
checked the tarball and yes, I'm remembering correctly. There were/are a
few services that it semi-hard-wires; that is, while there's a way to
change the order or skip them entirely (see below), it was NOT setup the
way standard dependencies worked and actually ignored the dependencies
set in the service files themselves.
The reason it worked that way was because the dependencies couldn't be
reliably calculated until these very basic services were started.
Because the dependency order couldn't be calculated using normal means,
the order had to be semi-hard-wired in ordered to get the system to a
minimum operational known state from which the rest of the dependencies
could be calculated normally and the rest of the configured services
started accordingly. FWIW, such "workaround semi-hard-wired" services
are not necessary on baselayout-2/openrc. It handles dependencies more
reliably regardless and doesn't need basic "critical services" started
before it can properly calculate them. Thus, the ordinary dependency
framework can be used as normal.
Clock was/is one of the these "critical services". I didn't recall the
others but as I said just downloaded the sources and checked. Here's the
default list, in order: checkroot, modules, checkfs, localmount, clock,
bootmisc.
The way it works is this: The /sbin/rc script contains the default list
above, set in a variable, CRITICAL_SERVICES. By default, these are run,
in the order specified above, no matter what. If for some reason a
particular installation needs to change the order, or if they need to add
a service to the critical list (or subtract one, but that can get rather
complicated), the script does check for a file .critical in the bootlevel
set on the kernel command line (by default if not set, "boot"). If that
file exists, it is sourced. It should set the CRITICAL_SERVICES variable
as appropriate for that installation, and /sbin/rc then uses the value it
sets instead of the built-in defaults. Once all the "critical services"
are started in the order set in the variable, the system is assumed to be
in a state functional enough to reliably calculate dependencies for
everything else, and booting continues normally, as described in the
handbook.
----
How all that applies to this thread is just this, here's the default
order:
CRITICAL_SERVICES="checkroot modules checkfs localmount clock bootmisc"
See the problem? The clock service isn't started until AFTER checkroot
and checkfs, and due to the above, changing the dependencies as one might
normally do won't change that, so the system won't be adjusted for local
time until after they have run. That's what's causing the issue.
To fix it, try this:
In /etc/runlevels/${BOOTLEVEL}/ (where $BOOTLEVEL is simply "boot", if
you don't do anything fancy like setting it on the kernel command line),
as root, create the (hidden) file .critical with the following contents,
using the following command (with the path changed if appropriate for
your setup, it's wrapped here, but it's all one command):
echo CRITICAL_SERVICES="clock checkroot modules checkfs localmount
bootmisc" > /etc/runlevels/boot/.critical
What that does is simply reorder those services, so clock is started
first, before checkroot, instead of after everything is already fscked
and mounted.
Of course, everything necessary to run the clock service must be on your
root filesystem, and it won't be able to write anything to it since at
that point, the filesystem is still read-only. However, as Gentoo is
normally setup, that shouldn't be an issue, or at least it wasn't for me,
way back when I was dealing with it, which is why I knew about it, tho I
did have to refresh my memory as that was well over a year ago, IIRC.
I believe that'll fix your problem! =:^)
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
