Project

General

Profile

Bug #15168

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

Added by intrigeri over 1 year ago. Updated 3 months ago.

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

0%

Feature Branch:
Type of work:
Code
Blueprint:
Starter:
Affected tool:

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. #14250 and #15548.

What we could do to mitigate the problem a bit:


Related issues

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

Associated revisions

Revision e2a548ac (diff)
Added by intrigeri over 1 year ago

Document workaround when the Applications menu stops working

Closes: #14250
Refs: #15168

Revision 7ae9cb6b (diff)
Added by intrigeri over 1 year ago

Known issues: adjust to reflect the fact this specific bug is fixed in Tails 3.5

refs: #14250, #15168

History

#1 Updated by intrigeri over 1 year ago

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

#2 Updated by intrigeri over 1 year ago

  • Status changed from Confirmed to In Progress

#3 Updated by intrigeri over 1 year ago

intrigeri wrote:

While handling #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 over 1 year ago

  • 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 over 1 year ago

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 over 1 year ago

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 over 1 year ago

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

#8 Updated by intrigeri about 1 year ago

  • 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 about 1 year ago

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

#10 Updated by intrigeri about 1 year ago

  • Description updated (diff)

#11 Updated by intrigeri about 1 year ago

  • Description updated (diff)

#12 Updated by intrigeri about 1 year ago

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 about 1 year ago

  • 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 about 1 year ago

  • 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 about 1 year ago

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

#16 Updated by intrigeri about 1 year ago

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 9 months ago

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

#18 Updated by sajolida 9 months ago

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

#19 Updated by intrigeri 8 months ago

  • Description updated (diff)

#20 Updated by intrigeri 8 months ago

  • Description updated (diff)

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

#21 Updated by intrigeri 8 months ago

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 8 months ago

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 8 months ago

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 8 months ago

  • 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 8 months ago

  • 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 8 months ago

  • 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 6 months ago

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

#28 Updated by intrigeri 5 months ago

#29 Updated by CyrilBrulebois 5 months ago

  • Assignee set to CyrilBrulebois

#30 Updated by intrigeri 4 months ago

#31 Updated by intrigeri 4 months ago

#32 Updated by intrigeri 3 months ago

  • Assignee deleted (CyrilBrulebois)

Also available in: Atom PDF