Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.
Sign upWhonixcheck systemd clock check result #4046
Comments
andrewdavidwong
added
bug
C: Whonix
labels
Jun 30, 2018
andrewdavidwong
added this to the Release 4.0 updates milestone
Jun 30, 2018
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
esote
Jul 1, 2018
Likely a duplicate of issue #3469. If you follow option 2 and create a 50_whonixcheck_user file for whonix-gw and whonix-ws, it will suppress the error.
esote
commented
Jul 1, 2018
•
|
Likely a duplicate of issue #3469. If you follow option 2 and create a |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Aekez
Jul 1, 2018
@andrewdavidwong
I think this might be a mixed user-mistake and a mixed motherboard/BIOS design mistake, rather than a Qubes, Linux, Tor, Whonix, or any other software based issue. So it might not be an issue for Qubes to tackle, unless it's about greater user awareness? More details of my reasoning for this below.
The reason is that BIOS's do typically not recognize timezones, so when the user go into their BIOS, they might make the mistake of setting their BIOS time to that of their local timezone time. This thus changes the universal time in dom0, which again changes the universal time in whonix (and other VM's). The user then tries to correct this by changing the timezone to a different timezone of which they live in, thus correcting the correct time in dom0 with a wrong timezone, but not without causing other issues (like the whonix clock issue).
In short, the user puts a wrong timezone in dom0, to correct the wrong timezone in the BIOS. But what should be done, is correcting the time to the correct timezone in the BIOS, so that the timezone remains correct in dom0 (and thereby the AppVM's).
To fix,
- Go to a website that shows the universal time, search or use https://www.timeanddate.com/worldclock/timezone/utc
- Shutdown Qubes system, and start up in BIOS, then change BIOS time to the UTC time.
- Boot up Qubes, changes dom0 timezone to the correct timezone.
- Shutdown all AppVM's and sys-VM's, when started again it should work normally.
- Universal time is based on UTC time (without timezones), and will always be different from your local time (unless you live in the same time-zone on which UTC is based).
- Local time is the same as offline universal time (In BIOS), but affected by the offline timezone choice used.
- For offline fine-time adjustments it's better to change minutes and seconds in the BIOS itself (since its the source for the offline time and moves upstream to dom0 and then the VM's), or instead go the online option by using the sys-net for online clock updates (optional choice). Probably a good idea to not change time itself in dom0, like the OP did, as seen in the bold text here (Time zone: Etc/UTC (UTC, +0000)). This was probably done in dom0, and it transferred to whonix upon whonix start, and probably why the time got messed up. Thereby it looks to me that the OP is a victim of a user-mistake, which is easily caused and misleading the user by poor motherboard/BIOS design.
Another sign but the bold Etc above showing a user-mistake (but easily missleading, so the user shouldn't be to blame here), is that the timezone is changed to +0000. Mathematically, this shows the user is trying to correct time in dom0 to match the wrong time-zone used in the BIOS, thus evens out in +0000. The user needs to avoid changing dom0 settings, and instead put the BIOS to correct UTC time.
It might be that the solution is greater community awareness (maybe included mentions in some related docs)?
Disclaimer - I do not have a full understanding of the above, however I've run into this particular issue my self, and the above is how I solved it. I have no expertise to make claims here, please feel free to criticize where due.
Aekez
commented
Jul 1, 2018
•
|
@andrewdavidwong The reason is that BIOS's do typically not recognize timezones, so when the user go into their BIOS, they might make the mistake of setting their BIOS time to that of their local timezone time. This thus changes the universal time in dom0, which again changes the universal time in whonix (and other VM's). The user then tries to correct this by changing the timezone to a different timezone of which they live in, thus correcting the correct time in dom0 with a wrong timezone, but not without causing other issues (like the whonix clock issue). In short, the user puts a wrong timezone in dom0, to correct the wrong timezone in the BIOS. But what should be done, is correcting the time to the correct timezone in the BIOS, so that the timezone remains correct in dom0 (and thereby the AppVM's). To fix,
Another sign but the bold Etc above showing a user-mistake (but easily missleading, so the user shouldn't be to blame here), is that the timezone is changed to +0000. Mathematically, this shows the user is trying to correct time in dom0 to match the wrong time-zone used in the BIOS, thus evens out in +0000. The user needs to avoid changing dom0 settings, and instead put the BIOS to correct UTC time. It might be that the solution is greater community awareness (maybe included mentions in some related docs)? Disclaimer - I do not have a full understanding of the above, however I've run into this particular issue my self, and the above is how I solved it. I have no expertise to make claims here, please feel free to criticize where due. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
esote
Jul 1, 2018
@Aekez If you look at the issue I linked above (#3469), you will see that it is the exact same error. I've had this issue without touching my BIOS or dom0 timezone, it only occurred after an update in Whonix. While having messed up BIOS and/or dom0 time information could (perhaps rightly) trip whonixcheck to show a warning, @pure007 didn't indicate problems with timezones. As adrelanos says in the linked issue, it is "only a false positive graphical user interface message warning" -- and is fixed in Whonix 14.
esote
commented
Jul 1, 2018
•
|
@Aekez If you look at the issue I linked above (#3469), you will see that it is the exact same error. I've had this issue without touching my BIOS or dom0 timezone, it only occurred after an update in Whonix. While having messed up BIOS and/or dom0 time information could (perhaps rightly) trip whonixcheck to show a warning, @pure007 didn't indicate problems with timezones. As adrelanos says in the linked issue, it is "only a false positive graphical user interface message warning" -- and is fixed in Whonix 14. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Aekez
Jul 1, 2018
@esote Thanks for that, though unfortunately it's not a duplicate, albeit it does look alike a lot. The reason is that it doesn't take much to throw off Whonix/Tor if the time information is wrong, and these are two different ways that the time gets messed up.
Also I'm using Whonix 14 my self, the above part user/BIOS-design mistake however still comes in Whonix 14, but disappears the moment you correct the timezone in BIOS, and avoid making changes to dom0 to try correct the wrong timezone in the BIOS. I'm aware of the old Whonix time bug, but it shouldn't affect Whonix 14, as far as I'm aware at least.
Aekez
commented
Jul 1, 2018
|
@esote Thanks for that, though unfortunately it's not a duplicate, albeit it does look alike a lot. The reason is that it doesn't take much to throw off Whonix/Tor if the time information is wrong, and these are two different ways that the time gets messed up. Also I'm using Whonix 14 my self, the above part user/BIOS-design mistake however still comes in Whonix 14, but disappears the moment you correct the timezone in BIOS, and avoid making changes to dom0 to try correct the wrong timezone in the BIOS. I'm aware of the old Whonix time bug, but it shouldn't affect Whonix 14, as far as I'm aware at least. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
esote
commented
Jul 1, 2018
•
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
esote
commented
Jul 1, 2018
•
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Aekez
Jul 1, 2018
@esote
NP's, as long as we get to the bottom of what happens, it doesn't matter who's right, and being skeptical only allows room for greater clarifications or finding mistakes, so I think it's really good that you question so that truth can be attained.
Besides, it may also be that I'm wrong too. For example I just realized if I run timedatectl in sys-whonix terminal, I get Time zone: Etc/UTC (UTC, +0000) as well, despite my normal VM's and dom0 show correct timezone, so Whonix seems different here from other Qubes timezone VM behaviors. If this is normal Whonix behavior (which it probably is to protect anonymity if all Whonix's use same +0000 UTC timezones), than parts of my above argument falls apart. However as far as I can tell, putting wrong timezone in BIOS can still messup Whonix, but it's now less clear if that is what the OP did or not. The question (I think) then becomes if this is what happened to the OP or not. In other words, it can probably still either be a duplicate issue, or wrong BIOS settings? or maybe even a third issue, though there is so far no clues for a third issue.
Maybe someone who has good understanding of how time works in Tor/Whonix is needed to clarify this?
edit:
Barring further input from @pure007, however, it is up in the air as to whether this is a duplicate or not.
Agreed, I didn't see your edit before posting this, but I agree, it's not clear.
Aekez
commented
Jul 1, 2018
•
|
@esote Besides, it may also be that I'm wrong too. For example I just realized if I run Maybe someone who has good understanding of how time works in Tor/Whonix is needed to clarify this? edit:
Agreed, I didn't see your edit before posting this, but I agree, it's not clear. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Aekez
Jul 1, 2018
Based on the assumption Whonix defaults to +0000 UTC timezone for all systems, then it seems Whonix complains if there is a difference between Local time, and Universal time (mathematical mismatch in time, that can be used to fingerprint Tor anonymity?). If Whonix uses a common timezone (UTC Universal time, at +0000, to make Whonix systems look more identical), then it's very, very odd that there is a difference between his local and universal time. It should be the same?
Local time: Sat 2018-06-30 07:09:46 UTC
Universal time: Sat 2018-06-30 07:09:46 UTC
RTC time: n/a
Time zone: Etc/UTC (UTC, +0000)
Could it be that Whonix still pulls the local and universal time from dom0, which pulls the universal time from the BIOS, but Whonix does not pull the timezone from dom0, and because it doesn't pull the wrong timezone from dom0 (due to wrong BIOS timezone), Whonix gets confused? If so, then that could explain why it messes up the local and universal time, that causes a time error.
In other words, if there is a missmatch in timezone and times in dom0 (due to wrong settings in BIOS), then it could still mess up the time in Whonix, because it fails to match up identical local and universal time (under the UTC, +0000 timezone)? Since with that timezone, both universal and local should be the same time.
Aekez
commented
Jul 1, 2018
•
|
Based on the assumption Whonix defaults to +0000 UTC timezone for all systems, then it seems Whonix complains if there is a difference between Local time, and Universal time (mathematical mismatch in time, that can be used to fingerprint Tor anonymity?). If Whonix uses a common timezone (UTC Universal time, at +0000, to make Whonix systems look more identical), then it's very, very odd that there is a difference between his local and universal time. It should be the same?
Could it be that Whonix still pulls the local and universal time from dom0, which pulls the universal time from the BIOS, but Whonix does not pull the timezone from dom0, and because it doesn't pull the wrong timezone from dom0 (due to wrong BIOS timezone), Whonix gets confused? If so, then that could explain why it messes up the local and universal time, that causes a time error. In other words, if there is a missmatch in timezone and times in dom0 (due to wrong settings in BIOS), then it could still mess up the time in Whonix, because it fails to match up identical local and universal time (under the UTC, +0000 timezone)? Since with that timezone, both universal and local should be the same time. |
andrewdavidwong
marked this as
a duplicate of
#3469
Jul 1, 2018
andrewdavidwong
closed this
Jul 1, 2018
andrewdavidwong
reopened this
Jul 1, 2018
andrewdavidwong
marked this as
not
a duplicate of
#3469
Jul 1, 2018
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
pure007
Jul 2, 2018
Thanks everyone for chiming in. @Aekez i just looked at my BIOS and the time is set to UTC. I think it may be a duplicate of #3469 like @esote said. The weird thing is that the error doesn't show up right away even after i fully update the system. On a fresh install, i would use it for a couple of days and then right after booting up it starts popping up.
pure007
commented
Jul 2, 2018
|
Thanks everyone for chiming in. @Aekez i just looked at my BIOS and the time is set to UTC. I think it may be a duplicate of #3469 like @esote said. The weird thing is that the error doesn't show up right away even after i fully update the system. On a fresh install, i would use it for a couple of days and then right after booting up it starts popping up. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
|
Duplicate of #3469 |
andrewdavidwong
marked this as
a duplicate of
#3469
Jul 2, 2018
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
andrewdavidwong
Jul 2, 2018
Member
This appears to be a duplicate of an existing issue. If you believe this is not really a duplicate, please leave a comment briefly explaining why. We'll be happy to take another look and, if appropriate, reopen this issue. Thank you.
|
This appears to be a duplicate of an existing issue. If you believe this is not really a duplicate, please leave a comment briefly explaining why. We'll be happy to take another look and, if appropriate, reopen this issue. Thank you. |
pure007 commentedJun 30, 2018
Qubes OS version:
Qubes release 4.0 (R4.0)
Affected component(s):
sys-whonix
Steps to reproduce the behavior:
Use the system for a few days.
Expected behavior:
no errors on sys-whonix startup
Actual behavior:
After using QubesOS 4.0 for a couple of days, whonixcheck starts to pop up with an error whenever sys-whonix starts.
ERROR: Systemd Clock Check Result:
Unexpected results by timedatectl.
timedatectl_output_pretty:
Local time: Sat 2018-06-30 07:09:46 UTC
Universal time: Sat 2018-06-30 07:09:46 UTC
RTC time: n/a
Time zone: Etc/UTC (UTC, +0000)
NTP enabled: yes
NTP synchronized: no
RTC in local TZ: no
DST active: n/a
It is generally recommended to keep the default as per Whonix Design. [1] If you did not change timezone related settings, please report this Whonix bug. If you know what you are doing and changed this on purpose, feel free to disable this check. [2]
[1] https://www.whonix.org/wiki/Dev/Design-Shared#timezone
[2] Create a file /etc/whonix.d/50_whonixcheck_user and add:
whonixcheck_skip_functions+=" check_systemd_clock "
General notes:
I havent really done a lot of changes to the system besides using Fedora-28 for my sys-net, sys-firewall, and sys-usb. I also have the system set to update via whonix.
Related issues: