VM first-run requires restart

[tasket]

The way that Qubes initializes /rw when a VM is first started presents a problem to vm-boot-protect. It appears that the Linux GUI bits (which run later) become jammed if they try to populate defaults in /home/user; this may be due to the added immutable file attributes.

Solution may be to add a callback to Xinit.d or similar GUI feature, allowing the process to resume late in that special situation.

Current workaround is to stop the service with a CLI message requesting VM be restarted.

---

Note this is not an issue when the vm-boot-protect* service is enabled after the VM's first run.

[0brand]

I'm not sure if this falls under this issue.
Qubes 4.0.2
whonix-gw-15
sys-whonix (15)

I'm not sure this is the same issue that I'm having. When sys-whonix is started for the first time and any time thereafter. Tor is not enabled unless I run sudo whonixsetup Then everything works as expected. With the exception of vm-boot-protect I'm running a vanilla sys-whonix (whonix-gw-15) .

For comparison, I created a vanilla sys-whonix VM and Anon-Connection-Wizard start up when sys-whonix is run for the first . Which is the expected behavior.

[tasket]

@0brand That isn't related. This issue is about the initial creation of the VM's filesystem.

What you're experiencing is an expected loss of Tor's state every time you start sys-whonix. To avoid that, you would need to either switch to the vm-boot-protect service (which doesn't clear out /rw), or
use the whitelist feature so that specific Tor and Whonix files aren't removed. I don't know exactly which files, so that would be a good question for the Whonix forum.

Should also mention that, since sys-whonix is like a router with no services, its overall risk and attack surface is fairly low. Its probably the whonix-ws based vms that you want to protect more. I'd recommend using vm-boot-protect here as well, at least for starters.