Now that we have a user forum in addition to qubes-users, it makes more
sense to link to /support/ than to link directly to qubes-users (or to
the forum, for that matter). This layer of redirection means allows us
to update just one thing (namely, the /support/ page) instead of having
to hunt through all the documentation every time support information
changes.
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.
When using a minimal template based sys-usb, `qubes-usb-proxy` appears to be an actual requirement, otherwise USB devices fail to attach. I'm not sure if this is also a bug (i.e., package `qubes-input-proxy-sender` should depend on `qubes-usb-proxy`), but it's definitely a documentation issue.
qvm-create command behaves differently:
--standalone is needed now in order to use --root-move-from
--mem is now set with --property=memory
and VM name must go at end of command
Additionally kernel='' (for none) must be set in order for the Win10 GUI to start.