mirror of
https://github.com/QubesOS/qubes-doc.git
synced 2025-08-05 21:24:15 -04:00
Convert to RST
This is done using tools at https://github.com/maiska/qubes-translation-utilz, commit 4c8e2a7f559fd37e29b51769ed1ab1c6cf92e00d.
This commit is contained in:
Marek Marczykowski-Górecki
parent
e3db139fe3
commit
7e464d0f40
428 changed files with 32833 additions and 29703 deletions
|
|
@ -1,230 +0,0 @@
|
|||
---
|
||||
advanced: true
|
||||
lang: en
|
||||
layout: doc
|
||||
permalink: /doc/templates/debian/in-place-upgrade/
|
||||
redirect_from:
|
||||
- /doc/template/debian/upgrade/
|
||||
- /doc/templates/debian/upgrade/
|
||||
- /doc/template/debian/upgrade-8-to-9/
|
||||
- /doc/debian-template-upgrade-8/
|
||||
- /en/doc/debian-template-upgrade-8/
|
||||
- /doc/DebianTemplateUpgrade8/
|
||||
- /wiki/DebianTemplateUpgrade8/
|
||||
ref: 133
|
||||
title: How to upgrade a Debian template in-place
|
||||
---
|
||||
|
||||
<div class="alert alert-danger" role="alert">
|
||||
<i class="fa fa-exclamation-triangle"></i>
|
||||
<b>Warning:</b> This page is intended for advanced users only. Most users
|
||||
seeking to upgrade should instead <a
|
||||
href="/doc/templates/debian/#installing">install a new Debian template</a>.
|
||||
Learn more about the two options <a
|
||||
href="/doc/templates/debian/#upgrading">here</a>.
|
||||
</div>
|
||||
|
||||
|
||||
This page provides instructions for performing an in-place upgrade of an
|
||||
installed [Debian Template](/doc/templates/debian/). If you wish to install a
|
||||
new, unmodified Debian template instead of upgrading a template that is already
|
||||
installed in your system, please see the [Debian
|
||||
Template](/doc/templates/debian/) page instead. ([Learn more about the two
|
||||
options.](/doc/templates/debian/#upgrading)) In general, upgrading a Debian
|
||||
template follows the same process as [upgrading a native Debian
|
||||
system](https://wiki.debian.org/DebianUpgrade).
|
||||
|
||||
## Summary instructions for Debian templates
|
||||
|
||||
**Important:** The prompt on each line indicates where each command should be
|
||||
entered: `dom0`, `debian-<old>`, or `debian-<new>`, where `<old>` is the Debian
|
||||
version number *from* which you are upgrading, and `<new>` is the Debian
|
||||
version number *to* which you are upgrading. The instructions may differ for
|
||||
certain releases. See [release-specific notes](#release-specific-notes) for any
|
||||
instructions specific to your particular release.
|
||||
|
||||
```
|
||||
[user@dom0 ~]$ qvm-clone debian-<old> debian-<new>
|
||||
[user@dom0 ~]$ qvm-run -a debian-<new> gnome-terminal
|
||||
[user@debian-<new> ~]$ sudo sed -i 's/<old-name>/<new-name>/g' /etc/apt/sources.list
|
||||
[user@debian-<new> ~]$ sudo sed -i 's/<old-name>/<new-name>/g' /etc/apt/sources.list.d/qubes-r4.list
|
||||
[user@debian-<new> ~]$ sudo apt update
|
||||
[user@debian-<new> ~]$ sudo apt upgrade
|
||||
[user@debian-<new> ~]$ sudo apt dist-upgrade
|
||||
[user@dom0 ~]$ qvm-shutdown debian-<new>
|
||||
```
|
||||
|
||||
**Recommended:** [Switch everything that was set to the old template to the new template.](/doc/templates/#switching)
|
||||
|
||||
## Detailed instructions for Debian templates
|
||||
|
||||
These instructions will show you how to upgrade Debian templates. The same
|
||||
general procedure may be used to upgrade any template based on the standard
|
||||
Debian template.
|
||||
|
||||
**Important:** The prompt on each line indicates where each command should be
|
||||
entered: `dom0`, `debian-<old>`, or `debian-<new>`, where `<old>` is the Debian
|
||||
version number *from* which you are upgrading, and `<new>` is the Debian
|
||||
version number *to* which you are upgrading. The instructions may differ for
|
||||
certain releases. See [release-specific notes](#release-specific-notes) for any
|
||||
instructions specific to your particular release.
|
||||
|
||||
1. Ensure the existing template is not running.
|
||||
|
||||
```
|
||||
[user@dom0 ~]$ qvm-shutdown debian-<old>
|
||||
```
|
||||
|
||||
2. Clone the existing template and start a terminal in the new template.
|
||||
|
||||
```
|
||||
[user@dom0 ~]$ qvm-clone debian-<old> debian-<new>
|
||||
[user@dom0 ~]$ qvm-run -a debian-<new> gnome-terminal
|
||||
```
|
||||
|
||||
3. Update your `apt` repositories to use the new release's code name instead of
|
||||
the old release's code name. (This can be done manually with a text editor,
|
||||
but `sed` can be used to automatically update the files.)
|
||||
|
||||
```
|
||||
[user@debian-<new> ~]$ sudo sed -i 's/<old-name>/<new-name>/g' /etc/apt/sources.list
|
||||
[user@debian-<new> ~]$ sudo sed -i 's/<old-name>/<new-name>/g' /etc/apt/sources.list.d/qubes-r4.list
|
||||
```
|
||||
|
||||
4. Update the package lists and upgrade. During the process, it may prompt you
|
||||
to overwrite the file `qubes-r4.list`. You should overwrite this file.
|
||||
|
||||
```
|
||||
[user@debian-<new> ~]$ sudo apt update
|
||||
[user@debian-<new> ~]$ sudo apt upgrade
|
||||
[user@debian-<new> ~]$ sudo apt dist-upgrade
|
||||
```
|
||||
|
||||
5. (Optional) Remove unnecessary packages that were previously installed.
|
||||
|
||||
```
|
||||
[user@debian-<new> ~]$ sudo apt-get autoremove
|
||||
```
|
||||
|
||||
6. (Optional) Clean cached packages from `/var/cache/apt`.
|
||||
|
||||
```
|
||||
[user@debian-<new> ~]$ sudo apt-get clean
|
||||
```
|
||||
|
||||
7. (Optional) Trim the new template. (This should [no longer be
|
||||
necessary](/doc/templates/#important-notes), but it does not hurt. Some
|
||||
users have [reported](https://github.com/QubesOS/qubes-issues/issues/5055)
|
||||
that it makes a difference.)
|
||||
|
||||
```
|
||||
[user@debian-<new> ~]$ sudo fstrim -av
|
||||
[user@dom0 ~]$ qvm-shutdown debian-<new>
|
||||
[user@dom0 ~]$ qvm-start debian-<new>
|
||||
[user@debian-<new> ~]$ sudo fstrim -av
|
||||
```
|
||||
|
||||
8. Shut down the new template.
|
||||
|
||||
```
|
||||
[user@dom0 ~]$ qvm-shutdown debian-<new>
|
||||
```
|
||||
|
||||
9. (Recommended) [Switch everything that was set to the old template to the new
|
||||
template.](/doc/templates/#switching)
|
||||
|
||||
10. (Optional) Make the new template the global default.
|
||||
|
||||
```
|
||||
[user@dom0 ~]$ qubes-prefs --set default_template debian-<new>
|
||||
```
|
||||
|
||||
11. (Optional) [Uninstall the old template.](/doc/templates/#uninstalling) Make
|
||||
sure that the template you're uninstalling is the old one, not the new one!
|
||||
|
||||
## Standalones
|
||||
|
||||
The procedure for upgrading a Debian [standalone](/doc/standalone-and-hvm/) is
|
||||
the same as for a template.
|
||||
|
||||
## Release-specific notes
|
||||
|
||||
This section contains notes about upgrading to specific releases.
|
||||
|
||||
### Debian 11 ("Bullseye")
|
||||
|
||||
Please see [Debian's Bullseye upgrade
|
||||
instructions](https://www.debian.org/releases/bullseye/amd64/release-notes/ch-upgrading.en.html).
|
||||
In particular: for APT source lines referencing the security archive, the
|
||||
format has changed slightly along with the release name, going from
|
||||
buster/updates to bullseye-security; see [Section 5.1.2, “Changed security
|
||||
archive
|
||||
layout”](https://www.debian.org/releases/stable/mips64el/release-notes/ch-information.en.html#security-archive).
|
||||
|
||||
This means that, when upgrading from Buster to Bullseye, an additional `sed`
|
||||
command is required:
|
||||
|
||||
```
|
||||
[user@dom0 ~]$ qvm-clone debian-10 debian-11
|
||||
[user@dom0 ~]$ qvm-run -a debian-11 gnome-terminal
|
||||
[user@debian-<new> ~]$ sudo sed -i 's/buster/bullseye/g' /etc/apt/sources.list
|
||||
[user@debian-<new> ~]$ sudo sed -i 's/debian-security bullseye\/updates/debian-security bullseye-security/g' /etc/apt/sources.list
|
||||
[user@debian-<new> ~]$ sudo sed -i 's/buster/bullseye/g' /etc/apt/sources.list.d/qubes-r4.list
|
||||
[user@debian-<new> ~]$ sudo apt update
|
||||
[user@debian-<new> ~]$ sudo apt upgrade
|
||||
[user@debian-<new> ~]$ sudo apt dist-upgrade
|
||||
[user@dom0 ~]$ qvm-shutdown debian-11
|
||||
```
|
||||
|
||||
### Debian 10 ("Buster")
|
||||
|
||||
Please see [Debian's Buster upgrade
|
||||
instructions](https://www.debian.org/releases/buster/amd64/release-notes.en.txt).
|
||||
|
||||
### Debian 9 ("Stretch")
|
||||
|
||||
* The upgrade process may prompt you to overwrite two files: `qubes-r4.list`
|
||||
and `pulse/client.conf`. `qubes-r4.list` can be overwritten, but
|
||||
`pulse/client.conf` must be left as the currently-installed version.
|
||||
|
||||
* If sound is not working, you may need to enable the Qubes testing repository
|
||||
to get the testing version of `qubes-gui-agent`. This can be done by editing
|
||||
the `/etc/apt/sources.list.d/qubes-r4.list` file and uncommenting the `Qubes Updates Candidates` repo.
|
||||
|
||||
* User-initiated updates/upgrades may not run when a template first starts.
|
||||
This is due to a new Debian config setting that attempts to update
|
||||
automatically; it should be disabled with `sudo systemctl disable apt-daily.{service,timer}`.
|
||||
|
||||
Relevant discussions:
|
||||
|
||||
* [Stretch Template Installation](https://groups.google.com/forum/#!topicsearchin/qubes-devel/debian$20stretch/qubes-devel/4rdayBF_UTc)
|
||||
* [Stretch availability in 3.2](https://groups.google.com/forum/#!topicsearchin/qubes-devel/debian$20stretch/qubes-devel/cekPfBqQMOI)
|
||||
* [Fixing sound in Debian Stretch](https://groups.google.com/forum/#!topic/qubes-users/JddCE54GFiU)
|
||||
* [User apt commands blocked on startup](https://github.com/QubesOS/qubes-issues/issues/2621)
|
||||
|
||||
Also see [Debian's Stretch upgrade
|
||||
instructions](https://www.debian.org/releases/stretch/amd64/release-notes.en.txt).
|
||||
|
||||
### Debian 8 ("Jessie")
|
||||
|
||||
Please see [Debian's Jessie upgrade
|
||||
instructions](https://www.debian.org/releases/jessie/amd64/release-notes.en.txt).
|
||||
|
||||
### End-of-life (EOL) releases
|
||||
|
||||
We strongly recommend against using any Debian release that has reached
|
||||
[end-of-life
|
||||
(EOL)](https://wiki.debian.org/DebianReleases#Production_Releases).
|
||||
|
||||
## Additional information
|
||||
|
||||
* Please note that, if you installed packages from one of the
|
||||
[testing](/doc/testing/) repositories, you must make sure that the repository
|
||||
is enabled in `/etc/apt/sources.list.d/qubes-r4.list` before attempting the
|
||||
upgrade. Otherwise, your upgrade will
|
||||
[break](https://github.com/QubesOS/qubes-issues/issues/2418).
|
||||
|
||||
* By default, Qubes uses code names in the `apt` sources files, although the
|
||||
templates are referred to by release number. Check the code names for the
|
||||
templates, and ensure you are aware of any changes you have made in the
|
||||
repository definitions.
|
||||
208
user/templates/debian/debian-upgrade.rst
Normal file
208
user/templates/debian/debian-upgrade.rst
Normal file
|
|
@ -0,0 +1,208 @@
|
|||
=========================================
|
||||
How to upgrade a Debian template in-place
|
||||
=========================================
|
||||
|
||||
.. warning::
|
||||
|
||||
This page is intended for advanced users.
|
||||
|
||||
.. DANGER::
|
||||
|
||||
**Warning:** This page is intended for advanced users only. Most users seeking to upgrade should instead :ref:`install a new Debian template <user/templates/debian/debian:installing>`. Learn more about the two options :ref:`here <user/templates/debian/debian:upgrading>`.
|
||||
|
||||
This page provides instructions for performing an in-place upgrade of an installed :doc:`Debian Template </user/templates/debian/debian>`. If you wish to install a new, unmodified Debian template instead of upgrading a template that is already installed in your system, please see the :doc:`Debian Template </user/templates/debian/debian>` page instead. (:ref:`Learn more about the two options. <user/templates/debian/debian:upgrading>`) In general, upgrading a Debian template follows the same process as `upgrading a native Debian system <https://wiki.debian.org/DebianUpgrade>`__.
|
||||
|
||||
Summary instructions for Debian templates
|
||||
-----------------------------------------
|
||||
|
||||
|
||||
**Important:** The prompt on each line indicates where each command should be entered: ``dom0``, ``debian-<old>``, or ``debian-<new>``, where ``<old>`` is the Debian version number *from* which you are upgrading, and ``<new>`` is the Debian version number *to* which you are upgrading. The instructions may differ for certain releases. See `release-specific notes <#release-specific-notes>`__ for any instructions specific to your particular release.
|
||||
|
||||
.. code:: bash
|
||||
|
||||
[user@dom0 ~]$ qvm-clone debian-<old> debian-<new>
|
||||
[user@dom0 ~]$ qvm-run -a debian-<new> gnome-terminal
|
||||
[user@debian-<new> ~]$ sudo sed -i 's/<old-name>/<new-name>/g' /etc/apt/sources.list
|
||||
[user@debian-<new> ~]$ sudo sed -i 's/<old-name>/<new-name>/g' /etc/apt/sources.list.d/qubes-r4.list
|
||||
[user@debian-<new> ~]$ sudo apt update
|
||||
[user@debian-<new> ~]$ sudo apt upgrade
|
||||
[user@debian-<new> ~]$ sudo apt dist-upgrade
|
||||
[user@dom0 ~]$ qvm-shutdown debian-<new>
|
||||
|
||||
|
||||
**Recommended:** :ref:`Switch everything that was set to the old template to the new template. <user/templates/templates:switching>`
|
||||
|
||||
Detailed instructions for Debian templates
|
||||
------------------------------------------
|
||||
|
||||
|
||||
These instructions will show you how to upgrade Debian templates. The same general procedure may be used to upgrade any template based on the standard Debian template.
|
||||
|
||||
**Important:** The prompt on each line indicates where each command should be entered: ``dom0``, ``debian-<old>``, or ``debian-<new>``, where ``<old>`` is the Debian version number *from* which you are upgrading, and ``<new>`` is the Debian version number *to* which you are upgrading. The instructions may differ for certain releases. See `release-specific notes <#release-specific-notes>`__ for any instructions specific to your particular release.
|
||||
|
||||
1. Ensure the existing template is not running.
|
||||
|
||||
.. code:: bash
|
||||
|
||||
[user@dom0 ~]$ qvm-shutdown debian-<old>
|
||||
|
||||
|
||||
2. Clone the existing template and start a terminal in the new template.
|
||||
|
||||
.. code:: bash
|
||||
|
||||
[user@dom0 ~]$ qvm-clone debian-<old> debian-<new>
|
||||
[user@dom0 ~]$ qvm-run -a debian-<new> gnome-terminal
|
||||
|
||||
|
||||
3. Update your ``apt`` repositories to use the new release’s code name instead of the old release’s code name. (This can be done manually with a text editor, but ``sed`` can be used to automatically update the files.)
|
||||
|
||||
.. code:: bash
|
||||
|
||||
[user@debian-<new> ~]$ sudo sed -i 's/<old-name>/<new-name>/g' /etc/apt/sources.list
|
||||
[user@debian-<new> ~]$ sudo sed -i 's/<old-name>/<new-name>/g' /etc/apt/sources.list.d/qubes-r4.list
|
||||
|
||||
|
||||
|
||||
4. Update the package lists and upgrade. During the process, it may prompt you to overwrite the file ``qubes-r4.list``. You should overwrite this file.
|
||||
|
||||
.. code:: bash
|
||||
|
||||
[user@debian-<new> ~]$ sudo apt update
|
||||
[user@debian-<new> ~]$ sudo apt upgrade
|
||||
[user@debian-<new> ~]$ sudo apt dist-upgrade
|
||||
|
||||
|
||||
|
||||
5. (Optional) Remove unnecessary packages that were previously installed.
|
||||
|
||||
.. code:: bash
|
||||
|
||||
[user@debian-<new> ~]$ sudo apt-get autoremove
|
||||
|
||||
|
||||
|
||||
6. (Optional) Clean cached packages from ``/var/cache/apt``.
|
||||
|
||||
.. code:: bash
|
||||
|
||||
[user@debian-<new> ~]$ sudo apt-get clean
|
||||
|
||||
|
||||
|
||||
7. (Optional) Trim the new template. (This should :ref:`no longer be necessary <user/templates/templates:important notes>`, but it does not hurt. Some users have `reported <https://github.com/QubesOS/qubes-issues/issues/5055>`__ that it makes a difference.)
|
||||
|
||||
.. code:: bash
|
||||
|
||||
[user@debian-<new> ~]$ sudo fstrim -av
|
||||
[user@dom0 ~]$ qvm-shutdown debian-<new>
|
||||
[user@dom0 ~]$ qvm-start debian-<new>
|
||||
[user@debian-<new> ~]$ sudo fstrim -av
|
||||
|
||||
|
||||
8. Shut down the new template.
|
||||
|
||||
.. code:: bash
|
||||
|
||||
[user@dom0 ~]$ qvm-shutdown debian-<new>
|
||||
|
||||
|
||||
9. (Recommended) :ref:`Switch everything that was set to the old template to the new template. <user/templates/templates:switching>`
|
||||
|
||||
10. (Optional) Make the new template the global default.
|
||||
|
||||
.. code:: bash
|
||||
|
||||
[user@dom0 ~]$ qubes-prefs --set default_template debian-<new>
|
||||
|
||||
|
||||
11. (Optional) :ref:`Uninstall the old template. <user/templates/templates:uninstalling>` Make sure that the template you’re uninstalling is the old one, not the new one!
|
||||
|
||||
|
||||
|
||||
Standalones
|
||||
-----------
|
||||
|
||||
|
||||
The procedure for upgrading a Debian :doc:`standalone </user/advanced-topics/standalones-and-hvms>` is the same as for a template.
|
||||
|
||||
Release-specific notes
|
||||
----------------------
|
||||
|
||||
|
||||
This section contains notes about upgrading to specific releases.
|
||||
|
||||
Debian 11 ("Bullseye")
|
||||
^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
|
||||
Please see `Debian’s Bullseye upgrade instructions <https://www.debian.org/releases/bullseye/amd64/release-notes/ch-upgrading.en.html>`__. In particular: for APT source lines referencing the security archive, the format has changed slightly along with the release name, going from buster/updates to bullseye-security; see `Section 5.1.2, “Changed security archive layout” <https://www.debian.org/releases/stable/mips64el/release-notes/ch-information.en.html#security-archive>`__.
|
||||
|
||||
This means that, when upgrading from Buster to Bullseye, an additional ``sed`` command is required:
|
||||
|
||||
.. code:: bash
|
||||
|
||||
[user@dom0 ~]$ qvm-clone debian-10 debian-11
|
||||
[user@dom0 ~]$ qvm-run -a debian-11 gnome-terminal
|
||||
[user@debian-<new> ~]$ sudo sed -i 's/buster/bullseye/g' /etc/apt/sources.list
|
||||
[user@debian-<new> ~]$ sudo sed -i 's/debian-security bullseye\/updates/debian-security bullseye-security/g' /etc/apt/sources.list
|
||||
[user@debian-<new> ~]$ sudo sed -i 's/buster/bullseye/g' /etc/apt/sources.list.d/qubes-r4.list
|
||||
[user@debian-<new> ~]$ sudo apt update
|
||||
[user@debian-<new> ~]$ sudo apt upgrade
|
||||
[user@debian-<new> ~]$ sudo apt dist-upgrade
|
||||
[user@dom0 ~]$ qvm-shutdown debian-11
|
||||
|
||||
|
||||
Debian 10 ("Buster")
|
||||
^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
|
||||
Please see `Debian’s Buster upgrade instructions <https://www.debian.org/releases/buster/amd64/release-notes.en.txt>`__.
|
||||
|
||||
Debian 9 ("Stretch")
|
||||
^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
|
||||
- The upgrade process may prompt you to overwrite two files: ``qubes-r4.list`` and ``pulse/client.conf``. ``qubes-r4.list`` can be overwritten, but ``pulse/client.conf`` must be left as the currently-installed version.
|
||||
|
||||
- If sound is not working, you may need to enable the Qubes testing repository to get the testing version of ``qubes-gui-agent``. This can be done by editing the ``/etc/apt/sources.list.d/qubes-r4.list`` file and uncommenting the ``Qubes Updates Candidates`` repo.
|
||||
|
||||
- User-initiated updates/upgrades may not run when a template first starts. This is due to a new Debian config setting that attempts to update automatically; it should be disabled with ``sudo systemctl disable apt-daily.{service,timer}``.
|
||||
|
||||
|
||||
|
||||
Relevant discussions:
|
||||
|
||||
- `Stretch Template Installation <https://groups.google.com/forum/#!topicsearchin/qubes-devel/debian$20stretch/qubes-devel/4rdayBF_UTc>`__
|
||||
|
||||
- `Stretch availability in 3.2 <https://groups.google.com/forum/#!topicsearchin/qubes-devel/debian$20stretch/qubes-devel/cekPfBqQMOI>`__
|
||||
|
||||
- `Fixing sound in Debian Stretch <https://groups.google.com/forum/#!topic/qubes-users/JddCE54GFiU>`__
|
||||
|
||||
- `User apt commands blocked on startup <https://github.com/QubesOS/qubes-issues/issues/2621>`__
|
||||
|
||||
|
||||
|
||||
Also see `Debian’s Stretch upgrade instructions <https://www.debian.org/releases/stretch/amd64/release-notes.en.txt>`__.
|
||||
|
||||
Debian 8 ("Jessie")
|
||||
^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
|
||||
Please see `Debian’s Jessie upgrade instructions <https://www.debian.org/releases/jessie/amd64/release-notes.en.txt>`__.
|
||||
|
||||
End-of-life (EOL) releases
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
|
||||
We strongly recommend against using any Debian release that has reached `end-of-life (EOL) <https://wiki.debian.org/DebianReleases#Production_Releases>`__.
|
||||
|
||||
Additional information
|
||||
----------------------
|
||||
|
||||
|
||||
- Please note that, if you installed packages from one of the :doc:`testing </user/downloading-installing-upgrading/testing>` repositories, you must make sure that the repository is enabled in ``/etc/apt/sources.list.d/qubes-r4.list`` before attempting the upgrade. Otherwise, your upgrade will `break <https://github.com/QubesOS/qubes-issues/issues/2418>`__.
|
||||
|
||||
- By default, Qubes uses code names in the ``apt`` sources files, although the templates are referred to by release number. Check the code names for the templates, and ensure you are aware of any changes you have made in the repository definitions.
|
||||
|
||||
|
||||
|
|
@ -1,108 +0,0 @@
|
|||
---
|
||||
lang: en
|
||||
layout: doc
|
||||
permalink: /doc/templates/debian/
|
||||
redirect_from:
|
||||
- /doc/debian/
|
||||
- /en/doc/templates/debian/
|
||||
- /doc/Templates/Debian/
|
||||
- /wiki/Templates/Debian/
|
||||
ref: 134
|
||||
title: Debian templates
|
||||
---
|
||||
|
||||
The Debian [template](/doc/templates/) is an officially [supported](/doc/supported-releases/#templates) template in Qubes OS.
|
||||
The Current version is Debian 12 ("bookworm"). It is available in 3 versions - `debian-12`, a standard template; `debian-12-xfce`, a larger template with more installed applications, selected for [Xfce](/doc/templates/xfce/); `debian-12-minimal`.
|
||||
This page is about the "full" templates.
|
||||
For the minimal version, please see the [Minimal templates](/doc/templates/minimal/) page.
|
||||
|
||||
## Installing
|
||||
|
||||
To [install](/doc/templates/#installing) a specific Debian template that is not currently installed in your system, use the Qubes Template Manager, or use the following command in a dom0 terminal:
|
||||
|
||||
```
|
||||
$ qvm-template install XX
|
||||
```
|
||||
(Replace `XX` with the name of the template you wish to install.)
|
||||
|
||||
To reinstall a Debian template that is already installed in your system, see [How to Reinstall a template](/doc/reinstall-template/).
|
||||
|
||||
## After Installing
|
||||
|
||||
After installing a fresh Debian template, we recommend performing the following steps:
|
||||
|
||||
1. [Update the template](/doc/software-update-vm/).
|
||||
|
||||
2. [Switch any app qubes that are based on the old template to the new one](/doc/templates/#switching).
|
||||
|
||||
3. If desired, [uninstall the old template](/doc/templates/#uninstalling).
|
||||
|
||||
## Installing software
|
||||
|
||||
See [How to Install Software](/doc/how-to-install-software/).
|
||||
|
||||
## Updating
|
||||
|
||||
For routine daily updates within a given release, see [How to Update](/doc/how-to-update/).
|
||||
|
||||
## Upgrading
|
||||
|
||||
There are two ways to upgrade your template to a new Debian release:
|
||||
|
||||
- **Recommended:** [Install a fresh template to replace the existing one.](#installing) **This option may be simpler for less experienced users.** After you install the new template, redo all desired template modifications and [switch everything that was set to the old template to the new template](/doc/templates/#switching). You may want to write down the modifications you make to your templates so that you remember what to redo on each fresh install. In the old Debian template, see `/var/log/dpkg.log` and `/var/log/apt/history.log` for logs of package manager actions.
|
||||
|
||||
- **Advanced:** [Perform an in-place upgrade of an existing Debian template.](/doc/templates/debian/in-place-upgrade/) This option will preserve any modifications you've made to the template, **but it may be more complicated for less experienced users.**
|
||||
|
||||
## Release-specific notes
|
||||
|
||||
This section contains notes about specific Debian releases.
|
||||
|
||||
### Debian 12
|
||||
|
||||
The Debian-12 templates that ship with release 4.2.4 cannot be used for salting Fedora templates. You must change the template used by `default-mgmt-dvm` to a Fedora template. You can do this in the Qubes Template Switcher tool, or at the command line using `qvm-prefs default-mgmt-dvm template`.
|
||||
|
||||
If you have a Debian template from an earlier release that you want to use for salting Qubes, you **must** stop the salt-common and salt-ssh packages from being upgraded.
|
||||
Do this by marking these packages on hold *before* updating the template.
|
||||
|
||||
```
|
||||
sudo apt-mark hold salt-common salt-ssh
|
||||
sudo apt update
|
||||
sudo apt upgrade
|
||||
```
|
||||
This is a [known bug](https://github.com/QubesOS/qubes-issues/issues/9129) in Salt which affects version 3006-5.
|
||||
|
||||
### Starting services
|
||||
|
||||
The Debian way (generally) is to start daemons if they are installed.
|
||||
This means that if you install (say) ssh-server in a template, *all* the qubes that use that template will run a ssh server when they start. (They will, naturally, all have the same server key.) This may not be what you want.
|
||||
|
||||
So be very careful when installing software in Templates - if the daemon spawns outbound connections then there is a serious security risk.
|
||||
|
||||
In general, a reasonable approach would be, (using ssh as example):
|
||||
|
||||
- Install the ssh service.
|
||||
- `systemctl stop ssh`
|
||||
- `systemctl disable ssh`
|
||||
- `systemctl mask ssh`
|
||||
- Close down template
|
||||
|
||||
Now the ssh service will **NOT** start in qubes based on this template.
|
||||
|
||||
Where you **DO** want the service to run, put this in `/rw/config/rc.local`:
|
||||
|
||||
```
|
||||
systemctl unmask ssh
|
||||
systemctl start ssh
|
||||
```
|
||||
|
||||
Don't forget to make the file executable.
|
||||
|
||||
### Unattended Upgrades
|
||||
|
||||
Some users have noticed that on upgrading Debian templates, the `unattended-upgrade` package is installed.
|
||||
This package is pulled in as part of a Recommend chain, and can be purged.
|
||||
The lesson is that you should carefully look at what is being installed to your system, particularly if you run `dist-upgrade`.
|
||||
|
||||
### Package installation errors in Qubes 4.0
|
||||
|
||||
If some packages throw installation errors, see [this guide.](/doc/vm-troubleshooting/#fixing-package-installation-errors)
|
||||
131
user/templates/debian/debian.rst
Normal file
131
user/templates/debian/debian.rst
Normal file
|
|
@ -0,0 +1,131 @@
|
|||
================
|
||||
Debian templates
|
||||
================
|
||||
|
||||
|
||||
The Debian :doc:`template </user/templates/templates>` is an officially :ref:`supported <user/downloading-installing-upgrading/supported-releases:templates>` template in Qubes OS. The Current version is Debian 12 (“bookworm”). It is available in 3 versions - ``debian-12``, a standard template; ``debian-12-xfce``, a larger template with more installed applications, selected for :doc:`Xfce </user/templates/xfce-templates>`; ``debian-12-minimal``. This page is about the “full” templates. For the minimal version, please see the :doc:`Minimal templates </user/templates/minimal-templates>` page.
|
||||
|
||||
Installing
|
||||
----------
|
||||
|
||||
|
||||
To :ref:`install <user/templates/templates:installing>` a specific Debian template that is not currently installed in your system, use the Qubes Template Manager, or use the following command in a dom0 terminal:
|
||||
|
||||
.. code:: bash
|
||||
|
||||
$ qvm-template install XX
|
||||
|
||||
|
||||
|
||||
(Replace ``XX`` with the name of the template you wish to install.)
|
||||
|
||||
To reinstall a Debian template that is already installed in your system, see :doc:`How to Reinstall a template </user/how-to-guides/how-to-reinstall-a-template>`.
|
||||
|
||||
After Installing
|
||||
----------------
|
||||
|
||||
|
||||
After installing a fresh Debian template, we recommend performing the following steps:
|
||||
|
||||
1. :doc:`Update the template </user/how-to-guides/how-to-install-software>`.
|
||||
|
||||
2. :ref:`Switch any app qubes that are based on the old template to the new one <user/templates/templates:switching>`.
|
||||
|
||||
3. If desired, :ref:`uninstall the old template <user/templates/templates:uninstalling>`.
|
||||
|
||||
|
||||
|
||||
Installing software
|
||||
-------------------
|
||||
|
||||
|
||||
See :doc:`How to Install Software </user/how-to-guides/how-to-install-software>`.
|
||||
|
||||
Updating
|
||||
--------
|
||||
|
||||
|
||||
For routine daily updates within a given release, see :doc:`How to Update </user/how-to-guides/how-to-update>`.
|
||||
|
||||
Upgrading
|
||||
---------
|
||||
|
||||
|
||||
There are two ways to upgrade your template to a new Debian release:
|
||||
|
||||
- **Recommended:** `Install a fresh template to replace the existing one. <#installing>`__ **This option may be simpler for less experienced users.** After you install the new template, redo all desired template modifications and :ref:`switch everything that was set to the old template to the new template <user/templates/templates:switching>`. You may want to write down the modifications you make to your templates so that you remember what to redo on each fresh install. In the old Debian template, see ``/var/log/dpkg.log`` and ``/var/log/apt/history.log`` for logs of package manager actions.
|
||||
|
||||
- **Advanced:** :doc:`Perform an in-place upgrade of an existing Debian template. </user/templates/debian/debian-upgrade>` This option will preserve any modifications you’ve made to the template, **but it may be more complicated for less experienced users.**
|
||||
|
||||
|
||||
|
||||
Release-specific notes
|
||||
----------------------
|
||||
|
||||
|
||||
This section contains notes about specific Debian releases.
|
||||
|
||||
Debian 12
|
||||
^^^^^^^^^
|
||||
|
||||
|
||||
The Debian-12 templates that ship with release 4.2.4 cannot be used for salting Fedora templates. You must change the template used by ``default-mgmt-dvm`` to a Fedora template. You can do this in the Qubes Template Switcher tool, or at the command line using ``qvm-prefs default-mgmt-dvm template``.
|
||||
|
||||
If you have a Debian template from an earlier release that you want to use for salting Qubes, you **must** stop the salt-common and salt-ssh packages from being upgraded. Do this by marking these packages on hold *before* updating the template.
|
||||
|
||||
.. code:: bash
|
||||
|
||||
sudo apt-mark hold salt-common salt-ssh
|
||||
sudo apt update
|
||||
sudo apt upgrade
|
||||
|
||||
|
||||
|
||||
This is a `known bug <https://github.com/QubesOS/qubes-issues/issues/9129>`__ in Salt which affects version 3006-5.
|
||||
|
||||
Starting services
|
||||
^^^^^^^^^^^^^^^^^
|
||||
|
||||
|
||||
The Debian way (generally) is to start daemons if they are installed. This means that if you install (say) ssh-server in a template, *all* the qubes that use that template will run a ssh server when they start. (They will, naturally, all have the same server key.) This may not be what you want.
|
||||
|
||||
So be very careful when installing software in Templates - if the daemon spawns outbound connections then there is a serious security risk.
|
||||
|
||||
In general, a reasonable approach would be, (using ssh as example):
|
||||
|
||||
- Install the ssh service.
|
||||
|
||||
- ``systemctl stop ssh``
|
||||
|
||||
- ``systemctl disable ssh``
|
||||
|
||||
- ``systemctl mask ssh``
|
||||
|
||||
- Close down template
|
||||
|
||||
|
||||
|
||||
Now the ssh service will **NOT** start in qubes based on this template.
|
||||
|
||||
Where you **DO** want the service to run, put this in ``/rw/config/rc.local``:
|
||||
|
||||
.. code:: bash
|
||||
|
||||
systemctl unmask ssh
|
||||
systemctl start ssh
|
||||
|
||||
|
||||
|
||||
Don’t forget to make the file executable.
|
||||
|
||||
Unattended Upgrades
|
||||
^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
|
||||
Some users have noticed that on upgrading Debian templates, the ``unattended-upgrade`` package is installed. This package is pulled in as part of a Recommend chain, and can be purged. The lesson is that you should carefully look at what is being installed to your system, particularly if you run ``dist-upgrade``.
|
||||
|
||||
Package installation errors in Qubes 4.0
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
|
||||
If some packages throw installation errors, see :ref:`this guide. <user/troubleshooting/vm-troubleshooting:fixing package installation errors>`
|
||||
|
|
@ -1,226 +0,0 @@
|
|||
---
|
||||
advanced: true
|
||||
lang: en
|
||||
layout: doc
|
||||
permalink: /doc/templates/fedora/in-place-upgrade/
|
||||
redirect_from:
|
||||
- /doc/template/fedora/upgrade/
|
||||
- /doc/templates/fedora/upgrade/
|
||||
- /doc/template/fedora/upgrade-26-to-27/
|
||||
- /doc/fedora-template-upgrade-26/
|
||||
- /en/doc/fedora-template-upgrade-26/
|
||||
- /doc/FedoraTemplateUpgrade26/
|
||||
- /wiki/FedoraTemplateUpgrade26/
|
||||
- /doc/template/fedora/upgrade-27-to-28/
|
||||
- /doc/fedora-template-upgrade-27/
|
||||
- /en/doc/fedora-template-upgrade-27/
|
||||
- /doc/FedoraTemplateUpgrade27/
|
||||
- /wiki/FedoraTemplateUpgrade27/
|
||||
- /doc/template/fedora/upgrade-28-to-29/
|
||||
- /doc/fedora-template-upgrade-28/
|
||||
- /en/doc/fedora-template-upgrade-28/
|
||||
- /doc/FedoraTemplateUpgrade28/
|
||||
- /wiki/FedoraTemplateUpgrade28/
|
||||
- /doc/template/fedora/upgrade-29-to-30/
|
||||
ref: 137
|
||||
title: How to upgrade a Fedora template in-place
|
||||
---
|
||||
|
||||
<div class="alert alert-danger" role="alert">
|
||||
<i class="fa fa-exclamation-triangle"></i>
|
||||
<b>Warning:</b> This page is intended for advanced users only. Most users seeking to upgrade should instead <a href="/doc/templates/fedora/#installing">install a new Fedora template</a>. Learn more about the two options <a href="/doc/templates/fedora/#upgrading">here</a>.
|
||||
</div>
|
||||
|
||||
This page provides instructions for performing an in-place upgrade of an installed [Fedora Template](/doc/templates/fedora/).
|
||||
If you wish to install a new, unmodified Fedora template instead of upgrading a template that is already installed in your system, please see the [Fedora Template](/doc/templates/fedora/) page instead. ([Learn more about the two options.](/doc/templates/fedora/#upgrading))
|
||||
|
||||
## Summary instructions for standard Fedora templates
|
||||
|
||||
**Note:** The prompt on each line indicates where each command should be entered: `dom0`, `fedora-<old>`, or `fedora-<new>`, where `<old>` is the Fedora version number *from* which you are upgrading, and `<new>` is the Fedora version number *to* which you are upgrading.
|
||||
|
||||
```
|
||||
[user@dom0 ~]$ qvm-clone fedora-<old> fedora-<new>
|
||||
[user@dom0 ~]$ truncate -s 5GB /var/tmp/template-upgrade-cache.img
|
||||
[user@dom0 ~]$ qvm-run -a fedora-<new> gnome-terminal
|
||||
[user@dom0 ~]$ dev=$(sudo losetup -f --show /var/tmp/template-upgrade-cache.img)
|
||||
[user@dom0 ~]$ qvm-block attach fedora-<new> dom0:${dev##*/}
|
||||
[user@fedora-<new> ~]$ sudo mkfs.ext4 /dev/xvdi
|
||||
[user@fedora-<new> ~]$ sudo mount /dev/xvdi /mnt/removable
|
||||
[user@fedora-<new> ~]$ sudo dnf clean all
|
||||
[user@fedora-<new> ~]$ sudo dnf --releasever=<new> --setopt=cachedir=/mnt/removable --best distro-sync --allowerasing
|
||||
[user@dom0 ~]$ qvm-shutdown fedora-<new>
|
||||
[user@dom0 ~]$ sudo losetup -d $dev
|
||||
[user@dom0 ~]$ rm /var/tmp/template-upgrade-cache.img
|
||||
[user@dom0 ~]$ qvm-features fedora-<new> template-name fedora-<new>
|
||||
```
|
||||
|
||||
**Recommended:** [Switch everything that was set to the old template to the new template.](/doc/templates/#switching)
|
||||
|
||||
## Detailed instructions for standard Fedora templates
|
||||
|
||||
These instructions will show you how to upgrade the standard Fedora template.
|
||||
The same general procedure may be used to upgrade any template based on the standard Fedora template.
|
||||
|
||||
**Note:** The prompt on each line indicates where each command should be entered: `dom0`, `fedora-<old>`, or `fedora-<new>`, where `<old>` is the Fedora version number *from* which you are upgrading, and `<new>` is the Fedora version number *to* which you are upgrading.
|
||||
|
||||
1. Ensure the existing template is not running.
|
||||
|
||||
```
|
||||
[user@dom0 ~]$ qvm-shutdown fedora-<old>
|
||||
```
|
||||
|
||||
2. Clone the existing template and start a terminal in the new template.
|
||||
|
||||
```
|
||||
[user@dom0 ~]$ qvm-clone fedora-<old> fedora-<new>
|
||||
[user@dom0 ~]$ qvm-run -a fedora-<new> gnome-terminal
|
||||
```
|
||||
|
||||
3. Attempt the upgrade process in the new template.
|
||||
|
||||
```
|
||||
[user@fedora-<new> ~]$ sudo dnf clean all
|
||||
[user@fedora-<new> ~]$ sudo dnf --releasever=<new> distro-sync --best --allowerasing
|
||||
```
|
||||
|
||||
**Note:** `dnf` might ask you to approve importing a new package signing key.
|
||||
For example, you might see a prompt like this one:
|
||||
|
||||
```
|
||||
warning: /mnt/removable/updates-0b4cc238d1aa4ffe/packages/example-package.fc<new>.x86_64.rpm: Header V3 RSA/SHA256 Signature, key ID XXXXXXXX: NOKEY
|
||||
Importing GPG key 0xXXXXXXXX:
|
||||
Userid : "Fedora <new> (<new>) <fedora-<new>@fedoraproject.org>"
|
||||
Fingerprint: XXXX XXXX XXXX XXXX XXXX XXXX XXXX XXXX XXXX XXXX
|
||||
From : /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-<new>-x86_64
|
||||
Is this ok [y/N]: y
|
||||
```
|
||||
|
||||
This key was already checked when it was installed (notice that the "From" line refers to a location on your local disk), so you can safely say yes to this prompt.
|
||||
|
||||
- **Note:** If you encounter no errors, proceed to step 4.
|
||||
If you do encounter errors, see the next two points first.
|
||||
|
||||
- If `dnf` reports that you do not have enough free disk space to proceed
|
||||
with the upgrade process, create an empty file in dom0 to use as a cache
|
||||
and attach it to the template as a virtual disk.
|
||||
|
||||
```
|
||||
[user@dom0 ~]$ truncate -s 5GB /var/tmp/template-upgrade-cache.img
|
||||
[user@dom0 ~]$ dev=$(sudo losetup -f --show /var/tmp/template-upgrade-cache.img)
|
||||
[user@dom0 ~]$ qvm-block attach fedora-<new> dom0:${dev##*/}
|
||||
```
|
||||
|
||||
Then reattempt the upgrade process, but this time use the virtual disk as a cache.
|
||||
|
||||
```
|
||||
[user@fedora-<new> ~]$ sudo mkfs.ext4 /dev/xvdi
|
||||
[user@fedora-<new> ~]$ sudo mount /dev/xvdi /mnt/removable
|
||||
[user@fedora-<new> ~]$ sudo dnf clean all
|
||||
[user@fedora-<new> ~]$ sudo dnf --releasever=<new> --setopt=cachedir=/mnt/removable --best distro-sync --allowerasing
|
||||
```
|
||||
|
||||
If this attempt is successful, proceed to step 4.
|
||||
|
||||
- `dnf` may error with the text: `At least X MB more space needed on the / filesystem.`
|
||||
|
||||
In this case, one option is to [resize the template's disk image](/doc/resize-disk-image/) before reattempting the upgrade process.
|
||||
(See [Additional Information](#additional-information) below for other options.)
|
||||
|
||||
4. Check that you are on the correct (new) Fedora release. Do this check only after completing the upgrade process. This is *not* a troubleshooting procedure for fixing download issues from the repository. This check simply verifies that your clone has successfully been upgraded.
|
||||
|
||||
```
|
||||
[user@fedora-<new> ~]$ cat /etc/fedora-release
|
||||
```
|
||||
|
||||
5. (Optional) Trim the new template.
|
||||
(This should [no longer be necessary](/doc/templates/#important-notes), but it does not hurt.
|
||||
Some users have [reported](https://github.com/QubesOS/qubes-issues/issues/5055) that it makes a difference.)
|
||||
|
||||
```
|
||||
[user@fedora-<new> ~]$ sudo fstrim -av
|
||||
[user@dom0 ~]$ qvm-shutdown fedora-<new>
|
||||
[user@dom0 ~]$ qvm-start fedora-<new>
|
||||
[user@fedora-<new> ~]$ sudo fstrim -av
|
||||
```
|
||||
|
||||
6. Shut down the new template.
|
||||
|
||||
```
|
||||
[user@dom0 ~]$ qvm-shutdown fedora-<new>
|
||||
```
|
||||
|
||||
7. Remove the cache file, if you created one.
|
||||
|
||||
```
|
||||
[user@dom0 ~]$ sudo losetup -d $dev
|
||||
[user@dom0 ~]$ rm /var/tmp/template-upgrade-cache.img
|
||||
```
|
||||
|
||||
8. Set the template-name, which is used by the Qubes updater.
|
||||
|
||||
```
|
||||
[user@dom0 ~]$ qvm-features fedora-<new> template-name fedora-<new>
|
||||
```
|
||||
|
||||
9. (Recommended) [Switch everything that was set to the old template to the new template.](/doc/templates/#switching)
|
||||
|
||||
10. (Optional) Make the new template the global default.
|
||||
|
||||
```
|
||||
[user@dom0 ~]$ qubes-prefs --set default_template fedora-<new>
|
||||
```
|
||||
|
||||
11. (Optional) [Uninstall the old template.](/doc/templates/#uninstalling)
|
||||
Make sure that the template you're uninstalling is the old one, not the new one!
|
||||
|
||||
## Summary instructions for Fedora Minimal templates
|
||||
|
||||
**Note:** The prompt on each line indicates where each command should be entered: `dom0`, `fedora-<old>`, or `fedora-<new>`, where `<old>` is the Fedora version number *from* which you are upgrading, and `<new>` is the Fedora version number *to* which you are upgrading.
|
||||
|
||||
```
|
||||
[user@dom0 ~]$ qvm-clone fedora-<old>-minimal fedora-<new>-minimal
|
||||
[user@dom0 ~]$ qvm-run -u root -a fedora-<new>-minimal xterm
|
||||
[root@fedora-<new>-minimal ~]# dnf clean all
|
||||
[user@fedora-<new>-minimal ~]# dnf --releasever=<new> --best distro-sync --allowerasing
|
||||
[user@fedora-<new>-minimal ~]# fstrim -v /
|
||||
[user@dom0 ~]$ qvm-features fedora-<new>-minimal template-name fedora-<new>
|
||||
```
|
||||
|
||||
(Shut down template by any normal means.)
|
||||
|
||||
(If you encounter insufficient space issues, you may need to use the methods described for the standard template above.)
|
||||
|
||||
## Standalones
|
||||
|
||||
The procedure for upgrading a Fedora [standalone](/doc/standalone-and-hvm/) is the same as for a template.
|
||||
|
||||
|
||||
## Release-specific notes
|
||||
|
||||
See the [news](/news/) announcement for each specific template release for any important notices about that particular release.
|
||||
|
||||
|
||||
### End-of-life (EOL) releases
|
||||
|
||||
We strongly recommend against using any Fedora release that has reached [end-of-life (EOL)](https://fedoraproject.org/wiki/End_of_life).
|
||||
Also see [supported releases](/doc/supported-releases/).
|
||||
|
||||
|
||||
## Additional information
|
||||
|
||||
As mentioned above, you may encounter the following `dnf` error:
|
||||
|
||||
```
|
||||
At least X MB more space needed on the / filesystem.
|
||||
```
|
||||
|
||||
In this case, you have several options:
|
||||
|
||||
1. [Increase the template's disk image size](/doc/resize-disk-image/).
|
||||
This is the solution mentioned in the main instructions above.
|
||||
2. Delete files in order to free up space. One way to do this is by uninstalling packages.
|
||||
You may then reinstall them again after you finish the upgrade process, if desired).
|
||||
However, you may end up having to increase the disk image size anyway (see previous option).
|
||||
3. Do the upgrade in parts, e.g., by using package groups.
|
||||
(First upgrade `@core` packages, then the rest.)
|
||||
4. Do not perform an in-place upgrade, see [Upgrading Fedora templates](/doc/templates/fedora/#upgrading).
|
||||
225
user/templates/fedora/fedora-upgrade.rst
Normal file
225
user/templates/fedora/fedora-upgrade.rst
Normal file
|
|
@ -0,0 +1,225 @@
|
|||
=========================================
|
||||
How to upgrade a Fedora template in-place
|
||||
=========================================
|
||||
|
||||
.. warning::
|
||||
|
||||
This page is intended for advanced users.
|
||||
|
||||
.. DANGER::
|
||||
|
||||
**Warning:** This page is intended for advanced users only. Most users seeking to upgrade should instead :ref:`install a new Fedora template <user/templates/fedora/fedora:installing>` . Learn more about the two options :ref:`here <user/templates/fedora/fedora:upgrading>` .
|
||||
|
||||
This page provides instructions for performing an in-place upgrade of an installed :doc:`Fedora Template </user/templates/fedora/fedora>`. If you wish to install a new, unmodified Fedora template instead of upgrading a template that is already installed in your system, please see the :doc:`Fedora Template </user/templates/fedora/fedora>` page instead. (:ref:`Learn more about the two options. <user/templates/fedora/fedora:upgrading>`)
|
||||
|
||||
Summary instructions for standard Fedora templates
|
||||
--------------------------------------------------
|
||||
|
||||
|
||||
**Note:** The prompt on each line indicates where each command should be entered: ``dom0``, ``fedora-<old>``, or ``fedora-<new>``, where ``<old>`` is the Fedora version number *from* which you are upgrading, and ``<new>`` is the Fedora version number *to* which you are upgrading.
|
||||
|
||||
.. code:: bash
|
||||
|
||||
[user@dom0 ~]$ qvm-clone fedora-<old> fedora-<new>
|
||||
[user@dom0 ~]$ truncate -s 5GB /var/tmp/template-upgrade-cache.img
|
||||
[user@dom0 ~]$ qvm-run -a fedora-<new> gnome-terminal
|
||||
[user@dom0 ~]$ dev=$(sudo losetup -f --show /var/tmp/template-upgrade-cache.img)
|
||||
[user@dom0 ~]$ qvm-block attach fedora-<new> dom0:${dev##*/}
|
||||
[user@fedora-<new> ~]$ sudo mkfs.ext4 /dev/xvdi
|
||||
[user@fedora-<new> ~]$ sudo mount /dev/xvdi /mnt/removable
|
||||
[user@fedora-<new> ~]$ sudo dnf clean all
|
||||
[user@fedora-<new> ~]$ sudo dnf --releasever=<new> --setopt=cachedir=/mnt/removable --best distro-sync --allowerasing
|
||||
[user@dom0 ~]$ qvm-shutdown fedora-<new>
|
||||
[user@dom0 ~]$ sudo losetup -d $dev
|
||||
[user@dom0 ~]$ rm /var/tmp/template-upgrade-cache.img
|
||||
[user@dom0 ~]$ qvm-features fedora-<new> template-name fedora-<new>
|
||||
|
||||
|
||||
**Recommended:** :ref:`Switch everything that was set to the old template to the new template. <user/templates/templates:switching>`
|
||||
|
||||
Detailed instructions for standard Fedora templates
|
||||
---------------------------------------------------
|
||||
|
||||
|
||||
These instructions will show you how to upgrade the standard Fedora template. The same general procedure may be used to upgrade any template based on the standard Fedora template.
|
||||
|
||||
**Note:** The prompt on each line indicates where each command should be entered: ``dom0``, ``fedora-<old>``, or ``fedora-<new>``, where ``<old>`` is the Fedora version number *from* which you are upgrading, and ``<new>`` is the Fedora version number *to* which you are upgrading.
|
||||
|
||||
1. Ensure the existing template is not running.
|
||||
|
||||
.. code:: bash
|
||||
|
||||
[user@dom0 ~]$ qvm-shutdown fedora-<old>
|
||||
|
||||
|
||||
2. Clone the existing template and start a terminal in the new template.
|
||||
|
||||
.. code:: bash
|
||||
|
||||
[user@dom0 ~]$ qvm-clone fedora-<old> fedora-<new>
|
||||
[user@dom0 ~]$ qvm-run -a fedora-<new> gnome-terminal
|
||||
|
||||
|
||||
3. Attempt the upgrade process in the new template.
|
||||
|
||||
.. code:: bash
|
||||
|
||||
[user@fedora-<new> ~]$ sudo dnf clean all
|
||||
[user@fedora-<new> ~]$ sudo dnf --releasever=<new> distro-sync --best --allowerasing
|
||||
|
||||
|
||||
**Note:** ``dnf`` might ask you to approve importing a new package signing key. For example, you might see a prompt like this one:
|
||||
|
||||
.. code:: bash
|
||||
|
||||
warning: /mnt/removable/updates-0b4cc238d1aa4ffe/packages/example-package.fc<new>.x86_64.rpm: Header V3 RSA/SHA256 Signature, key ID XXXXXXXX: NOKEY
|
||||
Importing GPG key 0xXXXXXXXX:
|
||||
Userid : "Fedora <new> (<new>) <fedora-<new>@fedoraproject.org>"
|
||||
Fingerprint: XXXX XXXX XXXX XXXX XXXX XXXX XXXX XXXX XXXX XXXX
|
||||
From : /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-<new>-x86_64
|
||||
Is this ok [y/N]: y
|
||||
|
||||
|
||||
This key was already checked when it was installed (notice that the “From” line refers to a location on your local disk), so you can safely say yes to this prompt.
|
||||
|
||||
- **Note:** If you encounter no errors, proceed to step 4. If you do encounter errors, see the next two points first.
|
||||
|
||||
- If ``dnf`` reports that you do not have enough free disk space to proceed with the upgrade process, create an empty file in dom0 to use as a cache and attach it to the template as a virtual disk.
|
||||
|
||||
.. code:: bash
|
||||
|
||||
[user@dom0 ~]$ truncate -s 5GB /var/tmp/template-upgrade-cache.img
|
||||
[user@dom0 ~]$ dev=$(sudo losetup -f --show /var/tmp/template-upgrade-cache.img)
|
||||
[user@dom0 ~]$ qvm-block attach fedora-<new> dom0:${dev##*/}
|
||||
|
||||
Then reattempt the upgrade process, but this time use the virtual disk as a cache.
|
||||
|
||||
.. code:: bash
|
||||
|
||||
[user@fedora-<new> ~]$ sudo mkfs.ext4 /dev/xvdi
|
||||
[user@fedora-<new> ~]$ sudo mount /dev/xvdi /mnt/removable
|
||||
[user@fedora-<new> ~]$ sudo dnf clean all
|
||||
[user@fedora-<new> ~]$ sudo dnf --releasever=<new> --setopt=cachedir=/mnt/removable --best distro-sync --allowerasing
|
||||
|
||||
|
||||
If this attempt is successful, proceed to step 4.
|
||||
|
||||
- ``dnf`` may error with the text: ``At least X MB more space needed on the / filesystem.``
|
||||
In this case, one option is to :doc:`resize the template’s disk image </user/advanced-topics/resize-disk-image>` before reattempting the upgrade process. (See `Additional Information <#additional-information>`__ below for other options.)
|
||||
|
||||
|
||||
|
||||
4. Check that you are on the correct (new) Fedora release. Do this check only after completing the upgrade process. This is *not* a troubleshooting procedure for fixing download issues from the repository. This check simply verifies that your clone has successfully been upgraded.
|
||||
|
||||
.. code:: bash
|
||||
|
||||
[user@fedora-<new> ~]$ cat /etc/fedora-release
|
||||
|
||||
|
||||
|
||||
5. (Optional) Trim the new template. (This should :ref:`no longer be necessary <user/templates/templates:important notes>`, but it does not hurt. Some users have `reported <https://github.com/QubesOS/qubes-issues/issues/5055>`__ that it makes a difference.)
|
||||
|
||||
.. code:: bash
|
||||
|
||||
[user@fedora-<new> ~]$ sudo fstrim -av
|
||||
[user@dom0 ~]$ qvm-shutdown fedora-<new>
|
||||
[user@dom0 ~]$ qvm-start fedora-<new>
|
||||
[user@fedora-<new> ~]$ sudo fstrim -av
|
||||
|
||||
|
||||
6. Shut down the new template.
|
||||
|
||||
.. code:: bash
|
||||
|
||||
[user@dom0 ~]$ qvm-shutdown fedora-<new>
|
||||
|
||||
|
||||
7. Remove the cache file, if you created one.
|
||||
|
||||
.. code:: bash
|
||||
|
||||
[user@dom0 ~]$ sudo losetup -d $dev
|
||||
[user@dom0 ~]$ rm /var/tmp/template-upgrade-cache.img
|
||||
|
||||
|
||||
8. Set the template-name, which is used by the Qubes updater.
|
||||
|
||||
.. code:: bash
|
||||
|
||||
[user@dom0 ~]$ qvm-features fedora-<new> template-name fedora-<new>
|
||||
|
||||
|
||||
9. (Recommended) :ref:`Switch everything that was set to the old template to the new template. <user/templates/templates:switching>`
|
||||
|
||||
10. (Optional) Make the new template the global default.
|
||||
|
||||
.. code:: bash
|
||||
|
||||
[user@dom0 ~]$ qubes-prefs --set default_template fedora-<new>
|
||||
|
||||
|
||||
11. (Optional) :ref:`Uninstall the old template. <user/templates/templates:uninstalling>` Make sure that the template you’re uninstalling is the old one, not the new one!
|
||||
|
||||
|
||||
|
||||
Summary instructions for Fedora Minimal templates
|
||||
-------------------------------------------------
|
||||
|
||||
|
||||
**Note:** The prompt on each line indicates where each command should be entered: ``dom0``, ``fedora-<old>``, or ``fedora-<new>``, where ``<old>`` is the Fedora version number *from* which you are upgrading, and ``<new>`` is the Fedora version number *to* which you are upgrading.
|
||||
|
||||
.. code:: bash
|
||||
|
||||
[user@dom0 ~]$ qvm-clone fedora-<old>-minimal fedora-<new>-minimal
|
||||
[user@dom0 ~]$ qvm-run -u root -a fedora-<new>-minimal xterm
|
||||
[root@fedora-<new>-minimal ~]# dnf clean all
|
||||
[user@fedora-<new>-minimal ~]# dnf --releasever=<new> --best distro-sync --allowerasing
|
||||
[user@fedora-<new>-minimal ~]# fstrim -v /
|
||||
[user@dom0 ~]$ qvm-features fedora-<new>-minimal template-name fedora-<new>
|
||||
|
||||
|
||||
(Shut down template by any normal means.)
|
||||
|
||||
(If you encounter insufficient space issues, you may need to use the methods described for the standard template above.)
|
||||
|
||||
Standalones
|
||||
-----------
|
||||
|
||||
|
||||
The procedure for upgrading a Fedora :doc:`standalone </user/advanced-topics/standalones-and-hvms>` is the same as for a template.
|
||||
|
||||
Release-specific notes
|
||||
----------------------
|
||||
|
||||
|
||||
See the `news <https://www.qubes-os.org/news/>`__ announcement for each specific template release for any important notices about that particular release.
|
||||
|
||||
End-of-life (EOL) releases
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
|
||||
We strongly recommend against using any Fedora release that has reached `end-of-life (EOL) <https://fedoraproject.org/wiki/End_of_life>`__. Also see :doc:`supported releases </user/downloading-installing-upgrading/supported-releases>`.
|
||||
|
||||
Additional information
|
||||
----------------------
|
||||
|
||||
|
||||
As mentioned above, you may encounter the following ``dnf`` error:
|
||||
|
||||
.. code:: bash
|
||||
|
||||
At least X MB more space needed on the / filesystem.
|
||||
|
||||
|
||||
|
||||
In this case, you have several options:
|
||||
|
||||
1. :doc:`Increase the template’s disk image size </user/advanced-topics/resize-disk-image>`. This is the solution mentioned in the main instructions above.
|
||||
|
||||
2. Delete files in order to free up space. One way to do this is by uninstalling packages. You may then reinstall them again after you finish the upgrade process, if desired). However, you may end up having to increase the disk image size anyway (see previous option).
|
||||
|
||||
3. Do the upgrade in parts, e.g., by using package groups. (First upgrade ``@core`` packages, then the rest.)
|
||||
|
||||
4. Do not perform an in-place upgrade, see :ref:`Upgrading Fedora templates <user/templates/fedora/fedora:upgrading>`.
|
||||
|
||||
|
||||
|
|
@ -1,45 +0,0 @@
|
|||
---
|
||||
lang: en
|
||||
layout: doc
|
||||
permalink: /doc/templates/fedora/
|
||||
ref: 136
|
||||
title: Fedora templates
|
||||
---
|
||||
|
||||
The Fedora [template](/doc/templates/) is the default template in Qubes OS. The current version is Fedora 41. This page is about the standard (or "full") Fedora template. For the minimal and Xfce versions, please see the [Minimal templates](/doc/templates/minimal/) and [Xfce templates](/doc/templates/xfce/) pages.
|
||||
|
||||
## Installing
|
||||
|
||||
To [install](/doc/templates/#installing) a specific Fedora template that is not currently installed in your system, use the Qubes Template Manager, or use the following command in a dom0 terminal:
|
||||
```
|
||||
$ qvm-template install XX
|
||||
```
|
||||
(Replace `XX` with the name of the Fedora template you wish to install.)
|
||||
|
||||
To reinstall a Fedora template that is already installed in your system, see [How to Reinstall a template](/doc/reinstall-template/).
|
||||
|
||||
## After Installing
|
||||
|
||||
After installing a fresh Fedora template, we recommend performing the following steps:
|
||||
|
||||
1. [Update the template](/doc/software-update-vm/).
|
||||
|
||||
2. [Switch any app qubes that are based on the old template to the new one](/doc/templates/#switching).
|
||||
|
||||
3. If desired, [uninstall the old template](/doc/templates/#uninstalling).
|
||||
|
||||
## Installing software
|
||||
|
||||
See [How to Install Software](/doc/how-to-install-software/).
|
||||
|
||||
## Updating
|
||||
|
||||
For routine daily updates within a given release, see [How to Update](/doc/how-to-update/).
|
||||
|
||||
## Upgrading
|
||||
|
||||
There are two ways to upgrade your template to a new Fedora release:
|
||||
|
||||
- **Recommended:** [Install a fresh template to replace the existing one.](#installing) **This option may be simpler for less experienced users.** After you install the new template, redo all desired template modifications and [switch everything that was set to the old template to the new template](/doc/templates/#switching). You may want to write down the modifications you make to your templates so that you remember what to redo on each fresh install. To see a log of package manager actions, open a terminal in the old Fedora template and use the `dnf history` command.
|
||||
|
||||
- **Advanced:** [Perform an in-place upgrade of an existing Fedora template.](/doc/templates/fedora/in-place-upgrade/) This option will preserve any modifications you've made to the template, **but it may be more complicated for less experienced users.**
|
||||
60
user/templates/fedora/fedora.rst
Normal file
60
user/templates/fedora/fedora.rst
Normal file
|
|
@ -0,0 +1,60 @@
|
|||
================
|
||||
Fedora templates
|
||||
================
|
||||
|
||||
|
||||
The Fedora :doc:`template </user/templates/templates>` is the default template in Qubes OS. The current version is Fedora 41. This page is about the standard (or “full”) Fedora template. For the minimal and Xfce versions, please see the :doc:`Minimal templates </user/templates/minimal-templates>` and :doc:`Xfce templates </user/templates/xfce-templates>` pages.
|
||||
|
||||
Installing
|
||||
----------
|
||||
|
||||
|
||||
To :ref:`install <user/templates/templates:installing>` a specific Fedora template that is not currently installed in your system, use the Qubes Template Manager, or use the following command in a dom0 terminal:
|
||||
|
||||
.. code:: bash
|
||||
|
||||
$ qvm-template install XX
|
||||
|
||||
|
||||
|
||||
(Replace ``XX`` with the name of the Fedora template you wish to install.)
|
||||
|
||||
To reinstall a Fedora template that is already installed in your system, see :doc:`How to Reinstall a template </user/how-to-guides/how-to-reinstall-a-template>`.
|
||||
|
||||
After Installing
|
||||
----------------
|
||||
|
||||
|
||||
After installing a fresh Fedora template, we recommend performing the following steps:
|
||||
|
||||
1. :doc:`Update the template </user/how-to-guides/how-to-install-software>`.
|
||||
|
||||
2. :ref:`Switch any app qubes that are based on the old template to the new one <user/templates/templates:switching>`.
|
||||
|
||||
3. If desired, :ref:`uninstall the old template <user/templates/templates:uninstalling>`.
|
||||
|
||||
|
||||
|
||||
Installing software
|
||||
-------------------
|
||||
|
||||
|
||||
See :doc:`How to Install Software </user/how-to-guides/how-to-install-software>`.
|
||||
|
||||
Updating
|
||||
--------
|
||||
|
||||
|
||||
For routine daily updates within a given release, see :doc:`How to Update </user/how-to-guides/how-to-update>`.
|
||||
|
||||
Upgrading
|
||||
---------
|
||||
|
||||
|
||||
There are two ways to upgrade your template to a new Fedora release:
|
||||
|
||||
- **Recommended:** `Install a fresh template to replace the existing one. <#installing>`__ **This option may be simpler for less experienced users.** After you install the new template, redo all desired template modifications and :ref:`switch everything that was set to the old template to the new template <user/templates/templates:switching>`. You may want to write down the modifications you make to your templates so that you remember what to redo on each fresh install. To see a log of package manager actions, open a terminal in the old Fedora template and use the ``dnf history`` command.
|
||||
|
||||
- **Advanced:** :doc:`Perform an in-place upgrade of an existing Fedora template. </user/templates/fedora/fedora-upgrade>` This option will preserve any modifications you’ve made to the template, **but it may be more complicated for less experienced users.**
|
||||
|
||||
|
||||
|
|
@ -1,306 +0,0 @@
|
|||
---
|
||||
advanced: true
|
||||
lang: en
|
||||
layout: doc
|
||||
permalink: /doc/templates/minimal/
|
||||
redirect_from:
|
||||
- /doc/templates/fedora-minimal/
|
||||
- /doc/fedora-minimal/
|
||||
- /en/doc/templates/fedora-minimal/
|
||||
- /doc/Templates/FedoraMinimal/
|
||||
- /wiki/Templates/FedoraMinimal/
|
||||
- /doc/templates/debian-minimal/
|
||||
ref: 132
|
||||
title: Minimal templates
|
||||
---
|
||||
|
||||
The minimal [templates](/doc/templates/) are lightweight versions of their
|
||||
standard template counterparts. They have only the most vital packages
|
||||
installed, including a minimal X and xterm installation. When properly
|
||||
configured and used, minimal templates can be less resource-intensive, reduce
|
||||
attack surface, and support more fine-grained compartmentalization. The
|
||||
sections below contain instructions for installing and configuring minimal
|
||||
templates, along with some examples of common use cases.
|
||||
|
||||
## Important
|
||||
|
||||
1. [The minimal templates are intended only for advanced
|
||||
users.](https://forum.qubes-os.org/t/9717/15) Most things will *not* work
|
||||
out-of-the-box, and you *will* have to fix them yourself. If you are not
|
||||
prepared to do a lot of reading, searching, learning, and troubleshooting,
|
||||
then you should instead stick to the standard templates, which are perfectly
|
||||
suitable for the vast majority of users. In particular, if you are new to
|
||||
Qubes, you should not attempt to use minimal templates until you have gained
|
||||
more experience.
|
||||
|
||||
2. If something works with a standard template but not the minimal version,
|
||||
this is most likely due to user error (e.g., a missing package or
|
||||
misconfiguration) rather than a bug. In such cases, please do *not* file a
|
||||
bug report. Instead, please see [Help, Support, Mailing Lists, and
|
||||
Forum](/support/) for the appropriate place to ask for help. Once you have
|
||||
learned how to solve your problem, please [contribute what you learned to
|
||||
the documentation](/doc/how-to-edit-the-documentation/).
|
||||
|
||||
3. The minimal templates are intentionally *minimal*. [Do not ask for your
|
||||
favorite package to be added to the minimal template by
|
||||
default.](/faq/#could-you-please-make-my-preference-the-default)
|
||||
|
||||
4. In order to reduce unnecessary risk, unused repositories have been disabled
|
||||
by default. If you wish to install or update any packages from those
|
||||
repositories, you must enable them.
|
||||
|
||||
## List
|
||||
|
||||
Minimal templates of the following distros are available:
|
||||
|
||||
- Fedora
|
||||
- Debian
|
||||
- Gentoo
|
||||
|
||||
A list of all available templates can also be obtained with the [Template Manager](/doc/template-manager/) tool.
|
||||
|
||||
## Installation
|
||||
|
||||
The minimal templates can be installed with the following type of command:
|
||||
|
||||
```
|
||||
[user@dom0 ~]$ sudo qubes-dom0-update qubes-template-<DISTRO_NAME>-<RELEASE_NUMBER>-minimal
|
||||
```
|
||||
|
||||
If your desired version is not found, it may still be in
|
||||
[testing](/doc/testing/). You may wish to try again with the testing repository
|
||||
enabled:
|
||||
|
||||
```
|
||||
[user@dom0 ~]$ sudo qubes-dom0-update --enablerepo=qubes-templates-itl-testing qubes-template-<DISTRO_NAME>-<RELEASE_NUMBER>-minimal
|
||||
```
|
||||
|
||||
If you would like to install a community distribution, try the install command
|
||||
by enabling the community repository:
|
||||
|
||||
```
|
||||
[user@dom0 ~]$ sudo qubes-dom0-update --enablerepo=qubes-templates-community qubes-template-<DISTRO_NAME>-<RELEASE_NUMBER>-minimal
|
||||
```
|
||||
|
||||
The download may take a while depending on your connection speed.
|
||||
|
||||
## Passwordless root
|
||||
|
||||
It is an intentional design choice for [Passwordless Root Access in
|
||||
VMs](/doc/vm-sudo/) to be optional in minimal templates. Since the minimal
|
||||
templates are *minimal*, they are not configured for passwordless root by
|
||||
default. To update or install packages, execute the following command in dom0:
|
||||
|
||||
```
|
||||
[user@dom0 ~]$ qvm-run -u root <DISTRO_NAME>-<RELEASE_NUMBER>-minimal xterm
|
||||
```
|
||||
|
||||
This opens a root terminal in the minimal template, from which you can use
|
||||
execute root commands without `sudo`. You will have to do this every time if
|
||||
you choose not to enable passwordless root.
|
||||
|
||||
If you want to be able to use `sudo` inside a minimal template (or app qubes
|
||||
based on a minimal template), open a root terminal as just instructed, then
|
||||
install the `qubes-core-agent-passwordless-root` package.
|
||||
|
||||
Optionally, verify that passwordless root now works by opening a normal
|
||||
(non-root) xterm window in the minimal template, then issue the command `sudo
|
||||
-l`. This should give you output that includes the `NOPASSWD` keyword.
|
||||
|
||||
## Customization
|
||||
|
||||
You may wish to clone the original template and make any changes in the clone
|
||||
instead of the original template. You must start the clone in order to
|
||||
customize it.
|
||||
|
||||
Customizing the template for specific use cases normally only requires
|
||||
installing additional packages.
|
||||
|
||||
## Distro-specific notes
|
||||
|
||||
This following sections provide information that is specific to a particular
|
||||
minimal template distro.
|
||||
|
||||
### Fedora
|
||||
|
||||
The following list provides an overview of which packages are needed for which
|
||||
purpose. As usual, the required packages are to be installed in the running
|
||||
template with the following command (replace `packages` with a space-delimited
|
||||
list of packages to be installed):
|
||||
|
||||
```
|
||||
[user@your-new-clone ~]$ sudo dnf install packages
|
||||
```
|
||||
|
||||
- Commonly used utilities: `pciutils` `vim-minimal` `less` `psmisc`
|
||||
`gnome-keyring`.
|
||||
- Audio: `pulseaudio-qubes` (QubesOS version <= 4.1.x) `pipewire-qubes` (QubesOS >= 4.2.x).
|
||||
- Networking: `qubes-core-agent-networking`, and whatever network tools
|
||||
you want. N.B. minimal templates do not include any browser.
|
||||
- [FirewallVM](/doc/firewall/), such as the template for `sys-firewall`: at
|
||||
least `qubes-core-agent-networking` and `iproute`, and also
|
||||
`qubes-core-agent-dom0-updates` if you want to use it as the `UpdateVM`
|
||||
(which is normally `sys-firewall`).
|
||||
- NetVM, such as the template for `sys-net`: `qubes-core-agent-networking`
|
||||
`qubes-core-agent-network-manager` `NetworkManager-wifi`
|
||||
`network-manager-applet` `notification-daemon`
|
||||
`gnome-keyring` `polkit` `@hardware-support`. If your network devices need
|
||||
extra packages for the template to work as a network VM, use the `lspci`
|
||||
command to identify the devices, then run `dnf search firmware` (replace
|
||||
`firmware` with the appropriate device identifier) to find the needed
|
||||
packages and then install them. If you need utilities for debugging and
|
||||
analyzing network connections, install `tcpdump` `telnet` `nmap` `nmap-ncat`.
|
||||
- [USB qube](/doc/usb-qubes/), such as the template for `sys-usb`:
|
||||
`qubes-usb-proxy` to provide USB devices to other Qubes and
|
||||
`qubes-input-proxy-sender` to provide keyboard or mouse input to dom0.
|
||||
- [VPN
|
||||
qube](https://forum.qubes-os.org/t/19061):
|
||||
Use the `dnf search "NetworkManager VPN plugin"` command to look up the VPN
|
||||
packages you need, based on the VPN technology you'll be using, and install
|
||||
them. Some GNOME related packages may be needed as well. After creation of a
|
||||
machine based on this template, follow the [VPN
|
||||
instructions](https://forum.qubes-os.org/t/19061#set-up-a-proxyvm-as-a-vpn-gateway-using-networkmanager)
|
||||
to configure it.
|
||||
- `default-mgmt-dvm`: requires `qubes-core-agent-passwordless-root` and
|
||||
`qubes-mgmt-salt-vm-connector`.
|
||||
|
||||
To manage fedora-39-minimal templates with salt, you may need to install `python3-urllib3` in older versions of the template. (This package is already installed in recent builds: see [discussion](https://github.com/QubesOS/qubes-issues/issues/8806).)
|
||||
|
||||
In Qubes 4.0, additional packages from the `qubes-core-agent` suite may be
|
||||
needed to make the customized minimal template work properly. These packages
|
||||
are:
|
||||
|
||||
- `qubes-core-agent-nautilus`: This package provides integration with the
|
||||
Nautilus file manager (without it, items like "copy to VM/open in disposable"
|
||||
will not be shown in Nautilus).
|
||||
- `qubes-core-agent-thunar`: This package provides integration with the thunar
|
||||
file manager (without it, items like "copy to VM/open in disposable" will not
|
||||
be shown in thunar).
|
||||
- `qubes-core-agent-dom0-updates`: Script required to handle `dom0` updates.
|
||||
Any template on which the qube responsible for 'dom0' updates (e.g.
|
||||
`sys-firewall`) is based must contain this package.
|
||||
- `qubes-menus`: Defines menu layout.
|
||||
- `qubes-desktop-linux-common`: Contains icons and scripts to improve desktop
|
||||
experience.
|
||||
- `qubes-core-agent-qrexec`: Qubes qrexec agent. Installed by default.
|
||||
- `qubes-core-agent-systemd`: Qubes unit files for SystemD init style.
|
||||
Installed by default.
|
||||
- `qubes-core-agent-passwordless-root`, `polkit`: By default, the Fedora
|
||||
minimal template doesn't have passwordless root. These two packages enable
|
||||
this feature.
|
||||
- `qubes-core-agent-sysvinit`: Qubes unit files for SysV init style or upstart.
|
||||
|
||||
Also, there are packages to provide additional services:
|
||||
|
||||
- `qubes-gpg-split`: For implementing split GPG.
|
||||
- `qubes-ctap`: For implementing secure forwarding of CTAP messages.
|
||||
- `qubes-pdf-converter`: For implementing safe conversion of PDFs.
|
||||
- `qubes-img-converter`: For implementing safe conversion of images.
|
||||
- `qubes-snapd-helper`: If you want to use snaps in qubes.
|
||||
- `thunderbird-qubes`: Additional tools for use in thunderbird.
|
||||
- `qubes-app-shutdown-idle`: If you want qubes to automatically shutdown when
|
||||
idle.
|
||||
- `qubes-mgmt-salt-vm-connector`: If you want to use salt management on the
|
||||
template and qubes.
|
||||
|
||||
You may also wish to consider additional packages from the `qubes-core-agent`
|
||||
suite.
|
||||
|
||||
See
|
||||
[here](https://forum.qubes-os.org/t/18999)
|
||||
for further information on customizing `fedora-minimal`.
|
||||
|
||||
#### Logging
|
||||
|
||||
The `rsyslog` logging service is not installed by default, as all logging is
|
||||
instead being handled by the `systemd` journal. Users requiring the `rsyslog`
|
||||
service should install it manually.
|
||||
|
||||
To access the `journald` log, use the `journalctl` command.
|
||||
|
||||
### Debian
|
||||
|
||||
The following list provides an overview of which packages are needed for which
|
||||
purpose. As usual, the required packages are to be installed in the running
|
||||
template with the following command (replace `packages` with a space-delimited
|
||||
list of packages to be installed):
|
||||
|
||||
```
|
||||
[user@your-new-clone ~]$ sudo apt install packages
|
||||
```
|
||||
|
||||
- Commonly used utilities: `pciutils` `vim-minimal` `less` `psmisc`
|
||||
`gnome-keyring`
|
||||
- The `zenity` package is required for interactive dialogs, e.g., file selection
|
||||
([#5202](https://github.com/QubesOS/qubes-issues/issues/5202)) and for using
|
||||
the Nautilus menu option to copy some files to other qubes
|
||||
([#6801](https://github.com/QubesOS/qubes-issues/issues/6801)).
|
||||
- Audio: `pulseaudio-qubes`
|
||||
- Networking: `qubes-core-agent-networking`, and whatever network tools
|
||||
you want. N.B. minimal templates do not include any browser.
|
||||
- [FirewallVM](/doc/firewall/), such as the template for `sys-firewall`: at
|
||||
least `qubes-core-agent-networking`, and also `qubes-core-agent-dom0-updates`
|
||||
if you want to use it as the `UpdateVM` (which is normally `sys-firewall`).
|
||||
- NetVM, such as the template for `sys-net`: `qubes-core-agent-networking`,
|
||||
`qubes-core-agent-network-manager`, `ntpd` (or other NTP Service).
|
||||
Wi-Fi also requires `wpasupplicant`, and (optionally) `gnome-keyring` for saving the Wi-Fi password.
|
||||
If your network devices need extra packages for a network VM, use the `lspci` command to identify the devices,
|
||||
then find the package that provides necessary firmware and install it. If you
|
||||
need utilities for debugging and analyzing network connections, install the
|
||||
following packages: `tcpdump` `telnet` `nmap` `ncat`.
|
||||
- [USB qube](/doc/usb-qubes/), such as the template for `sys-usb`:
|
||||
`qubes-usb-proxy` to provide USB devices to other Qubes and
|
||||
`qubes-input-proxy-sender` to provide keyboard or mouse input to dom0.
|
||||
- Qubes to which USB devices are attached: `libpam-systemd` (Until
|
||||
[#7689](https://github.com/QubesOS/qubes-issues/issues/7689) is fixed, either
|
||||
pair it with `qubes-core-agent-passwordless-root` or manually activate the
|
||||
user session with `loginctl activate <USER_SESSION_ID>`.)
|
||||
- [VPN
|
||||
qube](https://forum.qubes-os.org/t/19061):
|
||||
You may need to install network-manager VPN packages, depending on the VPN
|
||||
technology you'll be using. After creating a machine based on this template,
|
||||
follow the [VPN
|
||||
howto](https://forum.qubes-os.org/t/19061#set-up-a-proxyvm-as-a-vpn-gateway-using-networkmanager)
|
||||
to configure it.
|
||||
- `default-mgmt-dvm`: requires `qubes-core-agent-passwordless-root` and
|
||||
`qubes-mgmt-salt-vm-connector`.
|
||||
- [Yubikey](/doc/yubikey/): You may need to install `xserver-xorg-input-libinput` for 2FA responses to work in web browsers like Firefox.
|
||||
- Thumbnails (e.g., file previews in Nautilus): `libgdk-pixbuf2.0-bin` (images),
|
||||
`ffmpegthumbnailer` (videos). (Try `apt search thumbnailer` for other file
|
||||
types.)
|
||||
|
||||
In Qubes 4.0, additional packages from the `qubes-core-agent` suite may be
|
||||
needed to make the customized minimal template work properly. These packages
|
||||
are:
|
||||
|
||||
- `qubes-core-agent-nautilus`: This package provides integration with the
|
||||
Nautilus file manager (without it, items like "copy to VM/open in disposable"
|
||||
will not be shown in Nautilus).
|
||||
- `qubes-core-agent-thunar`: This package provides integration with the thunar
|
||||
file manager (without it, items like "copy to VM/open in disposable" will not
|
||||
be shown in thunar).
|
||||
- `qubes-core-agent-dom0-updates`: Script required to handle `dom0` updates.
|
||||
Any template on which the qube responsible for 'dom0' updates (e.g.
|
||||
`sys-firewall`) is based must contain this package.
|
||||
- `qubes-menus`: Defines menu layout.
|
||||
- `qubes-desktop-linux-common`: Contains icons and scripts to improve desktop
|
||||
experience.
|
||||
|
||||
Also, there are packages to provide additional services:
|
||||
|
||||
- `qubes-gpg-split`: For implementing split GPG.
|
||||
- `qubes-ctap`: For implementing secure forwarding of CTAP messages.
|
||||
- `qubes-pdf-converter`: For implementing safe conversion of PDFs.
|
||||
- `qubes-img-converter`: For implementing safe conversion of images.
|
||||
- `qubes-snapd-helper`: If you want to use snaps in qubes.
|
||||
- `qubes-thunderbird`: Additional tools for use in thunderbird.
|
||||
- `qubes-app-shutdown-idle`: If you want qubes to automatically shutdown when
|
||||
idle.
|
||||
- `qubes-mgmt-salt-vm-connector`: If you want to use salt management on the
|
||||
template and qubes.
|
||||
|
||||
Documentation on all of these can be found in the [docs](/doc/).
|
||||
|
||||
You could, of course, use `qubes-vm-recommended` to automatically install many
|
||||
of these, but in that case you are well on the way to a standard Debian
|
||||
template.
|
||||
259
user/templates/minimal-templates.rst
Normal file
259
user/templates/minimal-templates.rst
Normal file
|
|
@ -0,0 +1,259 @@
|
|||
=================
|
||||
Minimal templates
|
||||
=================
|
||||
|
||||
.. warning::
|
||||
|
||||
This page is intended for advanced users.
|
||||
|
||||
The minimal :doc:`templates </user/templates/templates>` are lightweight versions of their standard template counterparts. They have only the most vital packages installed, including a minimal X and xterm installation. When properly configured and used, minimal templates can be less resource-intensive, reduce attack surface, and support more fine-grained compartmentalization. The sections below contain instructions for installing and configuring minimal templates, along with some examples of common use cases.
|
||||
|
||||
Important
|
||||
---------
|
||||
|
||||
|
||||
1. `The minimal templates are intended only for advanced users. <https://forum.qubes-os.org/t/9717/15>`__ Most things will *not* work out-of-the-box, and you *will* have to fix them yourself. If you are not prepared to do a lot of reading, searching, learning, and troubleshooting, then you should instead stick to the standard templates, which are perfectly suitable for the vast majority of users. In particular, if you are new to Qubes, you should not attempt to use minimal templates until you have gained more experience.
|
||||
|
||||
2. If something works with a standard template but not the minimal version, this is most likely due to user error (e.g., a missing package or misconfiguration) rather than a bug. In such cases, please do *not* file a bug report. Instead, please see :doc:`Help, Support, Mailing Lists, and Forum </introduction/support>` for the appropriate place to ask for help. Once you have learned how to solve your problem, please `contribute what you learned to the documentation <https://www.qubes-os.org/doc/how-to-edit-the-documentation/>`__.
|
||||
|
||||
3. The minimal templates are intentionally *minimal*. :ref:`Do not ask for your favorite package to be added to the minimal template by default. <introduction/faq:could you please make my preference the default?>`
|
||||
|
||||
4. In order to reduce unnecessary risk, unused repositories have been disabled by default. If you wish to install or update any packages from those repositories, you must enable them.
|
||||
|
||||
|
||||
|
||||
List
|
||||
----
|
||||
|
||||
|
||||
Minimal templates of the following distros are available:
|
||||
|
||||
- Fedora
|
||||
|
||||
- Debian
|
||||
|
||||
- Gentoo
|
||||
|
||||
|
||||
|
||||
A list of all available templates can also be obtained with the :doc:`Template Manager </developer/system/template-manager>` tool.
|
||||
|
||||
Installation
|
||||
------------
|
||||
|
||||
|
||||
The minimal templates can be installed with the following type of command:
|
||||
|
||||
.. code:: bash
|
||||
|
||||
[user@dom0 ~]$ sudo qubes-dom0-update qubes-template-<DISTRO_NAME>-<RELEASE_NUMBER>-minimal
|
||||
|
||||
|
||||
If your desired version is not found, it may still be in :doc:`testing </user/downloading-installing-upgrading/testing>`. You may wish to try again with the testing repository enabled:
|
||||
|
||||
.. code:: bash
|
||||
|
||||
[user@dom0 ~]$ sudo qubes-dom0-update --enablerepo=qubes-templates-itl-testing qubes-template-<DISTRO_NAME>-<RELEASE_NUMBER>-minimal
|
||||
|
||||
|
||||
If you would like to install a community distribution, try the install command by enabling the community repository:
|
||||
|
||||
.. code:: bash
|
||||
|
||||
[user@dom0 ~]$ sudo qubes-dom0-update --enablerepo=qubes-templates-community qubes-template-<DISTRO_NAME>-<RELEASE_NUMBER>-minimal
|
||||
|
||||
|
||||
The download may take a while depending on your connection speed.
|
||||
|
||||
Passwordless root
|
||||
-----------------
|
||||
|
||||
|
||||
It is an intentional design choice for :doc:`Passwordless Root Access in VMs </user/security-in-qubes/vm-sudo>` to be optional in minimal templates. Since the minimal templates are *minimal*, they are not configured for passwordless root by default. To update or install packages, execute the following command in dom0:
|
||||
|
||||
.. code:: bash
|
||||
|
||||
[user@dom0 ~]$ qvm-run -u root <DISTRO_NAME>-<RELEASE_NUMBER>-minimal xterm
|
||||
|
||||
|
||||
This opens a root terminal in the minimal template, from which you can use execute root commands without ``sudo``. You will have to do this every time if you choose not to enable passwordless root.
|
||||
|
||||
If you want to be able to use ``sudo`` inside a minimal template (or app qubes based on a minimal template), open a root terminal as just instructed, then install the ``qubes-core-agent-passwordless-root`` package.
|
||||
|
||||
Optionally, verify that passwordless root now works by opening a normal (non-root) xterm window in the minimal template, then issue the command ``sudo -l``. This should give you output that includes the ``NOPASSWD`` keyword.
|
||||
|
||||
Customization
|
||||
-------------
|
||||
|
||||
|
||||
You may wish to clone the original template and make any changes in the clone instead of the original template. You must start the clone in order to customize it.
|
||||
|
||||
Customizing the template for specific use cases normally only requires installing additional packages.
|
||||
|
||||
Distro-specific notes
|
||||
---------------------
|
||||
|
||||
|
||||
This following sections provide information that is specific to a particular minimal template distro.
|
||||
|
||||
Fedora
|
||||
^^^^^^
|
||||
|
||||
|
||||
The following list provides an overview of which packages are needed for which purpose. As usual, the required packages are to be installed in the running template with the following command (replace ``packages`` with a space-delimited list of packages to be installed):
|
||||
|
||||
.. code:: bash
|
||||
|
||||
[user@your-new-clone ~]$ sudo dnf install packages
|
||||
|
||||
|
||||
|
||||
- Commonly used utilities: ``pciutils`` ``vim-minimal`` ``less`` ``psmisc`` ``gnome-keyring``.
|
||||
|
||||
- Audio: ``pulseaudio-qubes`` (QubesOS version <= 4.1.x) ``pipewire-qubes`` (QubesOS >= 4.2.x).
|
||||
|
||||
- Networking: ``qubes-core-agent-networking``, and whatever network tools you want. N.B. minimal templates do not include any browser.
|
||||
|
||||
- :doc:`FirewallVM </user/security-in-qubes/firewall>`, such as the template for ``sys-firewall``: at least ``qubes-core-agent-networking`` and ``iproute``, and also ``qubes-core-agent-dom0-updates`` if you want to use it as the ``UpdateVM`` (which is normally ``sys-firewall``).
|
||||
|
||||
- NetVM, such as the template for ``sys-net``: ``qubes-core-agent-networking`` ``qubes-core-agent-network-manager`` ``NetworkManager-wifi`` ``network-manager-applet`` ``notification-daemon`` ``gnome-keyring`` ``polkit`` ``@hardware-support``. If your network devices need extra packages for the template to work as a network VM, use the ``lspci`` command to identify the devices, then run ``dnf search firmware`` (replace ``firmware`` with the appropriate device identifier) to find the needed packages and then install them. If you need utilities for debugging and analyzing network connections, install ``tcpdump`` ``telnet`` ``nmap`` ``nmap-ncat``.
|
||||
|
||||
- :doc:`USB qube </user/advanced-topics/usb-qubes>`, such as the template for ``sys-usb``: ``qubes-usb-proxy`` to provide USB devices to other Qubes and ``qubes-input-proxy-sender`` to provide keyboard or mouse input to dom0.
|
||||
|
||||
- `VPN qube <https://forum.qubes-os.org/t/19061>`__: Use the ``dnf search "NetworkManager VPN plugin"`` command to look up the VPN packages you need, based on the VPN technology you’ll be using, and install them. Some GNOME related packages may be needed as well. After creation of a machine based on this template, follow the `VPN instructions <https://forum.qubes-os.org/t/19061#set-up-a-proxyvm-as-a-vpn-gateway-using-networkmanager>`__ to configure it.
|
||||
|
||||
- ``default-mgmt-dvm``: requires ``qubes-core-agent-passwordless-root`` and ``qubes-mgmt-salt-vm-connector``.
|
||||
|
||||
|
||||
|
||||
To manage fedora-39-minimal templates with salt, you may need to install ``python3-urllib3`` in older versions of the template. (This package is already installed in recent builds: see `discussion <https://github.com/QubesOS/qubes-issues/issues/8806>`__.)
|
||||
|
||||
In Qubes 4.0, additional packages from the ``qubes-core-agent`` suite may be needed to make the customized minimal template work properly. These packages are:
|
||||
|
||||
- ``qubes-core-agent-nautilus``: This package provides integration with the Nautilus file manager (without it, items like “copy to VM/open in disposable” will not be shown in Nautilus).
|
||||
|
||||
- ``qubes-core-agent-thunar``: This package provides integration with the thunar file manager (without it, items like “copy to VM/open in disposable” will not be shown in thunar).
|
||||
|
||||
- ``qubes-core-agent-dom0-updates``: Script required to handle ``dom0`` updates. Any template on which the qube responsible for ‘dom0’ updates (e.g. ``sys-firewall``) is based must contain this package.
|
||||
|
||||
- ``qubes-menus``: Defines menu layout.
|
||||
|
||||
- ``qubes-desktop-linux-common``: Contains icons and scripts to improve desktop experience.
|
||||
|
||||
- ``qubes-core-agent-qrexec``: Qubes qrexec agent. Installed by default.
|
||||
|
||||
- ``qubes-core-agent-systemd``: Qubes unit files for SystemD init style. Installed by default.
|
||||
|
||||
- ``qubes-core-agent-passwordless-root``, ``polkit``: By default, the Fedora minimal template doesn’t have passwordless root. These two packages enable this feature.
|
||||
|
||||
- ``qubes-core-agent-sysvinit``: Qubes unit files for SysV init style or upstart.
|
||||
|
||||
|
||||
|
||||
Also, there are packages to provide additional services:
|
||||
|
||||
- ``qubes-gpg-split``: For implementing split GPG.
|
||||
|
||||
- ``qubes-ctap``: For implementing secure forwarding of CTAP messages.
|
||||
|
||||
- ``qubes-pdf-converter``: For implementing safe conversion of PDFs.
|
||||
|
||||
- ``qubes-img-converter``: For implementing safe conversion of images.
|
||||
|
||||
- ``qubes-snapd-helper``: If you want to use snaps in qubes.
|
||||
|
||||
- ``thunderbird-qubes``: Additional tools for use in thunderbird.
|
||||
|
||||
- ``qubes-app-shutdown-idle``: If you want qubes to automatically shutdown when idle.
|
||||
|
||||
- ``qubes-mgmt-salt-vm-connector``: If you want to use salt management on the template and qubes.
|
||||
|
||||
|
||||
|
||||
You may also wish to consider additional packages from the ``qubes-core-agent`` suite.
|
||||
|
||||
See `here <https://forum.qubes-os.org/t/18999>`__ for further information on customizing ``fedora-minimal``.
|
||||
|
||||
Logging
|
||||
^^^^^^^
|
||||
|
||||
|
||||
The ``rsyslog`` logging service is not installed by default, as all logging is instead being handled by the ``systemd`` journal. Users requiring the ``rsyslog`` service should install it manually.
|
||||
|
||||
To access the ``journald`` log, use the ``journalctl`` command.
|
||||
|
||||
Debian
|
||||
^^^^^^
|
||||
|
||||
|
||||
The following list provides an overview of which packages are needed for which purpose. As usual, the required packages are to be installed in the running template with the following command (replace ``packages`` with a space-delimited list of packages to be installed):
|
||||
|
||||
.. code:: bash
|
||||
|
||||
[user@your-new-clone ~]$ sudo apt install packages
|
||||
|
||||
|
||||
|
||||
- Commonly used utilities: ``pciutils`` ``vim-minimal`` ``less`` ``psmisc`` ``gnome-keyring``
|
||||
|
||||
- The ``zenity`` package is required for interactive dialogs, e.g., file selection (`#5202 <https://github.com/QubesOS/qubes-issues/issues/5202>`__) and for using the Nautilus menu option to copy some files to other qubes (`#6801 <https://github.com/QubesOS/qubes-issues/issues/6801>`__).
|
||||
|
||||
- Audio: ``pulseaudio-qubes``
|
||||
|
||||
- Networking: ``qubes-core-agent-networking``, and whatever network tools you want. N.B. minimal templates do not include any browser.
|
||||
|
||||
- :doc:`FirewallVM </user/security-in-qubes/firewall>`, such as the template for ``sys-firewall``: at least ``qubes-core-agent-networking``, and also ``qubes-core-agent-dom0-updates`` if you want to use it as the ``UpdateVM`` (which is normally ``sys-firewall``).
|
||||
|
||||
- NetVM, such as the template for ``sys-net``: ``qubes-core-agent-networking``, ``qubes-core-agent-network-manager``, ``ntpd`` (or other NTP Service). Wi-Fi also requires ``wpasupplicant``, and (optionally) ``gnome-keyring`` for saving the Wi-Fi password. If your network devices need extra packages for a network VM, use the ``lspci`` command to identify the devices, then find the package that provides necessary firmware and install it. If you need utilities for debugging and analyzing network connections, install the following packages: ``tcpdump`` ``telnet`` ``nmap`` ``ncat``.
|
||||
|
||||
- :doc:`USB qube </user/advanced-topics/usb-qubes>`, such as the template for ``sys-usb``: ``qubes-usb-proxy`` to provide USB devices to other Qubes and ``qubes-input-proxy-sender`` to provide keyboard or mouse input to dom0.
|
||||
|
||||
- Qubes to which USB devices are attached: ``libpam-systemd`` (Until `#7689 <https://github.com/QubesOS/qubes-issues/issues/7689>`__ is fixed, either pair it with ``qubes-core-agent-passwordless-root`` or manually activate the user session with ``loginctl activate <USER_SESSION_ID>``.)
|
||||
|
||||
- `VPN qube <https://forum.qubes-os.org/t/19061>`__: You may need to install network-manager VPN packages, depending on the VPN technology you’ll be using. After creating a machine based on this template, follow the `VPN howto <https://forum.qubes-os.org/t/19061#set-up-a-proxyvm-as-a-vpn-gateway-using-networkmanager>`__ to configure it.
|
||||
|
||||
- ``default-mgmt-dvm``: requires ``qubes-core-agent-passwordless-root`` and ``qubes-mgmt-salt-vm-connector``.
|
||||
|
||||
- :doc:`Yubikey </user/security-in-qubes/mfa>`: You may need to install ``xserver-xorg-input-libinput`` for 2FA responses to work in web browsers like Firefox.
|
||||
|
||||
- Thumbnails (e.g., file previews in Nautilus): ``libgdk-pixbuf2.0-bin`` (images), ``ffmpegthumbnailer`` (videos). (Try ``apt search thumbnailer`` for other file types.)
|
||||
|
||||
|
||||
|
||||
In Qubes 4.0, additional packages from the ``qubes-core-agent`` suite may be needed to make the customized minimal template work properly. These packages are:
|
||||
|
||||
- ``qubes-core-agent-nautilus``: This package provides integration with the Nautilus file manager (without it, items like “copy to VM/open in disposable” will not be shown in Nautilus).
|
||||
|
||||
- ``qubes-core-agent-thunar``: This package provides integration with the thunar file manager (without it, items like “copy to VM/open in disposable” will not be shown in thunar).
|
||||
|
||||
- ``qubes-core-agent-dom0-updates``: Script required to handle ``dom0`` updates. Any template on which the qube responsible for ‘dom0’ updates (e.g. ``sys-firewall``) is based must contain this package.
|
||||
|
||||
- ``qubes-menus``: Defines menu layout.
|
||||
|
||||
- ``qubes-desktop-linux-common``: Contains icons and scripts to improve desktop experience.
|
||||
|
||||
|
||||
|
||||
Also, there are packages to provide additional services:
|
||||
|
||||
- ``qubes-gpg-split``: For implementing split GPG.
|
||||
|
||||
- ``qubes-ctap``: For implementing secure forwarding of CTAP messages.
|
||||
|
||||
- ``qubes-pdf-converter``: For implementing safe conversion of PDFs.
|
||||
|
||||
- ``qubes-img-converter``: For implementing safe conversion of images.
|
||||
|
||||
- ``qubes-snapd-helper``: If you want to use snaps in qubes.
|
||||
|
||||
- ``qubes-thunderbird``: Additional tools for use in thunderbird.
|
||||
|
||||
- ``qubes-app-shutdown-idle``: If you want qubes to automatically shutdown when idle.
|
||||
|
||||
- ``qubes-mgmt-salt-vm-connector``: If you want to use salt management on the template and qubes.
|
||||
|
||||
|
||||
|
||||
Documentation on all of these can be found in the :doc:`docs </index>`.
|
||||
|
||||
You could, of course, use ``qubes-vm-recommended`` to automatically install many of these, but in that case you are well on the way to a standard Debian template.
|
||||
|
|
@ -1,406 +0,0 @@
|
|||
---
|
||||
lang: en
|
||||
layout: doc
|
||||
permalink: /doc/templates/
|
||||
redirect_from:
|
||||
- /doc/template/
|
||||
- /en/doc/templates/
|
||||
- /doc/Templates/
|
||||
- /wiki/Templates/
|
||||
ref: 131
|
||||
title: Templates
|
||||
---
|
||||
|
||||
In [Getting Started](/doc/getting-started/), we covered the distinction
|
||||
in Qubes OS between where you *install* your software and where you *run* your
|
||||
software. Software that you use in most everyday tasks, is installed within [templates](/doc/glossary/#template).
|
||||
When using Qubes OS, you normally work in [app qubes](/doc/glossary/#app-qube).
|
||||
App qubes are based on a *template* qube (or more simply, just *a template*).
|
||||
They inherit most of the ["root filesystem"](https://opensource.com/life/16/10/introduction-linux-filesystems), from the template.
|
||||
Changes you make to the root filesystem are not written back to the template: if you install an application in an app qube it will disappear when you shut down the qube. (You may be able to work round this by using Flatpak or snap packages, which install to the user's home directory.)
|
||||
The user home directory *is* specific to the app qube, and changes there are kept.
|
||||
There is a full explanation of this [below](#inheritance-and-persistence).
|
||||
|
||||
If you use a [Standalone](/doc/glossary/#standalone), the **whole filesystem** is specific to the standalone, and every change you make will be kept after shutdown.
|
||||
|
||||
The template system has significant benefits:
|
||||
|
||||
* **Security:** Each qube has read-only access to the template on which it's
|
||||
based, so if a qube is compromised, it cannot infect its template or any of
|
||||
the other qubes based on that template.
|
||||
|
||||
* **Storage:** Each qube based on a template uses only the disk space required
|
||||
to store its own data (i.e., your files in its home directory), which
|
||||
dramatically saves on disk space.
|
||||
|
||||
* **Speed:** It is extremely fast to create new app qubes, since the root
|
||||
filesystem already exists in the template.
|
||||
|
||||
* **Updates:** Updates are naturally centralized, since updating a template
|
||||
means that all qubes based on it will automatically use those updates after
|
||||
they're restarted.
|
||||
|
||||
An important side effect of this system is that any software installed in an
|
||||
app qube (rather than in the template on which it is based) will disappear
|
||||
when the app qube shuts down (see [Inheritance and
|
||||
Persistence](#inheritance-and-persistence)). For this reason, we recommend
|
||||
installing most of your software in templates, not app qubes.
|
||||
|
||||
The default template in Qubes is based on Fedora, but there are additional
|
||||
templates based on other Linux distributions. There are also templates
|
||||
available with or without certain software preinstalled. You may find it useful
|
||||
to have multiple templates installed in order to provide:
|
||||
|
||||
* Different security levels (e.g., more or less trusted software installed)
|
||||
* Different environments (e.g., Fedora, Debian, Whonix)
|
||||
* Different tools (e.g., office, media, development, hardware drivers)
|
||||
|
||||
## Official
|
||||
|
||||
These are the official Qubes OS Project templates. We build and release updates
|
||||
for these templates. We guarantee that the binary updates are compiled from
|
||||
exactly the same source code as we publish.
|
||||
|
||||
* [Fedora](/doc/templates/fedora/) (default)
|
||||
* [Fedora Minimal](/doc/templates/minimal/)
|
||||
* [Fedora Xfce](/doc/templates/xfce)
|
||||
* [Debian](/doc/templates/debian/)
|
||||
* [Debian Minimal](/doc/templates/minimal/)
|
||||
* [Debian Xfce](/doc/templates/xfce)
|
||||
|
||||
You can see the current supported versions [here](/doc/supported-releases#templates).
|
||||
|
||||
## Community
|
||||
|
||||
These templates are supported by the Qubes community. Some of them are
|
||||
available in ready-to-use binary package form (built by the Qubes developers),
|
||||
while others are available only in source code form. In all cases, the Qubes OS
|
||||
Project does not provide updates for these templates. However, such updates may
|
||||
be provided by the template maintainer.
|
||||
|
||||
By installing these templates, you are trusting not only the Qubes developers
|
||||
and the distribution maintainers, but also the template maintainer. In
|
||||
addition, these templates may be somewhat less stable, since the Qubes
|
||||
developers do not test them.
|
||||
|
||||
* [Whonix](/doc/templates/whonix/)
|
||||
* [Ubuntu](/doc/templates/ubuntu/)
|
||||
* [Arch Linux](/doc/building-archlinux-template/)
|
||||
* [Gentoo](/doc/templates/gentoo/)
|
||||
* [Gentoo Minimal](/doc/templates/minimal/)
|
||||
* [CentOS*](/doc/templates/centos)
|
||||
|
||||
*\* The CentOS version used by this template reached
|
||||
[End-of-Life in June 2024](https://en.wikipedia.org/wiki/CentOS_Stream#Release_history)
|
||||
and is no longer receiving updates. Due to a lack of specific interest
|
||||
at this time a proposal to create a new CentOS 10 template was
|
||||
[declined](https://github.com/QubesOS/qubes-issues/issues/9716).*
|
||||
|
||||
## Windows
|
||||
|
||||
Windows templates are constructed differently from Linux-based templates as
|
||||
Windows is a closed source system that can be modified only after installing.
|
||||
So it is not possible to provide preconfigured Windows templates for Qubes.
|
||||
The process of installing a Windows qube and connecting it to the Qubes
|
||||
environment via installing Qubes Windows Tools (QWT) is described in several
|
||||
chapters in [Windows qubes](/doc/templates/windows/).
|
||||
|
||||
## Installing
|
||||
|
||||
Certain templates come preinstalled with Qubes OS. However, there may be times
|
||||
when you wish to install a fresh template from the Qubes repositories, e.g.:
|
||||
|
||||
* When a template version you're using reaches
|
||||
[end-of-life](/doc/how-to-update/#upgrading-to-avoid-eol).
|
||||
* When a new version of a template that you wish to use becomes
|
||||
[supported](/doc/supported-releases/).
|
||||
* When you suspect your template has been compromised.
|
||||
* When you have made modifications to your template that you no longer want.
|
||||
|
||||
You can manage your templates using the `Qubes Template Manager`, a GUI tool available from the Qube menu.
|
||||
You can also use a command line tool in dom0 - `qvm-template`.
|
||||
|
||||
At the command line in dom0, `qvm-template list --available` will show available templates. To install a template, use:
|
||||
|
||||
```
|
||||
$ qvm-template install <template_name>
|
||||
```
|
||||
You can also use `qvm-template` to upgrade or reinstall templates.
|
||||
|
||||
Repository (repo) definitions are stored in dom0 in `/etc/qubes/repo-templates` and associated keys in `/etc/qubes/repo-templates/keys`.
|
||||
There are additional repos for testing releases and community templates.
|
||||
To temporarily enable any of these repos, use the `--enablerepo=<repo-name>` option. E.g. :
|
||||
|
||||
```
|
||||
$ qvm-template --enablerepo qubes-templates-community install <template_name>
|
||||
```
|
||||
|
||||
To permanently enable a repo, set the line `enabled = 1` in the repo definition in `/etc/qubes/repo-templates`.
|
||||
To permanently disable, set the line to `enabled = 0`.
|
||||
|
||||
If you wish to install a template that is in testing, please see
|
||||
[here](/doc/testing/#templates).
|
||||
|
||||
## After Installing
|
||||
|
||||
After installing a fresh template, we recommend performing the following steps:
|
||||
|
||||
1. [Update the template](#updating).
|
||||
|
||||
2. [Switch any app qubes that are based on the old template to the new
|
||||
one](#switching).
|
||||
|
||||
3. If desired, [uninstall the old template](#uninstalling).
|
||||
|
||||
## Network access
|
||||
|
||||
For information about how templates access the network, please see [Why don’t
|
||||
templates have network
|
||||
access?](/doc/how-to-install-software/#why-dont-templates-have-normal-network-access)
|
||||
and the [Updates proxy](/doc/how-to-install-software/#updates-proxy).
|
||||
|
||||
## Updating
|
||||
|
||||
Please see [How to Update](/doc/how-to-update/).
|
||||
|
||||
## Installing Software
|
||||
|
||||
Please see [How to Install Software](/doc/how-to-install-software).
|
||||
|
||||
## Uninstalling
|
||||
|
||||
To remove a template, the graphical `Qube Manager` (Qubes Menu > Qubes Tools > Qube Manager) may be used. Right-click the template to be uninstalled and click "Delete qube" to begin removal. If no issues are found, a dialog box will request the template's name be typed as a final confirmation. Upon completion, the template will be deleted.
|
||||
|
||||
Alternatively, to remove a template via the command line in dom0:
|
||||
```
|
||||
$ qvm-template remove <TEMPLATE_NAME>
|
||||
```
|
||||
|
||||
\<TEMPLATE_NAME> is the first column from the output of:
|
||||
```
|
||||
$ qvm-template list --installed
|
||||
```
|
||||
|
||||
In either case, issues with template removal may be raised. If an issue is raised, the template will remain installed and a list of concerns displayed. "Global property default_template" requires [switching](#switching) the default_template property to another template. "Template for" can be resolved by [switching](#switching) the dependent qubes' template. Once the issues are addressed, attempt the removal again.
|
||||
|
||||
If the template's entry in the Qubes Menu is not removed with its uninstallation, consult the [troubleshooting page](/doc/app-menu-shortcut-troubleshooting/#what-if-a-removed-application-is-still-in-the-app-menu).
|
||||
|
||||
## Reinstalling
|
||||
|
||||
Please see [How to Reinstall a Template](/doc/reinstall-template/).
|
||||
|
||||
## Switching
|
||||
|
||||
When you install a new template or
|
||||
[upgrade](/doc/how-to-update/#upgrading-to-avoid-eol) a template, it is
|
||||
recommended that you switch everything that was using the old template to the
|
||||
new template:
|
||||
|
||||
1. **Make the new template the default template.** In the App Menu, go
|
||||
to Qubes Tools, then click on Qubes Global Settings. In the Qube Defaults
|
||||
section, next to Template, select the new template from the
|
||||
drop-down list. Press OK.
|
||||
|
||||
2. **Base your [disposable templates](/doc/glossary/#disposable-template) on
|
||||
the new template.**
|
||||
|
||||
- If your only keyboard and mouse are *not* connected through a [USB
|
||||
qube](/doc/usb-qubes/), or that USB qube is *not* a disposable, then shut
|
||||
down all disposables. In the App Menu, go to Qubes Tools, then click on
|
||||
Qube Manager. In the Qube Manager, find your disposable template(s). (By
|
||||
default, they end in `-dvm`.) Right click, hover over Template, then click
|
||||
on the new template. Repeat for each disposable template.
|
||||
|
||||
- If your only keyboard or mouse *are* connected through a USB qube, and
|
||||
that USB qube *is* a disposable, then you will have to enter a special
|
||||
command that shuts down all of your qubes, switches the USB qube's
|
||||
disposable template to the new template, then starts the USB qube again.
|
||||
In order to avoid being locked out of your system, you must be very
|
||||
careful to enter this command without typos and with the correct
|
||||
substitutions.
|
||||
|
||||
In the App Menu, click on Terminal Emulator. Type the command below,
|
||||
substituting `<SYS_USB_DISPOSABLE_TEMPLATE>` with the name of the
|
||||
disposable template on which `sys-usb` is based, `<NEW_TEMPLATE>` with the
|
||||
name of the new template, and `<USB_QUBE>` with the name of your USB qube.
|
||||
Other than these substitutions, make sure to enter the command exactly as
|
||||
written.
|
||||
|
||||
```
|
||||
qvm-shutdown --wait --all; qvm-prefs <SYS_USB_DISPOSABLE_TEMPLATE> template <NEW_TEMPLATE>; qvm-start <USB_QUBE>
|
||||
```
|
||||
|
||||
With substitutions, your command should look similar to this example.
|
||||
(Warning: This is just an example. Do not attempt to use it.)
|
||||
|
||||
```
|
||||
qvm-shutdown --wait --all; qvm-prefs fedora-01-dvm template fedora-02; qvm-start sys-usb
|
||||
```
|
||||
|
||||
3. **Base your app qubes on the new template.** In the Qube Manager, click on
|
||||
the Template heading to sort by template. Select all the qubes based on the
|
||||
old template by clicking on the first one, holding shift, then clicking on
|
||||
the last one. With multiple qubes selected, right-click on any of them,
|
||||
hover your cursor over Template, then click on the new template.
|
||||
Or in the `System` menu select `Manage templates for qubes`, select
|
||||
any qubes using the old template and update them to the new template
|
||||
using the drop down menu.
|
||||
|
||||
4. **Change the template for the default-mgmt-dvm** If the old template
|
||||
was used for management qubes, then you should change the template.
|
||||
This is an *internal* qube which does not appear by default in the Qube manager.
|
||||
In the `System` menu select `Manage templates for qubes`, and you will see the *default-mgmt-dvm* qube.
|
||||
Change the template used for this disposable template to the new template.
|
||||
|
||||
## Advanced
|
||||
|
||||
The following sections cover advanced topics pertaining to templates.
|
||||
|
||||
### Inheritance and persistence
|
||||
|
||||
Whenever an app qube is created, the contents of the `/home` directory of its
|
||||
parent template are *not* copied to the child app qube's `/home`. The child app
|
||||
qube's `/home` is always independent from its parent template's `/home`, which
|
||||
means that any subsequent changes to the parent template's `/home` will not
|
||||
affect the child app qube's `/home`.
|
||||
|
||||
Once an app qube has been created, any changes in its `/home`, `/usr/local`, or
|
||||
`/rw/config` directories will be persistent across reboots, which means that
|
||||
any files stored there will still be available after restarting the app qube.
|
||||
No changes in any other directories in app qubes persist in this manner. If you
|
||||
would like to make changes in other directories which *do* persist in this
|
||||
manner, you must make those changes in the parent template.
|
||||
|
||||
| Qube Type | Inheritance<sup>1</sup> | Persistence<sup>2</sup> |
|
||||
|-------------------------------------------------|-----------------------------------------------------------|---------------------------------------------------------|
|
||||
| [template](/doc/glossary/#template) | N/A (templates cannot be based on templates) | everything |
|
||||
| [app qube](/doc/glossary/#app-qube)<sup>3</sup> | `/etc/skel` to `/home`; `/usr/local.orig` to `/usr/local` | `/rw` (includes `/home`, `/usr/local`, and `bind-dirs`) |
|
||||
| [disposable](/doc/glossary/#disposable) | `/rw` (includes `/home`, `/usr/local`, and `bind-dirs`) | nothing |
|
||||
|
||||
<sup>1</sup>Upon creation
|
||||
<sup>2</sup>Following shutdown
|
||||
<sup>3</sup>Includes [disposable templates](/doc/glossary/#disposable-template)
|
||||
|
||||
### Trusting your templates
|
||||
|
||||
As the template is used for creating filesystems for other app qubes where you
|
||||
actually do the work, it means that the template is as trusted as the most
|
||||
trusted app qube based on this template. In other words, if your template gets
|
||||
compromised, e.g. because you installed an application, whose *installer's
|
||||
scripts* were malicious, then *all* your app qubes (based on this template)
|
||||
will inherit this compromise.
|
||||
|
||||
There are several ways to deal with this problem:
|
||||
|
||||
* Only install packages from trusted sources -- e.g. from the pre-configured
|
||||
Fedora repositories. All those packages are signed by Fedora, and we expect
|
||||
that at least the package's installation scripts are not malicious. This is
|
||||
enforced by default (at the [firewall qube level](/doc/firewall/)), by not
|
||||
allowing any networking connectivity in the default template, except for
|
||||
access to the Fedora repos.
|
||||
|
||||
* Use [standalones](/doc/glossary/#standalone) (see below) for installation of
|
||||
untrusted software packages.
|
||||
|
||||
* Use multiple templates (see below) for different classes of domains, e.g. a
|
||||
less trusted template, used for creation of less trusted app qubes, would get
|
||||
various packages from less trusted vendors, while the template used for more
|
||||
trusted app qubes will only get packages from the standard Fedora repos.
|
||||
|
||||
Some popular questions:
|
||||
|
||||
> So, why should we actually trust Fedora repos -- it also contains large
|
||||
> amount of third-party software that might be buggy, right?
|
||||
|
||||
As far as the template's compromise is concerned, it doesn't really matter
|
||||
whether `/usr/bin/firefox` is buggy and can be exploited, or not. What matters
|
||||
is whether its *installation* scripts (such as %post in the rpm.spec) are
|
||||
benign or not. A template should be used only for installation of packages, and
|
||||
nothing more, so it should never get a chance to actually run
|
||||
`/usr/bin/firefox` and get infected from it, in case it was compromised. Also,
|
||||
some of your more trusted app qubes would have networking restrictions enforced
|
||||
by the [firewall qube](/doc/firewall/), and again they should not fear this
|
||||
proverbial `/usr/bin/firefox` being potentially buggy and easy to compromise.
|
||||
|
||||
> But why trust Fedora?
|
||||
|
||||
Because we chose to use Fedora as a vendor for the Qubes OS foundation (e.g.
|
||||
for dom0 packages and for app qube packages). We also chose to trust several
|
||||
other vendors, such as Xen.org, kernel.org, and a few others whose software we
|
||||
use in dom0. We had to trust *somebody* as we are unable to write all the
|
||||
software from scratch ourselves. But there is a big difference in trusting all
|
||||
Fedora packages to be non-malicious (in terms of installation scripts) vs.
|
||||
trusting all those packages are non-buggy and non-exploitable. We certainly do
|
||||
not assume the latter.
|
||||
|
||||
> So, are the templates as trusted as dom0?
|
||||
|
||||
Not quite. Dom0 compromise is absolutely fatal, and it leads to Game
|
||||
Over<sup>TM</sup>. However, a compromise of a template affects only a subset of
|
||||
all your app qubes (in case you use more than one template, or also some
|
||||
standalones). Also, if your app qubes are network disconnected, even though
|
||||
their filesystems might get compromised due to the corresponding template
|
||||
compromise, it still would be difficult for the attacker to actually leak out
|
||||
the data stolen in an app qube. Not impossible (due to existence of covert
|
||||
channels between VMs on x86 architecture), but difficult and slow.
|
||||
|
||||
### Note on treating app qubes' root filesystem non-persistence as a security feature
|
||||
|
||||
Any app qube that is based on a template has its root filesystem non-persistent
|
||||
across qube reboots. In other words, whatever changes the qube makes (or the
|
||||
malware running in this qube makes) to its root filesystem, are automatically
|
||||
discarded whenever one restarts the qube.
|
||||
|
||||
This might seem like an excellent anti-malware mechanism to be used inside the
|
||||
qube. However, one should be careful with treating this property as a reliable
|
||||
way to keep the qube malware-free. This is because the non-persistence, in the
|
||||
case of normal qubes, applies only to the root filesystem and not to the user
|
||||
filesystem (on which the `/home`, `/rw`, and `/usr/local` are stored) for
|
||||
obvious reasons. It is possible that malware, especially malware that could be
|
||||
specifically written to target Qubes, could install its hooks
|
||||
inside the user home directory files only. Examples of obvious places for such
|
||||
hooks could be: `.bashrc`, the Firefox profile directory which contains the
|
||||
extensions, or some PDF or DOC documents that are expected to be opened by the
|
||||
user frequently (assuming the malware found an exploitable bug in the PDF or
|
||||
DOC reader), and surely many others places, all in the user's home directory.
|
||||
|
||||
One advantage of the non-persistent rootfs though, is that the malware is still
|
||||
inactive before the user's filesystem gets mounted and "processed" by
|
||||
system/applications, which might theoretically allow for some scanning programs
|
||||
(or a skilled user) to reliably scan for signs of infections of the app qube.
|
||||
But, of course, the problem of finding malware hooks in general is hard, so
|
||||
this would work likely only for some special cases (e.g. an app qube which
|
||||
doesn't use Firefox, as otherwise it would be hard to scan the Firefox profile
|
||||
directory reliably to find malware hooks there). Also note that the user
|
||||
filesystem's metadata might got maliciously modified by malware in order to
|
||||
exploit a hypothetical bug in the app qube kernel whenever it mounts the
|
||||
malformed filesystem. However, these exploits will automatically stop working
|
||||
(and so the infection might be cleared automatically) after the hypothetical
|
||||
bug got patched and the update applied (via template update), which is an
|
||||
exceptional feature of Qubes OS.
|
||||
|
||||
Also note that disposable qubes do not have persistent user filesystem, and so
|
||||
they start up completely "clean" every time. Note the word "clean" means in
|
||||
this context: the same as their template filesystem, of course.
|
||||
|
||||
### Important Notes
|
||||
|
||||
* `qvm-trim-template` is no longer necessary or available in Qubes 4.0 and
|
||||
higher. All qubes are created in a thin pool and trimming is handled
|
||||
automatically. No user action is required. See [Disk Trim](/doc/disk-trim)
|
||||
for more information.
|
||||
|
||||
* RPM-installed templates are "system managed" and therefore cannot be backed
|
||||
up using Qubes' built-in backup function. In order to ensure the preservation
|
||||
of your custom settings and the availability of a "known-good" backup
|
||||
template, you may wish to clone the default system template and use your
|
||||
clone as the default template for your app qubes.
|
||||
|
||||
* Some templates are available in ready-to-use binary form, but some of them
|
||||
are available only as source code, which can be built using the [Qubes
|
||||
Builder](https://github.com/QubesOS/qubes-builderv2/). In particular, some
|
||||
template "flavors" are available in source code form only. For the
|
||||
technical details of the template
|
||||
system, please see [Template Implementation](/doc/template-implementation/).
|
||||
Take a look at the [Qubes Builder](/doc/qubes-builder-v2/) documentation for
|
||||
instructions on how to compile them.
|
||||
317
user/templates/templates.rst
Normal file
317
user/templates/templates.rst
Normal file
|
|
@ -0,0 +1,317 @@
|
|||
=========
|
||||
Templates
|
||||
=========
|
||||
|
||||
|
||||
In :doc:`Getting Started </introduction/getting-started>`, we covered the distinction in Qubes OS between where you *install* your software and where you *run* your software. Software that you use in most everyday tasks, is installed within :ref:`templates <user/reference/glossary:template>`. When using Qubes OS, you normally work in :ref:`app qubes <user/reference/glossary:app qube>`. App qubes are based on a *template* qube (or more simply, just *a template*). They inherit most of the `“root filesystem” <https://opensource.com/life/16/10/introduction-linux-filesystems>`__, from the template. Changes you make to the root filesystem are not written back to the template: if you install an application in an app qube it will disappear when you shut down the qube. (You may be able to work round this by using Flatpak or snap packages, which install to the user’s home directory.) The user home directory *is* specific to the app qube, and changes there are kept. There is a full explanation of this `below <#inheritance-and-persistence>`__.
|
||||
|
||||
If you use a :ref:`Standalone <user/reference/glossary:standalone>`, the **whole filesystem** is specific to the standalone, and every change you make will be kept after shutdown.
|
||||
|
||||
The template system has significant benefits:
|
||||
|
||||
- **Security:** Each qube has read-only access to the template on which it’s based, so if a qube is compromised, it cannot infect its template or any of the other qubes based on that template.
|
||||
|
||||
- **Storage:** Each qube based on a template uses only the disk space required to store its own data (i.e., your files in its home directory), which dramatically saves on disk space.
|
||||
|
||||
- **Speed:** It is extremely fast to create new app qubes, since the root filesystem already exists in the template.
|
||||
|
||||
- **Updates:** Updates are naturally centralized, since updating a template means that all qubes based on it will automatically use those updates after they’re restarted.
|
||||
|
||||
|
||||
|
||||
An important side effect of this system is that any software installed in an app qube (rather than in the template on which it is based) will disappear when the app qube shuts down (see `Inheritance and Persistence <#inheritance-and-persistence>`__). For this reason, we recommend installing most of your software in templates, not app qubes.
|
||||
|
||||
The default template in Qubes is based on Fedora, but there are additional templates based on other Linux distributions. There are also templates available with or without certain software preinstalled. You may find it useful to have multiple templates installed in order to provide:
|
||||
|
||||
- Different security levels (e.g., more or less trusted software installed)
|
||||
|
||||
- Different environments (e.g., Fedora, Debian, Whonix)
|
||||
|
||||
- Different tools (e.g., office, media, development, hardware drivers)
|
||||
|
||||
|
||||
|
||||
Official
|
||||
--------
|
||||
|
||||
|
||||
These are the official Qubes OS Project templates. We build and release updates for these templates. We guarantee that the binary updates are compiled from exactly the same source code as we publish.
|
||||
|
||||
- :doc:`Fedora </user/templates/fedora/fedora>` (default)
|
||||
|
||||
- :doc:`Fedora Minimal </user/templates/minimal-templates>`
|
||||
|
||||
- :doc:`Fedora Xfce </user/templates/xfce-templates>`
|
||||
|
||||
- :doc:`Debian </user/templates/debian/debian>`
|
||||
|
||||
- :doc:`Debian Minimal </user/templates/minimal-templates>`
|
||||
|
||||
- :doc:`Debian Xfce </user/templates/xfce-templates>`
|
||||
|
||||
|
||||
|
||||
You can see the current supported versions :ref:`here <user/downloading-installing-upgrading/supported-releases:templates>`.
|
||||
|
||||
Community
|
||||
---------
|
||||
|
||||
|
||||
These templates are supported by the Qubes community. Some of them are available in ready-to-use binary package form (built by the Qubes developers), while others are available only in source code form. In all cases, the Qubes OS Project does not provide updates for these templates. However, such updates may be provided by the template maintainer.
|
||||
|
||||
By installing these templates, you are trusting not only the Qubes developers and the distribution maintainers, but also the template maintainer. In addition, these templates may be somewhat less stable, since the Qubes developers do not test them.
|
||||
|
||||
- `Whonix <https://forum.qubes-os.org/t/19014>`__
|
||||
|
||||
- `Ubuntu <https://qubes.3isec.org>`__
|
||||
|
||||
- `Arch Linux <https://forum.qubes-os.org/t/19052>`__
|
||||
|
||||
- `Gentoo <https://forum.qubes-os.org/t/19007>`__
|
||||
|
||||
- :doc:`Gentoo Minimal </user/templates/minimal-templates>`
|
||||
|
||||
- :doc:`CentOS* <https://forum.qubes-os.org/t/19006>`
|
||||
|
||||
|
||||
|
||||
\* *The CentOS version used by this template reached* `End-of-Life in June 2024 <https://en.wikipedia.org/wiki/CentOS_Stream#Release_history>`__ *and is no longer receiving updates. Due to a lack of specific interest at this time a proposal to create a new CentOS 10 template was* `declined <https://github.com/QubesOS/qubes-issues/issues/9716>`__ *.*
|
||||
|
||||
Windows
|
||||
-------
|
||||
|
||||
|
||||
Windows templates are constructed differently from Linux-based templates as Windows is a closed source system that can be modified only after installing. So it is not possible to provide preconfigured Windows templates for Qubes. The process of installing a Windows qube and connecting it to the Qubes environment via installing Qubes Windows Tools (QWT) is described in several chapters in :doc:`Windows qubes </user/templates/windows/windows>`.
|
||||
|
||||
Installing
|
||||
----------
|
||||
|
||||
|
||||
Certain templates come preinstalled with Qubes OS. However, there may be times when you wish to install a fresh template from the Qubes repositories, e.g.:
|
||||
|
||||
- When a template version you’re using reaches :ref:`end-of-life <user/how-to-guides/how-to-update:upgrading to avoid eol>`.
|
||||
|
||||
- When a new version of a template that you wish to use becomes :doc:`supported </user/downloading-installing-upgrading/supported-releases>`.
|
||||
|
||||
- When you suspect your template has been compromised.
|
||||
|
||||
- When you have made modifications to your template that you no longer want.
|
||||
|
||||
|
||||
|
||||
You can manage your templates using the ``Qubes Template Manager``, a GUI tool available from the Qube menu. You can also use a command line tool in dom0 - ``qvm-template``.
|
||||
|
||||
At the command line in dom0, ``qvm-template list --available`` will show available templates. To install a template, use:
|
||||
|
||||
.. code:: bash
|
||||
|
||||
$ qvm-template install <template_name>
|
||||
|
||||
|
||||
|
||||
You can also use ``qvm-template`` to upgrade or reinstall templates.
|
||||
|
||||
Repository (repo) definitions are stored in dom0 in ``/etc/qubes/repo-templates`` and associated keys in ``/etc/qubes/repo-templates/keys``. There are additional repos for testing releases and community templates. To temporarily enable any of these repos, use the ``--enablerepo=<repo-name>`` option. E.g. :
|
||||
|
||||
.. code:: bash
|
||||
|
||||
$ qvm-template --enablerepo qubes-templates-community install <template_name>
|
||||
|
||||
|
||||
To permanently enable a repo, set the line ``enabled = 1`` in the repo definition in ``/etc/qubes/repo-templates``.
|
||||
To permanently disable, set the line to ``enabled = 0``.
|
||||
|
||||
|
||||
If you wish to install a template that is in testing, please see :ref:`here <user/downloading-installing-upgrading/testing:templates>`.
|
||||
|
||||
After Installing
|
||||
----------------
|
||||
|
||||
|
||||
After installing a fresh template, we recommend performing the following steps:
|
||||
|
||||
1. `Update the template <#updating>`__.
|
||||
|
||||
2. `Switch any app qubes that are based on the old template to the new one <#switching>`__.
|
||||
|
||||
3. If desired, `uninstall the old template <#uninstalling>`__.
|
||||
|
||||
|
||||
|
||||
Network access
|
||||
--------------
|
||||
|
||||
|
||||
For information about how templates access the network, please see :ref:`Why don’t templates have network access? <user/how-to-guides/how-to-install-software:why don't templates have normal network access?>` and the :ref:`Updates proxy <user/how-to-guides/how-to-install-software:updates proxy>`.
|
||||
|
||||
Updating
|
||||
--------
|
||||
|
||||
|
||||
Please see :doc:`How to Update </user/how-to-guides/how-to-update>`.
|
||||
|
||||
Installing Software
|
||||
-------------------
|
||||
|
||||
|
||||
Please see :doc:`How to Install Software </user/how-to-guides/how-to-install-software>`.
|
||||
|
||||
Uninstalling
|
||||
------------
|
||||
|
||||
|
||||
To remove a template, the graphical ``Qube Manager`` (Qubes Menu > Qubes Tools > Qube Manager) may be used. Right-click the template to be uninstalled and click “Delete qube” to begin removal. If no issues are found, a dialog box will request the template’s name be typed as a final confirmation. Upon completion, the template will be deleted.
|
||||
|
||||
Alternatively, to remove a template via the command line in dom0:
|
||||
|
||||
.. code:: bash
|
||||
|
||||
$ qvm-template remove <TEMPLATE_NAME>
|
||||
|
||||
|
||||
|
||||
<TEMPLATE_NAME> is the first column from the output of:
|
||||
|
||||
.. code:: bash
|
||||
|
||||
$ qvm-template list --installed
|
||||
|
||||
|
||||
|
||||
In either case, issues with template removal may be raised. If an issue is raised, the template will remain installed and a list of concerns displayed. “Global property default_template” requires `switching <#switching>`__ the default_template property to another template. “Template for” can be resolved by `switching <#switching>`__ the dependent qubes’ template. Once the issues are addressed, attempt the removal again.
|
||||
|
||||
If the template’s entry in the Qubes Menu is not removed with its uninstallation, consult the :ref:`troubleshooting page <user/troubleshooting/app-menu-shortcut-troubleshooting:what if a removed application is still in the app menu?>`.
|
||||
|
||||
Reinstalling
|
||||
------------
|
||||
|
||||
|
||||
Please see :doc:`How to Reinstall a Template </user/how-to-guides/how-to-reinstall-a-template>`.
|
||||
|
||||
Switching
|
||||
---------
|
||||
|
||||
|
||||
When you install a new template or :ref:`upgrade <user/how-to-guides/how-to-update:upgrading to avoid eol>` a template, it is recommended that you switch everything that was using the old template to the new template:
|
||||
|
||||
1. **Make the new template the default template.** In the App Menu, go to Qubes Tools, then click on Qubes Global Settings. In the Qube Defaults section, next to Template, select the new template from the drop-down list. Press OK.
|
||||
|
||||
2. **Base your** :ref:`disposable templates <user/reference/glossary:disposable template>` **on the new template.**
|
||||
|
||||
- If your only keyboard and mouse are *not* connected through a :doc:`USB qube </user/advanced-topics/usb-qubes>`, or that USB qube is *not* a disposable, then shut down all disposables. In the App Menu, go to Qubes Tools, then click on Qube Manager. In the Qube Manager, find your disposable template(s). (By default, they end in ``-dvm``.) Right click, hover over Template, then click on the new template. Repeat for each disposable template.
|
||||
|
||||
- If your only keyboard or mouse *are* connected through a USB qube, and that USB qube *is* a disposable, then you will have to enter a special command that shuts down all of your qubes, switches the USB qube’s disposable template to the new template, then starts the USB qube again. In order to avoid being locked out of your system, you must be very careful to enter this command without typos and with the correct substitutions.
|
||||
In the App Menu, click on Terminal Emulator. Type the command below, substituting ``<SYS_USB_DISPOSABLE_TEMPLATE>`` with the name of the disposable template on which ``sys-usb`` is based, ``<NEW_TEMPLATE>`` with the name of the new template, and ``<USB_QUBE>`` with the name of your USB qube. Other than these substitutions, make sure to enter the command exactly as written.
|
||||
|
||||
.. code:: bash
|
||||
|
||||
qvm-shutdown --wait --all; qvm-prefs <SYS_USB_DISPOSABLE_TEMPLATE> template <NEW_TEMPLATE>; qvm-start <USB_QUBE>
|
||||
|
||||
|
||||
With substitutions, your command should look similar to this example. (**Warning:** This is just an example. Do not attempt to use it.)
|
||||
|
||||
.. code:: bash
|
||||
|
||||
qvm-shutdown --wait --all; qvm-prefs fedora-01-dvm template fedora-02; qvm-start sys-usb
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
3. **Base your app qubes on the new template.** In the Qube Manager, click on the Template heading to sort by template. Select all the qubes based on the old template by clicking on the first one, holding shift, then clicking on the last one. With multiple qubes selected, right-click on any of them, hover your cursor over Template, then click on the new template. Or in the ``System`` menu select ``Manage templates for qubes``, select any qubes using the old template and update them to the new template using the drop down menu.
|
||||
|
||||
4. **Change the template for the default-mgmt-dvm** If the old template was used for management qubes, then you should change the template. This is an *internal* qube which does not appear by default in the Qube manager. In the ``System`` menu select ``Manage templates for qubes``, and you will see the *default-mgmt-dvm* qube. Change the template used for this disposable template to the new template.
|
||||
|
||||
|
||||
|
||||
Advanced
|
||||
--------
|
||||
|
||||
|
||||
The following sections cover advanced topics pertaining to templates.
|
||||
|
||||
Inheritance and persistence
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
|
||||
Whenever an app qube is created, the contents of the ``/home`` directory of its parent template are *not* copied to the child app qube’s ``/home``. The child app qube’s ``/home`` is always independent from its parent template’s ``/home``, which means that any subsequent changes to the parent template’s ``/home`` will not affect the child app qube’s ``/home``.
|
||||
|
||||
Once an app qube has been created, any changes in its ``/home``, ``/usr/local``, or ``/rw/config`` directories will be persistent across reboots, which means that any files stored there will still be available after restarting the app qube. No changes in any other directories in app qubes persist in this manner. If you would like to make changes in other directories which *do* persist in this manner, you must make those changes in the parent template.
|
||||
|
||||
.. list-table::
|
||||
:widths: 44 44 44
|
||||
:align: center
|
||||
:header-rows: 1
|
||||
|
||||
* - Qube Type
|
||||
- Inheritance :superscript:`1`
|
||||
- Persistence :superscript:`2`
|
||||
* - :ref:`template <user/reference/glossary:template>`
|
||||
- N/A (templates cannot be based on templates)
|
||||
- everything
|
||||
* - :ref:`app qubes <user/reference/glossary:app qube>`:superscript:`3`
|
||||
- ``/etc/skel`` to ``/home``; ``/usr/local.orig`` to ``/usr/local``
|
||||
- ``/rw`` (includes ``/home``, ``/usr/local``, and ``bind-dirs``)
|
||||
* - :ref:`disposable <user/reference/glossary:disposable>`
|
||||
- ``/rw`` (includes ``/home``, ``/usr/local``, and ``bind-dirs``)
|
||||
- nothing
|
||||
|
||||
|
||||
| :superscript:`1` Upon creation
|
||||
| :superscript:`2` Following shutdown
|
||||
| :superscript:`3` Includes :ref:`disposable templates <user/reference/glossary:disposable template>`
|
||||
|
||||
|
||||
Trusting your templates
|
||||
^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
|
||||
As the template is used for creating filesystems for other app qubes where you actually do the work, it means that the template is as trusted as the most trusted app qube based on this template. In other words, if your template gets compromised, e.g. because you installed an application, whose *installer’s scripts* were malicious, then *all* your app qubes (based on this template) will inherit this compromise.
|
||||
|
||||
There are several ways to deal with this problem:
|
||||
|
||||
- Only install packages from trusted sources – e.g. from the pre-configured Fedora repositories. All those packages are signed by Fedora, and we expect that at least the package’s installation scripts are not malicious. This is enforced by default (at the :doc:`firewall qube level </user/security-in-qubes/firewall>`), by not allowing any networking connectivity in the default template, except for access to the Fedora repos.
|
||||
|
||||
- Use :ref:`standalones <user/reference/glossary:standalone>` (see below) for installation of untrusted software packages.
|
||||
|
||||
- Use multiple templates (see below) for different classes of domains, e.g. a less trusted template, used for creation of less trusted app qubes, would get various packages from less trusted vendors, while the template used for more trusted app qubes will only get packages from the standard Fedora repos.
|
||||
|
||||
|
||||
|
||||
Some popular questions:
|
||||
|
||||
So, why should we actually trust Fedora repos – it also contains large amount of third-party software that might be buggy, right?
|
||||
|
||||
As far as the template’s compromise is concerned, it doesn’t really matter whether ``/usr/bin/firefox`` is buggy and can be exploited, or not. What matters is whether its *installation* scripts (such as %post in the rpm.spec) are benign or not. A template should be used only for installation of packages, and nothing more, so it should never get a chance to actually run ``/usr/bin/firefox`` and get infected from it, in case it was compromised. Also, some of your more trusted app qubes would have networking restrictions enforced by the :doc:`firewall qube </user/security-in-qubes/firewall>`, and again they should not fear this proverbial ``/usr/bin/firefox`` being potentially buggy and easy to compromise.
|
||||
|
||||
But why trust Fedora?
|
||||
|
||||
Because we chose to use Fedora as a vendor for the Qubes OS foundation (e.g. for dom0 packages and for app qube packages). We also chose to trust several other vendors, such as Xen.org, kernel.org, and a few others whose software we use in dom0. We had to trust *somebody* as we are unable to write all the software from scratch ourselves. But there is a big difference in trusting all Fedora packages to be non-malicious (in terms of installation scripts) vs. trusting all those packages are non-buggy and non-exploitable. We certainly do not assume the latter.
|
||||
|
||||
So, are the templates as trusted as dom0?
|
||||
|
||||
Not quite. Dom0 compromise is absolutely fatal, and it leads to Game Over :superscript:`TM`. However, a compromise of a template affects only a subset of all your app qubes (in case you use more than one template, or also some standalones). Also, if your app qubes are network disconnected, even though their filesystems might get compromised due to the corresponding template compromise, it still would be difficult for the attacker to actually leak out the data stolen in an app qube. Not impossible (due to existence of covert channels between VMs on x86 architecture), but difficult and slow.
|
||||
|
||||
Note on treating app qubes' root filesystem non-persistence as a security feature
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
|
||||
Any app qube that is based on a template has its root filesystem non-persistent across qube reboots. In other words, whatever changes the qube makes (or the malware running in this qube makes) to its root filesystem, are automatically discarded whenever one restarts the qube.
|
||||
|
||||
This might seem like an excellent anti-malware mechanism to be used inside the qube. However, one should be careful with treating this property as a reliable way to keep the qube malware-free. This is because the non-persistence, in the case of normal qubes, applies only to the root filesystem and not to the user filesystem (on which the ``/home``, ``/rw``, and ``/usr/local`` are stored) for obvious reasons. It is possible that malware, especially malware that could be specifically written to target Qubes, could install its hooks inside the user home directory files only. Examples of obvious places for such hooks could be: ``.bashrc``, the Firefox profile directory which contains the extensions, or some PDF or DOC documents that are expected to be opened by the user frequently (assuming the malware found an exploitable bug in the PDF or DOC reader), and surely many others places, all in the user’s home directory.
|
||||
|
||||
One advantage of the non-persistent rootfs though, is that the malware is still inactive before the user’s filesystem gets mounted and “processed” by system/applications, which might theoretically allow for some scanning programs (or a skilled user) to reliably scan for signs of infections of the app qube. But, of course, the problem of finding malware hooks in general is hard, so this would work likely only for some special cases (e.g. an app qube which doesn’t use Firefox, as otherwise it would be hard to scan the Firefox profile directory reliably to find malware hooks there). Also note that the user filesystem’s metadata might got maliciously modified by malware in order to exploit a hypothetical bug in the app qube kernel whenever it mounts the malformed filesystem. However, these exploits will automatically stop working (and so the infection might be cleared automatically) after the hypothetical bug got patched and the update applied (via template update), which is an exceptional feature of Qubes OS.
|
||||
|
||||
Also note that disposable qubes do not have persistent user filesystem, and so they start up completely “clean” every time. Note the word “clean” means in this context: the same as their template filesystem, of course.
|
||||
|
||||
Important Notes
|
||||
^^^^^^^^^^^^^^^
|
||||
|
||||
|
||||
- ``qvm-trim-template`` is no longer necessary or available in Qubes 4.0 and higher. All qubes are created in a thin pool and trimming is handled automatically. No user action is required. See `Disk Trim <https://forum.qubes-os.org/t/19054>`__ for more information.
|
||||
|
||||
- RPM-installed templates are “system managed” and therefore cannot be backed up using Qubes’ built-in backup function. In order to ensure the preservation of your custom settings and the availability of a “known-good” backup template, you may wish to clone the default system template and use your clone as the default template for your app qubes.
|
||||
|
||||
- Some templates are available in ready-to-use binary form, but some of them are available only as source code, which can be built using the `Qubes Builder <https://github.com/QubesOS/qubes-builderv2/>`__. In particular, some template “flavors” are available in source code form only. For the technical details of the template system, please see :doc:`Template Implementation </developer/system/template-implementation>`. Take a look at the :doc:`Qubes Builder </developer/building/qubes-builder-v2>` documentation for instructions on how to compile them.
|
||||
|
||||
|
||||
|
|
@ -1,58 +0,0 @@
|
|||
---
|
||||
lang: en
|
||||
layout: doc
|
||||
permalink: /doc/templates/windows/migrate-to-4-1/
|
||||
redirect_from:
|
||||
- /doc/templates/windows/windows-migrate41/
|
||||
- /user/templates/windows/windows-migrate41/
|
||||
- /doc/windows-migrate41/
|
||||
title: Migrating Windows qubes to Qubes OS 4.1
|
||||
---
|
||||
|
||||
For Windows 7, 10 and 11, there is a way to migrate backups created under Qubes R4.0 to R4.1. For this, the version of Qubes Windows Tools (QWT) 4.1-68, available from [tabit-pro/qubes-windows-tools-cross](https://github.com/tabit-pro/qubes-windows-tools-cross/releases), has to be installed under Qubes R4.0, selecting the option to install the Xen PV disk driver, which emulates SCSI disks. For template VMs, the option to move user profiles may be selected, too. Then, the backup may be created, and this backup can be restored under Qubes R4.1, resulting in a VM well integrated into Qubes R4.1. If `qvm-features <VMname> audio-model ich6` is set, Windows even will have audio, although for Windows 10 and 11 somewhat scratchy.
|
||||
|
||||
While this is somewhat straightforward, things get difficult if QWT 4.0.1.3 was installed in the VM. Prior to installing version 4.1-68, the old version has to be removed, which can be quite tricky for Windows 10 and 11.
|
||||
|
||||
## Preparation for Windows 7
|
||||
|
||||
- Uninstall QWT 4.0.1.3, using the standard procedure from the system control panel of Windows. This will most likely result in a crash.
|
||||
- Restart Windows again, hitting the F8 key, select the restart menu, and there select a start in safe mode.
|
||||
- The system will start gain, but in a rather useless way. Just shut it down, and reboot again.
|
||||
- Now Windows will start normally. Check in the control panel, if there are any Xen drivers left. If so, uninstall them.
|
||||
- In the Windows device manager, check if there is still a (probably non working) Xen PV disk device. If so, uninstall it. Otherwise, QWT 4.1-68 will not install.
|
||||
- In the control panel, check again, if the Xen drivers are removed. A Xen Bus Package (version 8.2.1.8) may remain and cannot be removed, but does no harm. Any other Xen drivers should have disappeared.
|
||||
- There probably will be a drive `D:` containing the private user data. For Qubes, R4.1, QWT will expect this drive to be called `Q:`, so it has to be renamed:
|
||||
- Start the command prompt as administrator, i.e. right click on the Command Prompt icon (All Programs -> Accessories) and choose "Run as administrator"
|
||||
- In the command prompt type `diskmgmt.msc`
|
||||
- In the disk manager, select the volume `Private (D:)`
|
||||
- Select the option `Change Drive Letter and Path`
|
||||
- Select option `Change...`
|
||||
- Select the letter `Q`
|
||||
- Click `OK` in all still open windows of the disk manager and terminate it.
|
||||
|
||||
## Preparation for Windows 10 and 11
|
||||
|
||||
If there is a drive `D:` from this earlier installation of Qubes Windows Tools, it will probably contain incomplete private data; especially the folder `AppData` containing program configuration data will be missing. In this situation, it may be better to perform a new Windows installation, because repair may be difficult and trouble-prone.
|
||||
|
||||
- First, be sure that the automatic repair function is disabled. In a command window, execute `bcdedit /set recoveryenabled NO`, and check that this worked by issuing the command `bcdedit`, without parameters, again.
|
||||
- Now, uninstall QWT 4.0.1.3, using the Apps and Features function of Windows. This will most likely result in a crash.
|
||||
- Restart Windows again, possibly two or three times, until repair options are offered. By hitting the F8 key, select the restart menu, and there select a start in safe mode (in German, it's option number 4).
|
||||
- The system will start gain, but in a rather useless way. Just shut it down, and reboot again.
|
||||
- Now Windows will start normally. Check in the Apps and Features display, if there are any Xen drivers left. If so, uninstall them.
|
||||
- In the Windows device manager, check if there is still a (probably non working) Xen PV disk device. If so, uninstall it. Otherwise, QWT 4.1-68 will not install.
|
||||
- In the Apps and Features display, check again, if the Xen drivers are removed. A Xen Bus Package (version 8.2.1.8) may remain and cannot be removed, but does no harm. Any other Xen drivers should have disappeared.
|
||||
|
||||
## Transferring the Windows Qube
|
||||
|
||||
- Now, finally, after one additional reboot, Qubes Windows Tools 4.1-68 can be installed. The option `Move user profiles` should be used **if and only if** there was **no** separate drive `D:` in the earlier Windows installation.
|
||||
- After one more reboot, the backup for R4.1 may be created.
|
||||
- This backup can be installed in Qubes R4.1 and will (probably) work.
|
||||
|
||||
The PV disk drivers used for migration can be removed after successful installation of the VM under Qubes R4.1. For this, the QWT installation has to be started, the option Change has to be selected, and the PV disk driver must be unselected. After completion, the VM has to be rebooted. For Windows 10 and 11, the VM will crash with the error INACCESSIBLE BOOT DEVICE, which can be repaired as described above.
|
||||
|
||||
After successful uninstallation of the PV disk drivers, the disks will appear as QEMU ATA disks.
|
||||
|
||||
<div class="alert alert-warning" role="alert">
|
||||
<i class="fa fa-exclamation-circle"></i>
|
||||
<b>Caution:</b> This change may lead Windows to declare that the hardware has changed and that in consequence, the activation is no longer valid, possibly complaining that the use of the software is no longer lawful. It should be possible to reactivate the software if a valid product key is provided.
|
||||
</div>
|
||||
87
user/templates/windows/migrate-to-4-1.rst
Normal file
87
user/templates/windows/migrate-to-4-1.rst
Normal file
|
|
@ -0,0 +1,87 @@
|
|||
=======================================
|
||||
Migrating Windows qubes to Qubes OS 4.1
|
||||
=======================================
|
||||
|
||||
|
||||
For Windows 7, 10 and 11, there is a way to migrate backups created under Qubes R4.0 to R4.1. For this, the version of Qubes Windows Tools (QWT) 4.1-68, available from `tabit-pro/qubes-windows-tools-cross <https://github.com/tabit-pro/qubes-windows-tools-cross/releases>`__, has to be installed under Qubes R4.0, selecting the option to install the Xen PV disk driver, which emulates SCSI disks. For template VMs, the option to move user profiles may be selected, too. Then, the backup may be created, and this backup can be restored under Qubes R4.1, resulting in a VM well integrated into Qubes R4.1. If ``qvm-features <VMname> audio-model ich6`` is set, Windows even will have audio, although for Windows 10 and 11 somewhat scratchy.
|
||||
|
||||
While this is somewhat straightforward, things get difficult if QWT 4.0.1.3 was installed in the VM. Prior to installing version 4.1-68, the old version has to be removed, which can be quite tricky for Windows 10 and 11.
|
||||
|
||||
Preparation for Windows 7
|
||||
-------------------------
|
||||
|
||||
|
||||
- Uninstall QWT 4.0.1.3, using the standard procedure from the system control panel of Windows. This will most likely result in a crash.
|
||||
|
||||
- Restart Windows again, hitting the F8 key, select the restart menu, and there select a start in safe mode.
|
||||
|
||||
- The system will start gain, but in a rather useless way. Just shut it down, and reboot again.
|
||||
|
||||
- Now Windows will start normally. Check in the control panel, if there are any Xen drivers left. If so, uninstall them.
|
||||
|
||||
- In the Windows device manager, check if there is still a (probably non working) Xen PV disk device. If so, uninstall it. Otherwise, QWT 4.1-68 will not install.
|
||||
|
||||
- In the control panel, check again, if the Xen drivers are removed. A Xen Bus Package (version 8.2.1.8) may remain and cannot be removed, but does no harm. Any other Xen drivers should have disappeared.
|
||||
|
||||
- There probably will be a drive ``D:`` containing the private user data. For Qubes, R4.1, QWT will expect this drive to be called ``Q:``, so it has to be renamed:
|
||||
|
||||
- Start the command prompt as administrator, i.e. right click on the Command Prompt icon (All Programs -> Accessories) and choose “Run as administrator”
|
||||
|
||||
- In the command prompt type ``diskmgmt.msc``
|
||||
|
||||
- In the disk manager, select the volume ``Private (D:)``
|
||||
|
||||
- Select the option ``Change Drive Letter and Path``
|
||||
|
||||
- Select option ``Change...``
|
||||
|
||||
- Select the letter ``Q``
|
||||
|
||||
- Click ``OK`` in all still open windows of the disk manager and terminate it.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Preparation for Windows 10 and 11
|
||||
---------------------------------
|
||||
|
||||
|
||||
If there is a drive ``D:`` from this earlier installation of Qubes Windows Tools, it will probably contain incomplete private data; especially the folder ``AppData`` containing program configuration data will be missing. In this situation, it may be better to perform a new Windows installation, because repair may be difficult and trouble-prone.
|
||||
|
||||
- First, be sure that the automatic repair function is disabled. In a command window, execute ``bcdedit /set recoveryenabled NO``, and check that this worked by issuing the command ``bcdedit``, without parameters, again.
|
||||
|
||||
- Now, uninstall QWT 4.0.1.3, using the Apps and Features function of Windows. This will most likely result in a crash.
|
||||
|
||||
- Restart Windows again, possibly two or three times, until repair options are offered. By hitting the F8 key, select the restart menu, and there select a start in safe mode (in German, it’s option number 4).
|
||||
|
||||
- The system will start gain, but in a rather useless way. Just shut it down, and reboot again.
|
||||
|
||||
- Now Windows will start normally. Check in the Apps and Features display, if there are any Xen drivers left. If so, uninstall them.
|
||||
|
||||
- In the Windows device manager, check if there is still a (probably non working) Xen PV disk device. If so, uninstall it. Otherwise, QWT 4.1-68 will not install.
|
||||
|
||||
- In the Apps and Features display, check again, if the Xen drivers are removed. A Xen Bus Package (version 8.2.1.8) may remain and cannot be removed, but does no harm. Any other Xen drivers should have disappeared.
|
||||
|
||||
|
||||
|
||||
Transferring the Windows Qube
|
||||
-----------------------------
|
||||
|
||||
|
||||
- Now, finally, after one additional reboot, Qubes Windows Tools 4.1-68 can be installed. The option ``Move user profiles`` should be used **if and only if** there was **no** separate drive ``D:`` in the earlier Windows installation.
|
||||
|
||||
- After one more reboot, the backup for R4.1 may be created.
|
||||
|
||||
- This backup can be installed in Qubes R4.1 and will (probably) work.
|
||||
|
||||
|
||||
|
||||
The PV disk drivers used for migration can be removed after successful installation of the VM under Qubes R4.1. For this, the QWT installation has to be started, the option Change has to be selected, and the PV disk driver must be unselected. After completion, the VM has to be rebooted. For Windows 10 and 11, the VM will crash with the error INACCESSIBLE BOOT DEVICE, which can be repaired as described above.
|
||||
|
||||
After successful uninstallation of the PV disk drivers, the disks will appear as QEMU ATA disks.
|
||||
|
||||
.. warning::
|
||||
This change may lead Windows to declare that the hardware has changed and that in consequence, the activation is no longer valid, possibly complaining that the use of the software is no longer lawful. It should be possible to reactivate the software if a valid product key is provided.
|
||||
|
||||
|
||||
|
|
@ -1,362 +0,0 @@
|
|||
---
|
||||
lang: en
|
||||
layout: doc
|
||||
permalink: /doc/templates/windows/qubes-windows-tools-4-0/
|
||||
redirect_from:
|
||||
- /doc/templates/windows/windows-tools/
|
||||
- /user/templates/windows/windows-tools/
|
||||
- /doc/windows-tools/
|
||||
- /doc/windows-appvms/
|
||||
- /en/doc/windows-appvms/
|
||||
- /doc/WindowsAppVms/
|
||||
- /wiki/WindowsAppVms/
|
||||
- /doc/windows-tools-3/
|
||||
- /en/doc/windows-tools-3/
|
||||
- /doc/WindowsTools3/
|
||||
- /doc/WindowsTools/
|
||||
- /wiki/WindowsTools/
|
||||
title: Qubes Windows Tools (QWT) in Qubes OS 4.0
|
||||
---
|
||||
|
||||
**Warning:** *The content below describes Qubes Windows Tools installation in Qubes R4.0. The text has been updated to reflect the newer R4.1 release and QWT recent development. Please see [this updated document](/doc/templates/windows/qubes-windows-tools-4-1) for instructions for Qubes R4.1 and the updated version of Qubes Windows Tools.*
|
||||
|
||||
Qubes Windows Tools are a set of programs and drivers that provide integration of Windows AppVMs with the rest of the Qubes system. Currently the following features are available for Windows VMs after installation of those tools:
|
||||
|
||||
- **Qubes Video Driver** - provides for the Seamless GUI mode that integrates apps windows onto the common Qubes trusted desktop
|
||||
- **File sender/receiver** - Support for [secure clipboard copy/paste](/doc/copy-paste/) between the Windows VM and other AppVMs
|
||||
- **File sender/receiver** - Support for [secure file exchange](/doc/copying-files/) between the Windows VM and other AppVMs
|
||||
- **Copy/Edit in Disposable VM** - Support for editing files in DisposableVMs as well as for qvm-run and generic qrexec for the Windows VM (e.g. ability to run custom service within/from the Windows VM)
|
||||
- **Xen PV drivers** for Windows that increase performance compared to qemu emulated devices
|
||||
|
||||
Below is a breakdown of the feature availability depending on the windows version:
|
||||
|
||||
| Feature | Windows 7 x64 | Windows 10 x64 |
|
||||
| ------------------------------------ | :------------: | :------------: |
|
||||
| Qubes Video Driver | y | n |
|
||||
| Qubes Network Setup | y | y |
|
||||
| Private Volume Setup (move profiles) | y | y |
|
||||
| File sender/receiver | y | y |
|
||||
| Clipboard Copy/Paste | y | y |
|
||||
| Application shortcuts | y | y |
|
||||
| Copy/Edit in Disposable VM | y | y |
|
||||
| Block device | y | y |
|
||||
| USB device | y | y |
|
||||
| Audio | n | n |
|
||||
|
||||
Qubes Windows Tools are open source and are distributed under a GPL license.
|
||||
|
||||
**Notes:**
|
||||
|
||||
- Qubes Windows Tools are currently unmaintained
|
||||
- Currently only 64-bit versions of Windows 7 and Windows 10 are supported by Qubes Windows Tools. Only emulated SVGA GPU is supported (although [there has been reports](https://groups.google.com/forum/#!topic/qubes-users/cmPRMOkxkdA) on working GPU passthrough).
|
||||
- __This page documents the process of installing Qubes Windows Tools on versions up to R3.2.__. Installation on Qubes R4.0 is possible but is a work in progress and there are limitations/bugs (see [issue #3585](https://github.com/QubesOS/qubes-issues/issues/3585)).
|
||||
|
||||
Installing Windows OS in a Qubes VM
|
||||
-----------------------------------
|
||||
|
||||
Please refer to [this page](/doc/templates/windows/windows-vm) for instructions on how to install Windows in a Qubes VM.
|
||||
|
||||
**Note:** It is strongly suggested to enable autologon for any Windows HVMs that will have Qubes Tools installed. To do so, run `netplwiz` command from the `Win+R`/Start menu and uncheck the *Users must enter a user name and password to use this computer* option.
|
||||
|
||||
Installing Qubes guest tools in Windows 10 VMs
|
||||
----------------------------------------------
|
||||
|
||||
This will allow you to install the Qubes Windows Tools on Windows 10 both as a StandaloneVM as well as a Template VM and a corresponding AppVM. But some features are not available:
|
||||
|
||||
**Note:** seamless mode is currently not available for windows. Please check the top of this document for the full feature availability breakdown.
|
||||
|
||||
1. In the Windows 10 VM, download from the [XEN website](https://xenproject.org/downloads/windows-pv-drivers/windows-pv-drivers-9-series/windows-pv-drivers-9-0-0/) the installation kits for Xen bus (`xenbus`) and storage drivers (`xenvbd`) Version 9.0.0 (two files`xenvbd.tar`and `xenbus.tar`).
|
||||
|
||||
2. Use an archive extractor like [7-zip](https://www.7-zip.org/) to extract the contents of the `.tar` files.
|
||||
|
||||
3. Install `xenvbd` and `xenbus` by starting the file `dpinst.exe` from the `x64` directories of the extracted tar-files. If during installation, the Xen driver requests a reboot, select "No" and let the installation continue.
|
||||
|
||||
4. After installation, reboot.
|
||||
|
||||
5. Download the Qubes Windows Tools (`qubes-tools-4.0.1.3.exe`) from [the qubes FTP server](https://ftp.qubes-os.org/qubes-windows-tools/) and move it to `C:\`.
|
||||
|
||||
6. Check the integrity of the file `qubes-tools-4.0.1.3.exe`by comparing its hash checksum. This can be done using the Windows command `certutil` on the windows command prompt (`cmd.exe`) and specifying an appropriate hash algorithm like:
|
||||
|
||||
certutil -hashfile C:\qubes-tools-4.0.1.3.exe SHA256
|
||||
|
||||
- And compare it the value to `148A2A993F0C746B48FA6C5C9A5D1B504E09A7CFBA3FB931A4DCF86FDA4EC9B1` (**it has to exactly match for security reasons**). If it matches, feel free to continue the installation. If not, repeat the download to make sure it was not corrupted due to a network problem. If keeps on not matching it might be an attacker attempting to do something nasty to your system -- Ask for support.
|
||||
|
||||
- **Note**: This is a workaround for installing the qubes windows tools on windows 10 since the standard way is broken.
|
||||
|
||||
7. Install Qubes Windows Tools 4.0.1.3 by starting `qubes-tools-4.0.1.3.exe`, not selecting the `Xen PV disk drivers` and the `Move user profiles` (which would probably lead to problems in Windows, anyhow). If during installation, the Xen driver requests a reboot, select "No" and let the installation continue - the system will be rebooted later.
|
||||
|
||||
8. Shut down Windows and wait until the VM is really stopped, i.e. Qubes shows no more activity.
|
||||
|
||||
9. On a `dom0` terminal write: *(where `<VMname>` is the name of your Windows 10 VM)*
|
||||
|
||||
qvm-features <VMname> gui 1
|
||||
qvm-prefs <VMname> qrexec_timeout 300
|
||||
|
||||
10. Reboot Windows. If the VM starts, but does not show any window then shutdown Windows from the Qube manager, wait until it has really stopped, and reboot Windows once more.
|
||||
|
||||
11. Now the system should be up, with QWT running correctly.
|
||||
|
||||
12. Lastly to enable file copy operations to a Windows 10 VM the `default_user` property should be set the `<username>` that you use to login to the Windows VM. This can be done via the following command on a `dom0` terminal: *(where `<VMname>` is the name of your Windows 10 VM)*
|
||||
|
||||
```
|
||||
qvm-prefs <VMname> default_user <username>
|
||||
```
|
||||
|
||||
**Note:** If this property is not set or set to a wrong value, files copied to this VM are stored in the folder
|
||||
|
||||
C:\Windows\System32\config\systemprofile\Documents\QubesIncoming\<source_VM>
|
||||
|
||||
If the target VM is an AppVM, this has the consequence that the files are stored in the corresponding TemplateVM and so are lost on AppVM shutdown.
|
||||
|
||||
|
||||
Installing Qubes guest tools in Windows 7 VMs
|
||||
---------------------------------------------
|
||||
|
||||
First, make sure that `qubes-windows-tools` is installed in your system:
|
||||
|
||||
~~~
|
||||
sudo qubes-dom0-update qubes-windows-tools
|
||||
~~~
|
||||
|
||||
(If the above command does not work, it could be that the Qubes Tools are not in the stable repo yet. Try installing from the testing repo instead.)
|
||||
|
||||
You can also install the package from testing repositories, where we usually publish new versions first:
|
||||
|
||||
~~~
|
||||
sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing qubes-windows-tools
|
||||
~~~
|
||||
|
||||
This package brings the ISO with Qubes Windows Tools that is passed to the VM when `--install-windows-tools` is specified for the `qvm-start` command. Please note that none of this software ever runs in Dom0 or any other part of the system except for the Windows AppVM in which it is to be installed.
|
||||
|
||||
Before proceeding with the installation we need to disable Windows mechanism that allows only signed drivers to be installed, because currently (beta releases) the drivers we provide as part of the Windows Tools are not digitally signed with a publicly recognizable certificate. To do that:
|
||||
|
||||
- Start command prompt as Administrator, i.e. right click on the Command Prompt icon (All Programs -> Accessories) and choose "Run as administrator"
|
||||
- In the command prompt type `bcdedit /set testsigning on`
|
||||
- Reboot your Windows VM
|
||||
|
||||
In the future this step will not be necessary anymore, because we will sign our drivers with a publicly verifiable certificate. However, it should be noted that even now, the fact that those drivers are not digitally signed, this doesn't affect security of the Windows VM in 'any' way. This is because the actual installation ISO (the `qubes-windows-tools-*.iso` file) is distributed as a signed RPM package and its signature is verified by the `qubes-dom0-update` utility once it's being installed in Dom0. The only downside of those drivers not being signed is the inconvenience to the user that he or she must disable the signature enforcement policy before installing the tools.
|
||||
|
||||
To install the Qubes Windows Tools in a Windows VM one should start the VM passing the additional option `--install-windows-tools`:
|
||||
|
||||
~~~
|
||||
qvm-start lab-win7 --install-windows-tools
|
||||
~~~
|
||||
|
||||
Once the Windows VM boots, a CDROM should appear in the 'My Computer' menu (typically as `D:`) with a setup program in its main directory.
|
||||
|
||||
After successful installation, the Windows VM must be shut down and started again, possibly a couple of times.
|
||||
|
||||
Qubes will automatically detect the tools has been installed in the VM and will set appropriate properties for the VM, such as `qrexec_installed`, `guiagent_installed`, and `default_user`. This can be verified (but is not required) using qvm-prefs command:
|
||||
|
||||
~~~
|
||||
qvm-prefs <your-appvm-name>
|
||||
~~~
|
||||
|
||||
**Note:** it is recommended to increase the default value of Windows VM's `qrexec_timeout` property from 60 (seconds) to, for example, 300. During one of the first reboots after Windows Tools installation Windows user profiles are moved onto the private VM's virtual disk (private.img) and this operation can take some time. Moving profiles is performed in an early boot phase when qrexec is not yet running, so timeout may occur with the default value. To change the property use this command in dom0:
|
||||
|
||||
~~~
|
||||
qvm-prefs <vm-name> qrexec_timeout 300
|
||||
~~~
|
||||
|
||||
Xen PV drivers and Qubes Windows Tools
|
||||
--------------------------------------
|
||||
|
||||
Installing Xen's PV drivers in the VM will lower its resources usage when using network and/or I/O intensive applications, but *may* come at the price of system stability (although Xen's PV drivers on a Win7 VM are usually very stable). There are two ways of installing the drivers:
|
||||
|
||||
1. installing the drivers independently, from Xen's [official site](https://www.xenproject.org/developers/teams/windows-pv-drivers.html)
|
||||
2. installing Qubes Windows Tools (QWT), which bundles Xen's PV drivers.
|
||||
|
||||
Notes about using Xen's VBD (storage) PV driver:
|
||||
|
||||
- **Windows 7:** installing the driver requires a fully updated VM or else you'll likely get a BSOD and a VM in a difficult to fix state. Updating Windows takes *hours* and for casual usage there isn't much of a performance between the disk PV driver and the default one; so there is likely no need to go through the lengthy Windows Update process if your VM doesn't have access to untrusted networks and if you don't use I/O intensive apps. If you plan to update your newly installed Windows VM it is recommended that you do so *before* installing Qubes Windows Tools (QWT). If QWT are installed, you should temporarily re-enable the standard VGA adapter in Windows and disable Qubes' (see the section above).
|
||||
- the option to install the storage PV driver is disabled by default in Qubes Windows Tools
|
||||
- in case you already had QWT installed without the storage PV driver and you then updated the VM, you may then install the driver from Xen's site (xenvbd.tar).
|
||||
|
||||
**Caution:** Installing the version 9.0.0 Xen drivers on Windows 7 (a system without QWT - QWT uninstalled) leads to an unbootable system. The drivers install without error, but after reboot, the system aborts the reboot saying `Missing driver xenbus.sys`.
|
||||
|
||||
- **Windows 10:** The version 9.0.0 Xen drivers have to be installed before installing Qubes Windows Tools. Installing them on a system with QWT installed is likely to produce a system which crashes or has the tools in a non-functional state. Even if the tools were installed and then removed before installing the Xen drivers, they probably will not work as expected.
|
||||
|
||||
|
||||
With Qubes Windows Tools installed the early graphical console provided in debugging mode isn't needed anymore since Qubes' display driver will be used instead of the default VGA driver:
|
||||
|
||||
~~~
|
||||
qvm-prefs -s win7new debug false
|
||||
~~~
|
||||
|
||||
|
||||
Using Windows AppVMs in seamless mode
|
||||
-------------------------------------
|
||||
|
||||
**Note:** This feature is only available for Windows 7
|
||||
|
||||
Once you start a Windows-based AppVM with Qubes Tools installed, you can easily start individual applications from the VM (note the `-a` switch used here, which will auto-start the VM if it is not running):
|
||||
|
||||
~~~
|
||||
qvm-run -a my-win7-appvm explorer.exe
|
||||
~~~
|
||||
|
||||
[](/attachment/doc/windows-seamless-4.png)
|
||||
[](/attachment/doc/windows-seamless-1.png)
|
||||
|
||||
Also, the inter-VM services work as usual -- e.g. to request opening a document or URL in the Windows AppVM from another VM:
|
||||
|
||||
~~~
|
||||
[user@work ~]$ qvm-open-in-vm work-win7 roadmap.pptx
|
||||
~~~
|
||||
|
||||
~~~
|
||||
[user@work ~]$ qvm-open-in-vm work-win7 https://invisiblethingslab.com
|
||||
~~~
|
||||
|
||||
... just like in the case of Linux AppVMs. Of course all those operations are governed by central policy engine running in Dom0 -- if the policy doesn't contain explicit rules for the source and/or target AppVM, the user will be asked whether to allow or deny the operation.
|
||||
|
||||
Inter-VM file copy and clipboard works for Windows AppVMs the same way as for Linux AppVM (except that we don't provide a command line wrapper, `qvm-copy-to-vm` in Windows VMs) -- to copy files from Windows AppVMs just right-click on the file in Explorer, and choose: Send To-\> Other AppVM.
|
||||
|
||||
To simulate CTRL-ALT-DELETE in the HVM (SAS, Secure Attention Sequence), press Ctrl-Alt-Home while having any window of this VM in the foreground.
|
||||
|
||||
[](/attachment/doc/windows-seamless-7.png)
|
||||
|
||||
Changing between seamless and full desktop mode
|
||||
-----------------------------------------------
|
||||
|
||||
You can switch between seamless and "full desktop" mode for Windows HVMs in their settings in Qubes Manager. The latter is the default.
|
||||
|
||||
Using template-based Windows AppVMs
|
||||
-----------------------------------
|
||||
|
||||
Qubes allows HVM VMs to share a common root filesystem from a select Template VM, just as for Linux AppVMs. This mode is not limited to Windows AppVMs, and can be used for any HVM (e.g. FreeBSD running in a HVM).
|
||||
|
||||
In order to create a HVM TemplateVM one can use the following command, suitably adapted:
|
||||
|
||||
~~~
|
||||
qvm-create --class TemplateVM win-template --property virt_mode=HVM --property kernel='' -l green
|
||||
~~~
|
||||
|
||||
... , set memory as appropriate, and install Windows OS (or other OS) into this template the same way as you would install it into a normal HVM -- please see instructions on [this page](/doc/hvm-create/).
|
||||
|
||||
If you use this Template as it is, then any HVMs that use it will effectively be DisposableVMs - the User directory will be wiped when the HVN is closed down.
|
||||
|
||||
If you want to retain the User directory between reboots, then it would make sense to store the `C:\Users` directory on the 2nd disk which is automatically exposed by Qubes to all HVMs.
|
||||
This 2nd disk is backed by the `private.img` file in the AppVMs' and is not reset upon AppVMs reboot, so the user's directories and profiles would survive the AppVMs reboot, unlike the "root" filesystem which will be reverted to the "golden image" from the Template VM automatically.
|
||||
To facilitate such separation of user profiles, Qubes Windows Tools provide an option to automatically move `C:\Users` directory to the 2nd disk backed by `private.img`.
|
||||
It's a selectable feature of the installer, enabled by default, but working only for Windows 7.
|
||||
If that feature is selected during installation, completion of the process requires two reboots:
|
||||
|
||||
- The private disk is initialized and formatted on the first reboot after tools installation. It can't be done **during** the installation because Xen mass storage drivers are not yet active.
|
||||
- User profiles are moved to the private disk on the next reboot after the private disk is initialized.
|
||||
Reboot is required because the "mover utility" runs very early in the boot process so OS can't yet lock any files in there.
|
||||
This can take some time depending on the profiles' size and because the GUI agent is not yet active dom0/Qubes Manager may complain that the AppVM failed to boot.
|
||||
That's a false alarm (you can increase AppVM's default boot timeout using `qvm-prefs`), the VM should appear "green" in Qubes Manager shortly after.
|
||||
|
||||
For Windows 10, the user directories have to be moved manually, because the automatic transfer during QWT installation is bound to crash due to undocumented new features of NTFS, and a system having the directory `users`on another disk than `C:` will break on Windows update. So the following steps should be taken:
|
||||
|
||||
- The Windows disk manager may be used to add the private volume as disk `D:`, and you may, using the documented Windows operations, move the user directories `C:\users\<username>\Documents` to this new disk, allowing depending AppVMs to have their own private volumes. Moving the hidden application directories `AppData`, however, is likely to invite trouble - the same trouble that occurs if, during QWT installation, the option `Move user profiles` is selected.
|
||||
|
||||
- Configuration data like those stored in directories like `AppData` still remain in the TemplateVM, such that their changes are lost each time the AppVM shuts down. In order to make permanent changes to these configuration data, they have to be changed in the TemplateVM, meaning that applications have to be started there, which violates and perhaps even endangers the security of the TemplateVM. Such changes should be done only if absolutely necessary and with great care. It is a good idea to test them first in a cloned TemplateVM before applying them in the production VM.
|
||||
|
||||
It also makes sense to disable Automatic Updates for all the template-based AppVMs -- of course this should be done in the Template VM, not in individual AppVMs, because the system-wide settings are stored in the root filesystem (which holds the system-wide registry hives). Then, periodically check for updates in the Template VM and the changes will be carried over to any child AppVMs.
|
||||
|
||||
Once the template has been created and installed it is easy to create AppVMs based on it:
|
||||
|
||||
~~~
|
||||
qvm-create --property virt_mode=hvm <new windows appvm name> --template <name of template vm> --label <label color>
|
||||
~~~
|
||||
|
||||
Components
|
||||
----------
|
||||
|
||||
Qubes Windows Tools (QWT for short) contain several components than can be enabled or disabled during installation:
|
||||
|
||||
- Shared components (required): common libraries used by QWT components.
|
||||
- Xen PV drivers: drivers for the virtual hardware exposed by Xen.
|
||||
- Base Xen PV Drivers (required): paravirtual bus and interface drivers.
|
||||
- Xen PV Disk Drivers: paravirtual storage drivers.
|
||||
- Xen PV Network Drivers: paravirtual network drivers.
|
||||
- Qubes Core Agent: qrexec agent and services. Needed for proper integration with Qubes.
|
||||
- Move user profiles: user profile directory (`c:\users`) is moved to VM's private disk backed by private.img file in dom0 (useful mainly for HVM templates).
|
||||
- Qubes GUI Agent: video driver and gui agent that enable seamless showing of Windows applications on the secure Qubes desktop.
|
||||
- Disable UAC: User Account Control may interfere with QWT and doesn't really provide any additional benefits in Qubes environment.
|
||||
|
||||
**In testing VMs only** it's probably a good idea to install a VNC server before installing QWT. If something goes very wrong with the Qubes gui agent, a VNC server should still allow access to the OS.
|
||||
|
||||
**NOTE**: Xen PV disk drivers are not installed by default. This is because they seem to cause problems (BSOD = Blue Screen Of Death). We're working with upstream devs to fix this. *However*, the BSOD seems to only occur after the first boot and everything works fine after that. **Enable the drivers at your own risk** of course, but we welcome reports of success/failure in any case (backup your VM first!). With disk PV drivers absent `qvm-block` will not work for the VM, but you can still use standard Qubes inter-VM file copying mechanisms.
|
||||
|
||||
Xen PV driver components may display a message box asking for reboot during installation -- it's safe to ignore them and defer the reboot.
|
||||
|
||||
Installation logs
|
||||
-----------------
|
||||
|
||||
If the install process fails or something goes wrong during it, include the installation logs in your bug report. They are created in the `%TEMP%` directory, by default `<user profile>\AppData\Local\Temp`. There are two text files, one small and one big, with names starting with `Qubes_Windows_Tools`.
|
||||
|
||||
Uninstalling QWT is supported from version 3.2.1. Uninstalling previous versions is **not recommended**.
|
||||
After uninstalling you need to manually enable the DHCP Client Windows service, or set IP settings yourself to restore network access.
|
||||
|
||||
Configuration
|
||||
-------------
|
||||
|
||||
Starting from version 2.2.\* various aspects of Qubes Windows Tools can be configured through registry. Main configuration key is located in `HKEY_LOCAL_MACHINE\SOFTWARE\Invisible Things Lab\Qubes Tools`. Configuration values set on this level are global to all QWT components. It's possible to override global values with component-specific keys, this is useful mainly for setting log verbosity for troubleshooting. Possible configuration values are:
|
||||
|
||||
|**Name**|**Type**|**Description**|**Default value**|
|
||||
|:-------|:-------|:--------------|:----------------|
|
||||
|LogDir|String|Directory where logs are created|c:\\Program Files\\Invisible Things Lab\\Qubes Tools\\log|
|
||||
|LogLevel|DWORD|Log verbosity (see below)|2 (INFO)|
|
||||
|LogRetention|DWORD|Maximum age of log files (in seconds), older logs are automatically deleted|604800 (7 days)|
|
||||
|
||||
Possible log levels:
|
||||
|
||||
|**Level**| **Type** |**Description** |
|
||||
|:--------|:-----------|:-----------------------------------------------------|
|
||||
| 1 |Error |Serious errors that most likely cause irrecoverable failures|
|
||||
| 2 |Warning |Unexpected but non-fatal events|
|
||||
| 3 |Info |Useful information (default)|
|
||||
| 4 |Debug |Internal state dumps for troubleshooting|
|
||||
| 5 |Verbose |Trace most function calls|
|
||||
|
||||
Debug and Verbose levels can generate large volume of logs and are intended for development/troubleshooting only.
|
||||
|
||||
To override global settings for a specific component, create a new key under the root key mentioned above and name it as the executable name, without `.exe` extension. For example, to change qrexec-agent's log level to Debug, set it like this:
|
||||
|
||||
[](/attachment/doc/qtw-log-level.png)
|
||||
|
||||
Component-specific settings currently available:
|
||||
|
||||
| Component | Setting | Type | Description | Default value |
|
||||
|:--------------|:------------|:-----------|:------------------------------------------------|:------------------|
|
||||
|qga|DisableCursor|DWORD|Disable cursor in the VM. Useful for integration with Qubes desktop so you don't see two cursors. Can be disabled if you plan to use the VM through a remote desktop connection of some sort. Needs gui agent restart to apply change (locking OS/logoff should be enough since qga is restarted on desktop change).|1|
|
||||
|
||||
Troubleshooting
|
||||
---------------
|
||||
|
||||
If the VM is inaccessible (doesn't respond to qrexec commands, gui is not functioning), try to boot it in safe mode:
|
||||
|
||||
- `qvm-start --debug vmname`
|
||||
- mash F8 on the boot screen to enable boot options and select Safe Mode (optionally with networking)
|
||||
|
||||
Safe Mode should at least give you access to logs (see above).
|
||||
|
||||
**Please include appropriate logs when reporting bugs/problems.** Starting from version 2.4.2 logs contain QWT version, but if you're using an earlier version be sure to mention which one. If the OS crashes (BSOD) please include the BSOD code and parameters in your bug report. The BSOD screen should be visible if you run the VM in debug mode (`qvm-start --debug vmname`). If it's not visible or the VM reboots automatically, try to start Windows in safe mode (see above) and 1) disable automatic restart on BSOD (Control Panel - System - Advanced system settings - Advanced - Startup and recovery), 2) check the system event log for BSOD events. If you can, send the `memory.dmp` dump file from `c:\Windows`.
|
||||
Xen logs (`/var/log/xen/console/guest-*`) are also useful as they contain pvdrivers diagnostic output.
|
||||
|
||||
If a specific component is malfunctioning, you can increase its log verbosity as explained above to get more troubleshooting information. Below is a list of components:
|
||||
|
||||
| Component | Description |
|
||||
|:-----------|:-----------------------------------------------------------------------------------------------------------------------|
|
||||
|qrexec-agent|Responsible for most communication with Qubes (dom0 and other domains), secure clipboard, file copying, qrexec services.|
|
||||
|qrexec-wrapper|Helper executable that's responsible for launching qrexec services, handling their I/O and vchan communication.|
|
||||
|qrexec-client-vm|Used for communications by the qrexec protocol.|
|
||||
|qga|Gui agent.|
|
||||
|QgaWatchdog|Service that monitors session/desktop changes (logon/logoff/locking/UAC...) and simulates SAS sequence (ctrl-alt-del).|
|
||||
|qubesdb-daemon|Service for accessing Qubes configuration database.|
|
||||
|network-setup|Service that sets up network parameters according to VM's configuration.|
|
||||
|prepare-volume|Utility that initializes and formats the disk backed by `private.img` file. It's registered to run on next system boot during QWT setup, if that feature is selected (it can't run *during* the setup because Xen block device drivers are not yet active). It in turn registers move-profiles (see below) to run at early boot.|
|
||||
|relocate-dir|Utility that moves user profiles directory to the private disk. It's registered as an early boot native executable (similar to chkdsk) so it can run before any profile files are opened by some other process. Its log is in a fixed location: `c:\move-profiles.log` (it can't use our common logger library so none of the log settings apply).|
|
||||
|
||||
Updates
|
||||
-------
|
||||
|
||||
When we publish new QWT version, it's usually pushed to the `current-testing` or `unstable` repository first. To use versions from current-testing, run this in dom0:
|
||||
|
||||
`qubes-dom0-update --enablerepo=qubes-dom0-current-testing qubes-windows-tools`
|
||||
|
||||
That command will download a new QWT .iso from the testing repository. It goes without saying that you should **backup your VMs** before installing anything from testing repos.
|
||||
|
||||
536
user/templates/windows/qubes-windows-tools-4-0.rst
Normal file
536
user/templates/windows/qubes-windows-tools-4-0.rst
Normal file
|
|
@ -0,0 +1,536 @@
|
|||
=========================================
|
||||
Qubes Windows Tools (QWT) in Qubes OS 4.0
|
||||
=========================================
|
||||
|
||||
|
||||
**Warning:** *The content below describes Qubes Windows Tools installation in Qubes R4.0. The text has been updated to reflect the newer R4.1 release and QWT recent development. Please see* :doc:`this updated document </user/templates/windows/qubes-windows-tools-4-1>` *for instructions for Qubes R4.1 and the updated version of Qubes Windows Tools.*
|
||||
|
||||
Qubes Windows Tools are a set of programs and drivers that provide integration of Windows AppVMs with the rest of the Qubes system. Currently the following features are available for Windows VMs after installation of those tools:
|
||||
|
||||
- **Qubes Video Driver** - provides for the Seamless GUI mode that integrates apps windows onto the common Qubes trusted desktop
|
||||
|
||||
- **File sender/receiver** - Support for :doc:`secure clipboard copy/paste </user/how-to-guides/how-to-copy-and-paste-text>` between the Windows VM and other AppVMs
|
||||
|
||||
- **File sender/receiver** - Support for :doc:`secure file exchange </user/how-to-guides/how-to-copy-and-move-files>` between the Windows VM and other AppVMs
|
||||
|
||||
- **Copy/Edit in Disposable VM** - Support for editing files in DisposableVMs as well as for qvm-run and generic qrexec for the Windows VM (e.g. ability to run custom service within/from the Windows VM)
|
||||
|
||||
- **Xen PV drivers** for Windows that increase performance compared to qemu emulated devices
|
||||
|
||||
|
||||
|
||||
Below is a breakdown of the feature availability depending on the windows version:
|
||||
|
||||
.. list-table::
|
||||
:widths: 39 39 39
|
||||
:align: center
|
||||
:header-rows: 1
|
||||
|
||||
* - Feature
|
||||
- Windows 7 x64
|
||||
- Windows 10 x64
|
||||
* - Qubes Video Driver
|
||||
- y
|
||||
- n
|
||||
* - Qubes Network Setup
|
||||
- y
|
||||
- y
|
||||
* - Private Volume Setup (move profiles)
|
||||
- y
|
||||
- y
|
||||
* - File sender/receiver
|
||||
- y
|
||||
- y
|
||||
* - Clipboard Copy/Paste
|
||||
- y
|
||||
- y
|
||||
* - Application shortcuts
|
||||
- y
|
||||
- y
|
||||
* - Copy/Edit in Disposable VM
|
||||
- y
|
||||
- y
|
||||
* - Block device
|
||||
- y
|
||||
- y
|
||||
* - USB device
|
||||
- y
|
||||
- y
|
||||
* - Audio
|
||||
- n
|
||||
- n
|
||||
|
||||
|
||||
|
||||
Qubes Windows Tools are open source and are distributed under a GPL license.
|
||||
|
||||
**Notes:**
|
||||
|
||||
- Qubes Windows Tools are currently unmaintained
|
||||
|
||||
- Currently only 64-bit versions of Windows 7 and Windows 10 are supported by Qubes Windows Tools. Only emulated SVGA GPU is supported (although `there has been reports <https://groups.google.com/forum/#!topic/qubes-users/cmPRMOkxkdA>`__ on working GPU passthrough).
|
||||
|
||||
- **This page documents the process of installing Qubes Windows Tools on versions up to R3.2.**. Installation on Qubes R4.0 is possible but is a work in progress and there are limitations/bugs (see `issue #3585 <https://github.com/QubesOS/qubes-issues/issues/3585>`__).
|
||||
|
||||
|
||||
|
||||
Installing Windows OS in a Qubes VM
|
||||
-----------------------------------
|
||||
|
||||
|
||||
Please refer to :doc:`this page </user/templates/windows/windows-qubes-4-0>` for instructions on how to install Windows in a Qubes VM.
|
||||
|
||||
**Note:** It is strongly suggested to enable autologon for any Windows HVMs that will have Qubes Tools installed. To do so, run ``netplwiz`` command from the ``Win+R``/Start menu and uncheck the *Users must enter a user name and password to use this computer* option.
|
||||
|
||||
Installing Qubes guest tools in Windows 10 VMs
|
||||
----------------------------------------------
|
||||
|
||||
|
||||
This will allow you to install the Qubes Windows Tools on Windows 10 both as a StandaloneVM as well as a Template VM and a corresponding AppVM. But some features are not available:
|
||||
|
||||
**Note:** seamless mode is currently not available for windows. Please check the top of this document for the full feature availability breakdown.
|
||||
|
||||
1. In the Windows 10 VM, download from the `XEN website <https://xenproject.org/downloads/windows-pv-drivers/windows-pv-drivers-9-series/windows-pv-drivers-9-0-0/>`__ the installation kits for Xen bus (``xenbus``) and storage drivers (``xenvbd``) Version 9.0.0 (two files ``xenvbd.tar`` and ``xenbus.tar``).
|
||||
|
||||
2. Use an archive extractor like `7-zip <https://www.7-zip.org/>`__ to extract the contents of the ``.tar`` files.
|
||||
|
||||
3. Install ``xenvbd`` and ``xenbus`` by starting the file ``dpinst.exe`` from the ``x64`` directories of the extracted tar-files. If during installation, the Xen driver requests a reboot, select “No” and let the installation continue.
|
||||
|
||||
4. After installation, reboot.
|
||||
|
||||
5. Download the Qubes Windows Tools (``qubes-tools-4.0.1.3.exe``) from `the qubes FTP server <https://ftp.qubes-os.org/qubes-windows-tools/>`__ and move it to ``C:\``.
|
||||
|
||||
6. Check the integrity of the file ``qubes-tools-4.0.1.3.exe``by comparing its hash checksum. This can be done using the Windows command ``certutil`` on the windows command prompt (``cmd.exe``) and specifying an appropriate hash algorithm like:
|
||||
|
||||
.. code:: bash
|
||||
|
||||
certutil -hashfile C:\qubes-tools-4.0.1.3.exe SHA256
|
||||
|
||||
|
||||
|
||||
- And compare it the value to ``148A2A993F0C746B48FA6C5C9A5D1B504E09A7CFBA3FB931A4DCF86FDA4EC9B1`` (**it has to exactly match for security reasons**). If it matches, feel free to continue the installation. If not, repeat the download to make sure it was not corrupted due to a network problem. If keeps on not matching it might be an attacker attempting to do something nasty to your system – Ask for support.
|
||||
|
||||
- **Note**: This is a workaround for installing the qubes windows tools on windows 10 since the standard way is broken.
|
||||
|
||||
|
||||
|
||||
7. Install Qubes Windows Tools 4.0.1.3 by starting ``qubes-tools-4.0.1.3.exe``, not selecting the ``Xen PV disk drivers`` and the ``Move user profiles`` (which would probably lead to problems in Windows, anyhow). If during installation, the Xen driver requests a reboot, select “No” and let the installation continue - the system will be rebooted later.
|
||||
|
||||
8. Shut down Windows and wait until the VM is really stopped, i.e. Qubes shows no more activity.
|
||||
|
||||
9. On a ``dom0`` terminal write: *(where* ``<VMname>`` *is the name of your Windows 10 VM)*
|
||||
|
||||
.. code:: bash
|
||||
|
||||
qvm-features <VMname> gui 1
|
||||
qvm-prefs <VMname> qrexec_timeout 300
|
||||
|
||||
|
||||
|
||||
10. Reboot Windows. If the VM starts, but does not show any window then shutdown Windows from the Qube manager, wait until it has really stopped, and reboot Windows once more.
|
||||
|
||||
11. Now the system should be up, with QWT running correctly.
|
||||
|
||||
12. Lastly to enable file copy operations to a Windows 10 VM the ``default_user`` property should be set the ``<username>`` that you use to login to the Windows VM. This can be done via the following command on a ``dom0`` terminal: *(where* ``<VMname>`` *is the name of your Windows 10 VM)*
|
||||
|
||||
.. code:: bash
|
||||
|
||||
qvm-prefs <VMname> default_user <username>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
**Note:** If this property is not set or set to a wrong value, files copied to this VM are stored in the folder
|
||||
|
||||
.. code:: bash
|
||||
|
||||
C:\Windows\System32\config\systemprofile\Documents\QubesIncoming\<source_VM>
|
||||
|
||||
|
||||
|
||||
If the target VM is an AppVM, this has the consequence that the files are stored in the corresponding TemplateVM and so are lost on AppVM shutdown.
|
||||
|
||||
Installing Qubes guest tools in Windows 7 VMs
|
||||
---------------------------------------------
|
||||
|
||||
|
||||
First, make sure that ``qubes-windows-tools`` is installed in your system:
|
||||
|
||||
.. code:: bash
|
||||
|
||||
sudo qubes-dom0-update qubes-windows-tools
|
||||
|
||||
|
||||
|
||||
(If the above command does not work, it could be that the Qubes Tools are not in the stable repo yet. Try installing from the testing repo instead.)
|
||||
|
||||
You can also install the package from testing repositories, where we usually publish new versions first:
|
||||
|
||||
.. code:: bash
|
||||
|
||||
sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing qubes-windows-tools
|
||||
|
||||
|
||||
|
||||
This package brings the ISO with Qubes Windows Tools that is passed to the VM when ``--install-windows-tools`` is specified for the ``qvm-start`` command. Please note that none of this software ever runs in Dom0 or any other part of the system except for the Windows AppVM in which it is to be installed.
|
||||
|
||||
Before proceeding with the installation we need to disable Windows mechanism that allows only signed drivers to be installed, because currently (beta releases) the drivers we provide as part of the Windows Tools are not digitally signed with a publicly recognizable certificate. To do that:
|
||||
|
||||
- Start command prompt as Administrator, i.e. right click on the Command Prompt icon (All Programs -> Accessories) and choose “Run as administrator”
|
||||
|
||||
- In the command prompt type ``bcdedit /set testsigning on``
|
||||
|
||||
- Reboot your Windows VM
|
||||
|
||||
|
||||
|
||||
In the future this step will not be necessary anymore, because we will sign our drivers with a publicly verifiable certificate. However, it should be noted that even now, the fact that those drivers are not digitally signed, this doesn’t affect security of the Windows VM in ‘any’ way. This is because the actual installation ISO (the ``qubes-windows-tools-*.iso`` file) is distributed as a signed RPM package and its signature is verified by the ``qubes-dom0-update`` utility once it’s being installed in Dom0. The only downside of those drivers not being signed is the inconvenience to the user that he or she must disable the signature enforcement policy before installing the tools.
|
||||
|
||||
To install the Qubes Windows Tools in a Windows VM one should start the VM passing the additional option ``--install-windows-tools``:
|
||||
|
||||
.. code:: bash
|
||||
|
||||
qvm-start lab-win7 --install-windows-tools
|
||||
|
||||
|
||||
|
||||
Once the Windows VM boots, a CDROM should appear in the ‘My Computer’ menu (typically as ``D:``) with a setup program in its main directory.
|
||||
|
||||
After successful installation, the Windows VM must be shut down and started again, possibly a couple of times.
|
||||
|
||||
Qubes will automatically detect the tools has been installed in the VM and will set appropriate properties for the VM, such as ``qrexec_installed``, ``guiagent_installed``, and ``default_user``. This can be verified (but is not required) using qvm-prefs command:
|
||||
|
||||
.. code:: bash
|
||||
|
||||
qvm-prefs <your-appvm-name>
|
||||
|
||||
|
||||
|
||||
**Note:** it is recommended to increase the default value of Windows VM’s ``qrexec_timeout`` property from 60 (seconds) to, for example, 300. During one of the first reboots after Windows Tools installation Windows user profiles are moved onto the private VM’s virtual disk (private.img) and this operation can take some time. Moving profiles is performed in an early boot phase when qrexec is not yet running, so timeout may occur with the default value. To change the property use this command in dom0:
|
||||
|
||||
.. code:: bash
|
||||
|
||||
qvm-prefs <vm-name> qrexec_timeout 300
|
||||
|
||||
|
||||
|
||||
Xen PV drivers and Qubes Windows Tools
|
||||
--------------------------------------
|
||||
|
||||
|
||||
Installing Xen’s PV drivers in the VM will lower its resources usage when using network and/or I/O intensive applications, but *may* come at the price of system stability (although Xen’s PV drivers on a Win7 VM are usually very stable). There are two ways of installing the drivers:
|
||||
|
||||
1. installing the drivers independently, from Xen’s `official site <https://www.xenproject.org/developers/teams/windows-pv-drivers.html>`__
|
||||
|
||||
2. installing Qubes Windows Tools (QWT), which bundles Xen’s PV drivers.
|
||||
|
||||
|
||||
|
||||
Notes about using Xen’s VBD (storage) PV driver:
|
||||
|
||||
- **Windows 7:** installing the driver requires a fully updated VM or else you’ll likely get a BSOD and a VM in a difficult to fix state. Updating Windows takes *hours* and for casual usage there isn’t much of a performance between the disk PV driver and the default one; so there is likely no need to go through the lengthy Windows Update process if your VM doesn’t have access to untrusted networks and if you don’t use I/O intensive apps. If you plan to update your newly installed Windows VM it is recommended that you do so *before* installing Qubes Windows Tools (QWT). If QWT are installed, you should temporarily re-enable the standard VGA adapter in Windows and disable Qubes’ (see the section above).
|
||||
|
||||
- the option to install the storage PV driver is disabled by default in Qubes Windows Tools
|
||||
|
||||
- in case you already had QWT installed without the storage PV driver and you then updated the VM, you may then install the driver from Xen’s site (xenvbd.tar).
|
||||
|
||||
|
||||
|
||||
**Caution:** Installing the version 9.0.0 Xen drivers on Windows 7 (a system without QWT - QWT uninstalled) leads to an unbootable system. The drivers install without error, but after reboot, the system aborts the reboot saying ``Missing driver xenbus.sys``.
|
||||
|
||||
- **Windows 10:** The version 9.0.0 Xen drivers have to be installed before installing Qubes Windows Tools. Installing them on a system with QWT installed is likely to produce a system which crashes or has the tools in a non-functional state. Even if the tools were installed and then removed before installing the Xen drivers, they probably will not work as expected.
|
||||
|
||||
|
||||
|
||||
With Qubes Windows Tools installed the early graphical console provided in debugging mode isn’t needed anymore since Qubes’ display driver will be used instead of the default VGA driver:
|
||||
|
||||
.. code:: bash
|
||||
|
||||
qvm-prefs -s win7new debug false
|
||||
|
||||
|
||||
|
||||
Using Windows AppVMs in seamless mode
|
||||
-------------------------------------
|
||||
|
||||
|
||||
**Note:** This feature is only available for Windows 7
|
||||
|
||||
Once you start a Windows-based AppVM with Qubes Tools installed, you can easily start individual applications from the VM (note the ``-a`` switch used here, which will auto-start the VM if it is not running):
|
||||
|
||||
.. code:: bash
|
||||
|
||||
qvm-run -a my-win7-appvm explorer.exe
|
||||
|
||||
|
||||
|
||||
|windows-seamless-4.png| |windows-seamless-1.png|
|
||||
|
||||
Also, the inter-VM services work as usual – e.g. to request opening a document or URL in the Windows AppVM from another VM:
|
||||
|
||||
.. code:: bash
|
||||
|
||||
[user@work ~]$ qvm-open-in-vm work-win7 roadmap.pptx
|
||||
|
||||
|
||||
|
||||
.. code:: bash
|
||||
|
||||
[user@work ~]$ qvm-open-in-vm work-win7 https://invisiblethingslab.com
|
||||
|
||||
|
||||
|
||||
… just like in the case of Linux AppVMs. Of course all those operations are governed by central policy engine running in Dom0 – if the policy doesn’t contain explicit rules for the source and/or target AppVM, the user will be asked whether to allow or deny the operation.
|
||||
|
||||
Inter-VM file copy and clipboard works for Windows AppVMs the same way as for Linux AppVM (except that we don’t provide a command line wrapper, ``qvm-copy-to-vm`` in Windows VMs) – to copy files from Windows AppVMs just right-click on the file in Explorer, and choose: Send To-> Other AppVM.
|
||||
|
||||
To simulate CTRL-ALT-DELETE in the HVM (SAS, Secure Attention Sequence), press Ctrl-Alt-Home while having any window of this VM in the foreground.
|
||||
|
||||
|windows-seamless-7.png|
|
||||
|
||||
Changing between seamless and full desktop mode
|
||||
-----------------------------------------------
|
||||
|
||||
|
||||
You can switch between seamless and “full desktop” mode for Windows HVMs in their settings in Qubes Manager. The latter is the default.
|
||||
|
||||
Using template-based Windows AppVMs
|
||||
-----------------------------------
|
||||
|
||||
|
||||
Qubes allows HVM VMs to share a common root filesystem from a select Template VM, just as for Linux AppVMs. This mode is not limited to Windows AppVMs, and can be used for any HVM (e.g. FreeBSD running in a HVM).
|
||||
|
||||
In order to create a HVM TemplateVM one can use the following command, suitably adapted:
|
||||
|
||||
.. code:: bash
|
||||
|
||||
qvm-create --class TemplateVM win-template --property virt_mode=HVM --property kernel='' -l green
|
||||
|
||||
|
||||
|
||||
… , set memory as appropriate, and install Windows OS (or other OS) into this template the same way as you would install it into a normal HVM – please see instructions on :doc:`this page </user/advanced-topics/standalones-and-hvms>`.
|
||||
|
||||
If you use this Template as it is, then any HVMs that use it will effectively be DisposableVMs - the User directory will be wiped when the HVN is closed down.
|
||||
|
||||
If you want to retain the User directory between reboots, then it would make sense to store the ``C:\Users`` directory on the 2nd disk which is automatically exposed by Qubes to all HVMs. This 2nd disk is backed by the ``private.img`` file in the AppVMs’ and is not reset upon AppVMs reboot, so the user’s directories and profiles would survive the AppVMs reboot, unlike the “root” filesystem which will be reverted to the “golden image” from the Template VM automatically. To facilitate such separation of user profiles, Qubes Windows Tools provide an option to automatically move ``C:\Users`` directory to the 2nd disk backed by ``private.img``. It’s a selectable feature of the installer, enabled by default, but working only for Windows 7. If that feature is selected during installation, completion of the process requires two reboots:
|
||||
|
||||
- The private disk is initialized and formatted on the first reboot after tools installation. It can’t be done **during** the installation because Xen mass storage drivers are not yet active.
|
||||
|
||||
- User profiles are moved to the private disk on the next reboot after the private disk is initialized. Reboot is required because the “mover utility” runs very early in the boot process so OS can’t yet lock any files in there. This can take some time depending on the profiles’ size and because the GUI agent is not yet active dom0/Qubes Manager may complain that the AppVM failed to boot. That’s a false alarm (you can increase AppVM’s default boot timeout using ``qvm-prefs``), the VM should appear “green” in Qubes Manager shortly after.
|
||||
|
||||
|
||||
|
||||
For Windows 10, the user directories have to be moved manually, because the automatic transfer during QWT installation is bound to crash due to undocumented new features of NTFS, and a system having the directory ``users`` on another disk than ``C:`` will break on Windows update. So the following steps should be taken:
|
||||
|
||||
- The Windows disk manager may be used to add the private volume as disk ``D:``, and you may, using the documented Windows operations, move the user directories ``C:\users\<username>\Documents`` to this new disk, allowing depending AppVMs to have their own private volumes. Moving the hidden application directories ``AppData``, however, is likely to invite trouble - the same trouble that occurs if, during QWT installation, the option ``Move user profiles`` is selected.
|
||||
|
||||
- Configuration data like those stored in directories like ``AppData`` still remain in the TemplateVM, such that their changes are lost each time the AppVM shuts down. In order to make permanent changes to these configuration data, they have to be changed in the TemplateVM, meaning that applications have to be started there, which violates and perhaps even endangers the security of the TemplateVM. Such changes should be done only if absolutely necessary and with great care. It is a good idea to test them first in a cloned TemplateVM before applying them in the production VM.
|
||||
|
||||
|
||||
|
||||
It also makes sense to disable Automatic Updates for all the template-based AppVMs – of course this should be done in the Template VM, not in individual AppVMs, because the system-wide settings are stored in the root filesystem (which holds the system-wide registry hives). Then, periodically check for updates in the Template VM and the changes will be carried over to any child AppVMs.
|
||||
|
||||
Once the template has been created and installed it is easy to create AppVMs based on it:
|
||||
|
||||
.. code:: bash
|
||||
|
||||
qvm-create --property virt_mode=hvm <new windows appvm name> --template <name of template vm> --label <label color>
|
||||
|
||||
|
||||
|
||||
Components
|
||||
----------
|
||||
|
||||
|
||||
Qubes Windows Tools (QWT for short) contain several components than can be enabled or disabled during installation:
|
||||
|
||||
- Shared components (required): common libraries used by QWT components.
|
||||
|
||||
- Xen PV drivers: drivers for the virtual hardware exposed by Xen.
|
||||
|
||||
- Base Xen PV Drivers (required): paravirtual bus and interface drivers.
|
||||
|
||||
- Xen PV Disk Drivers: paravirtual storage drivers.
|
||||
|
||||
- Xen PV Network Drivers: paravirtual network drivers.
|
||||
|
||||
|
||||
|
||||
- Qubes Core Agent: qrexec agent and services. Needed for proper integration with Qubes.
|
||||
|
||||
- Move user profiles: user profile directory (``c:\users``) is moved to VM’s private disk backed by private.img file in dom0 (useful mainly for HVM templates).
|
||||
|
||||
|
||||
|
||||
- Qubes GUI Agent: video driver and gui agent that enable seamless showing of Windows applications on the secure Qubes desktop.
|
||||
|
||||
- Disable UAC: User Account Control may interfere with QWT and doesn’t really provide any additional benefits in Qubes environment.
|
||||
|
||||
|
||||
|
||||
**In testing VMs only** it’s probably a good idea to install a VNC server before installing QWT. If something goes very wrong with the Qubes gui agent, a VNC server should still allow access to the OS.
|
||||
|
||||
**NOTE**: Xen PV disk drivers are not installed by default. This is because they seem to cause problems (BSOD = Blue Screen Of Death). We’re working with upstream devs to fix this. *However*, the BSOD seems to only occur after the first boot and everything works fine after that. **Enable the drivers at your own risk** of course, but we welcome reports of success/failure in any case (backup your VM first!). With disk PV drivers absent ``qvm-block`` will not work for the VM, but you can still use standard Qubes inter-VM file copying mechanisms.
|
||||
|
||||
Xen PV driver components may display a message box asking for reboot during installation – it’s safe to ignore them and defer the reboot.
|
||||
|
||||
Installation logs
|
||||
-----------------
|
||||
|
||||
|
||||
If the install process fails or something goes wrong during it, include the installation logs in your bug report. They are created in the ``%TEMP%`` directory, by default ``<user profile>\AppData\Local\Temp``. There are two text files, one small and one big, with names starting with ``Qubes_Windows_Tools``.
|
||||
|
||||
Uninstalling QWT is supported from version 3.2.1. Uninstalling previous versions is **not recommended**. After uninstalling you need to manually enable the DHCP Client Windows service, or set IP settings yourself to restore network access.
|
||||
|
||||
Configuration
|
||||
-------------
|
||||
|
||||
|
||||
Starting from version 2.2.* various aspects of Qubes Windows Tools can be configured through registry. Main configuration key is located in ``HKEY_LOCAL_MACHINE\SOFTWARE\Invisible Things Lab\Qubes Tools``. Configuration values set on this level are global to all QWT components. It’s possible to override global values with component-specific keys, this is useful mainly for setting log verbosity for troubleshooting. Possible configuration values are:
|
||||
|
||||
.. list-table::
|
||||
:widths: 14 14 14 14
|
||||
:align: center
|
||||
:header-rows: 1
|
||||
|
||||
* - Name
|
||||
- Type
|
||||
- Description
|
||||
- Default value
|
||||
* - LogDir
|
||||
- String
|
||||
- Directory where logs are created
|
||||
- c:\\Program Files\\Invisible Things Lab\\Qubes Tools\\log
|
||||
* - LogLevel
|
||||
- DWORD
|
||||
- Log verbosity (see below)
|
||||
- 2 (INFO)
|
||||
* - LogRetention
|
||||
- DWORD
|
||||
- Maximum age of log files (in seconds), older logs are automatically deleted
|
||||
- 604800 (7 days)
|
||||
|
||||
|
||||
|
||||
Possible log levels:
|
||||
|
||||
.. list-table::
|
||||
:widths: 11 11 11
|
||||
:align: center
|
||||
:header-rows: 1
|
||||
|
||||
* - Level
|
||||
- Type
|
||||
- Description
|
||||
* - 1
|
||||
- Error
|
||||
- Serious errors that most likely cause irrecoverable failures
|
||||
* - 2
|
||||
- Warning
|
||||
- Unexpected but non-fatal events
|
||||
* - 3
|
||||
- Info
|
||||
- Useful information (default)
|
||||
* - 4
|
||||
- Debug
|
||||
- Internal state dumps for troubleshooting
|
||||
* - 5
|
||||
- Verbose
|
||||
- Trace most function calls
|
||||
|
||||
|
||||
|
||||
Debug and Verbose levels can generate large volume of logs and are intended for development/troubleshooting only.
|
||||
|
||||
To override global settings for a specific component, create a new key under the root key mentioned above and name it as the executable name, without ``.exe`` extension. For example, to change qrexec-agent’s log level to Debug, set it like this:
|
||||
|
||||
|qtw-log-level.png|
|
||||
|
||||
Component-specific settings currently available:
|
||||
|
||||
.. list-table::
|
||||
:widths: 11 11 11 11 11
|
||||
:align: center
|
||||
:header-rows: 1
|
||||
|
||||
* - Component
|
||||
- Setting
|
||||
- Type
|
||||
- Description
|
||||
- Default value
|
||||
* - qga
|
||||
- DisableCursor
|
||||
- DWORD
|
||||
- Disable cursor in the VM. Useful for integration with Qubes desktop so you don’t see two cursors. Can be disabled if you plan to use the VM through a remote desktop connection of some sort. Needs gui agent restart to apply change (locking OS/logoff should be enough since qga is restarted on desktop change).
|
||||
- 1
|
||||
|
||||
|
||||
|
||||
Troubleshooting
|
||||
---------------
|
||||
|
||||
|
||||
If the VM is inaccessible (doesn’t respond to qrexec commands, gui is not functioning), try to boot it in safe mode:
|
||||
|
||||
- ``qvm-start --debug vmname``
|
||||
|
||||
- mash F8 on the boot screen to enable boot options and select Safe Mode (optionally with networking)
|
||||
|
||||
|
||||
|
||||
Safe Mode should at least give you access to logs (see above).
|
||||
|
||||
**Please include appropriate logs when reporting bugs/problems.** Starting from version 2.4.2 logs contain QWT version, but if you’re using an earlier version be sure to mention which one. If the OS crashes (BSOD) please include the BSOD code and parameters in your bug report. The BSOD screen should be visible if you run the VM in debug mode (``qvm-start --debug vmname``). If it’s not visible or the VM reboots automatically, try to start Windows in safe mode (see above) and 1) disable automatic restart on BSOD (Control Panel - System - Advanced system settings - Advanced - Startup and recovery), 2) check the system event log for BSOD events. If you can, send the ``memory.dmp`` dump file from ``c:\Windows``. Xen logs (``/var/log/xen/console/guest-*``) are also useful as they contain pvdrivers diagnostic output.
|
||||
|
||||
If a specific component is malfunctioning, you can increase its log verbosity as explained above to get more troubleshooting information. Below is a list of components:
|
||||
|
||||
.. list-table::
|
||||
:widths: 18 18
|
||||
:align: center
|
||||
:header-rows: 1
|
||||
|
||||
* - Component
|
||||
- Description
|
||||
* - qrexec-agent
|
||||
- Responsible for most communication with Qubes (dom0 and other domains), secure clipboard, file copying, qrexec services.
|
||||
* - qrexec-wrapper
|
||||
- Helper executable that’s responsible for launching qrexec services, handling their I/O and vchan communication.
|
||||
* - qrexec-client-vm
|
||||
- Used for communications by the qrexec protocol.
|
||||
* - qga
|
||||
- Gui agent.
|
||||
* - QgaWatchdog
|
||||
- Service that monitors session/desktop changes (logon/logoff/locking/UAC…) and simulates SAS sequence (ctrl-alt-del).
|
||||
* - qubesdb-daemon
|
||||
- Service for accessing Qubes configuration database.
|
||||
* - network-setup
|
||||
- Service that sets up network parameters according to VM’s configuration.
|
||||
* - prepare-volume
|
||||
- Utility that initializes and formats the disk backed by private.img file. It’s registered to run on next system boot during QWT setup, if that feature is selected (it can’t run during the setup because Xen block device drivers are not yet active). It in turn registers move-profiles (see below) to run at early boot.
|
||||
* - relocate-dir
|
||||
- Utility that moves user profiles directory to the private disk. It’s registered as an early boot native executable (similar to chkdsk) so it can run before any profile files are opened by some other process. Its log is in a fixed location: c:\move-profiles.log (it can’t use our common logger library so none of the log settings apply).
|
||||
|
||||
|
||||
|
||||
Updates
|
||||
-------
|
||||
|
||||
|
||||
When we publish new QWT version, it’s usually pushed to the ``current-testing`` or ``unstable`` repository first. To use versions from current-testing, run this in dom0:
|
||||
|
||||
``qubes-dom0-update --enablerepo=qubes-dom0-current-testing qubes-windows-tools``
|
||||
|
||||
That command will download a new QWT .iso from the testing repository. It goes without saying that you should **backup your VMs** before installing anything from testing repos.
|
||||
|
||||
.. |windows-seamless-4.png| image:: /attachment/doc/windows-seamless-4.png
|
||||
|
||||
|
||||
.. |windows-seamless-1.png| image:: /attachment/doc/windows-seamless-1.png
|
||||
|
||||
|
||||
.. |windows-seamless-7.png| image:: /attachment/doc/windows-seamless-7.png
|
||||
|
||||
|
||||
.. |qtw-log-level.png| image:: /attachment/doc/qtw-log-level.png
|
||||
|
||||
|
|
@ -1,361 +0,0 @@
|
|||
---
|
||||
lang: en
|
||||
layout: doc
|
||||
permalink: /doc/templates/windows/qubes-windows-tools-4-1/
|
||||
redirect_from:
|
||||
- /doc/templates/windows/windows-tools41/
|
||||
- /user/templates/windows/windows-tools41/
|
||||
title: Qubes Windows Tools (QWT)
|
||||
---
|
||||
|
||||
Qubes Windows Tools (QWT) are a set of programs and drivers that provide integration of Windows 7, 8.1, 10 and 11 Standalone, TemplateVMs and AppVMs with the rest of the Qubes system. They contain several components than can be enabled or disabled during installation, and rely on specific functions of Qubes which support this integration:
|
||||
|
||||
- **Shared components (required)** - common libraries used by QWT components
|
||||
- **Qubes GUI Agent** - video driver and GUI agent that enable the seamless GUI mode that integrates windows apps onto the common Qubes trusted desktop (currently only for Windows 7)
|
||||
- **Disable UAC** - User Account Control may interfere with QWT and doesn't really provide any additional benefits in Qubes environment
|
||||
- **Clipboard sender/receiver** - Support for [secure clipboard copy/paste](/doc/copy-paste/) between the Windows VM and other AppVMs
|
||||
- **File sender/receiver** - Support for [secure file exchange](/doc/copying-files/) between the Windows VM and other AppVMs
|
||||
- **Xen PV drivers** - drivers for the virtual hardware exposed by Xen for Windows that increase performance compared to QEMU emulated devices and are required for attaching USB devices
|
||||
- Base Xen PV Drivers (required): paravirtual bus and interface drivers
|
||||
- Xen PV Disk Drivers: paravirtual storage drivers
|
||||
- Xen PV Network Drivers: paravirtual network drivers
|
||||
- Move user profiles: user profile directory (`C:\users`) is moved to VM's private disk backed by `private.img file` in `dom0` (useful mainly for HVM templates).
|
||||
|
||||
- **Qubes Core Agent** (part of Qubes) - Needed for proper integration with Qubes as well as for `qvm-run` and generic `qrexec` for the Windows VM (e.g. ability to run custom service within/from the Windows VM)
|
||||
- **Copy/Edit in Disposable VM** (part of Qubes) - Support for editing files in DisposableVMs
|
||||
- **Audio** - Audio support is available even without QWT installation if `qvm-features audio-model` is set as `ich6`
|
||||
|
||||
|
||||
**Note:** Due to the security problems described in [QSB-091](https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-091-2023.txt), installation of Qubes Windows Tools is currently blocked. Instead, a text file containing a warning is displayed. Currently, it is difficult to estimate the severity of the risks posed by the sources of the Xen drivers used in QWT possibly being compromised, so it was decided not to offer direct QWT installation until this problem could be treated properly. While Windows qubes are, in Qubes, generally not regarded as being very trustworthy, a possible compromise of the Xen drivers used in Qubes Windows Tools might create a risk for Xen or `dom0` and thus be dangerous for Qubes itself. This risk may be small or even non-existent, as stated in QSB-091. If you **understand** this risk and are **willing to take it**, you can still install the previous versions of Qubes Windows Tools, using the command
|
||||
|
||||
sudo qubes-dom0-update qubes-windows-tools-4.1.68
|
||||
|
||||
for Qubes R4.1.2, or
|
||||
|
||||
sudo qubes-dom0-update qubes-windows-tools-4.1.69
|
||||
|
||||
for Qubes R4.2.0, respectively, instead of the command listed in step 1 of the installation described below. This will provide the .iso file to be presented as an installation drive to the Windows qube in step 3 of the QWT installation.
|
||||
|
||||
If you prefer to download the corresponding .rpm files for manual QWT installation, these are still available from the repositories (version [4.1.68-1](https://yum.qubes-os.org/r4.1/current/dom0/fc32/rpm/qubes-windows-tools-4.1.68-1.noarch.rpm) for Qubes R4.1.2 and version [4.1.69-1](https://yum.qubes-os.org/r4.2/current/dom0/fc37/rpm/qubes-windows-tools-4.1.69-1.fc37.noarch.rpm) for Qubes R4.2.0). After downloading, copy the file to `dom0` as described in [How to copy from dom0](https://www.qubes-os.org/doc/how-to-copy-from-dom0/#copying-to-dom0) and install it via `sudo dnf install /path/to/rpmfile`. Now you can proceed according to step 3 of the description below.
|
||||
|
||||
**Warning**: These older versions of Qubes Windows Tools will be replaced during the next dom0 update by the current dummy version 4.1.70-1. This can be inhibited by appending the line `exclude=qubes-windows-tools` to the file `/etc/dnf/dnf.conf` in dom0. But this will also stop any further QWT updates - so be sure to remove this line when - hopefully - a new functional version 4.1.71-1 of Qubes Windows Tools will be made available!!!
|
||||
|
||||
**Note**: If you choose to move profiles, drive letter `Q:` must be assigned to the secondary (private) disk.
|
||||
|
||||
**Note**: Xen PV disk drivers are not installed by default. This is because they seem to cause problems (BSOD = Blue Screen Of Death). We're working with upstream devs to fix this. *However*, the BSOD seems to only occur after the first boot and everything works fine after that. **Enable the drivers at your own risk** of course, but we welcome reports of success/failure in any case (backup your VM first!). With disk PV drivers absent `qvm-block` will not work for the VM, but you can still use standard Qubes inter-VM file copying mechanisms. On the other hand, the Xen PV drivers allow USB device access even without QWT installation if `qvm-features stubdom-qrexec` is set as `1`.
|
||||
|
||||
Below is a breakdown of the feature availability depending on the windows version:
|
||||
|
||||
| Feature | Windows 7 x64 | Windows 8.1/10/11 x64 |
|
||||
| ------------------------------------ | :------------: | :-------------------: |
|
||||
| Qubes Video Driver | y | n |
|
||||
| Qubes Network Setup | y | y |
|
||||
| Private Volume Setup (move profiles) | y | y |
|
||||
| File sender/receiver | y | y |
|
||||
| Clipboard Copy/Paste | y | y |
|
||||
| Application shortcuts | y | y |
|
||||
| Copy/Edit in Disposable VM | y | y |
|
||||
| Block device | y | y |
|
||||
| USB device | y | y |
|
||||
| Audio | y | y |
|
||||
|
||||
Qubes Windows Tools are open source and are distributed under a GPL license.
|
||||
|
||||
**Notes:**
|
||||
|
||||
- Currently only 64-bit versions of Windows 7, 8.1, 10 and 11 are supported by Qubes Windows Tools. Only emulated SVGA GPU is supported (although [there has been reports](https://groups.google.com/forum/#!topic/qubes-users/cmPRMOkxkdA) on working GPU passthrough).
|
||||
- This page documents the process of installing Qubes Windows Tools in version **R4.1**.
|
||||
- *In testing VMs only* it's probably a good idea to install a VNC server before installing QWT. If something goes very wrong with the Qubes gui agent, a VNC server should still allow access to the OS.
|
||||
|
||||
|
||||
## Preparation
|
||||
|
||||
**Windows 7 only:** Before proceeding with the installation we need to disable the Windows mechanism that allows only signed drivers to be installed, because currently the Qubes video driver, available for Windows 7, provided as part of the Windows Tools are not digitally signed with a publicly recognizable certificate. To do that:
|
||||
|
||||
1. Start the command prompt as Administrator, i.e. right click on the Command Prompt icon (All Programs -> Accessories) and choose "Run as administrator"
|
||||
2. In the command prompt type `bcdedit /set testsigning on`
|
||||
3. Reboot your Windows VM
|
||||
|
||||
In the future this step will not be necessary anymore, because we will sign our drivers with a publicly verifiable certificate. However, it should be noted that even, given the fact that those drivers are not digitally signed, this doesn't affect security of the Windows VM in 'any' way. This is because the actual installation `iso` file can be verified as described in step 3 below. The only downside of those drivers not being signed is the inconvenience to the user that he or she must disable the signature enforcement policy before installing the tools.
|
||||
|
||||
The Xen PV Drivers bundled with QWT are signed by a Linux Foundation certificate. Thus Windows 10 and 11 do not require this security mitigation.
|
||||
|
||||
**Warning:** it is recommended to increase the default value of Windows VM's `qrexec_timeout` property from 60 (seconds) to, for example, 300. During one of the first reboots after Windows Tools installation Windows user profiles are moved onto the private VM's virtual disk (private.img) and this operation can take some time. Moving profiles and, later on, updating a Windows installation, is performed in an early boot phase when `qrexec` is not yet running, so timeout may occur with the default value. To change the property use this command in `dom0`: *(where* `<VMname>` *is the name of your Windows VM)*
|
||||
|
||||
[user@dom0 ~] $ qvm-prefs <VMname> qrexec_timeout 7200
|
||||
|
||||
## Installing Windows OS as a Qubes VM
|
||||
|
||||
Please refer to [this page](/doc/templates/windows/windows-qubes-4-1/) for instructions on how to install Windows in a Qubes VM.
|
||||
|
||||
**Warning:** It is strongly suggested to enable autologon for any Windows HVMs that will have Qubes Tools installed. To do so, run `netplwiz` command from the `Win+R`/Start menu and uncheck the *Users must enter a user name and password to use this computer* option.
|
||||
|
||||
## Installing Qubes Windows Tools (QWT) in a Windows VM
|
||||
|
||||
Installing the Qubes Windows Tools on Windows 7, 8.1, 10 and 11 both as a StandaloneVM as well as a Template VM and a corresponding AppVM is described in the following sections.
|
||||
|
||||
**Note:** Seamless mode is currently not available for windows 10 and 11. Please check the top of this document for the full feature availability breakdown.
|
||||
|
||||
1. First, make sure that `qubes-windows-tools` is installed in your system:
|
||||
|
||||
sudo qubes-dom0-update qubes-windows-tools
|
||||
|
||||
(If the above command does not work, it could be that the Qubes Tools are not in the stable repo yet. Try installing from the testing repo instead.)
|
||||
|
||||
You can also install the package from testing repositories, where we usually publish new versions first:
|
||||
|
||||
sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing qubes-windows-tools
|
||||
|
||||
If an earlier version of Qubes Windows Tools is already installed, with enabled current-testing repo you need to specify as action to `upgrade` the existing package, because the default action is `install`, which will fail if it detects that QWT is already present in Dom0:
|
||||
|
||||
sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing --action=upgrade qubes-windows-tools
|
||||
|
||||
This package brings the ISO with Qubes Windows Tools that is passed to the VM when `--install-windows-tools` is specified for the `qvm-start` command. Please note that none of this software ever runs in Dom0 or any other part of the system except for the Windows AppVM in which it is to be installed.
|
||||
|
||||
2. **For Windows 8.1, 10 and 11:** From the Windows command line, disable hibernation in order to avoid incomplete Windows shutdown, which may lead to corruption of the VM's disk.
|
||||
|
||||
powercfg -H off
|
||||
|
||||
Also, these versions of Windows won’t show the CD-ROM drive after starting the qube with `qvm-start vm --cdrom ...` or `qvm-start ... --install-windows-tools`. The solution is to disable hibernation in Windows with this command. (That command is included in QWT’s setup but it’s necessary to run it manually in order to be able to open QWT’s setup ISO/CD-ROM in Windows).
|
||||
|
||||
3. To install the Qubes Windows Tools in a Windows VM one should start the VM passing the additional option `--install-windows-tools`:
|
||||
|
||||
qvm-start <VMname> --install-windows-tools
|
||||
|
||||
Once the Windows VM boots, a CDROM should appear in the 'My Computer' menu (typically as `D:` or `E:`) with the setup program `qubes-tools-x64.msi` in its main directory.
|
||||
|
||||
4. Install Qubes Windows Tools by starting `qubes-tools-x64.msi` (logged in as administrator), optionally selecting the `Xen PV disk drivers`. For installation in a template, you should select `Move user profiles`.
|
||||
|
||||
[](/attachment/doc/QWT_install_select.png)
|
||||
|
||||
Several times, Windows security may ask for confirmation of driver installation. Driver installation has to be allowed; otherwise the installation of Qubes Windows Tools will abort.
|
||||
|
||||
[](/attachment/doc/QWT_install_driver.png)
|
||||
|
||||
If during installation, the Xen driver requests a reboot, select "No" and let the installation continue - the system will be rebooted later.
|
||||
|
||||
[](/attachment/doc/QWT_install_no_restart.png)
|
||||
|
||||
5. After successful installation, the Windows VM must be shut down and started again, possibly a couple of times. On each shutdown, wait until the VM is really stopped, i.e. Qubes shows no more activity.
|
||||
|
||||
6. Qubes will automatically detect that the tools have been installed in the VM and will set appropriate properties for the VM, such as `qrexec_installed`, `guiagent_installed`, and `default_user`. This can be verified (but is not required) using the `qvm-prefs` command *(where* `<VMname>` *is the name of your Windows VM)*:
|
||||
|
||||
|
||||
```
|
||||
[user@dom0 ~] $ qvm-prefs <VMname>
|
||||
```
|
||||
|
||||
It is advisable to set some other parameters in order to enable audio and USB block device access, synchronize the Windows clock with the Qubes clock, and so on:
|
||||
|
||||
```
|
||||
[user@dom0 ~] $ qvm-features <VMname> audio-model ich9
|
||||
[user@dom0 ~] $ qvm-features <VMname> stubdom-qrexec 1
|
||||
[user@dom0 ~] $ qvm-features <VMname> timezone localtime
|
||||
```
|
||||
|
||||
For audio, the parameter `audio-model` can be selected as `ich6` or `ich9`; select the value that gives the best audio quality. Audio quality may also be improved by setting the following parameters, but this can depend on the Windows version and on your hardware:
|
||||
|
||||
```
|
||||
[user@dom0 ~] $ qvm-features <VMname> timer-period 1000
|
||||
[user@dom0 ~] $ qvm-features <VMname> out.latency 10000
|
||||
[user@dom0 ~] $ qvm-features <VMname> out.buffer-length 4000
|
||||
```
|
||||
|
||||
With the value `localtime` the dom0 `timezone` will be provided to virtual hardware, effectively setting the Windows clock to that of Qubes. With a digit value (negative or positive) the guest clock will have an offset (in seconds) applied relative to UTC.
|
||||
|
||||
7. Reboot Windows. If the VM starts, but does not show any window then shutdown Windows from the Qube manager, wait until it has really stopped, and reboot Windows once more.
|
||||
|
||||
8. Now the system should be up, with QWT running correctly.
|
||||
|
||||
9. **Windows 7 only:** Optionally enable seamless mode on VM startup. This can be done by setting appropriate values in the Windows registry:
|
||||
|
||||
- Start the command prompt as administrator, i.e. right click on the Command Prompt icon (All Programs -> Accessories) and choose "Run as administrator"
|
||||
- In the command prompt type `regedit`
|
||||
- In the registry editor, position to the key `\HKEY_LOCAL_MACHINE\Software\Invisible Things Lab\Qubes Tools\`
|
||||
- Change the value `SeamlessMode` from 0 to 1
|
||||
- Position to the key `\HKEY_LOCAL_MACHINE\Software\Invisible Things Lab\Qubes Tools\qga\`
|
||||
- Change the value `SeamlessMode` from 0 to 1
|
||||
- Terminate the registry editor.
|
||||
|
||||
After the next boot, the VM will start in seamless mode.
|
||||
If Windows is used in a TemplateVM / AppVM combination, this registry fix has to be applied to the TemplateVM, as the `HKLM` registry key belongs to the template-based part of the registry.
|
||||
|
||||
10. Lastly to enable file copy operations to a Windows VM, the `default_user` property of this VM should be set to the `<username>` that you use to login to the Windows VM. This can be done via the following command on a `dom0` terminal: `[user@dom0 ~] $ qvm-prefs <VMname> default_user <username>` *(where* `<VMname>` *is the name of your Windows VM)*.
|
||||
|
||||
**Warning:** If this property is not set or set to a wrong value, files copied to this VM are stored in the folder `C:\Windows\System32\config\systemprofile\Documents\QubesIncoming\<source_VM>`.
|
||||
|
||||
If the target VM is an AppVM, this has the consequence that the files are stored in the corresponding TemplateVM and so are lost on AppVM shutdown.
|
||||
|
||||
## Xen PV drivers and Qubes Windows Tools
|
||||
|
||||
Installing Xen's PV drivers in the VM will lower its resources usage when using network and/or I/O intensive applications, but *may* come at the price of system stability (although Xen's PV drivers on a Windows VM are usually very stable). They can be installed as an optional part of Qubes Windows Tools (QWT), which bundles Xen's PV drivers.
|
||||
|
||||
**Notes** about using Xen's VBD (storage) PV driver:
|
||||
|
||||
- **Windows 7:** Installing the driver requires a fully updated VM or else you'll likely get a BSOD ("Blue Screen Of Death") and a VM in a difficult to fix state. Updating Windows takes *hours* and for casual usage there isn't much of a performance between the disk PV driver and the default one; so there is likely no need to go through the lengthy Windows Update process if your VM doesn't have access to untrusted networks and if you don't use I/O intensive apps or attach block devices. If you plan to update your newly installed Windows VM it is recommended that you do so *before* installing Qubes Windows Tools. Installing the driver will probably cause Windows 7 activation to become invalid, but the activation can be restored using the Microsoft telephone activation method.
|
||||
- The option to install the storage PV driver is disabled by default in Qubes Windows Tools
|
||||
- In case you already had QWT installed without the storage PV driver and you then updated the VM, you may then install the driver by again starting the QWT installer and selecting the change option.
|
||||
|
||||
## Using Windows AppVMs in seamless mode
|
||||
|
||||
**Note:** This feature is only available for Windows 7
|
||||
|
||||
Once you start a Windows-based AppVM with Qubes Tools installed, you can easily start individual applications from the VM (note the `-a` switch used here, which will auto-start the VM if it is not running):
|
||||
|
||||
~~~
|
||||
[user@dom0 ~] $ qvm-run -a my-win-appvm explorer.exe
|
||||
~~~
|
||||
|
||||
[](/attachment/doc/windows-seamless-4.png)
|
||||
[](/attachment/doc/windows-seamless-1.png)
|
||||
|
||||
Also, the inter-VM services work as usual -- e.g. to request opening a document or URL in the Windows AppVM from another VM:
|
||||
|
||||
~~~
|
||||
[user@dom0 ~] $ qvm-open-in-vm my-win-appvm roadmap.pptx
|
||||
|
||||
[user@dom0 ~]$ qvm-open-in-vm my-win-appvm https://invisiblethingslab.com
|
||||
~~~
|
||||
|
||||
... just like in the case of Linux AppVMs. Of course all those operations are governed by central policy engine running in Dom0 -- if the policy doesn't contain explicit rules for the source and/or target AppVM, the user will be asked whether to allow or deny the operation.
|
||||
|
||||
Inter-VM file copy and clipboard works for Windows AppVMs the same way as for Linux AppVM (except that we don't provide a command line wrapper, `qvm-copy-to-vm` in Windows VMs) -- to copy files from Windows AppVMs just right-click on the file in Explorer, and choose: Send To-\> Other AppVM.
|
||||
|
||||
To simulate Ctrl-Alt-Delete in the HVM (SAS, Secure Attention Sequence), press Ctrl-Alt-Home while having any window of this VM in the foreground.
|
||||
|
||||
[](/attachment/doc/windows-seamless-7.png)
|
||||
|
||||
**Changing between seamless and full desktop mode**
|
||||
|
||||
You can switch between seamless and "full desktop" mode for Windows HVMs in their settings in Qubes Manager. The latter is the default.
|
||||
|
||||
## Using template-based Windows AppVMs
|
||||
|
||||
Qubes allows HVM VMs to share a common root filesystem from a select Template VM, just as for Linux AppVMs. This mode is not limited to Windows AppVMs, and can be used for any HVM (e.g. FreeBSD running in a HVM).
|
||||
|
||||
In order to create an HVM TemplateVM, the type "TemplateVM" has to be selected on creating the VM. Then set memory as appropriate, and install the Windows OS (or any other OS) into this template the same way as you would install it into a normal HVM -- please see instructions on [this page](/doc/hvm-create/).
|
||||
|
||||
If you use this Template as it is, then any HVMs that use it will effectively be DisposableVMs - the User directory will be wiped when the HVM is closed down.
|
||||
|
||||
If you want to retain the User directory between reboots, then it would make sense to store the `C:\Users` directory on the 2nd disk which is automatically exposed by Qubes to all HVMs.
|
||||
This 2nd disk is backed by the `private.img` file in the AppVMs' and is not reset upon AppVMs reboot, so the user's directories and profiles would survive the AppVMs reboot, unlike the "root" filesystem which will be reverted to the "golden image" from the Template VM automatically.
|
||||
To facilitate such separation of user profiles, Qubes Windows Tools provide an option to automatically move `C:\Users` directory to the 2nd disk backed by `private.img`.
|
||||
It's a selectable feature of the installer. For Windows 7, it requires the private disk to be renamed to `Q:` before QWT installation (see above); for Windows 8.1, 10 and 11, this renaming occurs during QWT installation automatically.
|
||||
If that feature is selected during installation, completion of the process requires two reboots:
|
||||
|
||||
- The private disk is initialized and formatted on the first reboot after tools installation. It can't be done **during** the installation because Xen mass storage drivers are not yet active.
|
||||
- User profiles are moved to the private disk on the next reboot after the private disk is initialized.
|
||||
Reboot is required because the "mover utility" runs very early in the boot process so OS can't yet lock any files in there.
|
||||
This can take some time depending on the profiles' size and because the GUI agent is not yet active dom0/Qubes Manager may complain that the AppVM failed to boot.
|
||||
That's a false alarm (you can increase the AppVM's default boot timeout using `qvm-prefs`), the VM should appear "green" in Qubes Manager shortly after.
|
||||
|
||||
It also makes sense to disable Automatic Updates for all the template-based AppVMs -- of course this should be done in the Template VM, not in individual AppVMs, because the system-wide settings are stored in the root filesystem (which holds the system-wide registry hives). Then, periodically check for updates in the Template VM and the changes will be carried over to any child AppVMs.
|
||||
|
||||
Once the template has been created and installed it is easy to create AppVMs based on it, by selecting the type "AppVM" and a suitable template.
|
||||
|
||||
## Using Windows disposables
|
||||
|
||||
Windows qubes can be used as disposables, like any other Linux-based qubes. On creating a template for Windows disposables, certain preparations have to be executed:
|
||||
|
||||
- Create an AppVM based on a Windows TemplateVM.
|
||||
- Start this AppVM and insert a link to the command prompt executable in the `Autostart` directory of the Windows menu tree:
|
||||
- **For Windows 7:**
|
||||
- If the Windows qube started in seamless mode, hit the Windows keyboard key while the cursor is positioned in a window of this VM. In non-seamless mode, klick on the Start button. In both cases, the Windows menu will be displayed.
|
||||
- Position into the `Autostart` submenu.
|
||||
- **For Windows 8.1, 10 or 11:**
|
||||
- Type Win+R to open the execution Prompt.
|
||||
- Type `shell:startup`.
|
||||
- An explorer window will open, which is positioned to the `Autostart` folder.
|
||||
- Right-click and select the option "New -> Link".
|
||||
- Select `C:\Windows\System32\CMD.exe` as executable.
|
||||
- Name the link, e.g. as `Command Prompt`.
|
||||
- Close the Window with `OK`.
|
||||
- Shut down this AppVM.
|
||||
- In the Qube Manager, refresh the applications of the newly created AppVM and select those applications that you want to make available from the disposable. Alternatively, in dom0 execute the command `qvm-sync-appmenus <VMname>`, *where* `<VMname>` *is the name of your windows qube*.
|
||||
- In the Qube Manager, go to the "Advanced" tab and enable the option `Disposable template` for your Windows qube. Alternatively, in dom0 execute the commands `qvm-prefs <VMname> template_for_dispvms True` and `qvm-features <VMname> appmenus-dispvm 1`.
|
||||
- Click `Apply`.
|
||||
- Still in the Advanced tab, select your Windows qube as its own `Default disposable template`. Alternatively, in dom0 execute the command `qvm-prefs <VMname> default_dispvm <VMname>`.
|
||||
- Close the Qube Manager by clicking `OK`.
|
||||
|
||||
Now you should have a menu `Disposable: <VMname>` containing the applications that can be started in a disposable Windows VM. If you set the newly created and configured Windows VM as `Default disposable template` for any other Windows- (or Linux-) based qube, this qube can use the Windows-based dispvm like any other disposable.
|
||||
|
||||
For further information on usage of disposables, see [How to use disposables](/doc/how-to-use-disposables/).
|
||||
|
||||
**Caution:** *If a Windows-based disposable is used from another qube via the* `Open/Edit in DisposableVM` *command, this disposable may not close automatically, due to the command prompt window still running in this dispvm. In this case, the disposable has to be shut down manually.*
|
||||
|
||||
## Installation logs
|
||||
|
||||
If the install process fails or something goes wrong during it, include the installation logs in your bug report. They are created in the `%TEMP%` directory, by default `<user profile>\AppData\Local\Temp`. There are two text files, one small and one big, with names starting with `Qubes_Windows_Tools`.
|
||||
|
||||
Uninstalling QWT is supported. After uninstalling you need to manually enable the DHCP Client Windows service, or set IP settings yourself to restore network access.
|
||||
|
||||
## Configuration
|
||||
|
||||
Various aspects of Qubes Windows Tools (QWT) can be configured through the registry. The main configuration key is located in `HKEY_LOCAL_MACHINE\SOFTWARE\Invisible Things Lab\Qubes Tools`. Configuration values set on this level are global to all QWT components. It's possible to override global values with component-specific keys, this is useful mainly for setting log verbosity for troubleshooting. Possible configuration values are:
|
||||
|
||||
|**Name**|**Type**|**Description**|**Default value**|
|
||||
|:-------|:-------|:--------------|:----------------|
|
||||
|LogDir|String|Directory where logs are created|c:\\Program Files\\Invisible Things Lab\\Qubes Tools\\log|
|
||||
|LogLevel|DWORD|Log verbosity (see below)|2 (INFO)|
|
||||
|LogRetention|DWORD|Maximum age of log files (in seconds), older logs are automatically deleted|604800 (7 days)|
|
||||
|
||||
Possible log levels:
|
||||
|
||||
|**Level**|**Title**|**Description**|
|
||||
|:-----|:-----|:--------------|
|
||||
|1|Error|Serious errors that most likely cause irrecoverable failures|
|
||||
|2|Warning|Unexpected but non-fatal events|
|
||||
|3|Info|Useful information (default)|
|
||||
|4|Debug|Internal state dumps for troubleshooting|
|
||||
|5|Verbose|Trace most function calls|
|
||||
|
||||
Debug and Verbose levels can generate large volume of logs and are intended for development/troubleshooting only.
|
||||
|
||||
To override global settings for a specific component, create a new key under the root key mentioned above and name it as the executable name, without `.exe` extension.
|
||||
|
||||
Component-specific settings currently available:
|
||||
|
||||
| Component | Setting | Type | Description | Default value |
|
||||
|:--------------|:------------|:-----------|:------------------------------------------------|:------------------|
|
||||
|qga|DisableCursor|DWORD|Disable cursor in the VM. Useful for integration with Qubes desktop so you don't see two cursors. Can be disabled if you plan to use the VM through a remote desktop connection of some sort. Needs gui agent restart to apply change (locking OS/logoff should be enough since qga is restarted on desktop change).|1|
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
If the VM is inaccessible (doesn't respond to qrexec commands, gui is not functioning), try to boot it in safe mode:
|
||||
|
||||
- `[user@dom0 ~] $ qvm-start --debug <VMname>`
|
||||
- Enable boot options and select Safe Mode (method depends on the Windows version; optionally with networking)
|
||||
|
||||
Safe Mode should at least give you access to logs (see above).
|
||||
|
||||
**Please include appropriate logs when reporting bugs/problems.** Logs contain the QWT version. If the OS crashes (BSOD) please include the BSOD code and parameters in your bug report. The BSOD screen should be visible if you run the VM in debug mode (`qvm-start --debug vmname`). If it's not visible or the VM reboots automatically, try to start Windows in safe mode (see above) and 1) disable automatic restart on BSOD (Control Panel - System - Advanced system settings - Advanced - Startup and recovery), 2) check the system event log for BSOD events. If you can, send the `memory.dmp` dump file from `C:\Windows`.
|
||||
|
||||
Xen logs in dom0 (`/var/log/xen/console/guest-*`) are also useful as they contain pvdrivers diagnostic output.
|
||||
|
||||
If a specific component is malfunctioning, you can increase its log verbosity as explained above to get more troubleshooting information. Below is a list of components:
|
||||
|
||||
|**Component**|**Description**|
|
||||
|:------------|:--------------|
|
||||
|qrexec-agent|Responsible for most communication with Qubes (dom0 and other domains), secure clipboard, file copying, qrexec services.|
|
||||
|qrexec-wrapper|Helper executable that's responsible for launching qrexec services, handling their I/O and vchan communication.|
|
||||
|qrexec-client-vm|Used for communications by the qrexec protocol.|
|
||||
|qga|Gui agent.|
|
||||
|QgaWatchdog|Service that monitors session/desktop changes (logon/logoff/locking/UAC...) and simulates SAS sequence (Ctrl-Alt-Del).|
|
||||
|qubesdb-daemon|Service for accessing Qubes configuration database.|
|
||||
|network-setup|Service that sets up network parameters according to VM's configuration.|
|
||||
|prepare-volume|Utility that initializes and formats the disk backed by `private.img` file. It's registered to run on next system boot during QWT setup, if that feature is selected (it can't run *during* the setup because Xen block device drivers are not yet active). It in turn registers move-profiles (see below) to run at early boot.|
|
||||
|relocate-dir|Utility that moves user profiles directory to the private disk. It's registered as an early boot native executable (similar to chkdsk) so it can run before any profile files are opened by some other process. Its log is in a fixed location: `C:\move-profiles.log` (it can't use our common logger library so none of the log settings apply).|
|
||||
|
||||
If there are network-related issues, the qube doesn't resolve DNS and has trouble accessing the Internet, this might be an issue with the PV Network Drivers.
|
||||
|
||||
In this case it's recommended that the PV Network Drivers be unchecked during installation of Qubes Windows Tools as seen in the screenshot below.
|
||||
|
||||
[](/attachment/doc/QWT_no_PV_network.png)
|
||||
|
||||
## Updates
|
||||
|
||||
When we publish a new QWT version, it's usually pushed to the `current-testing` or `unstable` repository first. To use versions from current-testing, run this in dom0:
|
||||
|
||||
[user@dom0 ~] $ sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing qubes-windows-tools
|
||||
|
||||
That command will download a new QWT `iso` file from the testing repository. It goes without saying that you should **backup your VMs** before installing anything from testing repos.
|
||||
584
user/templates/windows/qubes-windows-tools-4-1.rst
Normal file
584
user/templates/windows/qubes-windows-tools-4-1.rst
Normal file
|
|
@ -0,0 +1,584 @@
|
|||
=========================
|
||||
Qubes Windows Tools (QWT)
|
||||
=========================
|
||||
|
||||
|
||||
Qubes Windows Tools (QWT) are a set of programs and drivers that provide integration of Windows 7, 8.1, 10 and 11 Standalone, TemplateVMs and AppVMs with the rest of the Qubes system. They contain several components than can be enabled or disabled during installation, and rely on specific functions of Qubes which support this integration:
|
||||
|
||||
- **Shared components (required)** - common libraries used by QWT components
|
||||
|
||||
- **Qubes GUI Agent** - video driver and GUI agent that enable the seamless GUI mode that integrates windows apps onto the common Qubes trusted desktop (currently only for Windows 7)
|
||||
|
||||
- **Disable UAC** - User Account Control may interfere with QWT and doesn’t really provide any additional benefits in Qubes environment
|
||||
|
||||
- **Clipboard sender/receiver** - Support for :doc:`secure clipboard copy/paste </user/how-to-guides/how-to-copy-and-paste-text>` between the Windows VM and other AppVMs
|
||||
|
||||
- **File sender/receiver** - Support for :doc:`secure file exchange </user/how-to-guides/how-to-copy-and-move-files>` between the Windows VM and other AppVMs
|
||||
|
||||
- **Xen PV drivers** - drivers for the virtual hardware exposed by Xen for Windows that increase performance compared to QEMU emulated devices and are required for attaching USB devices
|
||||
|
||||
- Base Xen PV Drivers (required): paravirtual bus and interface drivers
|
||||
|
||||
- Xen PV Disk Drivers: paravirtual storage drivers
|
||||
|
||||
- Xen PV Network Drivers: paravirtual network drivers
|
||||
|
||||
- Move user profiles: user profile directory (``C:\users``) is moved to VM’s private disk backed by ``private.img file`` in ``dom0`` (useful mainly for HVM templates).
|
||||
|
||||
|
||||
|
||||
- **Qubes Core Agent** (part of Qubes) - Needed for proper integration with Qubes as well as for ``qvm-run`` and generic ``qrexec`` for the Windows VM (e.g. ability to run custom service within/from the Windows VM)
|
||||
|
||||
- **Copy/Edit in Disposable VM** (part of Qubes) - Support for editing files in DisposableVMs
|
||||
|
||||
- **Audio** - Audio support is available even without QWT installation if ``qvm-features audio-model`` is set as ``ich6``
|
||||
|
||||
|
||||
|
||||
**Note:** Due to the security problems described in `QSB-091 <https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-091-2023.txt>`__, installation of Qubes Windows Tools is currently blocked. Instead, a text file containing a warning is displayed. Currently, it is difficult to estimate the severity of the risks posed by the sources of the Xen drivers used in QWT possibly being compromised, so it was decided not to offer direct QWT installation until this problem could be treated properly. While Windows qubes are, in Qubes, generally not regarded as being very trustworthy, a possible compromise of the Xen drivers used in Qubes Windows Tools might create a risk for Xen or ``dom0`` and thus be dangerous for Qubes itself. This risk may be small or even non-existent, as stated in QSB-091. If you **understand** this risk and are **willing to take it**, you can still install the previous versions of Qubes Windows Tools, using the command
|
||||
|
||||
.. code:: bash
|
||||
|
||||
sudo qubes-dom0-update qubes-windows-tools-4.1.68
|
||||
|
||||
|
||||
|
||||
for Qubes R4.1.2, or
|
||||
|
||||
.. code:: bash
|
||||
|
||||
sudo qubes-dom0-update qubes-windows-tools-4.1.69
|
||||
|
||||
|
||||
|
||||
for Qubes R4.2.0, respectively, instead of the command listed in step 1 of the installation described below. This will provide the .iso file to be presented as an installation drive to the Windows qube in step 3 of the QWT installation.
|
||||
|
||||
If you prefer to download the corresponding .rpm files for manual QWT installation, these are still available from the repositories (version `4.1.68-1 <https://yum.qubes-os.org/r4.1/current/dom0/fc32/rpm/qubes-windows-tools-4.1.68-1.noarch.rpm>`__ for Qubes R4.1.2 and version `4.1.69-1 <https://yum.qubes-os.org/r4.2/current/dom0/fc37/rpm/qubes-windows-tools-4.1.69-1.fc37.noarch.rpm>`__ for Qubes R4.2.0). After downloading, copy the file to ``dom0`` as described in `How to copy from dom0 <https://www.qubes-os.org/doc/how-to-copy-from-dom0/#copying-to-dom0>`__ and install it via ``sudo dnf install /path/to/rpmfile``. Now you can proceed according to step 3 of the description below.
|
||||
|
||||
**Warning**: These older versions of Qubes Windows Tools will be replaced during the next dom0 update by the current dummy version 4.1.70-1. This can be inhibited by appending the line ``exclude=qubes-windows-tools`` to the file ``/etc/dnf/dnf.conf`` in dom0. But this will also stop any further QWT updates - so be sure to remove this line when - hopefully - a new functional version 4.1.71-1 of Qubes Windows Tools will be made available!!!
|
||||
|
||||
**Note**: If you choose to move profiles, drive letter ``Q:`` must be assigned to the secondary (private) disk.
|
||||
|
||||
**Note**: Xen PV disk drivers are not installed by default. This is because they seem to cause problems (BSOD = Blue Screen Of Death). We’re working with upstream devs to fix this. *However*, the BSOD seems to only occur after the first boot and everything works fine after that. **Enable the drivers at your own risk** of course, but we welcome reports of success/failure in any case (backup your VM first!). With disk PV drivers absent ``qvm-block`` will not work for the VM, but you can still use standard Qubes inter-VM file copying mechanisms. On the other hand, the Xen PV drivers allow USB device access even without QWT installation if ``qvm-features stubdom-qrexec`` is set as ``1``.
|
||||
|
||||
Below is a breakdown of the feature availability depending on the windows version:
|
||||
|
||||
.. list-table::
|
||||
:widths: 38 38 38
|
||||
:align: center
|
||||
:header-rows: 1
|
||||
|
||||
* - Feature
|
||||
- Windows 7 x64
|
||||
- Windows 8.1/10/11 x64
|
||||
* - Qubes Video Driver
|
||||
- y
|
||||
- n
|
||||
* - Qubes Network Setup
|
||||
- y
|
||||
- y
|
||||
* - Private Volume Setup (move profiles)
|
||||
- y
|
||||
- y
|
||||
* - File sender/receiver
|
||||
- y
|
||||
- y
|
||||
* - Clipboard Copy/Paste
|
||||
- y
|
||||
- y
|
||||
* - Application shortcuts
|
||||
- y
|
||||
- y
|
||||
* - Copy/Edit in Disposable VM
|
||||
- y
|
||||
- y
|
||||
* - Block device
|
||||
- y
|
||||
- y
|
||||
* - USB device
|
||||
- y
|
||||
- y
|
||||
* - Audio
|
||||
- y
|
||||
- y
|
||||
|
||||
|
||||
|
||||
Qubes Windows Tools are open source and are distributed under a GPL license.
|
||||
|
||||
**Notes:**
|
||||
|
||||
- Currently only 64-bit versions of Windows 7, 8.1, 10 and 11 are supported by Qubes Windows Tools. Only emulated SVGA GPU is supported (although `there has been reports <https://groups.google.com/forum/#!topic/qubes-users/cmPRMOkxkdA>`__ on working GPU passthrough).
|
||||
|
||||
- This page documents the process of installing Qubes Windows Tools in version **R4.1**.
|
||||
|
||||
- *In testing VMs only* it’s probably a good idea to install a VNC server before installing QWT. If something goes very wrong with the Qubes gui agent, a VNC server should still allow access to the OS.
|
||||
|
||||
|
||||
|
||||
Preparation
|
||||
-----------
|
||||
|
||||
|
||||
**Windows 7 only:** Before proceeding with the installation we need to disable the Windows mechanism that allows only signed drivers to be installed, because currently the Qubes video driver, available for Windows 7, provided as part of the Windows Tools are not digitally signed with a publicly recognizable certificate. To do that:
|
||||
|
||||
1. Start the command prompt as Administrator, i.e. right click on the Command Prompt icon (All Programs -> Accessories) and choose “Run as administrator”
|
||||
|
||||
2. In the command prompt type ``bcdedit /set testsigning on``
|
||||
|
||||
3. Reboot your Windows VM
|
||||
|
||||
|
||||
|
||||
In the future this step will not be necessary anymore, because we will sign our drivers with a publicly verifiable certificate. However, it should be noted that even, given the fact that those drivers are not digitally signed, this doesn’t affect security of the Windows VM in ‘any’ way. This is because the actual installation ``iso`` file can be verified as described in step 3 below. The only downside of those drivers not being signed is the inconvenience to the user that he or she must disable the signature enforcement policy before installing the tools.
|
||||
|
||||
The Xen PV Drivers bundled with QWT are signed by a Linux Foundation certificate. Thus Windows 10 and 11 do not require this security mitigation.
|
||||
|
||||
**Warning:** it is recommended to increase the default value of Windows VM’s ``qrexec_timeout`` property from 60 (seconds) to, for example, 300. During one of the first reboots after Windows Tools installation Windows user profiles are moved onto the private VM’s virtual disk (private.img) and this operation can take some time. Moving profiles and, later on, updating a Windows installation, is performed in an early boot phase when ``qrexec`` is not yet running, so timeout may occur with the default value. To change the property use this command in ``dom0``: *(where* ``<VMname>`` *is the name of your Windows VM)*
|
||||
|
||||
.. code:: bash
|
||||
|
||||
[user@dom0 ~] $ qvm-prefs <VMname> qrexec_timeout 7200
|
||||
|
||||
|
||||
|
||||
Installing Windows OS as a Qubes VM
|
||||
-----------------------------------
|
||||
|
||||
|
||||
Please refer to :doc:`this page </user/templates/windows/windows-qubes-4-1>` for instructions on how to install Windows in a Qubes VM.
|
||||
|
||||
**Warning:** It is strongly suggested to enable autologon for any Windows HVMs that will have Qubes Tools installed. To do so, run ``netplwiz`` command from the ``Win+R``/Start menu and uncheck the *Users must enter a user name and password to use this computer* option.
|
||||
|
||||
Installing Qubes Windows Tools (QWT) in a Windows VM
|
||||
----------------------------------------------------
|
||||
|
||||
|
||||
Installing the Qubes Windows Tools on Windows 7, 8.1, 10 and 11 both as a StandaloneVM as well as a Template VM and a corresponding AppVM is described in the following sections.
|
||||
|
||||
**Note:** Seamless mode is currently not available for windows 10 and 11. Please check the top of this document for the full feature availability breakdown.
|
||||
|
||||
1. First, make sure that ``qubes-windows-tools`` is installed in your system:
|
||||
|
||||
.. code:: bash
|
||||
|
||||
sudo qubes-dom0-update qubes-windows-tools
|
||||
|
||||
|
||||
(If the above command does not work, it could be that the Qubes Tools are not in the stable repo yet. Try installing from the testing repo instead.)
|
||||
You can also install the package from testing repositories, where we usually publish new versions first:
|
||||
|
||||
.. code:: bash
|
||||
|
||||
sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing qubes-windows-tools
|
||||
|
||||
|
||||
If an earlier version of Qubes Windows Tools is already installed, with enabled current-testing repo you need to specify as action to ``upgrade`` the existing package, because the default action is ``install``, which will fail if it detects that QWT is already present in Dom0:
|
||||
|
||||
.. code:: bash
|
||||
|
||||
sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing --action=upgrade qubes-windows-tools
|
||||
|
||||
|
||||
This package brings the ISO with Qubes Windows Tools that is passed to the VM when ``--install-windows-tools`` is specified for the ``qvm-start`` command. Please note that none of this software ever runs in Dom0 or any other part of the system except for the Windows AppVM in which it is to be installed.
|
||||
|
||||
2. **For Windows 8.1, 10 and 11:** From the Windows command line, disable hibernation in order to avoid incomplete Windows shutdown, which may lead to corruption of the VM’s disk.
|
||||
|
||||
.. code:: bash
|
||||
|
||||
powercfg -H off
|
||||
|
||||
|
||||
Also, these versions of Windows won’t show the CD-ROM drive after starting the qube with ``qvm-start vm --cdrom ...`` or ``qvm-start ... --install-windows-tools``. The solution is to disable hibernation in Windows with this command. (That command is included in QWT’s setup but it’s necessary to run it manually in order to be able to open QWT’s setup ISO/CD-ROM in Windows).
|
||||
|
||||
3. To install the Qubes Windows Tools in a Windows VM one should start the VM passing the additional option ``--install-windows-tools``:
|
||||
|
||||
.. code:: bash
|
||||
|
||||
qvm-start <VMname> --install-windows-tools
|
||||
|
||||
|
||||
Once the Windows VM boots, a CDROM should appear in the ‘My Computer’ menu (typically as ``D:`` or ``E:``) with the setup program ``qubes-tools-x64.msi`` in its main directory.
|
||||
|
||||
4. Install Qubes Windows Tools by starting ``qubes-tools-x64.msi`` (logged in as administrator), optionally selecting the ``Xen PV disk drivers``. For installation in a template, you should select ``Move user profiles``.
|
||||
|
||||
|QWT_install_select|
|
||||
|
||||
Several times, Windows security may ask for confirmation of driver installation. Driver installation has to be allowed; otherwise the installation of Qubes Windows Tools will abort.
|
||||
|
||||
|QWT_install_driver|
|
||||
|
||||
If during installation, the Xen driver requests a reboot, select “No” and let the installation continue - the system will be rebooted later.
|
||||
|QWT_install_no_restart|
|
||||
|
||||
5. After successful installation, the Windows VM must be shut down and started again, possibly a couple of times. On each shutdown, wait until the VM is really stopped, i.e. Qubes shows no more activity.
|
||||
|
||||
6. Qubes will automatically detect that the tools have been installed in the VM and will set appropriate properties for the VM, such as ``qrexec_installed``, ``guiagent_installed``, and ``default_user``. This can be verified (but is not required) using the ``qvm-prefs`` command *(where* ``<VMname>`` *is the name of your Windows VM)*:
|
||||
|
||||
.. code:: bash
|
||||
|
||||
[user@dom0 ~] $ qvm-prefs <VMname>
|
||||
|
||||
|
||||
It is advisable to set some other parameters in order to enable audio and USB block device access, synchronize the Windows clock with the Qubes clock, and so on:
|
||||
|
||||
.. code:: bash
|
||||
|
||||
[user@dom0 ~] $ qvm-features <VMname> audio-model ich9
|
||||
[user@dom0 ~] $ qvm-features <VMname> stubdom-qrexec 1
|
||||
[user@dom0 ~] $ qvm-features <VMname> timezone localtime
|
||||
|
||||
|
||||
For audio, the parameter ``audio-model`` can be selected as ``ich6`` or ``ich9``; select the value that gives the best audio quality. Audio quality may also be improved by setting the following parameters, but this can depend on the Windows version and on your hardware:
|
||||
|
||||
.. code:: bash
|
||||
|
||||
[user@dom0 ~] $ qvm-features <VMname> timer-period 1000
|
||||
[user@dom0 ~] $ qvm-features <VMname> out.latency 10000
|
||||
[user@dom0 ~] $ qvm-features <VMname> out.buffer-length 4000
|
||||
|
||||
|
||||
With the value ``localtime`` the dom0 ``timezone`` will be provided to virtual hardware, effectively setting the Windows clock to that of Qubes. With a digit value (negative or positive) the guest clock will have an offset (in seconds) applied relative to UTC.
|
||||
|
||||
7. Reboot Windows. If the VM starts, but does not show any window then shutdown Windows from the Qube manager, wait until it has really stopped, and reboot Windows once more.
|
||||
|
||||
8. Now the system should be up, with QWT running correctly.
|
||||
|
||||
9. **Windows 7 only:** Optionally enable seamless mode on VM startup. This can be done by setting appropriate values in the Windows registry:
|
||||
|
||||
- Start the command prompt as administrator, i.e. right click on the Command Prompt icon (All Programs -> Accessories) and choose “Run as administrator”
|
||||
|
||||
- In the command prompt type ``regedit``
|
||||
|
||||
- In the registry editor, position to the key ``\HKEY_LOCAL_MACHINE\Software\Invisible Things Lab\Qubes Tools\``
|
||||
|
||||
- Change the value ``SeamlessMode`` from 0 to 1
|
||||
|
||||
- Position to the key ``\HKEY_LOCAL_MACHINE\Software\Invisible Things Lab\Qubes Tools\qga\``
|
||||
|
||||
- Change the value ``SeamlessMode`` from 0 to 1
|
||||
|
||||
- Terminate the registry editor.
|
||||
|
||||
|
||||
After the next boot, the VM will start in seamless mode. If Windows is used in a TemplateVM / AppVM combination, this registry fix has to be applied to the TemplateVM, as the ``HKLM`` registry key belongs to the template-based part of the registry.
|
||||
|
||||
10. Lastly to enable file copy operations to a Windows VM, the ``default_user`` property of this VM should be set to the ``<username>`` that you use to login to the Windows VM. This can be done via the following command on a ``dom0`` terminal: ``[user@dom0 ~] $ qvm-prefs <VMname> default_user <username>`` *(where* ``<VMname>`` *is the name of your Windows VM)*.
|
||||
|
||||
|
||||
|
||||
**Warning:** If this property is not set or set to a wrong value, files copied to this VM are stored in the folder ``C:\Windows\System32\config\systemprofile\Documents\QubesIncoming\<source_VM>``.
|
||||
|
||||
If the target VM is an AppVM, this has the consequence that the files are stored in the corresponding TemplateVM and so are lost on AppVM shutdown.
|
||||
|
||||
Xen PV drivers and Qubes Windows Tools
|
||||
--------------------------------------
|
||||
|
||||
|
||||
Installing Xen’s PV drivers in the VM will lower its resources usage when using network and/or I/O intensive applications, but *may* come at the price of system stability (although Xen’s PV drivers on a Windows VM are usually very stable). They can be installed as an optional part of Qubes Windows Tools (QWT), which bundles Xen’s PV drivers.
|
||||
|
||||
**Notes** about using Xen’s VBD (storage) PV driver:
|
||||
|
||||
- **Windows 7:** Installing the driver requires a fully updated VM or else you’ll likely get a BSOD (“Blue Screen Of Death”) and a VM in a difficult to fix state. Updating Windows takes *hours* and for casual usage there isn’t much of a performance between the disk PV driver and the default one; so there is likely no need to go through the lengthy Windows Update process if your VM doesn’t have access to untrusted networks and if you don’t use I/O intensive apps or attach block devices. If you plan to update your newly installed Windows VM it is recommended that you do so *before* installing Qubes Windows Tools. Installing the driver will probably cause Windows 7 activation to become invalid, but the activation can be restored using the Microsoft telephone activation method.
|
||||
|
||||
- The option to install the storage PV driver is disabled by default in Qubes Windows Tools
|
||||
|
||||
- In case you already had QWT installed without the storage PV driver and you then updated the VM, you may then install the driver by again starting the QWT installer and selecting the change option.
|
||||
|
||||
|
||||
|
||||
Using Windows AppVMs in seamless mode
|
||||
-------------------------------------
|
||||
|
||||
|
||||
**Note:** This feature is only available for Windows 7
|
||||
|
||||
Once you start a Windows-based AppVM with Qubes Tools installed, you can easily start individual applications from the VM (note the ``-a`` switch used here, which will auto-start the VM if it is not running):
|
||||
|
||||
.. code:: bash
|
||||
|
||||
[user@dom0 ~] $ qvm-run -a my-win-appvm explorer.exe
|
||||
|
||||
|
||||
|
||||
|windows-seamless-4.png| |windows-seamless-1.png|
|
||||
|
||||
Also, the inter-VM services work as usual – e.g. to request opening a document or URL in the Windows AppVM from another VM:
|
||||
|
||||
.. code:: bash
|
||||
|
||||
[user@dom0 ~] $ qvm-open-in-vm my-win-appvm roadmap.pptx
|
||||
|
||||
[user@dom0 ~]$ qvm-open-in-vm my-win-appvm https://invisiblethingslab.com
|
||||
|
||||
|
||||
… just like in the case of Linux AppVMs. Of course all those operations are governed by central policy engine running in Dom0 – if the policy doesn’t contain explicit rules for the source and/or target AppVM, the user will be asked whether to allow or deny the operation.
|
||||
|
||||
Inter-VM file copy and clipboard works for Windows AppVMs the same way as for Linux AppVM (except that we don’t provide a command line wrapper, ``qvm-copy-to-vm`` in Windows VMs) – to copy files from Windows AppVMs just right-click on the file in Explorer, and choose: Send To-> Other AppVM.
|
||||
|
||||
To simulate Ctrl-Alt-Delete in the HVM (SAS, Secure Attention Sequence), press Ctrl-Alt-Home while having any window of this VM in the foreground.
|
||||
|
||||
|windows-seamless-7.png|
|
||||
|
||||
**Changing between seamless and full desktop mode**
|
||||
|
||||
You can switch between seamless and “full desktop” mode for Windows HVMs in their settings in Qubes Manager. The latter is the default.
|
||||
|
||||
Using template-based Windows AppVMs
|
||||
-----------------------------------
|
||||
|
||||
|
||||
Qubes allows HVM VMs to share a common root filesystem from a select Template VM, just as for Linux AppVMs. This mode is not limited to Windows AppVMs, and can be used for any HVM (e.g. FreeBSD running in a HVM).
|
||||
|
||||
In order to create an HVM TemplateVM, the type “TemplateVM” has to be selected on creating the VM. Then set memory as appropriate, and install the Windows OS (or any other OS) into this template the same way as you would install it into a normal HVM – please see instructions on :doc:`this page </user/advanced-topics/standalones-and-hvms>`.
|
||||
|
||||
If you use this Template as it is, then any HVMs that use it will effectively be DisposableVMs - the User directory will be wiped when the HVM is closed down.
|
||||
|
||||
If you want to retain the User directory between reboots, then it would make sense to store the ``C:\Users`` directory on the 2nd disk which is automatically exposed by Qubes to all HVMs. This 2nd disk is backed by the ``private.img`` file in the AppVMs’ and is not reset upon AppVMs reboot, so the user’s directories and profiles would survive the AppVMs reboot, unlike the “root” filesystem which will be reverted to the “golden image” from the Template VM automatically. To facilitate such separation of user profiles, Qubes Windows Tools provide an option to automatically move ``C:\Users`` directory to the 2nd disk backed by ``private.img``. It’s a selectable feature of the installer. For Windows 7, it requires the private disk to be renamed to ``Q:`` before QWT installation (see above); for Windows 8.1, 10 and 11, this renaming occurs during QWT installation automatically. If that feature is selected during installation, completion of the process requires two reboots:
|
||||
|
||||
- The private disk is initialized and formatted on the first reboot after tools installation. It can’t be done **during** the installation because Xen mass storage drivers are not yet active.
|
||||
|
||||
- User profiles are moved to the private disk on the next reboot after the private disk is initialized. Reboot is required because the “mover utility” runs very early in the boot process so OS can’t yet lock any files in there. This can take some time depending on the profiles’ size and because the GUI agent is not yet active dom0/Qubes Manager may complain that the AppVM failed to boot. That’s a false alarm (you can increase the AppVM’s default boot timeout using ``qvm-prefs``), the VM should appear “green” in Qubes Manager shortly after.
|
||||
|
||||
|
||||
|
||||
It also makes sense to disable Automatic Updates for all the template-based AppVMs – of course this should be done in the Template VM, not in individual AppVMs, because the system-wide settings are stored in the root filesystem (which holds the system-wide registry hives). Then, periodically check for updates in the Template VM and the changes will be carried over to any child AppVMs.
|
||||
|
||||
Once the template has been created and installed it is easy to create AppVMs based on it, by selecting the type “AppVM” and a suitable template.
|
||||
|
||||
Using Windows disposables
|
||||
-------------------------
|
||||
|
||||
|
||||
Windows qubes can be used as disposables, like any other Linux-based qubes. On creating a template for Windows disposables, certain preparations have to be executed:
|
||||
|
||||
- Create an AppVM based on a Windows TemplateVM.
|
||||
|
||||
- Start this AppVM and insert a link to the command prompt executable in the ``Autostart`` directory of the Windows menu tree:
|
||||
|
||||
- **For Windows 7:**
|
||||
|
||||
- If the Windows qube started in seamless mode, hit the Windows keyboard key while the cursor is positioned in a window of this VM. In non-seamless mode, klick on the Start button. In both cases, the Windows menu will be displayed.
|
||||
|
||||
- Position into the ``Autostart`` submenu.
|
||||
|
||||
|
||||
|
||||
- **For Windows 8.1, 10 or 11:**
|
||||
|
||||
- Type Win+R to open the execution Prompt.
|
||||
|
||||
- Type ``shell:startup``.
|
||||
|
||||
- An explorer window will open, which is positioned to the ``Autostart`` folder.
|
||||
|
||||
|
||||
|
||||
- Right-click and select the option “New -> Link”.
|
||||
|
||||
- Select ``C:\Windows\System32\CMD.exe`` as executable.
|
||||
|
||||
- Name the link, e.g. as ``Command Prompt``.
|
||||
|
||||
- Close the Window with ``OK``.
|
||||
|
||||
- Shut down this AppVM.
|
||||
|
||||
|
||||
|
||||
- In the Qube Manager, refresh the applications of the newly created AppVM and select those applications that you want to make available from the disposable. Alternatively, in dom0 execute the command ``qvm-sync-appmenus <VMname>``, *where* ``<VMname>`` *is the name of your windows qube*.
|
||||
|
||||
- In the Qube Manager, go to the “Advanced” tab and enable the option ``Disposable template`` for your Windows qube. Alternatively, in dom0 execute the commands ``qvm-prefs <VMname> template_for_dispvms True`` and ``qvm-features <VMname> appmenus-dispvm 1``.
|
||||
|
||||
- Click ``Apply``.
|
||||
|
||||
- Still in the Advanced tab, select your Windows qube as its own ``Default disposable template``. Alternatively, in dom0 execute the command ``qvm-prefs <VMname> default_dispvm <VMname>``.
|
||||
|
||||
- Close the Qube Manager by clicking ``OK``.
|
||||
|
||||
|
||||
|
||||
Now you should have a menu ``Disposable: <VMname>`` containing the applications that can be started in a disposable Windows VM. If you set the newly created and configured Windows VM as ``Default disposable template`` for any other Windows- (or Linux-) based qube, this qube can use the Windows-based dispvm like any other disposable.
|
||||
|
||||
For further information on usage of disposables, see :doc:`How to use disposables </user/how-to-guides/how-to-use-disposables>`.
|
||||
|
||||
**Caution:** *If a Windows-based disposable is used from another qube via the* ``Open/Edit in DisposableVM`` *command, this disposable may not close automatically, due to the command prompt window still running in this dispvm. In this case, the disposable has to be shut down manually.*
|
||||
|
||||
Installation logs
|
||||
-----------------
|
||||
|
||||
|
||||
If the install process fails or something goes wrong during it, include the installation logs in your bug report. They are created in the ``%TEMP%`` directory, by default ``<user profile>\AppData\Local\Temp``. There are two text files, one small and one big, with names starting with ``Qubes_Windows_Tools``.
|
||||
|
||||
Uninstalling QWT is supported. After uninstalling you need to manually enable the DHCP Client Windows service, or set IP settings yourself to restore network access.
|
||||
|
||||
Configuration
|
||||
-------------
|
||||
|
||||
|
||||
Various aspects of Qubes Windows Tools (QWT) can be configured through the registry. The main configuration key is located in ``HKEY_LOCAL_MACHINE\SOFTWARE\Invisible Things Lab\Qubes Tools``. Configuration values set on this level are global to all QWT components. It’s possible to override global values with component-specific keys, this is useful mainly for setting log verbosity for troubleshooting. Possible configuration values are:
|
||||
|
||||
.. list-table::
|
||||
:widths: 14 14 14 14
|
||||
:align: center
|
||||
:header-rows: 1
|
||||
|
||||
* - Name
|
||||
- Type
|
||||
- Description
|
||||
- Default value
|
||||
* - LogDir
|
||||
- String
|
||||
- Directory where logs are created
|
||||
- c:\\Program Files\\Invisible Things Lab\\Qubes Tools\\log
|
||||
* - LogLevel
|
||||
- DWORD
|
||||
- Log verbosity (see below)
|
||||
- 2 (INFO)
|
||||
* - LogRetention
|
||||
- DWORD
|
||||
- Maximum age of log files (in seconds), older logs are automatically deleted
|
||||
- 604800 (7 days)
|
||||
|
||||
|
||||
|
||||
Possible log levels:
|
||||
|
||||
.. list-table::
|
||||
:widths: 11 11 11
|
||||
:align: center
|
||||
:header-rows: 1
|
||||
|
||||
* - Level
|
||||
- Title
|
||||
- Description
|
||||
* - 1
|
||||
- Error
|
||||
- Serious errors that most likely cause irrecoverable failures
|
||||
* - 2
|
||||
- Warning
|
||||
- Unexpected but non-fatal events
|
||||
* - 3
|
||||
- Info
|
||||
- Useful information (default)
|
||||
* - 4
|
||||
- Debug
|
||||
- Internal state dumps for troubleshooting
|
||||
* - 5
|
||||
- Verbose
|
||||
- Trace most function calls
|
||||
|
||||
|
||||
|
||||
Debug and Verbose levels can generate large volume of logs and are intended for development/troubleshooting only.
|
||||
|
||||
To override global settings for a specific component, create a new key under the root key mentioned above and name it as the executable name, without ``.exe`` extension.
|
||||
|
||||
Component-specific settings currently available:
|
||||
|
||||
.. list-table::
|
||||
:widths: 11 11 11 11 11
|
||||
:align: center
|
||||
:header-rows: 1
|
||||
|
||||
* - Component
|
||||
- Setting
|
||||
- Type
|
||||
- Description
|
||||
- Default value
|
||||
* - qga
|
||||
- DisableCursor
|
||||
- DWORD
|
||||
- Disable cursor in the VM. Useful for integration with Qubes desktop so you don’t see two cursors. Can be disabled if you plan to use the VM through a remote desktop connection of some sort. Needs gui agent restart to apply change (locking OS/logoff should be enough since qga is restarted on desktop change).
|
||||
- 1
|
||||
|
||||
|
||||
|
||||
Troubleshooting
|
||||
---------------
|
||||
|
||||
|
||||
If the VM is inaccessible (doesn’t respond to qrexec commands, gui is not functioning), try to boot it in safe mode:
|
||||
|
||||
- ``[user@dom0 ~] $ qvm-start --debug <VMname>``
|
||||
|
||||
- Enable boot options and select Safe Mode (method depends on the Windows version; optionally with networking)
|
||||
|
||||
|
||||
|
||||
Safe Mode should at least give you access to logs (see above).
|
||||
|
||||
**Please include appropriate logs when reporting bugs/problems.** Logs contain the QWT version. If the OS crashes (BSOD) please include the BSOD code and parameters in your bug report. The BSOD screen should be visible if you run the VM in debug mode (``qvm-start --debug vmname``). If it’s not visible or the VM reboots automatically, try to start Windows in safe mode (see above) and 1) disable automatic restart on BSOD (Control Panel - System - Advanced system settings - Advanced - Startup and recovery), 2) check the system event log for BSOD events. If you can, send the ``memory.dmp`` dump file from ``C:\Windows``.
|
||||
|
||||
Xen logs in dom0 (``/var/log/xen/console/guest-*``) are also useful as they contain pvdrivers diagnostic output.
|
||||
|
||||
If a specific component is malfunctioning, you can increase its log verbosity as explained above to get more troubleshooting information. Below is a list of components:
|
||||
|
||||
.. list-table::
|
||||
:widths: 32 32
|
||||
:align: center
|
||||
:header-rows: 1
|
||||
|
||||
* - Component
|
||||
- Description
|
||||
* - qrexec-agent
|
||||
- Responsible for most communication with Qubes (dom0 and other domains), secure clipboard, file copying, qrexec services.
|
||||
* - qrexec-wrapper
|
||||
- Helper executable that’s responsible for launching qrexec services, handling their I/O and vchan communication.
|
||||
* - qrexec-client-vm
|
||||
- Used for communications by the qrexec protocol.
|
||||
* - qga
|
||||
- Gui agent.
|
||||
* - QgaWatchdog
|
||||
- Service that monitors session/desktop changes (logon/logoff/locking/UAC…) and simulates SAS sequence (Ctrl-Alt-Del).
|
||||
* - qubesdb-daemon
|
||||
- Service for accessing Qubes configuration database.
|
||||
* - network-setup
|
||||
- Service that sets up network parameters according to VM’s configuration.
|
||||
* - prepare-volume
|
||||
- Utility that initializes and formats the disk backed by private.img file. It’s registered to run on next system boot during QWT setup, if that feature is selected (it can’t run during the setup because Xen block device drivers are not yet active). It in turn registers move-profiles (see below) to run at early boot.
|
||||
* - relocate-dir
|
||||
- Utility that moves user profiles directory to the private disk. It’s registered as an early boot native executable (similar to chkdsk) so it can run before any profile files are opened by some other process. Its log is in a fixed location: C:\\move-profiles.log (it can’t use our common logger library so none of the log settings apply).
|
||||
|
||||
|
||||
|
||||
If there are network-related issues, the qube doesn’t resolve DNS and has trouble accessing the Internet, this might be an issue with the PV Network Drivers.
|
||||
|
||||
In this case it’s recommended that the PV Network Drivers be unchecked during installation of Qubes Windows Tools as seen in the screenshot below.
|
||||
|
||||
|QWT_no_PV_network|
|
||||
|
||||
Updates
|
||||
-------
|
||||
|
||||
|
||||
When we publish a new QWT version, it’s usually pushed to the ``current-testing`` or ``unstable`` repository first. To use versions from current-testing, run this in dom0:
|
||||
|
||||
.. code:: bash
|
||||
|
||||
[user@dom0 ~] $ sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing qubes-windows-tools
|
||||
|
||||
|
||||
|
||||
That command will download a new QWT ``iso`` file from the testing repository. It goes without saying that you should **backup your VMs** before installing anything from testing repos.
|
||||
|
||||
.. |QWT_install_select| image:: /attachment/doc/QWT_install_select.png
|
||||
|
||||
|
||||
.. |QWT_install_driver| image:: /attachment/doc/QWT_install_driver.png
|
||||
|
||||
|
||||
.. |QWT_install_no_restart| image:: /attachment/doc/QWT_install_no_restart.png
|
||||
|
||||
|
||||
.. |windows-seamless-4.png| image:: /attachment/doc/windows-seamless-4.png
|
||||
|
||||
|
||||
.. |windows-seamless-1.png| image:: /attachment/doc/windows-seamless-1.png
|
||||
|
||||
|
||||
.. |windows-seamless-7.png| image:: /attachment/doc/windows-seamless-7.png
|
||||
|
||||
|
||||
.. |QWT_no_PV_network| image:: /attachment/doc/QWT_no_PV_network.png
|
||||
|
||||
|
|
@ -1,265 +0,0 @@
|
|||
---
|
||||
lang: en
|
||||
layout: doc
|
||||
permalink: /doc/templates/windows/windows-qubes-4-0/
|
||||
redirect_from:
|
||||
- /doc/templates/windows/windows-vm/
|
||||
- /user/templates/windows/windows-vm/
|
||||
- /doc/windows-vm/
|
||||
title: How to install Windows qubes in Qubes OS 4.0
|
||||
---
|
||||
|
||||
**Warning:** *The content below describes Windows installation in Qubes R4.0. The text has been updated to reflect the newer R4.1 release and QWT recent development. Please see [this updated document](/doc/templates/windows/windows-qubes-4-1) for instructions for Qubes R4.1.*
|
||||
|
||||
## Simple Windows install
|
||||
|
||||
If you just want something simple and you can live without some features.
|
||||
|
||||
Works:
|
||||
|
||||
- display (1440x900 or 1280x1024 are a nice fit onto FHD hw display)
|
||||
- keyboard (incl. correct mapping), pointing device
|
||||
- network (emulated Realtek NIC)
|
||||
|
||||
Does not work:
|
||||
|
||||
- copy & paste (the qubes way)
|
||||
- copying files into / out of the VM (the qubes way)
|
||||
- assigning USB devices (the qubes way via the tray applet)
|
||||
- audio output and input
|
||||
- PCI device 5853:0001 (Xen platform device) - no driver
|
||||
- all other features/hardware needing special tool/driver support
|
||||
|
||||
Installation procedure:
|
||||
|
||||
- Have the Windows 10 ISO image (I used the 64-bit version) downloaded in some qube.
|
||||
- Create a new Qube:
|
||||
- Name: Win10, Color: red
|
||||
- Standalone Qube not based on a template
|
||||
- Networking: sys-firewall (default)
|
||||
- Launch settings after creation: check
|
||||
- Click "OK".
|
||||
- Settings:
|
||||
- Basic:
|
||||
- System storage: 30000+ MB
|
||||
- Advanced:
|
||||
- Include in memory balancing: uncheck
|
||||
- Initial memory: 4096+ MB
|
||||
- Kernel: None
|
||||
- Mode: HVM
|
||||
- Click "Apply".
|
||||
- Click "Boot from CDROM":
|
||||
- "from file in qube":
|
||||
- Select the qube that has the ISO.
|
||||
- Select ISO by clicking "...".
|
||||
- Click "OK" to boot into the windows installer.
|
||||
- Windows Installer:
|
||||
- Mostly as usual, but automatic reboots will halt the qube - just restart
|
||||
it again and again until the installation is finished.
|
||||
- Install on first disk.
|
||||
- Windows license may be read from flash via root in dom0:
|
||||
|
||||
`strings < /sys/firmware/acpi/tables/MSDM`
|
||||
|
||||
Alternatively, you can also try a Windows 7 license key (as of 2018/11
|
||||
they are still accepted for a free upgrade).
|
||||
|
||||
I first installed Windows and all updates, then entered the license key.
|
||||
- Afterwards:
|
||||
- In case you switch from `sys-network` to `sys-whonix`, you'll need a static
|
||||
IP network configuration, DHCP won't work for `sys-whonix`.
|
||||
- Use `powercfg -H off` and `disk cleanup` to save some disk space.
|
||||
|
||||
|
||||
## Qubes 4.0 - importing a Windows VM from R3.2
|
||||
|
||||
Importing should work, simply make sure that you are not using Xen's newer linux stubdomain and that the VM is in HVM mode (these steps should be done automatically when importing the VM):
|
||||
|
||||
~~~
|
||||
qvm-features VMNAME linux-stubdom ''
|
||||
qvm-prefs VMNAME virt_mode hvm
|
||||
~~~
|
||||
|
||||
Note however that you are better off creating a new Windows VM to benefit from the more recent emulated hardware: R3.2 uses a MiniOS based stubdomain with an old and mostly unmaintained 'qemu-traditional' while R4.0 uses a Linux based stubdomain with a recent version of upstream qemu (see [this post](https://groups.google.com/d/msg/qubes-devel/tBqwJmOAJ94/xmFCGJnuAwAJ)).
|
||||
|
||||
|
||||
## Windows qube installation
|
||||
|
||||
### qvm-create-windows-qube
|
||||
|
||||
An unofficial, third-party tool for automating this process is available [here](https://github.com/elliotkillick/qvm-create-windows-qube).
|
||||
(Please note that this tool has not been reviewed by the Qubes OS Project.
|
||||
Use it at your own risk.)
|
||||
However, if you are an expert or want to do it manually you may continue below.
|
||||
|
||||
### Summary
|
||||
|
||||
~~~
|
||||
qvm-create --class StandaloneVM --label red --property virt_mode=hvm win7new
|
||||
qvm-prefs win7new memory 4096
|
||||
qvm-prefs win7new maxmem 4096
|
||||
qvm-prefs win7new kernel ''
|
||||
qvm-volume extend win7new:root 25g
|
||||
qvm-prefs win7new debug true
|
||||
qvm-features win7new video-model cirrus
|
||||
qvm-start --cdrom=untrusted:/home/user/windows_install.iso win7new
|
||||
# restart after the first part of the windows installation process ends
|
||||
qvm-start win7new
|
||||
# once Windows is installed and working
|
||||
qvm-prefs win7new memory 2048
|
||||
qvm-prefs win7new maxmem 2048
|
||||
qvm-features --unset win7new video-model
|
||||
qvm-prefs win7new qrexec_timeout 300
|
||||
# with Qubes Windows Tools installed:
|
||||
qvm-prefs win7new debug false
|
||||
~~~
|
||||
|
||||
To install Qubes Windows Tools, follow instructions in [Qubes Windows Tools](/doc/templates/windows/qubes-windows-tools-4-0).
|
||||
|
||||
### Detailed instructions
|
||||
|
||||
MS Windows versions considerations:
|
||||
|
||||
- The instructions *may* work on other versions than Windows 7 x64 but haven't been tested.
|
||||
- Qubes Windows Tools (QWT) only supports Windows 7 x64. Note that there are [known issues](https://github.com/QubesOS/qubes-issues/issues/3585) with QWT on Qubes 4.x
|
||||
- For Windows 10 under Qubes 4.0, a way to install QWT 4.0.1.3, which has worked in several instances, is described in [Qubes Windows Tools](/doc/templates/windows/qubes-windows-tools-4-0).
|
||||
|
||||
Create a VM named win7new in [HVM](/doc/hvm/) mode (Xen's current PVH limitations precludes from using PVH):
|
||||
|
||||
~~~
|
||||
qvm-create --class StandaloneVM --label red --property virt_mode=hvm win7new
|
||||
~~~
|
||||
|
||||
Windows' installer requires a significant amount of memory or else the VM will crash with such errors:
|
||||
|
||||
`/var/log/xen/console/hypervisor.log`:
|
||||
|
||||
~~~
|
||||
p2m_pod_demand_populate: Dom120 out of PoD memory! (tot=102411 ents=921600 dom120)
|
||||
(XEN) domain_crash called from p2m-pod.c:1218
|
||||
(XEN) Domain 120 (vcpu#0) crashed on cpu#3:
|
||||
~~~
|
||||
|
||||
So, increase the VM's memory to 4096MB (memory = maxmem because we don't use memory balancing).
|
||||
|
||||
~~~
|
||||
qvm-prefs win7new memory 4096
|
||||
qvm-prefs win7new maxmem 4096
|
||||
~~~
|
||||
|
||||
Disable direct boot so that the VM will go through the standard cdrom/HDD boot sequence:
|
||||
|
||||
~~~
|
||||
qvm-prefs win7new kernel ''
|
||||
~~~
|
||||
|
||||
A typical Windows 7 installation requires between 15GB up to 19GB of disk space depending on the version (Home/Professional/...). Windows updates also end up using significant space. So, extend the root volume from the default 10GB to 25GB (note: it is straightforward to increase the root volume size after Windows is installed: simply extend the volume again in dom0 and then extend the system partition with Windows's disk manager).
|
||||
|
||||
~~~
|
||||
qvm-volume extend win7new:root 25g
|
||||
~~~
|
||||
|
||||
Set the debug flag in order to have a graphical console:
|
||||
|
||||
~~~
|
||||
qvm-prefs win7new debug true
|
||||
~~~
|
||||
|
||||
The second part of the installation process will crash with the standard VGA video adapter and the VM will stay in "transient" mode with the following error in `guest-win7new-dm.log`:
|
||||
|
||||
~~~
|
||||
qemu: /home/user/qubes-src/vmm-xen-stubdom-linux/build/qemu/exec.c:1187: cpu_physical_memory_snapshot_get_dirty: Assertion `start + length <= snap->end' failed.
|
||||
~~~
|
||||
|
||||
To avoid that error we temporarily have to switch the video adapter to 'cirrus':
|
||||
|
||||
~~~
|
||||
qvm-features win7new video-model cirrus
|
||||
~~~
|
||||
|
||||
The VM is now ready to be started; the best practice is to use an installation ISO [located in a VM](/doc/standalones-and-hvms/#installing-an-os-in-an-hvm):
|
||||
|
||||
~~~
|
||||
qvm-start --cdrom=untrusted:/home/user/windows_install.iso win7new
|
||||
~~~
|
||||
|
||||
Given the higher than usual memory requirements of Windows, you may get a `Not enough memory to start domain 'win7new'` error. In that case try to shutdown unneeded VMs to free memory before starting the Windows VM.
|
||||
|
||||
At this point you may open a tab in dom0 for debugging, in case something goes amiss:
|
||||
|
||||
~~~
|
||||
tailf /var/log/qubes/vm-win7new.log \
|
||||
/var/log/xen/console/hypervisor.log \
|
||||
/var/log/xen/console/guest-win7new-dm.log
|
||||
~~~
|
||||
|
||||
The VM will shutdown after the installer completes the extraction of Windows installation files. It's a good idea to clone the VM now (eg. `qvm-clone win7new win7newbkp1`). Then, (re)start the VM with `qvm-start win7new`.
|
||||
|
||||
The second part of Windows' installer should then be able to complete successfully. You may then perform the following post-install steps:
|
||||
|
||||
Decrease the VM's memory to a more reasonable value (memory balancing on Windows is unstable so keep `memory` equal to `maxmen`).
|
||||
|
||||
~~~
|
||||
qvm-prefs win7new memory 2048
|
||||
qvm-prefs win7new maxmem 2048
|
||||
~~~
|
||||
|
||||
Revert to the standard VGA adapter: the 'cirrus' adapter will limit the maximum screen resolution to 1024x768 pixels, while the default VGA adapter allows for much higher resolutions (up to 2560x1600 pixels).
|
||||
|
||||
~~~
|
||||
qvm-features --unset win7new video-model
|
||||
~~~
|
||||
|
||||
Finally, increase the VM's `qrexec_timeout`: in case you happen to get a BSOD or a similar crash in the VM, utilities like chkdsk won't complete on restart before qrexec_timeout automatically halts the VM. That can really put the VM in a totally unrecoverable state, whereas with higher qrexec_timeout, chkdsk or the appropriate utility has plenty of time to fix the VM. Note that Qubes Windows Tools also require a larger timeout to move the user profiles to the private volume the first time the VM reboots after the tools' installation.
|
||||
|
||||
~~~
|
||||
qvm-prefs win7new qrexec_timeout 300
|
||||
~~~
|
||||
|
||||
At that point you should have a functional and stable Windows VM, although without updates, Xen's PV drivers nor Qubes integration (see sections [Windows Update](/doc/templates/windows/windows-qubes-4-0/#windows-update) and [Xen PV drivers and Qubes Windows Tools](/doc/templates/windows/qubes-windows-tools-4-0/#xen-pv-drivers-and-qubes-windows-tools)). It is a good time to clone the VM again.
|
||||
|
||||
|
||||
## Windows as a template
|
||||
|
||||
Windows 7 and 10 can be installed as TemplateVM by selecting
|
||||
|
||||
~~~
|
||||
qvm-create --class TemplateVM --property virt_mode=HVM --property kernel='' --label black Windows-template
|
||||
~~~
|
||||
when creating the VM. To have the user data stored in AppVMs depending on this template, Windows 7 and 10 have to be treated differently:
|
||||
|
||||
- For Windows 7, the option to move the user directories from drive `C` to drive `D` works and causes any user data to be stored in the AppVMs based on this template, and not in the template itself.
|
||||
|
||||
- After installation of Windows 10 as a TemplateVM, the Windows disk manager may be used to add the private volume as disk `D:`, and you may, using the documented Windows operations, move the user directories `C:\users\<username>\Documents` to this new disk, allowing depending AppVMs to have their own private volumes. Moving the hidden application directories `AppData`, however, is likely to invite trouble - the same trouble that occurs if, during QWT installation, the option `Move user profiles` is selected.
|
||||
|
||||
For Windows 10, configuration data like those stored in directories like `AppData` still remain in the TemplateVM, such that their changes are lost each time the AppVM shuts down. In order to make permanent changes to these configuration data, they have to be changed in the TemplateVM, meaning that applications have to be started there, which violates and perhaps even endangers the security of the TemplateVM. Such changes should be done only if absolutely necessary and with great care. It is a good idea to test them first in a cloned TemplateVM before applying them in the production VM.
|
||||
|
||||
AppVMs based on these templates can be created the normal way by using the Qube Manager or by specifying
|
||||
|
||||
~~~
|
||||
qvm-create --class=AppVM --template=<VMname>
|
||||
~~~
|
||||
|
||||
On starting the AppVM, sometimes a message is displayed that the Xen PV Network Class needs to restart the system. This message can be safely ignored and closed by selecting "No".
|
||||
|
||||
**Caution:** These AppVMs must not be started while the corresponding TemplateVM is running, because they share the TemplateVM's license data. Even if this could work sometimes, it would be a violation of the license terms.
|
||||
|
||||
### Windows 10 Usage According to GDPR
|
||||
|
||||
If Windows 10 is used in the EU to process personal data, according to GDPR no automatic data transfer to countries outside the EU is allowed without explicit consent of the person(s) concerned, or other legal consent, as applicable. Since no reliable way is found to completely control the sending of telemetry from Windows 10, the system containing personal data must be completely shielded from the internet.
|
||||
|
||||
This can be achieved by installing Windows 10 on a TemplateVM with the user data directory moved to a separate drive (usually `D:`). Personal data must not be stored within the TemplateVM, but only in AppVMs depending on this TemplateVM. Network access by these AppVMs must be restricted to the local network and perhaps additional selected servers within the EU. Any data exchange of the AppVMs must be restricted to file and clipboard operations to and from other VMs in the same Qubes system.
|
||||
|
||||
|
||||
## Windows update
|
||||
|
||||
Depending on how old your installation media is, fully updating your Windows VM may take *hours* (this isn't specific to Xen/Qubes) so make sure you clone your VM between the mandatory reboots in case something goes wrong. This [comment](https://github.com/QubesOS/qubes-issues/issues/3585#issuecomment-366471111) provides useful links on updating a Windows 7 SP1 VM.
|
||||
|
||||
Note: if you already have Qubes Windows Tools installed the video adapter in Windows will be "Qubes video driver" and you won't be able to see the Windows Update process when the VM is being powered off because Qubes services would have been stopped by then. Depending on the size of the Windows update packs it may take a bit of time until the VM shutdowns by itself, leaving one wondering if the VM has crashed or still finalizing the updates (in dom0 a changing CPU usage - eg. shown with `xentop` - usually indicates that the VM hasn't crashed).
|
||||
To avoid guessing the VM's state enable debugging (`qvm-prefs -s win7new debug true`) and in Windows' device manager (My computer -> Manage / Device manager / Display adapters) temporarily re-enable the standard VGA adapter and disable "Qubes video driver". You can disable debugging and revert to Qubes' display once the VM is updated.
|
||||
|
||||
|
||||
## Further customization
|
||||
|
||||
Please see the [Customizing Windows 7 templates](/doc/windows-template-customization/) page (despite the focus on preparing the VM for use as a template, most of the instructions are independent from how the VM will be used - ie. TemplateVM or StandaloneVM).
|
||||
|
||||
360
user/templates/windows/windows-qubes-4-0.rst
Normal file
360
user/templates/windows/windows-qubes-4-0.rst
Normal file
|
|
@ -0,0 +1,360 @@
|
|||
============================================
|
||||
How to install Windows qubes in Qubes OS 4.0
|
||||
============================================
|
||||
|
||||
|
||||
**Warning:** *The content below describes Windows installation in Qubes R4.0. The text has been updated to reflect the newer R4.1 release and QWT recent development. Please see* :doc:`this updated document </user/templates/windows/windows-qubes-4-1>` *for instructions for Qubes R4.1.*
|
||||
|
||||
Simple Windows install
|
||||
----------------------
|
||||
|
||||
|
||||
If you just want something simple and you can live without some features.
|
||||
|
||||
Works:
|
||||
|
||||
- display (1440x900 or 1280x1024 are a nice fit onto FHD hw display)
|
||||
|
||||
- keyboard (incl. correct mapping), pointing device
|
||||
|
||||
- network (emulated Realtek NIC)
|
||||
|
||||
|
||||
|
||||
Does not work:
|
||||
|
||||
- copy & paste (the qubes way)
|
||||
|
||||
- copying files into / out of the VM (the qubes way)
|
||||
|
||||
- assigning USB devices (the qubes way via the tray applet)
|
||||
|
||||
- audio output and input
|
||||
|
||||
- PCI device 5853:0001 (Xen platform device) - no driver
|
||||
|
||||
- all other features/hardware needing special tool/driver support
|
||||
|
||||
|
||||
|
||||
Installation procedure:
|
||||
|
||||
- Have the Windows 10 ISO image (I used the 64-bit version) downloaded in some qube.
|
||||
|
||||
- Create a new Qube:
|
||||
|
||||
- Name: Win10, Color: red
|
||||
|
||||
- Standalone Qube not based on a template
|
||||
|
||||
- Networking: sys-firewall (default)
|
||||
|
||||
- Launch settings after creation: check
|
||||
|
||||
- Click “OK”.
|
||||
|
||||
|
||||
|
||||
- Settings:
|
||||
|
||||
- Basic:
|
||||
|
||||
- System storage: 30000+ MB
|
||||
|
||||
|
||||
|
||||
- Advanced:
|
||||
|
||||
- Include in memory balancing: uncheck
|
||||
|
||||
- Initial memory: 4096+ MB
|
||||
|
||||
- Kernel: None
|
||||
|
||||
- Mode: HVM
|
||||
|
||||
|
||||
|
||||
- Click “Apply”.
|
||||
|
||||
- Click “Boot from CDROM”:
|
||||
|
||||
- “from file in qube”:
|
||||
|
||||
- Select the qube that has the ISO.
|
||||
|
||||
- Select ISO by clicking “…”.
|
||||
|
||||
|
||||
|
||||
- Click “OK” to boot into the windows installer.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
- Windows Installer:
|
||||
|
||||
- Mostly as usual, but automatic reboots will halt the qube - just restart it again and again until the installation is finished.
|
||||
|
||||
- Install on first disk.
|
||||
|
||||
- Windows license may be read from flash via root in dom0:
|
||||
``strings < /sys/firmware/acpi/tables/MSDM``
|
||||
Alternatively, you can also try a Windows 7 license key (as of 2018/11 they are still accepted for a free upgrade).
|
||||
I first installed Windows and all updates, then entered the license key.
|
||||
|
||||
|
||||
|
||||
- Afterwards:
|
||||
|
||||
- In case you switch from ``sys-network`` to ``sys-whonix``, you’ll need a static IP network configuration, DHCP won’t work for ``sys-whonix``.
|
||||
|
||||
- Use ``powercfg -H off`` and ``disk cleanup`` to save some disk space.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Qubes 4.0 - importing a Windows VM from R3.2
|
||||
--------------------------------------------
|
||||
|
||||
|
||||
Importing should work, simply make sure that you are not using Xen’s newer linux stubdomain and that the VM is in HVM mode (these steps should be done automatically when importing the VM):
|
||||
|
||||
.. code:: bash
|
||||
|
||||
qvm-features VMNAME linux-stubdom ''
|
||||
qvm-prefs VMNAME virt_mode hvm
|
||||
|
||||
|
||||
|
||||
Note however that you are better off creating a new Windows VM to benefit from the more recent emulated hardware: R3.2 uses a MiniOS based stubdomain with an old and mostly unmaintained ‘qemu-traditional’ while R4.0 uses a Linux based stubdomain with a recent version of upstream qemu (see `this post <https://groups.google.com/d/msg/qubes-devel/tBqwJmOAJ94/xmFCGJnuAwAJ>`__).
|
||||
|
||||
Windows qube installation
|
||||
-------------------------
|
||||
|
||||
|
||||
qvm-create-windows-qube
|
||||
^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
|
||||
An unofficial, third-party tool for automating this process is available `here <https://github.com/elliotkillick/qvm-create-windows-qube>`__. (Please note that this tool has not been reviewed by the Qubes OS Project. Use it at your own risk.) However, if you are an expert or want to do it manually you may continue below.
|
||||
|
||||
Summary
|
||||
^^^^^^^
|
||||
|
||||
|
||||
.. code:: bash
|
||||
|
||||
qvm-create --class StandaloneVM --label red --property virt_mode=hvm win7new
|
||||
qvm-prefs win7new memory 4096
|
||||
qvm-prefs win7new maxmem 4096
|
||||
qvm-prefs win7new kernel ''
|
||||
qvm-volume extend win7new:root 25g
|
||||
qvm-prefs win7new debug true
|
||||
qvm-features win7new video-model cirrus
|
||||
qvm-start --cdrom=untrusted:/home/user/windows_install.iso win7new
|
||||
# restart after the first part of the windows installation process ends
|
||||
qvm-start win7new
|
||||
# once Windows is installed and working
|
||||
qvm-prefs win7new memory 2048
|
||||
qvm-prefs win7new maxmem 2048
|
||||
qvm-features --unset win7new video-model
|
||||
qvm-prefs win7new qrexec_timeout 300
|
||||
# with Qubes Windows Tools installed:
|
||||
qvm-prefs win7new debug false
|
||||
|
||||
|
||||
|
||||
To install Qubes Windows Tools, follow instructions in :doc:`Qubes Windows Tools </user/templates/windows/qubes-windows-tools-4-0>`.
|
||||
|
||||
Detailed instructions
|
||||
^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
|
||||
MS Windows versions considerations:
|
||||
|
||||
- The instructions *may* work on other versions than Windows 7 x64 but haven’t been tested.
|
||||
|
||||
- Qubes Windows Tools (QWT) only supports Windows 7 x64. Note that there are `known issues <https://github.com/QubesOS/qubes-issues/issues/3585>`__ with QWT on Qubes 4.x
|
||||
|
||||
- For Windows 10 under Qubes 4.0, a way to install QWT 4.0.1.3, which has worked in several instances, is described in :doc:`Qubes Windows Tools </user/templates/windows/qubes-windows-tools-4-0>`.
|
||||
|
||||
|
||||
|
||||
Create a VM named win7new in :doc:`HVM </user/advanced-topics/standalones-and-hvms>` mode (Xen’s current PVH limitations precludes from using PVH):
|
||||
|
||||
.. code:: bash
|
||||
|
||||
qvm-create --class StandaloneVM --label red --property virt_mode=hvm win7new
|
||||
|
||||
|
||||
|
||||
Windows’ installer requires a significant amount of memory or else the VM will crash with such errors:
|
||||
|
||||
``/var/log/xen/console/hypervisor.log``:
|
||||
|
||||
.. code:: bash
|
||||
|
||||
p2m_pod_demand_populate: Dom120 out of PoD memory! (tot=102411 ents=921600 dom120)
|
||||
(XEN) domain_crash called from p2m-pod.c:1218
|
||||
(XEN) Domain 120 (vcpu#0) crashed on cpu#3:
|
||||
|
||||
|
||||
|
||||
So, increase the VM’s memory to 4096MB (memory = maxmem because we don’t use memory balancing).
|
||||
|
||||
.. code:: bash
|
||||
|
||||
qvm-prefs win7new memory 4096
|
||||
qvm-prefs win7new maxmem 4096
|
||||
|
||||
|
||||
|
||||
Disable direct boot so that the VM will go through the standard cdrom/HDD boot sequence:
|
||||
|
||||
.. code:: bash
|
||||
|
||||
qvm-prefs win7new kernel ''
|
||||
|
||||
|
||||
|
||||
A typical Windows 7 installation requires between 15GB up to 19GB of disk space depending on the version (Home/Professional/…). Windows updates also end up using significant space. So, extend the root volume from the default 10GB to 25GB (note: it is straightforward to increase the root volume size after Windows is installed: simply extend the volume again in dom0 and then extend the system partition with Windows’s disk manager).
|
||||
|
||||
.. code:: bash
|
||||
|
||||
qvm-volume extend win7new:root 25g
|
||||
|
||||
|
||||
|
||||
Set the debug flag in order to have a graphical console:
|
||||
|
||||
.. code:: bash
|
||||
|
||||
qvm-prefs win7new debug true
|
||||
|
||||
|
||||
|
||||
The second part of the installation process will crash with the standard VGA video adapter and the VM will stay in “transient” mode with the following error in ``guest-win7new-dm.log``:
|
||||
|
||||
.. code:: bash
|
||||
|
||||
qemu: /home/user/qubes-src/vmm-xen-stubdom-linux/build/qemu/exec.c:1187: cpu_physical_memory_snapshot_get_dirty: Assertion `start + length <= snap->end' failed.
|
||||
|
||||
|
||||
|
||||
To avoid that error we temporarily have to switch the video adapter to ‘cirrus’:
|
||||
|
||||
.. code:: bash
|
||||
|
||||
qvm-features win7new video-model cirrus
|
||||
|
||||
|
||||
|
||||
The VM is now ready to be started; the best practice is to use an installation ISO :ref:`located in a VM <user/advanced-topics/standalones-and-hvms:installing an os in an hvm>`:
|
||||
|
||||
.. code:: bash
|
||||
|
||||
qvm-start --cdrom=untrusted:/home/user/windows_install.iso win7new
|
||||
|
||||
|
||||
|
||||
Given the higher than usual memory requirements of Windows, you may get a ``Not enough memory to start domain 'win7new'`` error. In that case try to shutdown unneeded VMs to free memory before starting the Windows VM.
|
||||
|
||||
At this point you may open a tab in dom0 for debugging, in case something goes amiss:
|
||||
|
||||
.. code:: bash
|
||||
|
||||
tailf /var/log/qubes/vm-win7new.log \
|
||||
/var/log/xen/console/hypervisor.log \
|
||||
/var/log/xen/console/guest-win7new-dm.log
|
||||
|
||||
|
||||
|
||||
The VM will shutdown after the installer completes the extraction of Windows installation files. It’s a good idea to clone the VM now (eg. ``qvm-clone win7new win7newbkp1``). Then, (re)start the VM with ``qvm-start win7new``.
|
||||
|
||||
The second part of Windows’ installer should then be able to complete successfully. You may then perform the following post-install steps:
|
||||
|
||||
Decrease the VM’s memory to a more reasonable value (memory balancing on Windows is unstable so keep ``memory`` equal to ``maxmen``).
|
||||
|
||||
.. code:: bash
|
||||
|
||||
qvm-prefs win7new memory 2048
|
||||
qvm-prefs win7new maxmem 2048
|
||||
|
||||
|
||||
|
||||
Revert to the standard VGA adapter: the ‘cirrus’ adapter will limit the maximum screen resolution to 1024x768 pixels, while the default VGA adapter allows for much higher resolutions (up to 2560x1600 pixels).
|
||||
|
||||
.. code:: bash
|
||||
|
||||
qvm-features --unset win7new video-model
|
||||
|
||||
|
||||
|
||||
Finally, increase the VM’s ``qrexec_timeout``: in case you happen to get a BSOD or a similar crash in the VM, utilities like chkdsk won’t complete on restart before qrexec_timeout automatically halts the VM. That can really put the VM in a totally unrecoverable state, whereas with higher qrexec_timeout, chkdsk or the appropriate utility has plenty of time to fix the VM. Note that Qubes Windows Tools also require a larger timeout to move the user profiles to the private volume the first time the VM reboots after the tools’ installation.
|
||||
|
||||
.. code:: bash
|
||||
|
||||
qvm-prefs win7new qrexec_timeout 300
|
||||
|
||||
|
||||
|
||||
At that point you should have a functional and stable Windows VM, although without updates, Xen’s PV drivers nor Qubes integration (see sections :ref:`Windows Update <user/templates/windows/windows-qubes-4-0:windows update>` and :ref:`Xen PV drivers and Qubes Windows Tools <user/templates/windows/qubes-windows-tools-4-0:xen pv drivers and qubes windows tools>`). It is a good time to clone the VM again.
|
||||
|
||||
Windows as a template
|
||||
---------------------
|
||||
|
||||
|
||||
Windows 7 and 10 can be installed as TemplateVM by selecting
|
||||
|
||||
.. code:: bash
|
||||
|
||||
qvm-create --class TemplateVM --property virt_mode=HVM --property kernel='' --label black Windows-template
|
||||
|
||||
|
||||
|
||||
when creating the VM. To have the user data stored in AppVMs depending on this template, Windows 7 and 10 have to be treated differently:
|
||||
|
||||
- For Windows 7, the option to move the user directories from drive ``C`` to drive ``D`` works and causes any user data to be stored in the AppVMs based on this template, and not in the template itself.
|
||||
|
||||
- After installation of Windows 10 as a TemplateVM, the Windows disk manager may be used to add the private volume as disk ``D:``, and you may, using the documented Windows operations, move the user directories ``C:\users\<username>\Documents`` to this new disk, allowing depending AppVMs to have their own private volumes. Moving the hidden application directories ``AppData``, however, is likely to invite trouble - the same trouble that occurs if, during QWT installation, the option ``Move user profiles`` is selected.
|
||||
|
||||
|
||||
|
||||
For Windows 10, configuration data like those stored in directories like ``AppData`` still remain in the TemplateVM, such that their changes are lost each time the AppVM shuts down. In order to make permanent changes to these configuration data, they have to be changed in the TemplateVM, meaning that applications have to be started there, which violates and perhaps even endangers the security of the TemplateVM. Such changes should be done only if absolutely necessary and with great care. It is a good idea to test them first in a cloned TemplateVM before applying them in the production VM.
|
||||
|
||||
AppVMs based on these templates can be created the normal way by using the Qube Manager or by specifying
|
||||
|
||||
.. code:: bash
|
||||
|
||||
qvm-create --class=AppVM --template=<VMname>
|
||||
|
||||
|
||||
|
||||
On starting the AppVM, sometimes a message is displayed that the Xen PV Network Class needs to restart the system. This message can be safely ignored and closed by selecting “No”.
|
||||
|
||||
**Caution:** These AppVMs must not be started while the corresponding TemplateVM is running, because they share the TemplateVM’s license data. Even if this could work sometimes, it would be a violation of the license terms.
|
||||
|
||||
Windows 10 Usage According to GDPR
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
|
||||
If Windows 10 is used in the EU to process personal data, according to GDPR no automatic data transfer to countries outside the EU is allowed without explicit consent of the person(s) concerned, or other legal consent, as applicable. Since no reliable way is found to completely control the sending of telemetry from Windows 10, the system containing personal data must be completely shielded from the internet.
|
||||
|
||||
This can be achieved by installing Windows 10 on a TemplateVM with the user data directory moved to a separate drive (usually ``D:``). Personal data must not be stored within the TemplateVM, but only in AppVMs depending on this TemplateVM. Network access by these AppVMs must be restricted to the local network and perhaps additional selected servers within the EU. Any data exchange of the AppVMs must be restricted to file and clipboard operations to and from other VMs in the same Qubes system.
|
||||
|
||||
Windows update
|
||||
--------------
|
||||
|
||||
|
||||
Depending on how old your installation media is, fully updating your Windows VM may take *hours* (this isn’t specific to Xen/Qubes) so make sure you clone your VM between the mandatory reboots in case something goes wrong. This `comment <https://github.com/QubesOS/qubes-issues/issues/3585#issuecomment-366471111>`__ provides useful links on updating a Windows 7 SP1 VM.
|
||||
|
||||
**Note:** if you already have Qubes Windows Tools installed the video adapter in Windows will be “Qubes video driver” and you won’t be able to see the Windows Update process when the VM is being powered off because Qubes services would have been stopped by then. Depending on the size of the Windows update packs it may take a bit of time until the VM shutdowns by itself, leaving one wondering if the VM has crashed or still finalizing the updates (in dom0 a changing CPU usage - eg. shown with ``xentop`` - usually indicates that the VM hasn’t crashed). To avoid guessing the VM’s state enable debugging (``qvm-prefs -s win7new debug true``) and in Windows’ device manager (My computer -> Manage / Device manager / Display adapters) temporarily re-enable the standard VGA adapter and disable “Qubes video driver”. You can disable debugging and revert to Qubes’ display once the VM is updated.
|
||||
|
||||
Further customization
|
||||
---------------------
|
||||
|
||||
|
||||
Please see the `Customizing Windows 7 templates <https://forum.qubes-os.org/t/19005>`__ page (despite the focus on preparing the VM for use as a template, most of the instructions are independent from how the VM will be used - ie. TemplateVM or StandaloneVM).
|
||||
|
|
@ -1,310 +0,0 @@
|
|||
---
|
||||
lang: en
|
||||
layout: doc
|
||||
permalink: /doc/templates/windows/windows-qubes-4-1/
|
||||
redirect_from:
|
||||
- /doc/templates/windows/windows-vm41/
|
||||
- /doc/templates/windows/windows-vm41/
|
||||
title: How to install Windows qubes in Qubes OS
|
||||
---
|
||||
|
||||
You can install Windows just like any other OS as an [HVM](/doc/hvm/), if you just want something simple and you can live without some features. This works for Windows XP, 7, 8.1, 10 and 11.
|
||||
|
||||
Please keep in mind that Qubes Windows Tools are not supported on Windows XP.
|
||||
|
||||
You will get an environment in which basic functions are supported, but integration into the Qubes environment is rather restricted. The following functions will work right out of the box:
|
||||
|
||||
- display (1440x900 or 1280x1024 are a nice fit onto FHD hw display)
|
||||
- keyboard (incl. correct mapping), pointing device
|
||||
- network (emulated Realtek NIC)
|
||||
- audio output and input (available even without QWT installation if `qvm-features audio-model` is set as `ich6`)
|
||||
|
||||
For better integration, a set of drivers and services, called Qubes Windows Tools (QWT) is available. Installation of these tools is straightforward and is described in a [separate document](/doc/templates/windows/qubes-windows-tools-4-1). QWT’s main features are:
|
||||
|
||||
- copy/paste between qubes
|
||||
- copy files between qubes
|
||||
- attaching USB devices to the qube
|
||||
- attaching block devices to the qube (XEN PV disk driver must be installed)
|
||||
- automatically set up networking
|
||||
- automatically set up time/clock synchronization
|
||||
- XEN PV drivers (some of them optional)
|
||||
- optional user migration from `C:` to the qubes’ private volume (to be able use the qubes as a TemplateVM).
|
||||
- seamless mode (Windows 7 only for now)
|
||||
- propagating keyboard layout ?
|
||||
|
||||
## Importing a Windows VM from an earlier version of Qubes
|
||||
|
||||
- Importing from R3.2 or earlier will not work, because Qubes R3.2 has the old stubdomain by default and this is preserved over backup and restore (as Windows otherwise won't boot).
|
||||
|
||||
- Importing from R4.0 should work, see [Migrate backups of Windows VMs created under Qubes R4.0 to R4.1](/doc/templates/windows/migrate-to-4-1).
|
||||
|
||||
|
||||
## Windows VM installation
|
||||
|
||||
**qvm-create-windows-qube**: An unofficial, third-party tool for automating this process is available [here](https://github.com/elliotkillick/qvm-create-windows-qube). (Please note that this tool has not been reviewed by the Qubes OS Project. Use it at your own risk.)
|
||||
|
||||
However, if you are an expert or want to do it manually you may continue below.
|
||||
|
||||
**Notes:**
|
||||
|
||||
- The instructions may work on other versions than Windows 7, 8.1, 10 and 11 x64 but haven't been tested.
|
||||
- Qubes Windows Tools (QWT) only supports Windows 7, 8.1, 10 and 11 x64. For installation, see [Qubes Windows Tools](/doc/templates/windows/qubes-windows-tools-4-1).
|
||||
|
||||
**Provide installation media**
|
||||
|
||||
Have the Windows ISO image (preferrably the 64-bit version) downloaded in some qube.
|
||||
|
||||
Windows ISOs can be downloaded directly from Microsoft (eg. [here](https://www.microsoft.com/en-us/software-download/windows10ISO) for Win10), or selected and downloaded via the [Windows Media Creation Tool](https://go.microsoft.com/fwlink/?LinkId=691209). You should, however, regard the downloaded image to be untrustworthy, since there is no reliable way to check that the download was not somehow compromised (see the discussion in issue [Simplify Qubes Windows Tools Installation for R4.1 #7240](https://github.com/QubesOS/qubes-issues/issues/7240)).
|
||||
|
||||
Unofficial “debloated” ISOs from projects like reviOS 18 or ameliorated 10 can be found on the net, although obviously you should consider them even “unsafer” than MS provided ISOs. Alternatively, one could download an official ISO and run scripts/apply patches before installation. Some of the “tweaks” might end up being too much depending on the qube’s planned usage though (eg. no appx functionality in ameliorated windows - so the installation of Windows Store apps is impossible, even with powershell).
|
||||
|
||||
**Create Windows VM**
|
||||
|
||||
Create a VM named WindowsNew in [HVM](/doc/hvm/) mode (Xen's current PVH limitations precludes from using PVH). This can be done in either of two ways:
|
||||
|
||||
- Using Qube Manager: In order to create the new qube, select the command Qube -> New Qube in the Qube Manager:
|
||||
|
||||
- Name: `WindowsNew`, Color: `orange` (for a standalone qubes, `black` for a template)
|
||||
- Type: `StandaloneVM (fully persistent)` or `TemplateVM (template home, persistent root)`
|
||||
- Template: `(none)`
|
||||
- Networking: `sys-firewall (default)`
|
||||
- Launch settings after creation: check
|
||||
- Click "OK".
|
||||
- Settings:
|
||||
- Basic:
|
||||
- System storage: 60.0+ GB
|
||||
- Advanced:
|
||||
- Include in memory balancing: uncheck
|
||||
- Initial memory: 4096+ MB
|
||||
- Kernel: `(none)`
|
||||
- Mode: `HVM`
|
||||
- Click "Apply".
|
||||
|
||||
After creation, set `qvm-prefs WindowsNew qrexec_timeout 7200` via CLI in a dom0 terminal.
|
||||
|
||||
- Using CLI in a dom0 terminal
|
||||
|
||||
- This can also be done via the following CLI commands in dom0, for a standalone qube:
|
||||
|
||||
~~~
|
||||
qvm-create --class StandaloneVM --label orange --property virt_mode=hvm WindowsNew
|
||||
~~~
|
||||
|
||||
and for a template:
|
||||
|
||||
~~~
|
||||
qvm-create --class TemplateVM --label black --property virt_mode=hvm WindowsNew
|
||||
~~~
|
||||
|
||||
- After creation, set the following parameters via CLI in a dom0 terminal:
|
||||
|
||||
~~~
|
||||
qvm-volume extend WindowsNew:root 60g
|
||||
qvm-prefs WindowsNew memory 4096
|
||||
qvm-prefs WindowsNew maxmem 4096
|
||||
qvm-prefs WindowsNew kernel ''
|
||||
qvm-prefs WindowsNew qrexec_timeout 7200
|
||||
~~~
|
||||
|
||||
These parameters are set for the following reasons:
|
||||
|
||||
- A typical Windows installation requires between 25GB up to 60GB of disk space depending on the version (Home/Professional/...). Windows updates also end up using significant space. So, extend the root volume from the default 10GB to at least 60GB (note: it is straightforward to increase the root volume size after Windows is installed: simply extend the volume again in dom0 and then extend the system partition with Windows's disk manager).
|
||||
|
||||
- Setting memory to 4096MB may work in most cases, but using 6144MB (or even 8192MB) may reduce the likelihood of crashes during installation, especially for Windows 10 or 11. This is important as Windows qubes have to be created without memory balancing, as requested by the parameter settings described above.
|
||||
|
||||
- The Windows' installer requires a significant amount of memory or else the VM will crash with such errors:
|
||||
|
||||
~~~
|
||||
/var/log/xen/console/hypervisor.log:
|
||||
|
||||
p2m_pod_demand_populate: Dom120 out of PoD memory! (tot=102411 ents=921600 dom120)
|
||||
(XEN) domain_crash called from p2m-pod.c:1218
|
||||
(XEN) Domain 120 (vcpu#0) crashed on cpu#3:
|
||||
~~~
|
||||
|
||||
So, increase the VM's memory to 4096MB (memory = maxmem because we don't use memory balancing), or 6144MB / 8192MB, as recommended above.
|
||||
|
||||
- Disable direct boot so that the VM will go through the standard cdrom/HDD boot sequence. This is done by setting the qube's kernel to an empty value.
|
||||
|
||||
- After creating the new qube, increase the VM's `qrexec_timeout`: in case you happen to get a BSOD or a similar crash in the VM, utilities like `chkdsk` won't complete on restart before `qrexec_timeout` automatically halts the VM. That can really put the VM in a totally unrecoverable state, whereas with higher `qrexec_timeout`, `chkdsk` or the appropriate utility has plenty of time to fix the VM. Note that Qubes Windows Tools also require a larger timeout to move the user profiles to the private volume the first time the VM reboots after the tools' installation. So set the parameter via the following CLI command from a dom0 terminal, because the Qube manager does not support this setting:
|
||||
|
||||
~~~
|
||||
qvm-prefs WindowsNew qrexec_timeout 7200
|
||||
~~~
|
||||
|
||||
|
||||
**Start Windows VM**
|
||||
|
||||
- The VM is now ready to be started; the best practice is to use an installation ISO [located in a VM](/doc/standalones-and-hvms/#installing-an-os-in-an-hvm). Now boot the newly created qube from the Windows installation media. In the Qubes Manager:
|
||||
|
||||
- Select the new qube, in this example "WindowsNew".
|
||||
- Switch to the "Advanced" tab.
|
||||
- Click "Boot from CDROM":
|
||||
- "from file in qube":
|
||||
- Select the qube that has the ISO.
|
||||
- Select ISO by clicking "...".
|
||||
- Click "OK" to boot into the windows installer.
|
||||
|
||||
This can also be done via the following CLI command in dom0 (assuming that the Windows installer ISO is stored in the directory `/home/user/` in the AppVM `untrusted`):
|
||||
|
||||
~~~
|
||||
qvm-start --cdrom=untrusted:/home/user/windows_install.iso WindowsNew
|
||||
~~~
|
||||
|
||||
- Install Windows on the new VM
|
||||
|
||||
- At the first start, the Windows logo may be briefly shown, and then a black screen with a blinking cursor may appear and stay for a few minutes. This is normal, and you just have to wait until the installation window appears.
|
||||
- The installation will run mostly as usual, but automatic reboots will halt the qube - just restart it again and again until the installation is finished. Note, however, that for these restarts, the parameter `--cdrom` **must not** be used, because otherwise the installation will start all over.
|
||||
- Install on first disk.
|
||||
- **For Windows 11 only**: Windows 11 requires TPM 2.0, which currently is not supported from Xen. In Order to install Windows 11 under Qubes, the check for TPM in the Windows installer has to be disabled:
|
||||
|
||||
- When the window allowing you to select a Windows version is displayed, **do not select a version and close this window**, but instead type Shift-F10 to open a console window.
|
||||
- Here you type `regedit` to start the registry editor.
|
||||
- There you position to the key `HKEY_LOCAL_MACHINE\SYSTEM\Setup`.
|
||||
- Now create the key `LabConfig`.
|
||||
- Position to this key and create 3 DWORD values called `BypassTPMCheck`, `BypassSecureBootCheck` and `BypassRAMCheck` and set each value to `1`.
|
||||
- Close the registry editor and console windows.
|
||||
- You will then return to the setup, which will continue normally and install Windows 11 without TPM 2.0.
|
||||
<div class="alert alert-warning" role="alert">
|
||||
<i class="fa fa-exclamation-circle"></i>
|
||||
<b>Caution:</b> This temporary patch may cease to work if it so pleases Microsoft sometime. With version 24H2 it is still working.
|
||||
</div>
|
||||
|
||||
- The installation of Windows 11 may require an internet connection to grab a Microsoft ID. Previously, this was true only for the home edition, but since version 24H2, it extends to the Pro edition, too. A workaround to bypass the internet connection requirements of the Windows 11 setup has been published that works for version 21H2 but may be blocked for newer versions:
|
||||
|
||||
- When you reach the “Let’s Connect You To A Network” page, type Shift-F10 to open a console window.
|
||||
- Here you type `taskmgr` to start the Task Manager window so you can see all running processes.
|
||||
- Expand the Task Manager by clicking the “More Details” button, and then find “Network Connection Flow.”
|
||||
- Select this process and then hit the “End Task” button.
|
||||
- Now you can close these newly opened windows and return to the Windows 11 setup, where you will enter local account information.
|
||||
|
||||
- For Windows 11 version 22H2, the following sequence of actions to use a local account instead of a Microsoft account has been published:
|
||||
|
||||
- Enter `no@thankyou.com` (or some other senseless address) as the email address and click `Next` when Windows 11 setup prompts you to log into your Microsoft account.
|
||||
- Enter any text you want in the password field and click `Sign in`. If this method works, you'll get a message saying "Oops, something went wrong."
|
||||
- Click `Next`. A screen appears saying "Who's going to use this device?" This is the local account creation screen.
|
||||
- Enter the username you want to use and click `Next`.
|
||||
- Enter a password and click `Next`. You can leave the field blank but it's not recommended.
|
||||
|
||||
- For version 24H2, the following actions allow you to install Windows 11 with a local account, if the VM is defined, at least temporarily, without a netVM:
|
||||
- After some reboots, the VM will show a window allowing the selection of an installation country. In this window, type Shift-F10 to open a console window.
|
||||
- In this window, type `oobe\bypassnro`. The VM will then reboot and return to the country selection window. The network connection window will now show an option "I don't have internet", allowing you to define a local account.
|
||||
|
||||
- In new preview builds of Windows (26120 and beyond, and eventually the next release version), the `oobe\bypassnro` command has been erased and no longer works. Instead, there's a new command called start `ms-chx:localonly` that does something similar. In this case, proceed as follows:
|
||||
- Follow the Windows 11 install process until you get to the Sign in screen. Here, type Shift-F10 to open a console window.
|
||||
- Enter start `ms-cxh:localonly` at the command prompt.
|
||||
- A "Create a user for this PC" dialog window appears, allowing you to define a local account.
|
||||
|
||||
- On systems shipped with a Windows license, the product key may be read from flash via root in dom0:
|
||||
|
||||
|
||||
`strings < /sys/firmware/acpi/tables/MSDM`
|
||||
|
||||
|
||||
Alternatively, you can also try a Windows 7 license key (as of 2018/11 they are still accepted for a free upgrade to Windows 10).
|
||||
|
||||
- The VM will shutdown after the installer completes the extraction of Windows installation files. It's a good idea to clone the VM now (eg. `qvm-clone WindowsNew WindowsNewbkp1`). Then, (re)start the VM via the Qubes Manager or with `qvm-start WindowsNew` from a dom0 terminal (without the `--cdrom` parameter!).
|
||||
|
||||
The second part of Windows' installer should then be able to complete successfully.
|
||||
|
||||
**After Windows installation**
|
||||
|
||||
- From the Windows command line, disable hibernation in order to avoid incomplete Windows shutdown, which could lead to corruption of the VM's disk.
|
||||
|
||||
~~~
|
||||
powercfg -H off
|
||||
~~~
|
||||
|
||||
Also, recent versions of Windows won’t show the CD-ROM drive after starting the qube with `qvm-start vm --cdrom ...` (or using the GUI). The solution is to disable hibernation in Windows with this command. (That command is included in QWT’s setup but it’s necessary to run it manually in order to be able to open QWT’s setup ISO/CD-ROM in Windows).
|
||||
|
||||
- In case you switch from `sys-firewall` to `sys-whonix`, you'll need a static IP network configuration, DHCP won't work for `sys-whonix`. Sometimes this may also happen if you keep using `sys-firewall`. In both cases, proceed as follows:
|
||||
- Check the IP address allocated to the qube - either from GUI Manager, or via `qvm-ls -n WindowsNew` from a dom0 terminal (E.g. 10.137.0.x with gateway 10.138.y.z).
|
||||
- In the Windows qube, open the Network manager and change the IPv4 configuration of the network interfacefrom "Automatic" to "Manual".
|
||||
- Enter the Address: 10.137.0.x in our example.
|
||||
- Enter the Netmask: 255.255.255.0
|
||||
- Enter the Gateway: 10.138.y.z in our example.
|
||||
- Enter DNS: 10.139.1.1,10.139.1.2 (the Virtual DNS addresses used by Qubes.
|
||||
- Click "Apply". You should now see "Connected".
|
||||
|
||||
- Given the higher than usual memory requirements of Windows, you may get a `Not enough memory to start domain 'WindowsNew'` error. In that case try to shutdown unneeded VMs to free memory before starting the Windows VM.
|
||||
|
||||
|
||||
At this point you may open a tab in dom0 for debugging, in case something goes amiss:
|
||||
|
||||
~~~
|
||||
tailf /var/log/qubes/vm-WindowsNew.log \
|
||||
/var/log/xen/console/hypervisor.log \
|
||||
/var/log/xen/console/guest-WindowsNew-dm.log
|
||||
~~~
|
||||
|
||||
At that point you should have a functional and stable Windows VM, although without updates, Xen's PV drivers nor Qubes integration (see sections [Windows Update](/doc/templates/windows/windows-qubes-4-1/#windows-update) and [Xen PV drivers and Qubes Windows Tools](/doc/templates/windows/qubes-windows-tools-4-1/#xen-pv-drivers-and-qubes-windows-tools)). It is a good time to clone the VM again.
|
||||
|
||||
**Installing Qubes Windows Tools**
|
||||
|
||||
To install Qubes Windows Tools, follow instructions in [Qubes Windows Tools](/doc/templates/windows/qubes-windows-tools-4-1), but don’t forget to `qvm-clone` your qube before you install Qubes Windows Tools (QWT) in case something goes south.
|
||||
|
||||
**Post-install best practices**
|
||||
|
||||
Optimize resources for use in virtual machine as “vanilla” version of Windows are bloated; e.g.:
|
||||
|
||||
- set up Windows for best performance (this pc → advanced settings → …)
|
||||
- think about Windows’ page file: is it needed ? should you set it with a fixed size ? maybe on the private volume ?
|
||||
- disable services you don’t need
|
||||
- disable networking stuff in the network adapter’s setting (eg. link discovery, file and print server, …)
|
||||
- background: set a solid color
|
||||
- …
|
||||
|
||||
For additional information on configuring a Windows qube, see the [Customizing Windows 7 templates](/doc/windows-template-customization/) page (despite the focus on preparing the VM for use as a template, most of the instructions are independent from how the VM will be used - i.e. TemplateVM or StandaloneVM).
|
||||
|
||||
## Windows as a template
|
||||
|
||||
As described above Windows 7, 8.1, 10, and 11 can be installed as TemplateVM. To have the user data stored in AppVMs depending on this template, the user data have to be stored on a private disk named `Q:`. If there is already a disk for user data, possibly called `D:`, it has to be renamed to `Q:`. Otherwise, this disk has to be created via the Windows `diskpart` utility, or the Disk Management administrative function by formatting the qube's private volume and associating the letter `Q:` with it. The volume name is of no importance.
|
||||
|
||||
Moving the user data is not directly possible under Windows, because the directory `C:\Users` is permanently open and thus locked. Qubes Windows Tools provides a function to move these data on Windows reboot when the directory is not yet locked. To use this function, a working version of QWT has to be used (see the documentation on QWT installation). For Qubes R4.2, this is currently the version 4.1.69. There are two possibilities to move the user data to this volume `Q:`.
|
||||
|
||||
- If Qubes Windows Tools is installed, the option `Move User Profiles` has to be selected on the installation. In this case, the user files are moved to the new disk during the reboot at the end of the installation.
|
||||
|
||||
- This can also be accomplished without QWT installation, avoiding the installation of the Xen PV drivers, if the risk of a compromised version of these drivers according to QSB-091 is considered too severe. In this case, the file `relocate_dir.exe` has to be extracted from the QWT installer kit `qubes-tools-x64.msi`, which will be shown as the content of the CDROM made available by starting the Windows qube with the additional option `--install-windows-tools` (see the QWT installation documentation). The installer kit is a specially formatted archive, from which the file `relocate_dir.exe` can be extracted using a utility like 7-Zip. The file has then to be copied to `%windir%\system32`, i.e. usually `C:\Windows\system32`. Furthermore, locate the registry key `HKLM\SYSTEM\CurrentControlSet\Control\Session Manager`, and add the text `relocate_dir.exe C:\Users Q:\Users` as a new line to the `REG_MULTI_SZ` value `\BootExecute` in this key. On rebooting the Windows qube, the user files will be moved to the disk `Q:`, and the additional registry entry will be removed, such that this action occurs only once.
|
||||
|
||||
If the user data have been moved to `Q:`, be sure not to user the option `Move User Profeiles`on subsequent installations of Qubes Windows tools.
|
||||
|
||||
|
||||
AppVMs based on these templates can be created the normal way by using the Qube Manager or by specifying
|
||||
|
||||
~~~
|
||||
qvm-create --class=AppVM --template=<VMname>
|
||||
~~~
|
||||
|
||||
On starting the AppVM, sometimes a message is displayed that the Xen PV Network Class needs to restart the system. This message can be safely ignored and closed by selecting "No".
|
||||
|
||||
**Caution:** These AppVMs must not be started while the corresponding TemplateVM is running, because they share the TemplateVM's license data. Even if this could work sometimes, it would be a violation of the license terms.
|
||||
|
||||
Furthermore, if manual IP setup was used for the template, the IP address selected for the template will also be used for the AppVM, as it inherits this address from the template. Qubes, however, will have assigned a different address to the AppVM, which will have to be changed to that of the template (e.g. 10.137.0.x) so that the AppVM can access the network, via the CLI command in a dom0 terminal:
|
||||
|
||||
~~~
|
||||
qvm-prefs WindowsNew ip 10.137.0.x
|
||||
~~~
|
||||
|
||||
## Windows 10 and 11 Usage According to GDPR
|
||||
|
||||
If Windows 10 or 11 is used in the EU to process personal data, according to GDPR no automatic data transfer to countries outside the EU is allowed without explicit consent of the person(s) concerned, or other legal consent, as applicable. Since no reliable way is found to completely control the sending of telemetry from Windows 10 or 11, the system containing personal data must be completely shielded from the internet.
|
||||
|
||||
This can be achieved by installing Windows 10 or 11 in a TemplateVM with the user data directory moved to a separate drive (usually `Q:`). Personal data must not be stored within the TemplateVM, but only in AppVMs depending on this TemplateVM. Network access by these AppVMs must be restricted to the local network and perhaps additional selected servers within the EU. Any data exchange of the AppVMs must be restricted to file and clipboard operations to and from other VMs in the same Qubes system.
|
||||
|
||||
## Windows update
|
||||
|
||||
Depending on how old your installation media is, fully updating your Windows VM may take *hours* (this isn't specific to Xen/Qubes) so make sure you clone your VM between the mandatory reboots in case something goes wrong. For Windows 7, you may find the necessary updates bundled at [WinFuture Windows 7 SP1 Update Pack 2.107 (Vollversion)](https://10gbit.winfuture.de/9Y6Lemoxl-I1_901xOu6Hg/1648348889/2671/Update%20Packs/2020_01/WinFuture_7SP1_x64_UpdatePack_2.107_Januar_2020-Vollversion.exe). At your own risk you may use such an installation image with bundled updates, but generally we do not recommend this way for security reasons - so, if you do it anyhow, check that you get this image from a source that you trust, which may be quite different from that one named here!
|
||||
|
||||
Note: if you already have Qubes Windows Tools installed the video adapter in Windows will be "Qubes video driver" and you won't be able to see the Windows Update process when the VM is being powered off because Qubes services would have been stopped by then. Depending on the size of the Windows update packs it may take a bit of time until the VM shutdowns by itself, leaving one wondering if the VM has crashed or still finalizing the updates (in dom0 a changing CPU usage - eg. shown with the domains widget in the task bar, or with `xentop` - usually indicates that the VM hasn't crashed).
|
||||
|
||||
To avoid guessing the VM's state enable debugging (`qvm-prefs -s WindowsNew debug true`) and in Windows' device manager (My computer -> Manage / Device manager / Display adapters) temporarily re-enable the standard VGA adapter and disable "Qubes video driver". You can disable debugging and revert to Qubes' display once the VM is updated.
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
**Windows 7 - USB drives are not visible in your domain**
|
||||
|
||||
After Qubes Windows Tools have been installed on your Windows 7 system, please install the [Chipset_Driver_X2NF0_WN_2.1.39.0_A03.EXE driver](https://web.archive.org/web/20221007093126/https://dl.dell.com/FOLDER01557883M/3/Chipset_Driver_X2NF0_WN_2.1.39.0_A03.EXE). Then shut down your domain.
|
||||
|
||||
From now on you should be able to attach your USB drive by passing it from your *Qubes Devices* menu as a *USB device* rather than *Data (Block) Device*
|
||||
|
||||
This procedure has been tested on Windows 7 installed as a TemplateVM. Different combinations (such as StandaloneVM or different Windows versions) have not been tested.
|
||||
443
user/templates/windows/windows-qubes-4-1.rst
Normal file
443
user/templates/windows/windows-qubes-4-1.rst
Normal file
|
|
@ -0,0 +1,443 @@
|
|||
========================================
|
||||
How to install Windows qubes in Qubes OS
|
||||
========================================
|
||||
|
||||
|
||||
You can install Windows just like any other OS as an :doc:`HVM </user/advanced-topics/standalones-and-hvms>`, if you just want something simple and you can live without some features. This works for Windows XP, 7, 8.1, 10 and 11.
|
||||
|
||||
Please keep in mind that Qubes Windows Tools are not supported on Windows XP.
|
||||
|
||||
You will get an environment in which basic functions are supported, but integration into the Qubes environment is rather restricted. The following functions will work right out of the box:
|
||||
|
||||
- display (1440x900 or 1280x1024 are a nice fit onto FHD hw display)
|
||||
|
||||
- keyboard (incl. correct mapping), pointing device
|
||||
|
||||
- network (emulated Realtek NIC)
|
||||
|
||||
- audio output and input (available even without QWT installation if ``qvm-features audio-model`` is set as ``ich6``)
|
||||
|
||||
|
||||
|
||||
For better integration, a set of drivers and services, called Qubes Windows Tools (QWT) is available. Installation of these tools is straightforward and is described in a :doc:`separate document </user/templates/windows/qubes-windows-tools-4-1>`. QWT’s main features are:
|
||||
|
||||
- copy/paste between qubes
|
||||
|
||||
- copy files between qubes
|
||||
|
||||
- attaching USB devices to the qube
|
||||
|
||||
- attaching block devices to the qube (XEN PV disk driver must be installed)
|
||||
|
||||
- automatically set up networking
|
||||
|
||||
- automatically set up time/clock synchronization
|
||||
|
||||
- XEN PV drivers (some of them optional)
|
||||
|
||||
- optional user migration from ``C:`` to the qubes’ private volume (to be able use the qubes as a TemplateVM).
|
||||
|
||||
- seamless mode (Windows 7 only for now)
|
||||
|
||||
- propagating keyboard layout ?
|
||||
|
||||
|
||||
|
||||
Importing a Windows VM from an earlier version of Qubes
|
||||
-------------------------------------------------------
|
||||
|
||||
|
||||
- Importing from R3.2 or earlier will not work, because Qubes R3.2 has the old stubdomain by default and this is preserved over backup and restore (as Windows otherwise won’t boot).
|
||||
|
||||
- Importing from R4.0 should work, see :doc:`Migrate backups of Windows VMs created under Qubes R4.0 to R4.1 </user/templates/windows/migrate-to-4-1>`.
|
||||
|
||||
|
||||
|
||||
Windows VM installation
|
||||
-----------------------
|
||||
|
||||
|
||||
**qvm-create-windows-qube**: An unofficial, third-party tool for automating this process is available `here <https://github.com/elliotkillick/qvm-create-windows-qube>`__. (Please note that this tool has not been reviewed by the Qubes OS Project. Use it at your own risk.)
|
||||
|
||||
However, if you are an expert or want to do it manually you may continue below.
|
||||
|
||||
**Notes:**
|
||||
|
||||
- The instructions may work on other versions than Windows 7, 8.1, 10 and 11 x64 but haven’t been tested.
|
||||
|
||||
- Qubes Windows Tools (QWT) only supports Windows 7, 8.1, 10 and 11 x64. For installation, see :doc:`Qubes Windows Tools </user/templates/windows/qubes-windows-tools-4-1>`.
|
||||
|
||||
|
||||
|
||||
**Provide installation media**
|
||||
|
||||
Have the Windows ISO image (preferrably the 64-bit version) downloaded in some qube.
|
||||
|
||||
Windows ISOs can be downloaded directly from Microsoft (eg. `here <https://www.microsoft.com/en-us/software-download/windows10ISO>`__ for Win10), or selected and downloaded via the `Windows Media Creation Tool <https://go.microsoft.com/fwlink/?LinkId=691209>`__. You should, however, regard the downloaded image to be untrustworthy, since there is no reliable way to check that the download was not somehow compromised (see the discussion in issue `Simplify Qubes Windows Tools Installation for R4.1 #7240 <https://github.com/QubesOS/qubes-issues/issues/7240>`__).
|
||||
|
||||
Unofficial “debloated” ISOs from projects like reviOS 18 or ameliorated 10 can be found on the net, although obviously you should consider them even “unsafer” than MS provided ISOs. Alternatively, one could download an official ISO and run scripts/apply patches before installation. Some of the “tweaks” might end up being too much depending on the qube’s planned usage though (eg. no appx functionality in ameliorated windows - so the installation of Windows Store apps is impossible, even with powershell).
|
||||
|
||||
**Create Windows VM**
|
||||
|
||||
Create a VM named WindowsNew in :doc:`HVM </user/advanced-topics/standalones-and-hvms>` mode (Xen’s current PVH limitations precludes from using PVH). This can be done in either of two ways:
|
||||
|
||||
- Using Qube Manager: In order to create the new qube, select the command Qube -> New Qube in the Qube Manager:
|
||||
|
||||
- Name: ``WindowsNew``, Color: ``orange`` (for a standalone qubes, ``black`` for a template)
|
||||
|
||||
- Type: ``StandaloneVM (fully persistent)`` or ``TemplateVM (template home, persistent root)``
|
||||
|
||||
- Template: ``(none)``
|
||||
|
||||
- Networking: ``sys-firewall (default)``
|
||||
|
||||
- Launch settings after creation: check
|
||||
|
||||
- Click “OK”.
|
||||
|
||||
- Settings:
|
||||
|
||||
- Basic:
|
||||
|
||||
- System storage: 60.0+ GB
|
||||
|
||||
|
||||
|
||||
- Advanced:
|
||||
|
||||
- Include in memory balancing: uncheck
|
||||
|
||||
- Initial memory: 4096+ MB
|
||||
|
||||
- Kernel: ``(none)``
|
||||
|
||||
- Mode: ``HVM``
|
||||
|
||||
|
||||
|
||||
- Click “Apply”.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
After creation, set ``qvm-prefs WindowsNew qrexec_timeout 7200`` via CLI in a dom0 terminal.
|
||||
|
||||
- Using CLI in a dom0 terminal
|
||||
|
||||
- This can also be done via the following CLI commands in dom0, for a standalone qube:
|
||||
|
||||
|
||||
|
||||
.. code:: bash
|
||||
|
||||
qvm-create --class StandaloneVM --label orange --property virt_mode=hvm WindowsNew
|
||||
|
||||
|
||||
and for a template:
|
||||
|
||||
.. code:: bash
|
||||
|
||||
qvm-create --class TemplateVM --label black --property virt_mode=hvm WindowsNew
|
||||
|
||||
|
||||
|
||||
- After creation, set the following parameters via CLI in a dom0 terminal:
|
||||
|
||||
|
||||
|
||||
.. code:: bash
|
||||
|
||||
qvm-volume extend WindowsNew:root 60g
|
||||
qvm-prefs WindowsNew memory 4096
|
||||
qvm-prefs WindowsNew maxmem 4096
|
||||
qvm-prefs WindowsNew kernel ''
|
||||
qvm-prefs WindowsNew qrexec_timeout 7200
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
These parameters are set for the following reasons:
|
||||
|
||||
- A typical Windows installation requires between 25GB up to 60GB of disk space depending on the version (Home/Professional/…). Windows updates also end up using significant space. So, extend the root volume from the default 10GB to at least 60GB (note: it is straightforward to increase the root volume size after Windows is installed: simply extend the volume again in dom0 and then extend the system partition with Windows’s disk manager).
|
||||
|
||||
- Setting memory to 4096MB may work in most cases, but using 6144MB (or even 8192MB) may reduce the likelihood of crashes during installation, especially for Windows 10 or 11. This is important as Windows qubes have to be created without memory balancing, as requested by the parameter settings described above.
|
||||
|
||||
- The Windows’ installer requires a significant amount of memory or else the VM will crash with such errors:
|
||||
|
||||
.. code:: bash
|
||||
|
||||
/var/log/xen/console/hypervisor.log:
|
||||
|
||||
p2m_pod_demand_populate: Dom120 out of PoD memory! (tot=102411 ents=921600 dom120)
|
||||
(XEN) domain_crash called from p2m-pod.c:1218
|
||||
(XEN) Domain 120 (vcpu#0) crashed on cpu#3:
|
||||
|
||||
|
||||
So, increase the VM’s memory to 4096MB (memory = maxmem because we don’t use memory balancing), or 6144MB / 8192MB, as recommended above.
|
||||
|
||||
- Disable direct boot so that the VM will go through the standard cdrom/HDD boot sequence. This is done by setting the qube’s kernel to an empty value.
|
||||
|
||||
- After creating the new qube, increase the VM’s ``qrexec_timeout``: in case you happen to get a BSOD or a similar crash in the VM, utilities like ``chkdsk`` won’t complete on restart before ``qrexec_timeout`` automatically halts the VM. That can really put the VM in a totally unrecoverable state, whereas with higher ``qrexec_timeout``, ``chkdsk`` or the appropriate utility has plenty of time to fix the VM. Note that Qubes Windows Tools also require a larger timeout to move the user profiles to the private volume the first time the VM reboots after the tools’ installation. So set the parameter via the following CLI command from a dom0 terminal, because the Qube manager does not support this setting:
|
||||
|
||||
.. code:: bash
|
||||
|
||||
qvm-prefs WindowsNew qrexec_timeout 7200
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
**Start Windows VM**
|
||||
|
||||
- The VM is now ready to be started; the best practice is to use an installation ISO :ref:`located in a VM <user/advanced-topics/standalones-and-hvms:installing an os in an hvm>`. Now boot the newly created qube from the Windows installation media. In the Qubes Manager:
|
||||
|
||||
- Select the new qube, in this example “WindowsNew”.
|
||||
|
||||
- Switch to the “Advanced” tab.
|
||||
|
||||
- Click “Boot from CDROM”:
|
||||
|
||||
- “from file in qube”:
|
||||
|
||||
- Select the qube that has the ISO.
|
||||
|
||||
- Select ISO by clicking “…”.
|
||||
|
||||
- Click “OK” to boot into the windows installer.
|
||||
|
||||
|
||||
|
||||
|
||||
This can also be done via the following CLI command in dom0 (assuming that the Windows installer ISO is stored in the directory ``/home/user/`` in the AppVM ``untrusted``):
|
||||
|
||||
.. code:: bash
|
||||
|
||||
qvm-start --cdrom=untrusted:/home/user/windows_install.iso WindowsNew
|
||||
|
||||
|
||||
|
||||
- Install Windows on the new VM
|
||||
|
||||
- At the first start, the Windows logo may be briefly shown, and then a black screen with a blinking cursor may appear and stay for a few minutes. This is normal, and you just have to wait until the installation window appears.
|
||||
|
||||
- The installation will run mostly as usual, but automatic reboots will halt the qube - just restart it again and again until the installation is finished. Note, however, that for these restarts, the parameter ``--cdrom`` **must not** be used, because otherwise the installation will start all over.
|
||||
|
||||
- Install on first disk.
|
||||
|
||||
- **For Windows 11 only**: Windows 11 requires TPM 2.0, which currently is not supported from Xen. In Order to install Windows 11 under Qubes, the check for TPM in the Windows installer has to be disabled:
|
||||
|
||||
- When the window allowing you to select a Windows version is displayed, **do not select a version and close this window**, but instead type Shift-F10 to open a console window.
|
||||
|
||||
- Here you type ``regedit`` to start the registry editor.
|
||||
|
||||
- There you position to the key ``HKEY_LOCAL_MACHINE\SYSTEM\Setup``.
|
||||
|
||||
- Now create the key ``LabConfig``.
|
||||
|
||||
- Position to this key and create 3 DWORD values called ``BypassTPMCheck``, ``BypassSecureBootCheck`` and ``BypassRAMCheck`` and set each value to ``1``.
|
||||
|
||||
- Close the registry editor and console windows.
|
||||
|
||||
- You will then return to the setup, which will continue normally and install Windows 11 without TPM 2.0.
|
||||
|
||||
.. warning::
|
||||
|
||||
Caution: This temporary patch may cease to work if it so pleases Microsoft sometime. With version 24H2 it is still working.
|
||||
|
||||
- The installation of Windows 11 may require an internet connection to grab a Microsoft ID. Previously, this was true only for the home edition, but since version 24H2, it extends to the Pro edition, too. A workaround to bypass the internet connection requirements of the Windows 11 setup has been published that works for version 21H2 but may be blocked for newer versions:
|
||||
|
||||
- When you reach the “Let’s Connect You To A Network” page, type Shift-F10 to open a console window.
|
||||
|
||||
- Here you type ``taskmgr`` to start the Task Manager window so you can see all running processes.
|
||||
|
||||
- Expand the Task Manager by clicking the “More Details” button, and then find “Network Connection Flow.”
|
||||
|
||||
- Select this process and then hit the “End Task” button.
|
||||
|
||||
- Now you can close these newly opened windows and return to the Windows 11 setup, where you will enter local account information.
|
||||
|
||||
|
||||
|
||||
- For Windows 11 version 22H2, the following sequence of actions to use a local account instead of a Microsoft account has been published:
|
||||
|
||||
- Enter ``no@thankyou.com`` (or some other senseless address) as the email address and click ``Next`` when Windows 11 setup prompts you to log into your Microsoft account.
|
||||
|
||||
- Enter any text you want in the password field and click ``Sign in``. If this method works, you’ll get a message saying “Oops, something went wrong.”
|
||||
|
||||
- Click ``Next``. A screen appears saying “Who’s going to use this device?” This is the local account creation screen.
|
||||
|
||||
- Enter the username you want to use and click ``Next``.
|
||||
|
||||
- Enter a password and click ``Next``. You can leave the field blank but it’s not recommended.
|
||||
|
||||
|
||||
|
||||
- For version 24H2, the following actions allow you to install Windows 11 with a local account, if the VM is defined, at least temporarily, without a netVM:
|
||||
|
||||
- After some reboots, the VM will show a window allowing the selection of an installation country. In this window, type Shift-F10 to open a console window.
|
||||
|
||||
- In this window, type ``oobe\bypassnro``. The VM will then reboot and return to the country selection window. The network connection window will now show an option “I don’t have internet”, allowing you to define a local account.
|
||||
|
||||
|
||||
|
||||
- In new preview builds of Windows (26120 and beyond, and eventually the next release version), the ``oobe\bypassnro`` command has been erased and no longer works. Instead, there’s a new command called start ``ms-chx:localonly`` that does something similar. In this case, proceed as follows:
|
||||
|
||||
- Follow the Windows 11 install process until you get to the Sign in screen. Here, type Shift-F10 to open a console window.
|
||||
|
||||
- Enter start ``ms-cxh:localonly`` at the command prompt.
|
||||
|
||||
- A “Create a user for this PC” dialog window appears, allowing you to define a local account.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
- On systems shipped with a Windows license, the product key may be read from flash via root in dom0:
|
||||
``strings < /sys/firmware/acpi/tables/MSDM``
|
||||
Alternatively, you can also try a Windows 7 license key (as of 2018/11 they are still accepted for a free upgrade to Windows 10).
|
||||
|
||||
- The VM will shutdown after the installer completes the extraction of Windows installation files. It’s a good idea to clone the VM now (eg. ``qvm-clone WindowsNew WindowsNewbkp1``). Then, (re)start the VM via the Qubes Manager or with ``qvm-start WindowsNew`` from a dom0 terminal (without the ``--cdrom`` parameter!).
|
||||
The second part of Windows’ installer should then be able to complete successfully.
|
||||
|
||||
|
||||
|
||||
**After Windows installation**
|
||||
|
||||
- From the Windows command line, disable hibernation in order to avoid incomplete Windows shutdown, which could lead to corruption of the VM’s disk.
|
||||
|
||||
.. code:: bash
|
||||
|
||||
powercfg -H off
|
||||
|
||||
|
||||
Also, recent versions of Windows won’t show the CD-ROM drive after starting the qube with ``qvm-start vm --cdrom ...`` (or using the GUI). The solution is to disable hibernation in Windows with this command. (That command is included in QWT’s setup but it’s necessary to run it manually in order to be able to open QWT’s setup ISO/CD-ROM in Windows).
|
||||
|
||||
- In case you switch from ``sys-firewall`` to ``sys-whonix``, you’ll need a static IP network configuration, DHCP won’t work for ``sys-whonix``. Sometimes this may also happen if you keep using ``sys-firewall``. In both cases, proceed as follows:
|
||||
|
||||
- Check the IP address allocated to the qube - either from GUI Manager, or via ``qvm-ls -n WindowsNew`` from a dom0 terminal (E.g. 10.137.0.x with gateway 10.138.y.z).
|
||||
|
||||
- In the Windows qube, open the Network manager and change the IPv4 configuration of the network interfacefrom “Automatic” to “Manual”.
|
||||
|
||||
- Enter the Address: 10.137.0.x in our example.
|
||||
|
||||
- Enter the Netmask: 255.255.255.0
|
||||
|
||||
- Enter the Gateway: 10.138.y.z in our example.
|
||||
|
||||
- Enter DNS: 10.139.1.1,10.139.1.2 (the Virtual DNS addresses used by Qubes.
|
||||
|
||||
|
||||
|
||||
- Click “Apply”. You should now see “Connected”.
|
||||
|
||||
|
||||
|
||||
- Given the higher than usual memory requirements of Windows, you may get a ``Not enough memory to start domain 'WindowsNew'`` error. In that case try to shutdown unneeded VMs to free memory before starting the Windows VM.
|
||||
At this point you may open a tab in dom0 for debugging, in case something goes amiss:
|
||||
|
||||
.. code:: bash
|
||||
|
||||
tailf /var/log/qubes/vm-WindowsNew.log \
|
||||
/var/log/xen/console/hypervisor.log \
|
||||
/var/log/xen/console/guest-WindowsNew-dm.log
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
At that point you should have a functional and stable Windows VM, although without updates, Xen’s PV drivers nor Qubes integration (see sections :ref:`Windows Update <user/templates/windows/windows-qubes-4-1:windows update>` and :ref:`Xen PV drivers and Qubes Windows Tools <user/templates/windows/qubes-windows-tools-4-1:xen pv drivers and qubes windows tools>`). It is a good time to clone the VM again.
|
||||
|
||||
**Installing Qubes Windows Tools**
|
||||
|
||||
To install Qubes Windows Tools, follow instructions in :doc:`Qubes Windows Tools </user/templates/windows/qubes-windows-tools-4-1>`, but don’t forget to ``qvm-clone`` your qube before you install Qubes Windows Tools (QWT) in case something goes south.
|
||||
|
||||
**Post-install best practices**
|
||||
|
||||
Optimize resources for use in virtual machine as “vanilla” version of Windows are bloated; e.g.:
|
||||
|
||||
- set up Windows for best performance (this pc → advanced settings → …)
|
||||
|
||||
- think about Windows’ page file: is it needed ? should you set it with a fixed size ? maybe on the private volume ?
|
||||
|
||||
- disable services you don’t need
|
||||
|
||||
- disable networking stuff in the network adapter’s setting (eg. link discovery, file and print server, …)
|
||||
|
||||
- background: set a solid color
|
||||
|
||||
- …
|
||||
|
||||
|
||||
|
||||
For additional information on configuring a Windows qube, see the `Customizing Windows 7 templates <https://forum.qubes-os.org/t/19005>`__ page (despite the focus on preparing the VM for use as a template, most of the instructions are independent from how the VM will be used - i.e. TemplateVM or StandaloneVM).
|
||||
|
||||
Windows as a template
|
||||
---------------------
|
||||
|
||||
|
||||
As described above Windows 7, 8.1, 10, and 11 can be installed as TemplateVM. To have the user data stored in AppVMs depending on this template, the user data have to be stored on a private disk named ``Q:``. If there is already a disk for user data, possibly called ``D:``, it has to be renamed to ``Q:``. Otherwise, this disk has to be created via the Windows ``diskpart`` utility, or the Disk Management administrative function by formatting the qube’s private volume and associating the letter ``Q:`` with it. The volume name is of no importance.
|
||||
|
||||
Moving the user data is not directly possible under Windows, because the directory ``C:\Users`` is permanently open and thus locked. Qubes Windows Tools provides a function to move these data on Windows reboot when the directory is not yet locked. To use this function, a working version of QWT has to be used (see the documentation on QWT installation). For Qubes R4.2, this is currently the version 4.1.69. There are two possibilities to move the user data to this volume ``Q:``.
|
||||
|
||||
- If Qubes Windows Tools is installed, the option ``Move User Profiles`` has to be selected on the installation. In this case, the user files are moved to the new disk during the reboot at the end of the installation.
|
||||
|
||||
- This can also be accomplished without QWT installation, avoiding the installation of the Xen PV drivers, if the risk of a compromised version of these drivers according to QSB-091 is considered too severe. In this case, the file ``relocate_dir.exe`` has to be extracted from the QWT installer kit ``qubes-tools-x64.msi``, which will be shown as the content of the CDROM made available by starting the Windows qube with the additional option ``--install-windows-tools`` (see the QWT installation documentation). The installer kit is a specially formatted archive, from which the file ``relocate_dir.exe`` can be extracted using a utility like 7-Zip. The file has then to be copied to ``%windir%\system32``, i.e. usually ``C:\Windows\system32``. Furthermore, locate the registry key ``HKLM\SYSTEM\CurrentControlSet\Control\Session Manager``, and add the text ``relocate_dir.exe C:\Users Q:\Users`` as a new line to the ``REG_MULTI_SZ`` value ``\BootExecute`` in this key. On rebooting the Windows qube, the user files will be moved to the disk ``Q:``, and the additional registry entry will be removed, such that this action occurs only once.
|
||||
|
||||
|
||||
|
||||
If the user data have been moved to ``Q:``, be sure not to user the option ``Move User Profeiles`` on subsequent installations of Qubes Windows tools.
|
||||
|
||||
AppVMs based on these templates can be created the normal way by using the Qube Manager or by specifying
|
||||
|
||||
.. code:: bash
|
||||
|
||||
qvm-create --class=AppVM --template=<VMname>
|
||||
|
||||
|
||||
|
||||
On starting the AppVM, sometimes a message is displayed that the Xen PV Network Class needs to restart the system. This message can be safely ignored and closed by selecting “No”.
|
||||
|
||||
**Caution:** These AppVMs must not be started while the corresponding TemplateVM is running, because they share the TemplateVM’s license data. Even if this could work sometimes, it would be a violation of the license terms.
|
||||
|
||||
Furthermore, if manual IP setup was used for the template, the IP address selected for the template will also be used for the AppVM, as it inherits this address from the template. Qubes, however, will have assigned a different address to the AppVM, which will have to be changed to that of the template (e.g. 10.137.0.x) so that the AppVM can access the network, via the CLI command in a dom0 terminal:
|
||||
|
||||
.. code:: bash
|
||||
|
||||
qvm-prefs WindowsNew ip 10.137.0.x
|
||||
|
||||
|
||||
|
||||
Windows 10 and 11 Usage According to GDPR
|
||||
-----------------------------------------
|
||||
|
||||
|
||||
If Windows 10 or 11 is used in the EU to process personal data, according to GDPR no automatic data transfer to countries outside the EU is allowed without explicit consent of the person(s) concerned, or other legal consent, as applicable. Since no reliable way is found to completely control the sending of telemetry from Windows 10 or 11, the system containing personal data must be completely shielded from the internet.
|
||||
|
||||
This can be achieved by installing Windows 10 or 11 in a TemplateVM with the user data directory moved to a separate drive (usually ``Q:``). Personal data must not be stored within the TemplateVM, but only in AppVMs depending on this TemplateVM. Network access by these AppVMs must be restricted to the local network and perhaps additional selected servers within the EU. Any data exchange of the AppVMs must be restricted to file and clipboard operations to and from other VMs in the same Qubes system.
|
||||
|
||||
Windows update
|
||||
--------------
|
||||
|
||||
|
||||
Depending on how old your installation media is, fully updating your Windows VM may take *hours* (this isn’t specific to Xen/Qubes) so make sure you clone your VM between the mandatory reboots in case something goes wrong. For Windows 7, you may find the necessary updates bundled at `WinFuture Windows 7 SP1 Update Pack 2.107 (Vollversion) <https://10gbit.winfuture.de/9Y6Lemoxl-I1_901xOu6Hg/1648348889/2671/Update%20Packs/2020_01/WinFuture_7SP1_x64_UpdatePack_2.107_Januar_2020-Vollversion.exe>`__. At your own risk you may use such an installation image with bundled updates, but generally we do not recommend this way for security reasons - so, if you do it anyhow, check that you get this image from a source that you trust, which may be quite different from that one named here!
|
||||
|
||||
**Note:** if you already have Qubes Windows Tools installed the video adapter in Windows will be “Qubes video driver” and you won’t be able to see the Windows Update process when the VM is being powered off because Qubes services would have been stopped by then. Depending on the size of the Windows update packs it may take a bit of time until the VM shutdowns by itself, leaving one wondering if the VM has crashed or still finalizing the updates (in dom0 a changing CPU usage - eg. shown with the domains widget in the task bar, or with ``xentop`` - usually indicates that the VM hasn’t crashed).
|
||||
|
||||
To avoid guessing the VM’s state enable debugging (``qvm-prefs -s WindowsNew debug true``) and in Windows’ device manager (My computer -> Manage / Device manager / Display adapters) temporarily re-enable the standard VGA adapter and disable “Qubes video driver”. You can disable debugging and revert to Qubes’ display once the VM is updated.
|
||||
|
||||
Troubleshooting
|
||||
---------------
|
||||
|
||||
|
||||
**Windows 7 - USB drives are not visible in your domain**
|
||||
|
||||
After Qubes Windows Tools have been installed on your Windows 7 system, please install the `Chipset_Driver_X2NF0_WN_2.1.39.0_A03.EXE driver <https://web.archive.org/web/20221007093126/https://dl.dell.com/FOLDER01557883M/3/Chipset_Driver_X2NF0_WN_2.1.39.0_A03.EXE>`__. Then shut down your domain.
|
||||
|
||||
From now on you should be able to attach your USB drive by passing it from your *Qubes Devices* menu as a *USB device* rather than *Data (Block) Device*
|
||||
|
||||
This procedure has been tested on Windows 7 installed as a TemplateVM. Different combinations (such as StandaloneVM or different Windows versions) have not been tested.
|
||||
|
|
@ -1,19 +0,0 @@
|
|||
---
|
||||
lang: en
|
||||
layout: doc
|
||||
permalink: /doc/templates/windows/
|
||||
redirect_from:
|
||||
- /doc/windows/
|
||||
title: Windows qubes
|
||||
---
|
||||
|
||||
Like any other unmodified OSes, Windows can be installed in Qubes as an [HVM](/doc/standalones-and-hvms/) domain.
|
||||
|
||||
Qubes Windows Tools (QWT) are then usually installed to provide integration with the rest of the Qubes system; they also include Xen's paravirtualized (PV) drivers to increase performance compared to qemu emulated devices. Alternatively, only Xen's PV drivers can be installed if integration with Qubes isn't required or if the tools aren't supported on a given version of Windows. In the latter case, one would have to [enable inter-VM networking](/doc/firewall/#enabling-networking-between-two-qubes) to be able to exchange files with HVMs.
|
||||
|
||||
For more information about Windows VMs in Qubes OS, please see the following external resources:
|
||||
|
||||
* [Installing and Using Windows-based VMs](/doc/templates/windows/windows-qubes-4-1/)
|
||||
* [Installing and Using Qubes Windows Tools](/doc/templates/windows/qubes-windows-tools-4-1/)
|
||||
* [Create a Gaming HVM in Qubes](https://forum.qubes-os.org/t/create-a-gaming-hvm/19000)
|
||||
* [Migrate backups of Windows VMs created under Qubes R4.0 to R4.1](/doc/templates/windows/migrate-to-4-1/)
|
||||
20
user/templates/windows/windows.rst
Normal file
20
user/templates/windows/windows.rst
Normal file
|
|
@ -0,0 +1,20 @@
|
|||
=============
|
||||
Windows qubes
|
||||
=============
|
||||
|
||||
|
||||
Like any other unmodified OSes, Windows can be installed in Qubes as an :doc:`HVM </user/advanced-topics/standalones-and-hvms>` domain.
|
||||
|
||||
Qubes Windows Tools (QWT) are then usually installed to provide integration with the rest of the Qubes system; they also include Xen’s paravirtualized (PV) drivers to increase performance compared to qemu emulated devices. Alternatively, only Xen’s PV drivers can be installed if integration with Qubes isn’t required or if the tools aren’t supported on a given version of Windows. In the latter case, one would have to :ref:`enable inter-VM networking <user/security-in-qubes/firewall:enabling networking between two qubes>` to be able to exchange files with HVMs.
|
||||
|
||||
For more information about Windows VMs in Qubes OS, please see the following external resources:
|
||||
|
||||
- :doc:`Installing and Using Windows-based VMs </user/templates/windows/windows-qubes-4-1>`
|
||||
|
||||
- :doc:`Installing and Using Qubes Windows Tools </user/templates/windows/qubes-windows-tools-4-1>`
|
||||
|
||||
- `Create a Gaming HVM in Qubes <https://forum.qubes-os.org/t/create-a-gaming-hvm/19000>`__
|
||||
|
||||
- :doc:`Migrate backups of Windows VMs created under Qubes R4.0 to R4.1 </user/templates/windows/migrate-to-4-1>`
|
||||
|
||||
|
||||
|
|
@ -1,54 +0,0 @@
|
|||
---
|
||||
lang: en
|
||||
layout: doc
|
||||
permalink: /doc/templates/xfce/
|
||||
redirect_from:
|
||||
- /doc/xfce/
|
||||
- /doc/templates/fedora-xfce/
|
||||
- /en/doc/templates/xfce/
|
||||
- /doc/Templates/Xfce/
|
||||
- /wiki/Templates/Xfce/
|
||||
ref: 222
|
||||
title: Xfce templates
|
||||
---
|
||||
|
||||
If you would like to use Xfce (more lightweight compared to GNOME desktop environment) Linux distribution in your qubes,
|
||||
you can install one of the available Xfce templates for [Fedora](/doc/templates/fedora/), [Debian](/doc/templates/debian/), [Gentoo](/doc/templates/gentoo/) or [CentOS*](/doc/templates/centos/).
|
||||
|
||||
*\* The CentOS version used by this template reached
|
||||
[End-of-Life in June 2024](https://en.wikipedia.org/wiki/CentOS_Stream#Release_history)
|
||||
and is no longer receiving updates. Due to a lack of specific interest
|
||||
at this time a proposal to create a new CentOS 10 template was
|
||||
[declined](https://github.com/QubesOS/qubes-issues/issues/9716).*
|
||||
|
||||
## Installation
|
||||
|
||||
The Fedora Xfce templates can be installed with the following command (where `X` is your desired distro and version number):
|
||||
|
||||
```
|
||||
[user@dom0 ~]$ sudo qubes-dom0-update qubes-template-X-xfce
|
||||
```
|
||||
|
||||
If your desired version is not found, it may still be in [testing](/doc/testing/).
|
||||
You may wish to try again with the testing repository enabled:
|
||||
|
||||
```
|
||||
[user@dom0 ~]$ sudo qubes-dom0-update --enablerepo=qubes-templates-itl-testing qubes-template-X-xfce
|
||||
```
|
||||
|
||||
If you would like to install a community distribution such as Gentoo, try the install command by enabling the community repository:
|
||||
|
||||
```
|
||||
[user@dom0 ~]$ sudo qubes-dom0-update --enablerepo=qubes-templates-community qubes-template-X-xfce
|
||||
```
|
||||
|
||||
If your desired version is not found, it may still be in [testing](/doc/testing/).
|
||||
You may wish to try again with the testing repository enabled:
|
||||
|
||||
```
|
||||
[user@dom0 ~]$ sudo qubes-dom0-update --enablerepo=qubes-templates-community-testing qubes-template-X-xfce
|
||||
```
|
||||
|
||||
The download may take a while depending on your connection speed.
|
||||
|
||||
To reinstall a Xfce template that is already installed in your system, see [How to Reinstall a template](/doc/reinstall-template/).
|
||||
44
user/templates/xfce-templates.rst
Normal file
44
user/templates/xfce-templates.rst
Normal file
|
|
@ -0,0 +1,44 @@
|
|||
==============
|
||||
Xfce templates
|
||||
==============
|
||||
|
||||
|
||||
If you would like to use Xfce (more lightweight compared to GNOME desktop environment) Linux distribution in your qubes, you can install one of the available Xfce templates for :doc:`Fedora </user/templates/fedora/fedora>`, :doc:`Debian </user/templates/debian/debian>`, `Gentoo <https://forum.qubes-os.org/t/19007>`__ or `CentOS* <https://forum.qubes-os.org/t/19006>`__.
|
||||
|
||||
\* *The CentOS version used by this template reached* `End-of-Life in June 2024 <https://en.wikipedia.org/wiki/CentOS_Stream#Release_history>`__ *and is no longer receiving updates. Due to a lack of specific interest at this time a proposal to create a new CentOS 10 template was* `declined <https://github.com/QubesOS/qubes-issues/issues/9716>`__ *.*
|
||||
|
||||
Installation
|
||||
------------
|
||||
|
||||
|
||||
The Fedora Xfce templates can be installed with the following command (where ``X`` is your desired distro and version number):
|
||||
|
||||
.. code:: bash
|
||||
|
||||
[user@dom0 ~]$ sudo qubes-dom0-update qubes-template-X-xfce
|
||||
|
||||
|
||||
If your desired version is not found, it may still be in :doc:`testing </user/downloading-installing-upgrading/testing>`. You may wish to try again with the testing repository enabled:
|
||||
|
||||
.. code:: bash
|
||||
|
||||
[user@dom0 ~]$ sudo qubes-dom0-update --enablerepo=qubes-templates-itl-testing qubes-template-X-xfce
|
||||
|
||||
|
||||
If you would like to install a community distribution such as Gentoo, try the install command by enabling the community repository:
|
||||
|
||||
.. code:: bash
|
||||
|
||||
[user@dom0 ~]$ sudo qubes-dom0-update --enablerepo=qubes-templates-community qubes-template-X-xfce
|
||||
|
||||
|
||||
If your desired version is not found, it may still be in :doc:`testing </user/downloading-installing-upgrading/testing>`. You may wish to try again with the testing repository enabled:
|
||||
|
||||
.. code:: bash
|
||||
|
||||
[user@dom0 ~]$ sudo qubes-dom0-update --enablerepo=qubes-templates-community-testing qubes-template-X-xfce
|
||||
|
||||
|
||||
The download may take a while depending on your connection speed.
|
||||
|
||||
To reinstall a Xfce template that is already installed in your system, see :doc:`How to Reinstall a template </user/how-to-guides/how-to-reinstall-a-template>`.
|
||||
Loading…
Add table
Add a link
Reference in a new issue