Bug #15168

Improve UX when hardware clock is set to localtime in a timezone too far from UTC

Added by intrigeri 2018-01-15 14:22:55 . Updated 2019-08-11 16:01:18 .

Status:
Resolved
Priority:
Normal
Assignee:
Category:
Time synchronization
Target version:
Start date:
2018-01-15
Due date:
% Done:

0%

Feature Branch:
Type of work:
Code
Blueprint:

Starter:
Affected tool:
Deliverable for:

Description

There’s no general solution to the “software tends to break when system time goes backwards” well-known class of problems. Given we have to set the system clock correctly and we cannot easily guess whether the hardware clock (RTC) is in localtime or UTC, it seems unavoidable that we will trigger all kinds of problems for users with a RTC set to localtime in a timezone >> UTC, e.g. Bug #14250 and Bug #15548.

What we could do to mitigate the problem a bit:

Subtasks

Related issues

Related to Tails - Bug #14250: Applications menu stops working sometimes due to time going backwards Resolved 2017-08-20
Related to Tails - Bug #9268: obfs4 bridges often don't work (maybe MTU?) Duplicate 2015-04-21
Related to Tails - Feature #14544: Spend software developer time on smallish UX improvements In Progress 2018-08-31
Blocks Tails - Bug #15548: Tails can't establish a connection with obfs4 bridges and a hardware clock too far away from UTC Confirmed 2018-05-09
Blocks Tails - Feature #16209: Core work: Foundations Team Confirmed

History

#1 Updated by intrigeri 2018-01-15 14:24:49

  • related to Bug #14250: Applications menu stops working sometimes due to time going backwards added

#2 Updated by intrigeri 2018-01-15 15:05:01

  • Status changed from Confirmed to In Progress

Applied in changeset commit:e2a548ac9346901fd644caa01ac2fe6f0daf0429.

#3 Updated by intrigeri 2018-01-15 15:16:52

intrigeri wrote:
> * Document how to set the RTC to UTC. This is the default on most Linux and macOS but Windows defaults to localtime. https://wiki.archlinux.org/index.php/Time#UTC_in_Windows explains how to fix that for Windows 7 and newer; on older Windows it seems to be a lost case.

While handling Bug #14250 it felt wrong to document only a temporary workaround, so I felt bold and also mentioned that this technique can be used to fix the problem permanently. Reviews & comments are welcome :)

#4 Updated by cbrownstein 2018-01-16 09:07:29

  • Assignee set to sajolida

https://github.com/cbrownstein/tails/tree/web/15168-known-issues-hardware-clock

The changes I made are minor but I believe they are an improvement nonetheless.

#5 Updated by intrigeri 2018-01-16 12:30:04

cbrownstein wrote:
> The changes I made are minor but I believe they are an improvement nonetheless.

Merged and also applied your grammar fixes to the FAQ (from which I had copied’n’pasted the exact phrasing for consistency’s sake, assuming that had been reviewed already). Leaving this on sajolida’s plate in case he wants to take another look and triage/prioritize the broader problem this ticket is about.

#6 Updated by anonym 2018-01-19 22:25:58

intrigeri wrote:
> * Ubuntu interprets the RTC as localtime “if Windows was detected on any disk during Ubuntu installation”. This seems clever. Perhaps we could do the same?

It is clever! Sadly it bites the users that went out of their way to fix their Windows (e.g. on a multi-boot system… so perhaps we ignore the Windows installation if we also see a Linux installation? :P). It does seem worth it; I bet it will improve the situation for 90% of users.

#7 Updated by sajolida 2018-03-27 11:53:13

  • blocks Feature #15392: Core work 2018Q2 → 2018Q3: User experience added

#8 Updated by intrigeri 2018-04-30 10:46:37

  • related to Bug #15548: Tails can't establish a connection with obfs4 bridges and a hardware clock too far away from UTC added

#9 Updated by intrigeri 2018-04-30 10:46:41

  • related to Bug #9268: obfs4 bridges often don't work (maybe MTU?) added

#10 Updated by intrigeri 2018-04-30 10:52:20

  • Description updated

#11 Updated by intrigeri 2018-04-30 10:52:46

  • Description updated

#12 Updated by intrigeri 2018-04-30 10:54:39

anonym wrote:
> intrigeri wrote:
> > * Ubuntu interprets the RTC as localtime “if Windows was detected on any disk during Ubuntu installation”. This seems clever. Perhaps we could do the same?
>
> It is clever! Sadly it bites the users that went out of their way to fix their Windows (e.g. on a multi-boot system… so perhaps we ignore the Windows installation if we also see a Linux installation? :P). It does seem worth it; I bet it will improve the situation for 90% of users.

I agree this would be better but IMO let’s not block on this (best, ennemy, good, all that): let’s not stick for years to a crappy situation, refraining from applying a fix that’s good enough for Ubuntu users, merely because we would like an even better solution.

#13 Updated by sajolida 2018-05-02 15:07:40

  • Assignee deleted (sajolida)

> Leaving this on sajolida’s plate in case he wants to take another look and triage/prioritize the broader problem this ticket is about.

I have nothing to add.

#14 Updated by sajolida 2018-05-02 15:08:05

  • Type of work changed from User interface design to Code

The next step seems to be to code something like Ubuntu does, right?

#15 Updated by intrigeri 2018-05-25 14:35:49

  • related to Feature #14544: Spend software developer time on smallish UX improvements added

