Live CD changes hardware clock

I also noticed this behavior with Karmic beta, and with Karmic Release Candidate.

This is bad because running a live CD is supposed to be completely harmless for a computer.
I would expect my computer to be in the exact same state as before running the liveCD

I can reproduce that easily on a Lenovo T61 notebook. But I don't think if it has something to do with the hardware.
This is how to reproduce :
- boot on the liveCD without pluging the computer to the Internet. In a terminal, the "date" command outputs something like "16:12:41 (UTC+0000)"
- connect to the Internet
- just after connecting, the time changes to GMT. The "date" command outputs "14:13:56 (UTC+0000)"

I don't think it's related to https://bugs.launchpad.net/bugs/268808 because this bug has been fixed in the RC version of Karmic

I suspect something related to NTP : as the liveCD thinks I am in GMT+0 (even if I live in GMT+2), NTP would correct the time.
I have the same behavior with jaunty (9.04).

Is this a duplucate of https://bugs.launchpad.net/ubuntu/+source/casper/+bug/105519 ?

This is not a duplicate since the other bug is about the clock being wrong (shown wrong) in the live CD.

Confirming bug for Ubuntu 9.10 desktop amd64 live

It is very annoying. :-(

I've been running Ubuntu 9.10 and Kubuntu 9.10 from LiveCD and they both reset my system clock to GMT.

Apart from just not setting the clock, couldn't the LiveCD just read the System Clock instead of assuming GMT? Even if it's wrong it's because the system clock is wrong, not Ubuntu. (retorical question)

very annoying bug.
undecided importance ? unassigned ? so it won't be corrected for lucid ?
so bad that a simple live cd demo of ubuntu change anything on a computer.

This bug was not present in Ubuntu 8.10 or 9.04.

In the Ubuntu 8.10 LiveCD there are no K*hwclock* links in the /etc/rc?.d/ directories, which is correct, so /etc/init.d/hwclock.sh doesn't get called with "stop", and the hardware clock is not changed.

When Ubuntu 8.10 is installed, K25hwclock.sh, a link to /etc/init.d/hwclock.sh is placed in /etc/rc0.d/ and /etc/rc6.d/ so that /etc/init.d/hwclock.sh gets executed with "stop", and the hardware clock is updated, when the PC is halted or rebooted. This is OK since there is, of course, no promise of not changing the computer.

That difference between the installed flavor and the LiveCD flavor is a result of this correct 2005 change to casper-0.10:

------------------------------------------------------------------------

From debian/changelog in casper-1.228:

casper (0.10) hoary; urgency=low

  * Remove rc?.d/K??hwclock.sh links, to avoid changing the system clock
    during reboot or shutdown

 -- Matt Zimmerman <email address hidden> Thu, 13 Jan 2005 18:13:31 -0800

From scripts/casper-bottom/25configure_init in casper-1.228:

# Avoid clobbering the user's clock
rm -f /root/etc/rc?.d/K??hwclock.sh

------------------------------------------------------------------------

As can be seen from the above, this code still exists in casper-1.228. The problem is that this code affects the System V initialization scripts, which have been replaced by upstart. What casper now needs is equivalent code that works for upstart.

When halting or rebooting, upstart runs the script in /etc/init/hwclock-save.conf. So the simplest fix would seem to be to have casper remove that file. It looks like no other script currently depends upon the hwclock-save job, so this should be safe to do.

If I boot up my 9.10 LiveCD and remove /etc/init/hwclock-save.conf before halting or rebooting, life is good: the hardware clock is left unchanged.

With a new LiveCD being released next month, it would be great if this could be fixed soon.

The "Try Ubuntu without any changes to your computer" promise gives potential Ubuntu users a great sense of freedom to try it. "Try it out? No changes? OK, sure, what have I got to loose?" That's how I got hooked on Ubuntu. But when those potential users find that their clocks have been "clobbered", and the promise broken, they naturally wonder what other changes have been made to their computers. They can easily reset their clocks, but their trust in Ubuntu will not be restored so easily.

Few, if any, of those potential users will take the time to find their way to Launchpad and file a bug report. They won't be counted in the Launchpad "This bug affects N people" tally. Many will simply toss the CD. I did not toss mine, but I had already developed a liking for Ubuntu from previous releases. I did, however, put my 9.10 CD on the shelf, went back to 8.10, and went looking for another disto.

Yesterday was the six-month birthday for this bug report. Is it time to raise the Importance from "Undecided"? It would be a good birthday present.

Norm, thanks for your analysis! I've committed your suggested fix to casper, and it should be in beta-2.

This bug was fixed in the package casper - 1.230

---------------
casper (1.230) lucid; urgency=low

  * Don't save the hardware clock on live CD reboot; we used to do this in
    the sysvinit world, but it regressed when we switched to Upstart
    (thanks, Norm Pierce; LP: #436535).
  * When running update-initramfs on writable media, update initrd.lz rather
    than initrd.gz if it's present, and make the update process a bit safer
    while we're there (LP: #489736).
  * Handle toram and todisk=DEVICE options on command line (LP: #526305).
  * Policy version 3.8.4: no changes required.
  * Convert to source format 3.0 (native).
 -- Colin Watson <email address hidden> Tue, 30 Mar 2010 11:41:24 +0100