Installer (alternate-CD) saves wrong time in RTC

Thanks for looking at this report!

Although I don't know for sure, I doubt that this really is a duplicate of Bug #268808. The reasons:
First, the author of the bug description is in a time-zone UTC-X, I'm in UTC+X. So the effect should be different, right?
Second, and more important, I'm really talking about an installer bug while the other bug is filed against ubiquity (I didn't use the Live-CD-installer) and about sysvinit. To make clear why the alternate-CD-installer is the problem I'd like to clarify it again.

Let's say it's 16:00 UTC, 18:00 CEST. The system clock is set to 18:00. I start the installer, give my correct location. I'm asked if my clock is set to UTC. I say "no", it's not. The installation took 15 minutes, the installer sets the system clock to 20:15 and reboots. I checked this by booting a Live-CD and typing date --utc before and immediately after the installation. Then ubuntu boots the first time, and tells me it's 20:20 although it's actually 18:20. So the clock was ok before installation and 2 hours ahead after installation.

What Stefan Hamminga described in the other bug report (comment #2) is exactly what happened to me as well and I think it belongs to this bug and not the other one.

Feel free to unmark it. I guess the main problem is that the time should be initialized before fsck runs.
It would be even better imho if default Ubuntu wouldn't mess with the time at all, at least on Desktop systems. If the bios time on some sever needs to be UTC there is an option but I guess most people can live with the local time in the bios so it doesn't always gets changed while for example starting Windows or different Ubuntu versions.

The desktop installer for example doesn't ask this system time question anymore afaik.

> Feel free to unmark it.

Ähem, yes, I would have, but I don't know how to.

> I guess the main problem is that the time should be initialized before fsck runs.

Agreed. But that's the other bug. Here the time at startup doesn't only get "misinterpreted" but it's simply wrong as well.

> It would be even better imho if default Ubuntu wouldn't mess with the time at all, at least on Desktop systems. If the bios time on some sever needs to be UTC there is an option but I guess most people can live with the local time in the bios so it doesn't always gets changed while for example starting Windows or different Ubuntu versions.

Actually I like to keep my time at UTC because it resolves the problem of who (in a multiboot-environment) updates the time after changing from/to DST: noone. Otherwise, if you multiboot, it might happen twice. It would be much better if Microsoft would change to using UTC than everyone else changing to local time.

Jaunty doesn't use UTC in the default settings and it makes sense. I mean why should the time always be changed after booting and on shutdown and not just use the local one so there is no change needed except of ntp adjustions. I think MS has a point.

unggnu: That is not actually true in general; you seem to be generalising from your own experience and assuming that that's what the installer does in all situations, which is not sound practice. As for why we prefer UTC if possible, there are many good reasons why storing the hardware clock in local time is fundamentally unreliable and cannot be made reliable; Markus Kuhn makes the case in http://www.cl.cam.ac.uk/~mgk25/mswish/ut-rtc.html much better than I can, and I encourage everyone with an interest in this area to read and digest that article. We only reluctantly use local time on systems believed to be already storing the hardware clock in local time because that's the only way to achieve at least minimal cooperation (even though it's unreliable) with other installed operating systems.

Everyone, but especially unggnu: please, please stop marking bugs about this issue in general as duplicates. One thing that is actively making it difficult for us to track down all the causes of this and fix them independently (for there is more than one cause of this problem!) is people piling onto bugs and assuming they're the same basic thing. It would make it easier for us if people worked on the assumption that all instances of this bug are independent until proven otherwise.

So far, we know of at least the following independent causes of this type of problem:

  1) various bugs that existed before Karmic (http://wiki.ubuntu.com/HardwareClock was the result of our last in-depth analysis of this class of problem);
  2) this issue with the alternate CD installer (d-i), which Christian has described accurately in comment 1 and which is on my list to fix for Karmic;
  3) bug 431786 (fixed), which was a similar issue with the desktop CD installer, although the ordering is quite different there and so the fix was independent;
  4) bug 427822 (fixed), which was a problem with the behaviour of the ext3/ext4 filesystems when replaying the journal at mount time, particularly relevant when mounting the root filesystem before we've had a chance to adjust the system clock properly;
  5) a further conjectured bug in ext3/ext4, in which the clock is just plain incorrect (due to user error, clock drift, etc.) and is corrected by NTP or user action after filesystems are mounted, but the corrected time is not written back to the superblock on unmount.

... and this is just what we've come up with so far! Unless you are able to perform an accurate in-depth analysis of the problem, therefore, please do not mark bugs such as this as duplicates, and if possible we would also greatly appreciate the waters not being muddied in comments, as it really does make it more difficult for us to put all the pieces together.

This bug was fixed in the package clock-setup - 0.98ubuntu3

---------------
clock-setup (0.98ubuntu3) karmic; urgency=low

  * If we didn't manage to sync the clock to NTP, then don't set the
    hardware clock. At best, all we'll be doing is writing back the value
    present when d-i started plus d-i's run-time; at worst, we'll also
    introduce a timezone error (LP: #440281).

 -- Colin Watson <email address hidden> Mon, 19 Oct 2009 01:06:47 +0100