In Whonix 7 it was possible to mitigate this by disabling sdwdate, it was also documented in the Whonix wiki.
I see I2P reporting the same clock-skew error with sdwdate disabled in Whonix 8.
Deactivating sdwdate is still documented, has not changed since then.
I improved the documentation a bit. Only running “sudo chmod -x /etc/init.d/sdwdate” would require reboot since the daemon would still run in background. It is better to run “sudo service sdwdate stop” followed by “sudo chmod -x /etc/init.d/sdwdate”. Note, that “sudo service sdwdate stop” won’t work, once /etc/init.d/sdwdate is no longer executable.
I currently can’t imagine any changes between Whonix 7 and Whonix 8 causing this. Sdwdate can still be disabled. Perhaps manually fixing the clock and restarting i2p will help?
Maybe i2p itself introduced new bugs since then?
Are you certain the same i2p version works in Whonix 7 but not in Whonix 8?
[quote=“Patrick, post:2, topic:147”]Deactivating sdwdate is still documented, has not changed since then.
I improved the documentation a bit. Only running “sudo chmod -x /etc/init.d/sdwdate” would require reboot since the daemon would still run in background. It is better to run “sudo service sdwdate stop” followed by “sudo chmod -x /etc/init.d/sdwdate”. Note, that “sudo service sdwdate stop” won’t work, once /etc/init.d/sdwdate is no longer executable.[/quote]
Good improvement, but I’ve observed the clock issues in I2P for a few days before coming and complaining in the forum, Whonix workstation was restarted multiple times during that period.
[quote=“Patrick, post:2, topic:147”]I currently can’t imagine any changes between Whonix 7 and Whonix 8 causing this. Sdwdate can still be disabled.
Maybe i2p itself introduced new bugs since then?
Are you certain the same i2p version works in Whonix 7 but not in Whonix 8?[/quote]
I have ran the same I2P version 0.9.11 on Whonix 7 few weeks before Whonix 8 was released. Everything was running smooth, since the switch to Whonix 8 sometimes I need to refresh certain eepsites for a few hours to be able to access them. I don’t know what can be different, perhaps debian stable which whonix 8 is based on uses an older version of jre and I2P doesn’t play nice with it? This is just a random assumption though, I lack knowledge to do some deeper investigation.
What exactly do you mean by this? Just use the date command in console or polling some internet time service? I am willing to sync time manually if that will make the I2P issues go away.
Could have to do with stable / testing indeed. Then the question would be, does i2p have such issues on vanilla Debian stable?
Setting time manually: either using date or the gui function of the desktop.
When you manually set the clock, sync with your watch. It would be interesting to run the “date” command in terminal from time to time. (The gui version may lie to you.) Without reboot, for hours and days there should be no difference (except 1 or 2 seconds maybe).
With sdwdate disabled, clock shouldn’t jump anymore. Could you verify that please? For one you could “tail -f /var/log/sdwdate.log” and check, that it’s not really running anymore. Running “pgrep sdwdate ; echo $?” should return 1 (not running).
Eventually i2p tries to connect before bootclockrandomization has run and then gets confused by it. You could try disabling it “sudo chmod -x /etc/init.d/bootclockrandomization”.
Eventually guest additions get into the way? Do you have them installed? They also synchronize host / guest. That feature gets turned off by sdwdate’s init script, but when it’s disabled, it won’t be turned off. You can turn that feature off by using “sudo service virtualbox-guest-utils stop”. (The rest of guest additions remains unaffected.)
After disabling bootclockrandomization, I still kept getting clock skew errors from I2P.
It seems like adjusting the clock manually is the workaround for Whonix 8 now.
I have documented these gotchas by editing the I2P wiki page a bit, feel free to review the changes.
I do have guest additions enabled but I didn’t try to modify anything related to them. I have tried your suggestions in the order you posted them and stopped as soon as I got some positive results. Just manually adjusting the clock for now seems practically much easier and quicker.
This is indeed a complex issue with many factors involved and a full investigation by trial and error seems to be very time consuming
Edit: typo