On Fri, Sep 07, 2007 at 12:47:19PM +0100, Ian Jackson wrote:
> I would be happy explain what the problems are with getting the time
> right but I'm sure you've had plenty of representations along those
> lines already. If you're interested, let me know.
Sure, please let me know why it is *impossible*.
I can think of three possible cases which might cause this
problem.
The first, which seems to be the most common, is simply because
Debian/Ubuntu is simply not setting the time zone early enough, and so
for people who live west of the UTC line (or during British Summer
Time), and who insist for some unknown reason to make their hardware
clock tick localtime instead of GMT, end up having the time set
incorrectly when the kernel sets the time from the hardware clock
during the boot process, and then the root filesystem gets checked at
S20/S30, and then the clock isn't correctly set via hwclock until S50
or so. So the fix is to obviously call hwclock sooner, before S20 ---
possibly as early as in scripts found in initrd.
The second case, which you mentioned in the Ubuntu bug report:
* It is not reasonable for us to assume that the CMOS can be correct
at this point and in particular we mustn't assume that the system
clock will not warp backwards shortly after installation. There
are many reasons why this might happen, including that the
installer setup may not have as good access to ntp timeservers as
the installed system. I don't think we should try to get all of
this perfect (in particular, there is guesswork involved which is
never going to be right without asking the user questions, which we
want to avoid).
I don't see what's wrong with asking the user what time it is if you
can't get access to the NTP timeservers. Getting the time right is
*important*, and there is the chance that the user will never be able
to get access to NTP timeservers (i.e., they aren't on the network, or
some kind of secure environment w/o access to NTP, etc.). So if you
can't set the time from NTP, *ask*. It's better than just leaving the
time wrong, perhaps indefinitely.
The final and third case, is if the time zone as set by Linux is
different from the one as set by Windows. Realistically, the only
excuse for having the clock tick localtime is *if* you are booting
with Windows with its really stupid idea of having the hardware clock
tick localtime. But Ubuntu has all of this whiz-bang code to fetch
information like the timezone from the Windows registry, right? So
that's not really much of an excuse either.
Hence, as far as I'm concerned, if a Distro can't arrange to have time
correct when the root filesystem is being checked, it's a bug in the
Distro init scripts, and I want to hold the Distro to a higher
standard than what Ubuntu seems to be willing to settle to. So sure,
I'll provide a workaround in e2fsprogs, but I'm going to call it as I
see it, which is as a workaround to lame/buggy init scripts and/or a
lame installer.
- Ted
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
