Upgrading TemplateVM's by installing a new TemplateVM, then redo changes is way more user friendly, and technically there are benefits too. This option is currently behind a link at the bottom of this page , but it should be at the top.
- User friendlyness: The commands involved are less in number, less error prone, and far less complex.
- The technical benefit is that you are getting a fresh OS, which can not have issues that are possibly inherited from older versions. The fact that this is possible without reinstalling your laptop is actually one of the benefits of Qubes.
- Of course there are users who are lacking diskspace or who are on a slow or metered internet connection. They can still use the other method.
I want to explicitly include the part 'There is currently ... dependencies.' (line 33). Installing extra packages is the main thing users do in a TemplateVM, so including this saves users time from searching for such a method themselves, and it will prompt somebody who in fact does know a way to report this, because it would be a great addition. To be clear, a list of packages to be installed, should not include dependencies, because when the user manually installs packages formerly installed as dependencies, the packagemanager will not remove them automatically anymore when they are no longer needed.
My addition deviates a little bit from the succinct and technical style of the rest of the page, but given that upgrading templates is a frequent operation in Qubes that no user can avoid, I think this is fair.
please confirm my changes are correct.
if we are showing an example of applying some configuration values (like ... `= true`), then it should be not be commented out, to make clear this is what the user needs to do to apply a configuration.
also if the default of audio_low_latency is true, then (and in my dom0 it is the case) that it should be by default set to `true` not `false`. also updated the language to reflect what the `guid.conf` looks like by default.
Two changes:
1. Correct the file to be edited on the flash drive (s/xen.cfg/BOOTX64.cfg/), closing qubesos/qubes-issues#5851
2. Improve the list of affected Thinkpads, with citations when available.
The original instructions on how to verify the release signing key used
the `--list-sigs` option for gpg. However, unlike `--check-signatures`,
the `--list-sigs` option does not verify the authenticity of key
signatures.
See gpg2(1):
--list-signatures
--list-sigs
Same as --list-keys, but the signatures are listed too.
[...]
Note that in contrast to --check-signatures the key signatures
are not verified.
[...]
--check-signatures
--check-sigs
Same as --list-keys, but the key signatures are verified and
listed too.
[...]
This updates the documentation to use `--check-signatures` instead.
