Bug #9557
Write regression test for the hardware clock not being saved
100%
Description
That is, check that Bug #9364 remains fixed, e.g.:
--- a/features/time_syncing.feature
+++ b/features/time_syncing.feature
@@ -32,6 +32,12 @@ Feature: Time syncing
And Tor is ready
Then Tails clock is less than 5 minutes incorrect
+ Scenario: The system time is not synced to the hardware clock
+ When I bump the system time with "+1 day"
+ And I warm reboot the computer
+ And the computer reboots Tails
+ Then the hardware clock is still the same as the host's time
+
# Scenario: Clock vs Tor consensus' valid-{after,until} etc.
Scenario: Create a new snapshot to the same state (w.r.t. Sikuli steps) as the Background except we're now in bridge mode
Tip: hwclock -r can be used to query the hardware clock from within Tails in the the hardware clock is still the same as the host's time step (bonus points for a better name that doesn’t refer to the “host”). Then it should be compared to the host’s clock +/- some seconds.
Subtasks
Related issues
|
Related to Tails - |
Resolved |
History
#1 Updated by anonym 2015-06-10 23:24:05
- related to
Bug #9364: Do not set the hardware clock to the system time on shutdown added
#2 Updated by anonym 2015-06-10 23:25:37
- Assignee set to kytv
- Target version set to Tails_1.4.1
- Parent task set to
Feature #8543
kytv, do you think you can manage this for Tails 1.4.1? Otherwise, please un/re-parent and set a new milestone.
#3 Updated by anonym 2015-06-10 23:26:03
- blocks #8538 added
#4 Updated by anonym 2015-06-11 00:27:00
I think we need an anti-test too: verifying that if we change the hardware clock, do a warm reboot, then the hardware clock change remains (modulo the time spent on rebooting).
#5 Updated by intrigeri 2015-06-11 07:10:46
> I think we need an anti-test too: verifying that if we change the hardware clock, do a warm reboot, then the hardware clock change remains (modulo the time spent on rebooting).
Yes, this would be ideal. Not sure if libvirt/QEMU give us the means to do that, though. We’ll see :)
#6 Updated by anonym 2015-06-11 10:46:06
intrigeri wrote:
> > I think we need an anti-test too: verifying that if we change the hardware clock, do a warm reboot, then the hardware clock change remains (modulo the time spent on rebooting).
>
> Yes, this would be ideal. Not sure if libvirt/QEMU give us the means to do that, though. We’ll see :)
As in “there’s no way to query the hardware clock state directly via Libvirt”? That’s probably true, but we can do it the same way we do the real test, with hwclock -r. Something like:
Scenario: Anti-test: the hardware clock is kept after reboot
When I bump the hardware clock with "+1234 day"
And I cold reboot the computer
And the computer reboots Tails
Then the hardware clock is still the same as the host's time +1234 days#7 Updated by kytv 2015-06-23 06:20:35
anonym wrote:
> kytv, do you think you can manage this for Tails 1.4.1? Otherwise, please un/re-parent and set a new milestone.
I’ll try but if not it should be ready just after 1.4.1.
Setting the hwclock and systime are working as expected. Now I just have to translate what I’ve done to ruby…
#8 Updated by kytv 2015-06-27 13:42:47
- Status changed from Confirmed to In Progress
- Assignee changed from kytv to anonym
- QA Check set to Ready for QA
- Feature Branch set to kytv:test/9557-hwclock
I think this branch tests what it is supposed to.
#9 Updated by intrigeri 2015-06-28 03:04:03
- Assignee changed from anonym to intrigeri
#10 Updated by intrigeri 2015-06-28 03:42:56
- Assignee changed from intrigeri to kytv
- % Done changed from 0 to 50
- QA Check changed from Ready for QA to Dev Needed
OK, so conceptually everything seems fine, yay :)
Here are some comments on the actual implementation.
> hwclock_time_str = @vm.execute(‘hwclock -r’).stdout.chomp
Why not execute_successfully?
> Then /^the hardware clock was not updated when Tails shut down$/ do
- Why isn’t this step skipped when restoring background snapshots?
- This step’s phrasing doesn’t really reflect what it actually does, that is comparing the host system’s clock with the system under testing’s hardware clock; I suggest rephrasing it to something like “Tails hardware clock is close to the host system’s one” (or what anonym proposed initially).
> I bump the hardware clock’s time with
This duplicates most of I bump the system time with => please refactor.
Also, please don’t use date + parsing to get the host system’s time: we have Time.now: see examples in Tails clock is less than...
#11 Updated by kytv 2015-06-28 13:01:41
- Assignee changed from kytv to intrigeri
- QA Check changed from Dev Needed to Ready for QA
Changes pushed.
#12 Updated by intrigeri 2015-06-28 14:09:02
- Status changed from In Progress to Fix committed
- Assignee deleted (
intrigeri) - % Done changed from 50 to 100
- QA Check changed from Ready for QA to Pass
Yay! Merged locally into stable. Cannot push since my local stable branch is being used to prepare the release, and in its current state I’m not sure what it’s worth.
#13 Updated by intrigeri 2015-06-28 14:09:42
Applied in changeset commit:07ad1b43fcfb9f74efbf581c74ec38055f4ac376.
#14 Updated by intrigeri 2015-06-28 23:37:23
Applied in changeset commit:6efba81d8c26cc7bc3feef450073804c1fc5d8bf.
#15 Updated by intrigeri 2015-07-03 03:35:42
- Status changed from Fix committed to Resolved