Removed/renamed VMs are not completely removed from system configuration data

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hi all,

I'm sending the following question at the request of Achim Patzner
(CCed):

```
What I did: I restored (among other machines) sys-net, sys-firewall
and work from a backup. These machines were marked as auto-start. They
were automaticaly renamed to *1 on import, their (auto-start) flags
were kept. I immediately used qvm-remove to get rid of them except
"work1" which I renamed to "work-32" using the qubes-manager.

What I expected: I expected the machines to be completely removed and
the name change being appropriately recorded in the database. I forgot
the auto-start feature at that time.

What I found:

Apr 08 00:42:34 dom0 systemd[1]: Started Qubes OS daemon.Apr 08 00:42:34 dom0 systemd[1]: Starting Qubes Dom0 startup setup...Apr 08 00:42:35 dom0 systemd[1]: Started Qubes Dom0 startup setup.Apr 08 00:42:35 dom0 systemd[1]: Started Qubes memory information reporter.Apr 08 00:42:35 dom0 systemd[1]: Starting Start Qubes VM sys-whonix1...Apr 08 00:42:35 dom0 systemd[1]: Starting Start Qubes VM sys-net1...Apr 08 00:42:35 dom0 systemd[1]: Starting Start Qubes VM sys-net...Apr 08 00:42:35 dom0 systemd[1]: Starting Start Qubes VM sys-usb...Apr 08 00:42:35 dom0 systemd[1]: Starting Start Qubes VM sys-firewall...Apr 08 00:42:35 dom0 systemd[1]: Starting Start Qubes VM sys-whonix...Apr 08 00:42:35 dom0 systemd[1]: Starting Start Qubes VM work-32...Apr 08 00:42:35 dom0 systemd[1]: Starting Start Qubes VM sys-firewall1...Apr 08 00:42:35 dom0 systemd[1]: Starting Start

Qubes VM work1...Apr 08 00:42:35 dom0 qvm-start[2683]: usage: qvm-start [--verbose] [--quiet] [--help] [--all] [--exclude EXCLUDE]Apr 08 00:42:35 dom0 qvm-start[2683]: [--skip-if-running]Apr 08 00:42:35 dom0 qvm-start[2683]: [--drive DRIVE | --hddisk IMAGE | --cdrom IMAGE | --install-windows-tools]Apr 08 00:42:35 dom0 qvm-start[2683]: [VMNAME [VMNAME ...]]Apr 08 00:42:35 dom0 qvm-start[2683]: qvm-start: error: no such domain: 'work1'Apr 08 00:42:35 dom0 qvm-start[2680]: usage: qvm-start [--verbose] [--quiet] [--help] [--all] [--exclude EXCLUDE]Apr 08 00:42:35 dom0 qvm-start[2680]: [--skip-if-running]Apr 08 00:42:35 dom0 qvm-start[2680]: [--drive DRIVE | --hddisk IMAGE | --cdrom IMAGE | --install-windows-tools]Apr 08 00:42:35 dom0 qvm-start[2680]: [VMNAME [VMNAME ...]]Apr 08 00:42:35 dom0
qvm-start[2680]: qvm-start: error: no such domain: 'sys-firewall1'Apr 08 00:42:35 dom0 qubesd[2548]: Starting sys-usbApr 08 00:42:35 dom0 qvm-start[2662]: usage: qvm-start [--verbose] [--quiet] [--help] [--all] [--exclude EXCLUDE]Apr 08 00:42:35 dom0 qvm-start[2662]: [--skip-if-running]Apr 08 00:42:35 dom0 qvm-start[2662]: [--drive DRIVE | --hddisk IMAGE | --cdrom IMAGE | --install-windows-tools]Apr 08 00:42:35 dom0 qvm-start[2662]: [VMNAME [VMNAME ...]]Apr 08 00:42:35 dom0 qvm-start[2662]: qvm-start: error: no such domain: 'sys-whonix1'Apr 08 00:42:35 dom0 qvm-start[2664]: usage: qvm-start [--verbose] [--quiet] [--help] [--all] [--exclude EXCLUDE]Apr 08 00:42:35 dom0 qvm-start[2664]: [--skip-if-running]Apr 08 00:42:35 dom0 qvm-start[2664]: [--drive DRIVE | --hddisk IMAGE | --cdrom IMAGE |
- --install-windows-tools]Apr 08 00:42:35 dom0 qvm-start[2664]: [VMNAME [VMNAME ...]]Apr 08 00:42:35 dom0 qvm-start[2664]: qvm-start: error: no such domain: 'sys-net1'Apr 08 00:42:35 dom0 systemd[1]: qube...@sys-net1.service: Main process exited, code=exited, status=2/INVALIDARGUMENTApr 08 00:42:35 dom0 systemd[1]: Failed to start Start Qubes VM sys-net1.Apr 08 00:42:35 dom0 systemd[1]: qube...@sys-net1.service: Unit entered failed state.Apr 08 00:42:35 dom0 systemd[1]: qube...@sys-net1.service: Failed with result 'exit-code'.Apr 08 00:42:35 dom0 systemd[1]: qube...@sys-whonix1.service: Main process exited, code=exited, status=2/INVALIDARGUMENTApr 08 00:42:35 dom0 systemd[1]: Failed to start Start Qubes VM sys-whonix1.Apr 08 00:42:35 dom0 systemd[1]: qube...@sys-whonix1.service: Unit entered failed state.Apr 08 00:42:35 dom0 systemd[1]: qube...@sys-whonix1.service:
Failed with result 'exit-code'.Apr 08 00:42:35 dom0 systemd[1]: qube...@sys-firewall1.service: Main process exited, code=exited, status=2/INVALIDARGUMENTApr 08 00:42:35 dom0 systemd[1]: Failed to start Start Qubes VM sys-firewall1.Apr 08 00:42:35 dom0 qubesd[2548]: Starting sys-whonixApr 08 00:42:35 dom0 systemd[1]: qube...@sys-firewall1.service: Unit entered failed state.Apr 08 00:42:35 dom0 systemd[1]: qube...@sys-firewall1.service: Failed with result 'exit-code'.Apr 08 00:42:35 dom0 systemd[1]: qube...@work1.service: Main process exited, code=exited, status=2/INVALIDARGUMENTApr 08 00:42:35 dom0 systemd[1]: Failed to start Start Qubes VM work1.Apr 08 00:42:35 dom0 qubesd[2548]: Starting sys-firewallApr 08 00:42:35 dom0 qubesd[2548]: Starting sys-netApr 08 00:42:35 dom0 qubesd[2548]: Starting work-32

* It still tries auto-starting the "*1" VMs even though they were
removed
* It still tries starting the "work1" VM
* Nevertheless work-32 is correctly launched so on renaming the flag
remained active.

How [can I] get these entries out of the appropriate database again?
Maybe the same part of the boot process which is removing corpses of
dispVMs could do these plausibility checks for machines that do not
exist anymore. Or add a qubes-system-dbck.
```

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAlrKgtoACgkQ203TvDlQ
MDAt1BAAlR/1wla5VBz6mYB5EoPTTYQwV0WY90aPCfumrzRj6et1EOTZUSZHNhZM
KAuIuF/lcKfIEFWxeYTUivS46wk16rd812IjbyKphPEr2XNQO+qZBjjs5qEyLWD4
bsPCZ7Sq+ZJg7Rrgj4H0Jzmu4SNqABYjNomM+hJjOU4ePgoXT7wb6d/Q/yXm//f3
r/OXHWVhpvr5jAv2+7h8LMeUI5yR30sp/522Er/7qY+Gm5bT/c1ySzJTZ1B5I6l4
qCIsyus7wQ622owDsLlqdPyMJ6U8UK75+jwoYNJIPcTc4lZ3ckTbb5EV+qicfsDz
Vak0c3I7tuGhSiYQA9f7uolvAiP0WFJldZIFYEi9wJARwQZiwwiM4aBsLQ3Mcg+G
6OFB1pTyuvRuabAw+BKMkrb92rbT7S8dTwE/q4qW9kl07o1kNdApOvb4rTvQmc3R
PA7NB381d0A7AZRv+RldN9aJ1zHqpQwf/EQ/MX1aoYd2pLQOCKBi09F5c63O7TRj
IFR5SJI0MW5M+qkmYQ6GDWubmdTkCpyrxgZkEsmWJrJ2qvjMq2sI1HrUMv3V/v+Z
3jn6zuqKTt7rocopSpdFTfBsBoy6tVjeNJ13BOV098Ni/TkD0Mq91WiQAzZWYjIJ
QOaoXScVJx+Pay2NT7hph1iWcQDvlP6+q/6fes6Gr4vk8KnJcXU=
=EEOl
-----END PGP SIGNATURE-----

[cooloutac]

I had same thing happen to me but only when restoring appvms of the same name installed on installer. or cancelling a restore halfway through and restoring again.

I also noticed you can remove them from system, but they will still be looked for on bootup. I ended up just reinstalling this time choosing not to install any default appvms and letting restore completely finish.

[awokd]

On Sun, April 8, 2018 9:01 pm, Andrew David Wong wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
>
> Hi all,
>
>
> I'm sending the following question at the request of Achim Patzner
> (CCed):

> * It still tries auto-starting the "*1" VMs even though they were
> removed * It still tries starting the "work1" VM
> * Nevertheless work-32 is correctly launched so on renaming the flag
> remained active.
>
> How [can I] get these entries out of the appropriate database again?
> Maybe the same part of the boot process which is removing corpses of
> dispVMs could do these plausibility checks for machines that do not exist
> anymore. Or add a qubes-system-dbck. ```

These settings used to get stored in /var/lib/qubes/qubes.xml but don't
see them in there for R4.0. Can you "qvm-prefs" the VMs you don't want to
try to autostart and set to false?

[NaBaCo]

I had the same problem, after renaming VMs restored from Q3.2.

--
NaBaCo