My conclusion is, that dom0 has no knowledge about DispVM template status file
When you have killed and deleted disp1, disp2 (if existing) in Qubes VM Manager (QVMM) and then deleted
qvm-remove whonix-ws-dvm or using QVMM).... I.e. from a somewhat fresh/clean/resetted state. When you run
qvm-create-default-dvm whonix-ws (same for all templates), then "DVM boot complete" indicates that the DVM template was booted (without you seeing that).
Since seeing is believing, you can run in another terminal window "sudo xl console whonix-ws-dvm` during DVM creation (qvm-create-default-dvm). (Run this command several times if it does not work at first, since qvm-create-default-dvm may not be at that stage yet.)
qubesdb-read /qubes-vm-type inside DVM template outputs
That is why during that time tb-updater-first-boot.service will copy
/home/user. (Resulting in the
/home/user/.tb/tor-browser DispVM "template".)
The confusion comes from Qubes calling it on one hand DVM template and on the other hand starting that DVM template like an TemplateBased AppVM.
Start whonix-ws-dvm. (
qvm-start whonix-ws-dvm && qvm-run whonix-ws-dvm konsole)
- create some random file in root image
- create some random file in private image
Shut down the VM (
sudo poweroff). Start whonix-ws-dvm again. Learn, that:
- the random file in root image
/etc/zzzzzzzzzz is lost
- the random file in private image
/home/user/zzzzzzzzzz still exists
So DVM "template" really is started like an TemplateBased AppVM.
Shut the DVM "template" down for more experiments.
Now start whonix-ws TemplateVM. Create a file
/etc/zzz_create_in_whonix-ws_TemplateVM as well as
/home/user/zzz_create_in_whonix-ws_TemplateVM. Shut down whonix-ws- TemplateVM.
Start a DVM "template" konsole. See that
/etc/zzz_create_in_whonix-ws_TemplateVM exists. Start DispVM (
/usr/lib/qubes/qfile-daemon-dvm qubes.VMShell dom0 DEFAULT red). And run into some Qubes issue: