I use an app based on a Whonix-Wrokstation template suddenly my tor support experienced unexpected issues and now it is preventing me from accessing my AppVM contents because it needs network to refresh new messages. Upon checking for status in swddate status it tells me - Preparation not done yet. More more information, see: sdwdate-gui → right click → Open sdwdate’s log
Which then brings me to a terminal some info will be left out for potential privacy reasons but the main information that appears to show errors shows as -
__ ### START: ### /usr/libexec/helper-scripts/onion-time-pre-script
__ Status: Subsequent run after boot.
__ Static Time Sanity Check: Within minimum time ‘Mon Jul 21 00:00:00 UTC 2025’ and expiration timestamp ‘Tue May 17 10:00:00 UTC 2033’, ok.
__ Tor circuit: not established
__ Tor Consensus Time Sanity Check: Clock within consensus parameters consensus/valid-after 2026-01-28 22:00:00 and consensus/valid-until 2026-01-29 01:00:00.
__ Conclusion: No Tor circuit established yet.
__ ### END: ### Exiting with exit_code ‘2’ indicating ‘wait, show busy icon and retry.’.
2026-01-28 --:–:-- (blocked out time stamp) - sdwdate - INFO - PREPARATION RESULT: onion-time-pre-script recommended to wait. Consider running systemcheck for more information.
This brings me to think has the time now passed expiration for time stamp? How can I fix this without having to switch templates and or delete the AppVM as I will lose all data due to the contents being a session based application where all data is deleted when a new qube is made.
(AI Assistance to help better the message since english is not my first language.)
I’m having a frustrating issue with my AppVM, which is based on a Whonix-Workstation template. I can’t connect to Tor at all in this qube, while everything else is working fine.
Recently, my Tor support hit a snag, and now I can’t access any of the contents in my AppVM because it needs a network connection to refresh new messages. When I checked the status using sdwdate, I saw the message: “Preparation not done yet. For more information, see: sdwdate-gui → right-click → Open sdwdate’s log.”
Looking at the log, I found these details (redacting some info for privacy):
Code
### START: /usr/libexec/helper-scripts/onion-time-pre-script
Status: Subsequent run after boot.
Static Time Sanity Check: Within minimum time ‘Mon Jul 21 00:00:00 UTC 2025’ and expiration timestamp ‘Tue May 17 10:00:00 UTC 2033’, ok.
Tor circuit: not established
Tor Consensus Time Sanity Check: Clock within consensus parameters (consensus/valid-after 2026-01-28 22:00:00 and consensus/valid-until 2026-01-29 01:00:00).
Conclusion: No Tor circuit established yet.
### END: Exiting with exit_code ‘2’ indicating ‘wait, show busy icon and retry.’
2026-01-28 --:–:-- (timestamp blocked out) - sdwdate - INFO - PREPARATION RESULT: onion-time-pre-script recommended to wait. Consider running systemcheck for more information.
I also ran a system check, and it reported:
Code
[INFO] [systemcheck] (qube name) | Whonix-Workstation | whonix-workstation-17 TemplateBased AppVM | Thu J (time and date redacted).
It’s all a bit perplexing, especially since this qube has worked perfectly for over a year. My SYS-WHONIX (the gateway) is connecting to Tor just fine, so it feels strange that this particular workstation is having such issues.
I’m really hoping to fix this without having to switch templates or delete the AppVM, which would lead to data loss, given that this is a session-based app.
If anyone has suggestions on how to get the connection back up and running—maybe checking the time parameters or running some diagnostics—I’d greatly appreciate your help!