According to the documentation:
https://qubes-doc-rst.readthedocs.io/de/latest/user/how-to-guides/how-to-reinstall-a-template.html
in order to reinstall a template you are required to uninstall the existing one using a command like
sudo dnf remove qubes-template-whonix-gw
but when that command is used for sys-usb, there is a return of “No match for argument: qubes-template-sys-usb”
From Templates — Qubes Docs (first link on the page you were reading):
In Getting Started, we covered the distinction in Qubes OS between where you install your software and where you run your software. Your software is installed in templates. Each template shares its root filesystem (i.e., all of its programs and system files) with all the qubes based on it. App qubes are where you run your software and store your data.
– so by that logic, sys-usb/sys-net/sys-firewalls should not be “Templates” but “App qubes”.
Edit1:
Wrt. the reinstalling of sys-usb/sys-net/sys-firewall, I guess you could use this:
and
Edit2:
Caution: “The pages are intended for advanced users.” – I’ve not tried any of it myself, but I would make a new backup of important files, read the full pages … and be prepared to either restore from the backup or cry a lot.
You could use salt…and I do…but be ready for a very steep learning curve.
Is it possible to create a new sys-usb AppVM? It is an AppVM, not a template.
For example, if the sys-usb AppVM was deleted and then the following command run:
sudo qubesctl state.sls qvm.sys-usb
will this delete the existing sys-usb AppVM and then recreate it with a clean VM?
Yes.
The trickiest part of rebuilding sys-* qubes is their dependencies (other qubes and/or configurations where they are used).
Some self-promotion but, maybe this post/project can help you better understand the process flow.
be gone!
I think I’m mistaken about this, please ignore above.
I wonder what means could be used to re-prompt for the user to re-select options for things like:
disposable-sys-usb
sys-usb-mouse
sys-net-as-usbvm
?
I would put a sleep between those two activities and check for the
success of the removal before running the state.
I thought the same and debated between “;” or “&&” but, regardless for either case qvm-remove doesn’t background by default such that, should the remove command fail and, sys-* exists, so too will the qubesctl “re-salt” command.
@unman
Could you offer any input/direction on a slick way to incorporate the pillar options I mentioned above? From my experience, “resalting” just uses the same options chosen at install.