#16 Updated by intrigeri 2018-05-25 14:36:20

> The next step seems to be to code something like Ubuntu does, right?

Yep. And hopefully we can reuse Ubuntu’s code somehow.

#17 Updated by sajolida 2018-10-29 14:24:15

  • blocks Feature #16080: Core work 2018Q4 → 2019Q2: User experience added

#18 Updated by sajolida 2018-10-29 14:24:18

  • blocked by deleted (Feature #15392: Core work 2018Q2 → 2018Q3: User experience)

#19 Updated by intrigeri 2018-11-18 08:47:38

  • Description updated

#20 Updated by intrigeri 2018-11-18 09:10:14

  • Description updated

(Adding link to the Debian Installer’s implementation because that’s actually not Ubuntu-specific :)

#21 Updated by intrigeri 2018-11-18 09:26:49

live-config supports a utc=yes|no kernel command line which “Allows to change if the system is assuming that the hardware clock is set to UTC or not”. It’s used by components/1120-util-linux to create /etc/adjtime. We could add support for utc=auto in there: it would parse the os-prober output just like the Debian Installer does and boom. The default value for this setting could even become “auto” when os-prober is available.

os-prober has no dependency that we don’t ship already but its dependency on grub-common might be a problem for some Debian Live systems, so I don’t think we should make live-config hard-depend on os-prober; a mere Recommends should be sufficient.

#22 Updated by intrigeri 2018-11-18 10:03:09

Note that the way live-config tweaks /etc/adjtime is ineffective on current systems because by the time this code runs, systemd has already read /etc/adjtime: https://bugs.debian.org/882851. So:

  • either there’s a way to fix this bug in live-config itself; I have a few ideas, will report on the Debian bug;
  • or this code needs to be moved to live-boot, presumably to be run in a new script installed in /usr/share/initramfs-tools/scripts/$something-bottom, so it runs before systemd is started; but then, I’m not sure how os-prober will work in that environment, so it would be good if we can avoid going down that road;
  • or systemd could detect itself whether there’s a Windows installation and DTRT, but that’s much more work and I’m pretty sure the risk of breaking things is just too big, so I’d rather ignore this option for now.

#23 Updated by intrigeri 2018-11-18 11:35:55

I’ve suggested some ways upstream to fix the buggy utc= live-config option: https://bugs.debian.org/882851#10.
I’ve reported a wishlist bug against live-config about the utc=auto idea: https://bugs.debian.org/914001.
Whoever will implement this could do their initial experiments directly in tails.git (config/chroot_local-includes/lib/live/config/ for the live-config way, config/chroot_local-includes/usr/share/initramfs-tools/ for the initrd one) to get a PoC before integrating the code into live-{boot,config}.

#24 Updated by intrigeri 2018-11-20 12:32:01

  • related to deleted (Bug #15548: Tails can't establish a connection with obfs4 bridges and a hardware clock too far away from UTC)

#25 Updated by intrigeri 2018-11-20 12:32:08

  • blocks Bug #15548: Tails can't establish a connection with obfs4 bridges and a hardware clock too far away from UTC added

#26 Updated by intrigeri 2018-11-20 12:33:19

  • Subject changed from Improve UX when hardware clock is set to localtime in a timezone >> UTC to Improve UX when hardware clock is set to localtime in a timezone too far from UTC

#27 Updated by sajolida 2019-01-16 18:14:05

  • blocked by deleted (Feature #16080: Core work 2018Q4 → 2019Q2: User experience)

#28 Updated by intrigeri 2019-02-06 16:27:56

#29 Updated by CyrilBrulebois 2019-02-06 16:29:53

  • Assignee set to CyrilBrulebois

#30 Updated by intrigeri 2019-03-12 16:09:46

#31 Updated by intrigeri 2019-03-12 16:09:50

  • blocked by deleted (Feature #15507: Core work 2019Q1: Foundations Team)

#32 Updated by intrigeri 2019-04-05 16:11:58

  • Assignee deleted (CyrilBrulebois)

#33 Updated by intrigeri 2019-08-11 15:51:47

  • Description updated

intrigeri wrote:
> * Ubuntu interprets the RTC as localtime “if Windows was detected on any disk during Ubuntu installation”. This seems clever. Debian does the same thing. Perhaps we could do the same?

Argh, that’s not going to work: all it will tell us is “the system clock might be very wrong”; but without also knowing what’s the local timezone (or inferring it from the current correct local time + the RTC), that info is not actionable at all.

So the only way we can improve things in this situation is via Feature #5774 (more specifically, the part of the plan where we “[let] the user set the correct time and choose their preferred timezone” whenever Tor fails to bootstrap.

#34 Updated by intrigeri 2019-08-11 15:52:06

#35 Updated by intrigeri 2019-08-11 15:54:06

intrigeri wrote:
> So the only way we can improve things in this situation is via Feature #5774 (more specifically, the part of the plan where we “[let] the user set the correct time and choose their preferred timezone” whenever Tor fails to bootstrap.

… and/or via the “Integration with the new Greeter” part of that plan. Both refer to https://tails.boum.org/blueprint/robust_time_syncing/.

#36 Updated by intrigeri 2019-08-11 15:59:28

#37 Updated by intrigeri 2019-08-11 16:01:18

  • Status changed from In Progress to Resolved

This ticket was about tracking easy enough improvements in this area. One was implemented and the other can’t possibly work. The problem this is about is tracked on Bug #15548 so I don’t see what this very ticket is useful for now.