Suspend/Resume during LiveCD session changes hardware clock
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| acpi-support (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned | ||
Bug Description
Binary package hint: acpi-support
When using a Ubuntu LiveCD (i.e. choosing "Try Ubuntu without any changes to your computer" from the boot menu) on a computer where the hardware clock is set to timezone different from UTC, there is an active internet connection and the computer is suspended to memory and resumed at least once, the hardware clock is changed. This results in a wrong system time when the computer is booted into the installed operating system (whether Windows or Linux). This is disappointing since "without any changes to your computer" was chosen at boot time.
I discovered this using Jaunty alpha-2, but I could also reproduce it with Hardy 8.04.1.
Example: The time is around 10:48 AM EST, when the computer is booted using the LiveCD, which sets the time zone to UTC automatically.
ubuntu@ubuntu:~$ sudo hwclock --show
Tue 30 Dec 2008 10:48:27 AM UTC -0.835046 seconds
ubuntu@ubuntu:~$ date
Tue Dec 30 10:48:29 UTC 2008
Now, wireless network is selected (this synchronizes the system clock to have a correct UTC time)
ubuntu@ubuntu:~$ sudo hwclock --show
Tue 30 Dec 2008 10:49:16 AM UTC -0.534459 seconds
ubuntu@ubuntu:~$ date
Tue Dec 30 15:49:17 UTC 2008
Then, a suspend and resume cycle, and the hardware clock is set.
ubuntu@ubuntu:~$ sudo hwclock --show
Tue 30 Dec 2008 03:51:35 PM UTC -0.565752 seconds
ubuntu@ubuntu:~$ date
Tue Dec 30 15:51:37 UTC 2008
I don't worry that the time zone is set to UTC in the LiveCD environment, but that the hardware is clock is changed so that the installed software gets confused.
Use case 1:
Peter uses Windows XP. He is thrilled that he gets the option to try Ubuntu without any changes to his computer. Later that day he is doing some work in Windows before a date with his girfriend at 7 pm. Unfortunately, the Windows system time is now 1 hour behind, so he is an hour late for his date.
Use case 2:
John asks a friend if he can borrow his computer to check if a suspend/resume bug can be reproduced on that hardware. He says that he can run linux on the computer without changing anything, but does not know that his testing will leave the computer with a wrong system time afterwards.
Related branches
| Scott James Remnant (Canonical) (canonical-scott) wrote | #1 |
| Changed in acpi-support: | |
| status: | New → Fix Committed |
| Launchpad Janitor (janitor) wrote | #2 |
| Changed in acpi-support: | |
| status: | Fix Committed → Fix Released |
| Changed in acpi-support (Ubuntu): | |
| status: | Fix Released → Incomplete |
| Ram (rgkrishn) wrote | #3 |
| Steve Langasek (vorlon) wrote | #4 |
| Changed in acpi-support (Ubuntu): | |
| status: | Incomplete → Fix Released |
Committed changes to stop synchronising the system and hardware clocks over a suspend/resume cycle, which will be released with acpi-support 0.120 in jaunty.
The rationale is that the kernel records the delta between the two clocks on suspend, and resets the system clock on resume based on this delta. The mix of the two can lead to strange issues such as you've seen.
We now just let the kernel do its thing.