diff --git a/user/hardware/certified-hardware/nitropc-pro-2.md b/user/hardware/certified-hardware/nitropc-pro-2.md
index 5ee72bb45..a1572692c 100644
--- a/user/hardware/certified-hardware/nitropc-pro-2.md
+++ b/user/hardware/certified-hardware/nitropc-pro-2.md
@@ -4,6 +4,7 @@ layout: doc
permalink: /doc/certified-hardware/nitropc-pro-2/
title: NitroPC Pro 2
image: /attachment/posts/nitropc-pro.jpg
+ref: 355
---
diff --git a/user/hardware/certified-hardware/nitropc-pro.md b/user/hardware/certified-hardware/nitropc-pro.md
index e05f34fde..d3a65ebc0 100644
--- a/user/hardware/certified-hardware/nitropc-pro.md
+++ b/user/hardware/certified-hardware/nitropc-pro.md
@@ -4,6 +4,7 @@ layout: doc
permalink: /doc/certified-hardware/nitropc-pro/
title: NitroPC Pro
image: /attachment/posts/nitropc-pro.jpg
+ref: 356
---
@@ -16,7 +17,7 @@ image: /attachment/posts/nitropc-pro.jpg
Note: Only the "Dasharo TianoCore UEFI without Measured Boot, without Nitrokey" firmware option is certified. The "HEADS with Measured Boot, requires Nitrokey!" firmware option is not certified.
-The [NitroPC Pro](https://shop.nitrokey.com/shop/product/nitropc-pro-523) is [officially certified](/doc/certified-hardware/) for Qubes OS Release 4.
+The [NitroPC Pro](https://web.archive.org/web/20231027112856/https://shop.nitrokey.com/shop/product/nitropc-pro-523) is [officially certified](/doc/certified-hardware/) for Qubes OS Release 4.
[](https://shop.nitrokey.com/shop/product/nitropc-pro-523)
@@ -39,7 +40,7 @@ The NitroPC Pro also comes with a "Dasharo Entry Subscription," which includes t
- Accesses to the latest firmware releases
- Exclusive newsletter
- Special firmware updates, including early access to updates enhancing privacy, security, performance, and compatibility
-- Early access to new firmware releases for [newly-supported desktop platforms](https://docs.dasharo.com/variants/overview/#desktop) (please see the [roadmap](https://github.com/Dasharo/presentations/blob/main/dug2_dasharo_roadmap.md#dasharo-desktop-roadmap))
+- Early access to new firmware releases for [newly-supported desktop platforms](https://docs.dasharo.com/variants/overview/#desktop) (please see the [roadmap](https://github.com/Dasharo/presentations/blob/8f360b3e82108d1e85585c1c324a28a08dd276a5/dug2_dasharo_roadmap.md))
- Access to the Dasharo Premier Support invite-only live chat channel on the Matrix network, allowing direct access to the Dasharo Team and fellow subscribers with personalized and priority assistance
- Insider's view and influence on the Dasharo feature roadmap for a real impact on Dasharo development
- [Dasharo Tools Suite Entry Subscription](https://docs.dasharo.com/osf-trivia-list/dts/#what-is-dasharo-tools-suite-supporters-entrance) keys
diff --git a/user/hardware/certified-hardware/novacustom-nv41-series.md b/user/hardware/certified-hardware/novacustom-nv41-series.md
index 9592fcd5c..d4600ad56 100644
--- a/user/hardware/certified-hardware/novacustom-nv41-series.md
+++ b/user/hardware/certified-hardware/novacustom-nv41-series.md
@@ -4,6 +4,7 @@ layout: doc
permalink: /doc/certified-hardware/novacustom-nv41-series/
title: NovaCustom NV41 Series
image: /attachment/site/novacustom-nv41-series.png
+ref: 357
---
The [NovaCustom NV41 Series](https://novacustom.com/product/nv41-series/) is [officially certified](/doc/certified-hardware/) for Qubes OS Release 4.
@@ -15,19 +16,23 @@ The [NovaCustom NV41 Series](https://novacustom.com/product/nv41-series/) is [of
The following configuration options are certified for Qubes OS Release 4:
Processor:
+
- Intel Core i5-1240P processor
- Intel Core i7-1260P processor
Memory:
+
- 2 x 16 GB Kingston DDR4 SODIMM 3200 MHz (32 GB total)
- 1 x 32 GB Kingston DDR4 SODIMM 3200 MHz (32 GB total)
- 2 x 32 GB Kingston DDR4 SODIMM 3200 MHz (64 GB total)
M.2 storage chip:
+
- Samsung 980 SSD (all capacities)
- Samsung 980 Pro SSD (all capacities)
Wi-Fi and Bluetooth:
+
- Intel AX-200/201 Wi-Fi module 2976 Mbps, 802.11ax/Wi-Fi 6 + Bluetooth 5.2
- Killer (Intel) Wireless-AX 1675x M.2 Wi-Fi module 802.11ax/Wi-Fi 6E + Bluetooth 5.3
- Blob-free: Qualcomm Atheros QCNFA222 Wi-Fi 802.11a/b/g/n + Bluetooth 4.0
diff --git a/user/hardware/certified-hardware/novacustom-v54-series.md b/user/hardware/certified-hardware/novacustom-v54-series.md
index 448da878f..80487a7dc 100644
--- a/user/hardware/certified-hardware/novacustom-v54-series.md
+++ b/user/hardware/certified-hardware/novacustom-v54-series.md
@@ -4,6 +4,7 @@ layout: doc
permalink: /doc/certified-hardware/novacustom-v54-series/
title: NovaCustom V54 Series
image: /attachment/site/novacustom-v54-series.png
+ref: 358
---
The [NovaCustom V54 Series 14.0 inch coreboot laptop](https://novacustom.com/product/v54-series/) is [officially certified](/doc/certified-hardware/) for Qubes OS Release 4.
diff --git a/user/hardware/certified-hardware/novacustom-v56-series.md b/user/hardware/certified-hardware/novacustom-v56-series.md
index d743d7abd..57f07e78d 100644
--- a/user/hardware/certified-hardware/novacustom-v56-series.md
+++ b/user/hardware/certified-hardware/novacustom-v56-series.md
@@ -4,6 +4,7 @@ layout: doc
permalink: /doc/certified-hardware/novacustom-v56-series/
title: NovaCustom V56 Series
image: /attachment/site/novacustom-v56-series.png
+ref: 359
---
The [NovaCustom V56 Series 16.0 inch coreboot laptop](https://novacustom.com/product/v56-series/) is [officially certified](/doc/certified-hardware/) for Qubes OS Release 4.
diff --git a/user/hardware/certified-hardware/starlabs-starbook.md b/user/hardware/certified-hardware/starlabs-starbook.md
index 2fb274779..3a00ca57a 100644
--- a/user/hardware/certified-hardware/starlabs-starbook.md
+++ b/user/hardware/certified-hardware/starlabs-starbook.md
@@ -4,6 +4,7 @@ layout: doc
permalink: /doc/certified-hardware/starlabs-starbook/
title: Star Labs StarBook
image: /attachment/site/starlabs-starbook.png
+ref: 360
---
The [Star Labs StarBook](https://starlabs.systems/pages/starbook) is [officially certified](/doc/certified-hardware/) for Qubes OS Release 4.
diff --git a/user/hardware/system-requirements.md b/user/hardware/system-requirements.md
index 232d652f9..1afd565f9 100644
--- a/user/hardware/system-requirements.md
+++ b/user/hardware/system-requirements.md
@@ -98,7 +98,7 @@ We recommend consulting these resources when selecting hardware for Qubes OS:
offer significant security advantages over conventional operating systems on
the same hardware.
- Intel maintains a
+ - Intel maintains a
[list](https://www.intel.com/content/www/us/en/support/articles/000022396/processors.html)
of end-of-support dates for its processors. However, this list seems to
include only processors that are no longer supported or will soon no longer
@@ -122,7 +122,7 @@ We recommend consulting these resources when selecting hardware for Qubes OS:
2. The user's OEM, ODM, or MB to provide a suitable BIOS or (U)EFI update for
the user's system.
- Historically, AMD has often been slow to complete step (1), at least for its
+ - Historically, AMD has often been slow to complete step (1), at least for its
client (as opposed to server) platforms [^2]. In some cases, AMD has made fixes
available for its server platforms very shortly after a security embargo was
lifted, but it did not make fixes available for client platforms facing the
@@ -131,11 +131,9 @@ We recommend consulting these resources when selecting hardware for Qubes OS:
designated date.) By contrast, Intel has consistently made fixes available for
new CPU vulnerabilities across its supported platforms very shortly after
security embargoes have been lifted.
-
- Step (2) varies by vendor. Many vendors fail to complete step (2) at all,
+ - Step (2) varies by vendor. Many vendors fail to complete step (2) at all,
while some others take a very long time to complete it.
-
- The bottom line is that Qubes OS **can** run on AMD systems, and the Qubes and
+ - The bottom line is that Qubes OS **can** run on AMD systems, and the Qubes and
Xen security teams do their best to provide security support for AMD systems.
However, without the ability to ship microcode updates, there is only so much
they can do.
diff --git a/user/how-to-guides/backup-emergency-restore-v3.md b/user/how-to-guides/backup-emergency-restore-v3.md
index 2b54406f2..efa42c2ae 100644
--- a/user/how-to-guides/backup-emergency-restore-v3.md
+++ b/user/how-to-guides/backup-emergency-restore-v3.md
@@ -52,11 +52,11 @@ any GNU/Linux system with the following procedure.
[user@restore ~]$ cat backup-header.hmac
(stdin)= 5b266783e116fe3b2601a54c249ca5f5f96d421dfe6828eeaeb2dcd014e9e945c27b3d7b0f952f5d55c927318906d9c360f387b0e1f069bb8195e96543e2969c
- **Note:** The hash values should match. If they do not match, then the
+ - **Note:** The hash values should match. If they do not match, then the
backup file may have been tampered with, or there may have been a storage
error.
- **Note:** If your backup was hashed with a message digest algorithm other
+ - **Note:** If your backup was hashed with a message digest algorithm other
than `sha512`, you must substitute the correct message digest command. This
information is contained in the `backup-header` file (see step 4), however
it is not recommended to open this file until its integrity and
@@ -86,11 +86,11 @@ any GNU/Linux system with the following procedure.
[user@restore vm1]$ cat private.img.000.hmac
(stdin)= cf83e1357eefb8bdf1542850d66d8007d620e4050b5715dc83f4a921d36ce9ce47d0d13c5d85f2b0ff8318d2877eec2f63b931bd47417a81a538327af927da3e
- **Note:** The hash values should match. If they do not match, then the
+ - **Note:** The hash values should match. If they do not match, then the
backup file may have been tampered with, or there may have been a storage
error.
- **Note:** If your backup was hashed with a message digest algorithm other
+ - **Note:** If your backup was hashed with a message digest algorithm other
than `sha512`, you must substitute the correct message digest command. This
information is contained in the `backup-header` file (see step 4). A
complete list of supported message digest algorithms can be found with
@@ -135,7 +135,7 @@ any GNU/Linux system with the following procedure.
10. Success! If you wish to recover data from more than one VM in your backup,
simply repeat steps 5--9 for each additional VM.
- **Note:** You may wish to store a copy of these instructions with your
+ - **Note:** You may wish to store a copy of these instructions with your
Qubes backups in the event that you fail to recall the above procedure
while this web page is inaccessible. All Qubes documentation, including
this page, is available in plain text format in the following Git
diff --git a/user/how-to-guides/backup-emergency-restore-v4.md b/user/how-to-guides/backup-emergency-restore-v4.md
index d4baa698e..e8a61c2fa 100644
--- a/user/how-to-guides/backup-emergency-restore-v4.md
+++ b/user/how-to-guides/backup-emergency-restore-v4.md
@@ -131,10 +131,10 @@ any GNU/Linux system.
scrypt dec -P qubes.xml.000.enc | gzip -d | tar -xv
qubes.xml
- If this pipeline fails, it is likely that the backup is corrupted or has
+ - If this pipeline fails, it is likely that the backup is corrupted or has
been tampered with.
- **Note:** If your backup was compressed with a program other than `gzip`,
+ - **Note:** If your backup was compressed with a program other than `gzip`,
you must substitute the correct compression program in the command above.
This information is contained in `backup-header` (see step 4). For example,
if your backup is compressed with `bzip2`, use `bzip2 -d` instead of `gzip
diff --git a/user/how-to-guides/how-to-back-up-restore-and-migrate.md b/user/how-to-guides/how-to-back-up-restore-and-migrate.md
index 4e8ab787c..42b89edb3 100644
--- a/user/how-to-guides/how-to-back-up-restore-and-migrate.md
+++ b/user/how-to-guides/how-to-back-up-restore-and-migrate.md
@@ -53,44 +53,44 @@ fresh installation.
2. Move the VMs that you want to back up to the right-hand **Selected** column.
VMs in the left-hand **Available** column will not be backed up.
- You may choose whether to compress backups by checking or unchecking the
- **Compress the backup** box. Normally this should be left on unless you have
- a specific reason otherwise.
+ - You may choose whether to compress backups by checking or unchecking the
+ **Compress the backup** box. Normally this should be left on unless you have
+ a specific reason otherwise.
- Once you have selected all desired VMs, click **Next**.
+ - Once you have selected all desired VMs, click **Next**.
3. Select the destination for the backup:
- If you wish to send your backup to a (currently running) VM, select the VM
- in the drop-down box next to **Target app qube**. If you wish to send your
- backup to a [USB mass storage device](/doc/usb/), you can use the directory
- selection widget to mount a connected device (under "Other locations" item
- on the left); or first mount the device in a VM, then select the mount point
- inside that VM as the backup destination.
-
- You must also specify a directory on the device or in the VM, or a command
- to be executed in the VM as a destination for your backup. For example, if
- you wish to send your backup to the `~/backups` folder in the target VM, you
- would simply browse to it using the convenient directory selection dialog
- (`...`) at the right. This destination directory must already exist. If it
- does not exist, you must create it manually prior to backing up.
-
- By specifying the appropriate directory as the destination in a VM, it is
- possible to send the backup directly to, e.g., a USB mass storage device
- attached to the VM. Likewise, it is possible to enter any command as a
- backup target by specifying the command as the destination in the VM. This
- can be used to send your backup directly to, e.g., a remote server using
- SSH.
-
- **Note:** The supplied passphrase is used for **both** encryption/decryption
- and integrity verification.
-
- At this point, you may also choose whether to save your settings by checking
- or unchecking the **Save settings as default backup profile** box.
-
- **Warning: Saving the settings will result in your backup passphrase being
- saved in plaintext in dom0, so consider your threat model before checking
- this box.**
+ - If you wish to send your backup to a (currently running) VM, select the VM
+ in the drop-down box next to **Target app qube**. If you wish to send your
+ backup to a [USB mass storage device](/doc/usb/), you can use the directory
+ selection widget to mount a connected device (under "Other locations" item
+ on the left); or first mount the device in a VM, then select the mount point
+ inside that VM as the backup destination.
+
+ - You must also specify a directory on the device or in the VM, or a command
+ to be executed in the VM as a destination for your backup. For example, if
+ you wish to send your backup to the `~/backups` folder in the target VM, you
+ would simply browse to it using the convenient directory selection dialog
+ (`...`) at the right. This destination directory must already exist. If it
+ does not exist, you must create it manually prior to backing up.
+
+ - By specifying the appropriate directory as the destination in a VM, it is
+ possible to send the backup directly to, e.g., a USB mass storage device
+ attached to the VM. Likewise, it is possible to enter any command as a
+ backup target by specifying the command as the destination in the VM. This
+ can be used to send your backup directly to, e.g., a remote server using
+ SSH.
+
+ - **Note:** The supplied passphrase is used for **both** encryption/decryption
+ and integrity verification.
+
+ - At this point, you may also choose whether to save your settings by checking
+ or unchecking the **Save settings as default backup profile** box.
+
+ - **Warning: Saving the settings will result in your backup passphrase being
+ saved in plaintext in dom0, so consider your threat model before checking
+ this box.**
4. You will now see the summary of VMs to be backed up. If there are any issues
preventing the backup, they will be listed here and the **Next** button
@@ -148,10 +148,10 @@ fresh installation.
a passphrase was supplied during the creation of your backup (regardless of
whether it is encrypted), then you must supply it here.
- **Note:** The passphrase which was supplied when the backup was created is
- used for **both** encryption/decryption and integrity verification. If the
- backup was not encrypted, the supplied passphrase is used only for integrity
- verification. All backups made from a Qubes R4.0 system will be encrypted.
+ - **Note:** The passphrase which was supplied when the backup was created is
+ used for **both** encryption/decryption and integrity verification. If the
+ backup was not encrypted, the supplied passphrase is used only for integrity
+ verification. All backups made from a Qubes R4.0 system will be encrypted.
5. You will now see the summary of VMs to be restored. If there are any issues
preventing the restore, they will be listed here and the **Next** button grayed
@@ -203,23 +203,9 @@ the new machine. All of your settings and data will be preserved!
Here are some things to consider when selecting a passphrase for your backups:
-- If you plan to store the backup for a long time or on third-party servers,
- you should make sure to use a very long, high-entropy passphrase. (Depending
- on the decryption passphrase you use for your system drive, this may
- necessitate selecting a stronger passphrase. If your system drive decryption
- passphrase is already sufficiently strong, it may not.)
-- An adversary who has access to your backups may try to substitute one backup
- for another. For example, when you attempt to retrieve a recent backup, the
- adversary may instead give you a very old backup containing a compromised VM.
- If you're concerned about this type of attack, you may wish to use a
- different passphrase for each backup, e.g., by appending a number or date to
- the passphrase.
-- If you're forced to enter your system drive decryption passphrase in plain
- view of others (where it can be shoulder-surfed), then you may want to use a
- different passphrase for your backups (even if your system drive decryption
- passphrase is already maximally strong). On the other hand, if you're careful
- to avoid shoulder-surfing and/or have a passphrase that's difficult to detect
- via shoulder-surfing, then this may not be a problem for you.
+- If you plan to store the backup for a long time or on third-party servers, you should make sure to use a very long, high-entropy passphrase. (Depending on the decryption passphrase you use for your system drive, this may necessitate selecting a stronger passphrase. If your system drive decryption passphrase is already sufficiently strong, it may not.)
+- An adversary who has access to your backups may try to substitute one backup for another. For example, when you attempt to retrieve a recent backup, the adversary may instead give you a very old backup containing a compromised VM. If you're concerned about this type of attack, you may wish to use a different passphrase for each backup, e.g., by appending a number or date to the passphrase.
+- If you're forced to enter your system drive decryption passphrase in plain view of others (where it can be shoulder-surfed), then you may want to use a different passphrase for your backups (even if your system drive decryption passphrase is already maximally strong). On the other hand, if you're careful to avoid shoulder-surfing and/or have a passphrase that's difficult to detect via shoulder-surfing, then this may not be a problem for you.
## Notes
diff --git a/user/how-to-guides/how-to-copy-from-dom0.md b/user/how-to-guides/how-to-copy-from-dom0.md
index 0aacfcbb3..321bc6801 100644
--- a/user/how-to-guides/how-to-copy-from-dom0.md
+++ b/user/how-to-guides/how-to-copy-from-dom0.md
@@ -15,7 +15,7 @@ title: How to copy from dom0
This page covers copying files and clipboard text between [dom0](/doc/glossary/#dom0) and [domUs](/doc/glossary/#domu).
Since dom0 is special, the processes are different from [copying and pasting text between qubes](/doc/how-to-copy-and-paste-text/) and [copying and moving files between qubes](/doc/how-to-copy-and-move-files/).
-## Copying **from** dom0
+## Copying *from* dom0
### Copying files from dom0
@@ -61,7 +61,7 @@ In order to easily copy/paste the contents of logs from dom0 to the inter-VM cli
You may now paste the log contents in qube as you normally would (e.g., Ctrl+Shift+V, then Ctrl+V).
-## Copying **to** dom0
+## Copying *to* dom0
Copying anything into dom0 is not advised, since doing so can compromise the security of your Qubes system.
For this reason, there is no simple means of copying anything into dom0, unlike [copying from dom0](#copying-from-dom0).
diff --git a/user/how-to-guides/how-to-install-software.md b/user/how-to-guides/how-to-install-software.md
index 685eae60b..e141acc21 100644
--- a/user/how-to-guides/how-to-install-software.md
+++ b/user/how-to-guides/how-to-install-software.md
@@ -165,7 +165,7 @@ Please see [How to Update](/doc/how-to-update/).
In order to protect you from performing risky activities in templates, they do
not have normal network access by default. Instead, templates use an
-[updates-proxy](#updates-proxy)which allows you to install and update software using
+[updates-proxy](#updates-proxy) which allows you to install and update software using
the distribution's package manager over the proxy connection.
**The updates proxy is already set up to work automatically out-of-the-box and
requires no special action from you.**
@@ -453,10 +453,10 @@ these in an app qube you need to take the following steps:
**app qube** launch the Qube Settings. Then go to the Applications tab and
click "Refresh Applications"
- The refresh will take a few minutes; after it's complete the Snap app will
- appear in the app qube's list of available applications. At this point the
- snap will be persistent within the app qube and will receive updates when
- the app qube is running.
+ - The refresh will take a few minutes; after it's complete the Snap app will
+ appear in the app qube's list of available applications. At this point the
+ snap will be persistent within the app qube and will receive updates when
+ the app qube is running.
### Autostarting Installed Applications
diff --git a/user/how-to-guides/how-to-organize-your-qubes.md b/user/how-to-guides/how-to-organize-your-qubes.md
index 947312b96..780f06641 100644
--- a/user/how-to-guides/how-to-organize-your-qubes.md
+++ b/user/how-to-guides/how-to-organize-your-qubes.md
@@ -336,7 +336,7 @@ her setup looks like this:
reports.
- **Two qubes for taxes.** Carol has a [Windows
- qube](https://github.com/Qubes-Community/Contents/blob/master/docs/os/windows/windows.md)
+ qube](/doc/templates/windows/)
for running her Windows-only tax software. She also has an offline vault
where she stores all of her tax-related forms and documents, organized by
year.
diff --git a/user/how-to-guides/how-to-reinstall-a-template.md b/user/how-to-guides/how-to-reinstall-a-template.md
index cc7cce67a..f7d803bf0 100644
--- a/user/how-to-guides/how-to-reinstall-a-template.md
+++ b/user/how-to-guides/how-to-reinstall-a-template.md
@@ -48,14 +48,16 @@ If you want to reinstall more than one template, repeat these instructions for e
1. Clone the existing target template.
- This can be a good idea if you've customized the existing template and want to keep your customizations.
- On the other hand, if you suspect that this template is broken, misconfigured, or compromised, be certain you do not start any VMs using it in the below procedure.
+
+ - This can be a good idea if you've customized the existing template and want to keep your customizations.
+ On the other hand, if you suspect that this template is broken, misconfigured, or compromised, be certain you do not start any VMs using it in the below procedure.
2. Temporarily change all VMs based on the target template to the new clone template, or remove them.
- This can be a good idea if you have user data in these VMs that you want to keep.
- On the other hand, if you suspect that these VMs (or the templates on which they are based) are broken, misconfigured, or compromised, you may want to remove them instead.
- You can do this in Qubes Manager by right-clicking on the VM and clicking **Remove VM**, or you can use the command `qvm-remove
` in dom0.
+
+ - This can be a good idea if you have user data in these VMs that you want to keep.
+ On the other hand, if you suspect that these VMs (or the templates on which they are based) are broken, misconfigured, or compromised, you may want to remove them instead.
+ You can do this in Qubes Manager by right-clicking on the VM and clicking **Remove VM**, or you can use the command `qvm-remove ` in dom0.
3. Uninstall the target template from dom0:
diff --git a/user/how-to-guides/how-to-use-block-storage-devices.md b/user/how-to-guides/how-to-use-block-storage-devices.md
index 5658682af..a46f1a8ed 100644
--- a/user/how-to-guides/how-to-use-block-storage-devices.md
+++ b/user/how-to-guides/how-to-use-block-storage-devices.md
@@ -90,9 +90,9 @@ If you don't see anything that looks like your drive, run `sudo udevadm trigger
qvm-block attach work sys-usb:sdb
```
- This will attach the device to the qube as `/dev/xvdi` if that name is not already taken by another attached device, or `/dev/xvdj`, etc.
+ - This will attach the device to the qube as `/dev/xvdi` if that name is not already taken by another attached device, or `/dev/xvdj`, etc.
- You may also mount one partition at a time by using the same command with the partition number, e.g. `sdb1`.
+ - You may also mount one partition at a time by using the same command with the partition number, e.g. `sdb1`.
3. The block device is now attached to the qube.
If using a default qube, you may open the Nautilus file manager in the qube, and your drive should be visible in the **Devices** panel on the left.
@@ -106,7 +106,7 @@ If you don't see anything that looks like your drive, run `sudo udevadm trigger
4. When you finish using the block device, click the eject button or right-click and select **Unmount**.
- If you've manually mounted a single partition in the above step, use:
+ - If you've manually mounted a single partition in the above step, use:
```
sudo umount mnt
@@ -179,10 +179,10 @@ To attach a file as block device to another qube, first turn it into a loopback
2. If you want to use the GUI, you're done.
Click the Device Manager  and select the `loop0`-device to attach it to another qube.
- If you rather use the command line, continue:
+ - If you rather use the command line, continue:
- In dom0, run `qvm-block` to display known block devices.
- The newly created loop device should show up:
+ - In dom0, run `qvm-block` to display known block devices.
+ The newly created loop device should show up:
```shell_session
~]$ qvm-block
diff --git a/user/how-to-guides/how-to-use-devices.md b/user/how-to-guides/how-to-use-devices.md
index 3b65f1e6a..66269c416 100644
--- a/user/how-to-guides/how-to-use-devices.md
+++ b/user/how-to-guides/how-to-use-devices.md
@@ -26,6 +26,7 @@ In Qubes 3.X, the Qubes VM Manager dealt with attachment as well.
This functionality was moved to the Qubes Device Widget, the tool tray icon with a yellow square located in the top right of your screen by default.
There are currently four categories of devices Qubes understands:
+
- Microphones
- Block devices
- USB devices
@@ -64,7 +65,7 @@ A list of VMs appears, one showing the eject symbol: , however, only one of them can be started at the same time.
-But be careful: There is a [bug in `qvm-device block` or `qvm-block`](https://github.com/QubesOS/qubes-issues/issues/4692) which will allow you to *attach* a block device to two running VMs.
+But be careful: There is a [bug in](https://github.com/QubesOS/qubes-issues/issues/4692) `qvm-device block` or `qvm-block` which will allow you to *attach* a block device to two running VMs.
Don't do that!
diff --git a/user/how-to-guides/how-to-use-disposables.md b/user/how-to-guides/how-to-use-disposables.md
index 2a0f7eaaa..ffd804029 100644
--- a/user/how-to-guides/how-to-use-disposables.md
+++ b/user/how-to-guides/how-to-use-disposables.md
@@ -42,7 +42,7 @@ In Qubes 4.2, the qube will now appear in the menu as a disposable template (in
In Qubes 4.1: named disposables can be created under **Application Menu -> Create Qubes VM**, set the qube type to be _DisposableVM_.
-In Qubes 4.2: named disposables can be created by **Application Menu -> Settings -> Qubes Settings -> Create New Qube**. Set the qube type to Named disposable_
+In Qubes 4.2: named disposables can be created by **Application Menu -> Settings -> Qubes Settings -> Create New Qube**. Set the qube type to **Named disposable**.
## Security
@@ -171,6 +171,7 @@ In dom0, add the following line at the beginning of the file `/etc/qubes-rpc/pol
~~~
This line means:
+
- FROM: Any qube
- TO: A disposable based on ``
- WHAT: Allow sending an "Open URL" request
diff --git a/user/how-to-guides/how-to-use-pci-devices.md b/user/how-to-guides/how-to-use-pci-devices.md
index be70e0056..9552cfc69 100644
--- a/user/how-to-guides/how-to-use-pci-devices.md
+++ b/user/how-to-guides/how-to-use-pci-devices.md
@@ -45,7 +45,7 @@ There you can attach PCI-devices to a qube.
1. To reach the settings of any qube either
- - Press Alt+F3 to open the application finder, type in the VM name, select the "\[VM-name\]: Qube Settings" menu entry and press enter or click "Launch"!
+ - Press Alt+F3 to open the application finder, type in the VM name, select the  `[VM-name]: Qube Settings` menu entry and press enter or click `Launch`!
- Select the VM in Qube Manager and click the settings-button or right-click the VM and select `Qube settings`.
- Click the Domain Manager, hover the VM you want to attach a device to and select "settings" in the additional menu. (only running VMs!)
diff --git a/user/reference/glossary.md b/user/reference/glossary.md
index df3009b68..6c63617a4 100644
--- a/user/reference/glossary.md
+++ b/user/reference/glossary.md
@@ -144,7 +144,7 @@ its net qube.
## policies
-In Qubes OS, "policies" govern interactions between qubes, powered by [Qubes' qrexec system](https://www.qubes-os.org/doc/qrexec/).
+In Qubes OS, "policies" govern interactions between qubes, powered by [Qubes' qrexec system](/doc/qrexec/).
A single policy is a rule applied to a qube or set of qubes, that governs how and when information or assets may be shared with other qubes.
An example is the rules governing how files can be copied between qubes.
Policy rules are grouped together in files under `/etc/qubes/policy.d`
diff --git a/user/security-in-qubes/anti-evil-maid.md b/user/security-in-qubes/anti-evil-maid.md
index 0bcf09645..e9b3f205b 100644
--- a/user/security-in-qubes/anti-evil-maid.md
+++ b/user/security-in-qubes/anti-evil-maid.md
@@ -43,7 +43,7 @@ Security Considerations
However, in its default configuration, installing and using AEM requires attaching a USB drive (i.e., [mass storage device](https://en.wikipedia.org/wiki/USB_mass_storage_device_class)) directly to dom0.
(The other option is to install AEM to an internal disk.
However, this carries significant security implications, as explained [here](https://blog.invisiblethings.org/2011/09/07/anti-evil-maid.html).) This presents us with a classic security trade-off: each Qubes user must make a choice between protecting dom0 from a potentially malicious USB drive, on the one hand, and protecting the system from Evil Maid attacks, on the other hand.
-Given the practical feasibility of attacks like [BadUSB](https://srlabs.de/badusb/) and revelations regarding pervasive government hardware backdoors, this is no longer a straightforward decision.
+Given the practical feasibility of attacks like [BadUSB](https://web.archive.org/web/20160304013434/https://srlabs.de/badusb/) and revelations regarding pervasive government hardware backdoors, this is no longer a straightforward decision.
New, factory-sealed USB drives cannot simply be assumed to be "clean" (e.g., to have non-malicious microcontroller firmware).
Therefore, it is up to each individual Qubes user to evaluate the relative risk of each attack vector against his or her security model.
diff --git a/user/security-in-qubes/data-leaks.md b/user/security-in-qubes/data-leaks.md
index 51c81201d..a341143e4 100644
--- a/user/security-in-qubes/data-leaks.md
+++ b/user/security-in-qubes/data-leaks.md
@@ -48,9 +48,9 @@ Such attacks have been described in the academic literature, but it is doubtful
3. **Unintentional leaks.** Non-malicious software which is either buggy or doesn't maintain the privacy of user data, whether by design or accident.
For example, software which automatically sends error reports to a remote server, where these reports contain details about the system which the user did not want to share.
- Both Qubes firewall and an empty NetVM (i.e., setting the NetVM of an app qube to "none") can fully protect against leaks of type 3.
- However, neither Qubes firewall nor an empty NetVM are guaranteed to protect against leaks of types 1 and 2.
- There are few effective, practical policy measures available to end-users today to stop the leaks of type 1.
- It is likely that the only way to fully protect against leaks of type 2 is to either pause or shut down all other VMs while performing sensitive operations in the target VM(s) (such as key generation).
+Both Qubes firewall and an empty NetVM (i.e., setting the NetVM of an app qube to "none") can fully protect against leaks of type 3.
+However, neither Qubes firewall nor an empty NetVM are guaranteed to protect against leaks of types 1 and 2.
+There are few effective, practical policy measures available to end-users today to stop the leaks of type 1.
+It is likely that the only way to fully protect against leaks of type 2 is to either pause or shut down all other VMs while performing sensitive operations in the target VM(s) (such as key generation).
For further discussion, see [this thread](https://groups.google.com/d/topic/qubes-users/t0cmNfuVduw/discussion).
diff --git a/user/security-in-qubes/firewall.md b/user/security-in-qubes/firewall.md
index 5af06ec4c..272eab361 100644
--- a/user/security-in-qubes/firewall.md
+++ b/user/security-in-qubes/firewall.md
@@ -14,7 +14,7 @@ title: Firewall
Introduction
----------------------------------
This page explains use of the firewall in Qubes 4.2, using `nftables`.
-In Qubes 4.1, all firewall components used `iptables`. For details of that usage see [here](../firewall_4.1/)
+In Qubes 4.1, all firewall components used `iptables`. For details of that usage see [here](../firewall_4.1/).
Understanding firewalling in Qubes
@@ -165,7 +165,7 @@ Consider the following example. `mytcp-service` qube has a TCP service running o
[user@untrusted #]$ qvm-connect-tcp 444:@default:444
~~~
-> Note: The syntax is the same as SSH tunnel handler. The first `444` correspond to the localport destination of `untrusted`, `@default` the remote machine and the second `444` to the remote machine port.
+- **Note:** The syntax is the same as SSH tunnel handler. The first `444` correspond to the localport destination of `untrusted`, `@default` the remote machine and the second `444` to the remote machine port.
The service of `mytcp-service` running on port `444` is now accessible in `untrusted` as `localhost:444`.
@@ -263,9 +263,9 @@ In order to allow a service present in a qube to be exposed to the outside world
As an example we can take the use case of qube QubeDest running a web server listening on port 443 that we want to expose on our physical interface ens6, but only to our local network 192.168.x.y/24.
-> Note: To have all interfaces available and configured, make sure the 3 qubes are up and running
+- **Note:** To have all interfaces available and configured, make sure the 3 qubes are up and running
-> Note: [Issue #4028](https://github.com/QubesOS/qubes-issues/issues/4028) discusses adding a command to automate exposing the port.
+- **Note:** [Issue #4028](https://github.com/QubesOS/qubes-issues/issues/4028) discusses adding a command to automate exposing the port.
**1. Identify the IP addresses you will need to use for sys-net, sys-firewall and the destination qube.**
@@ -279,7 +279,7 @@ Only the first method can be used for `sys-net` to find the external IP:
Note the IP addresses you will need, they will be required in the next steps.
-> Note: The vifx.0 interface is the one used by qubes connected to this netvm so it is _not_ an outside world interface.
+- **Note:** The vifx.0 interface is the one used by qubes connected to this netvm so it is _not_ an outside world interface.
**2. Route packets from the outside world to the FirewallVM**
@@ -296,9 +296,9 @@ In the sys-net VM's Terminal, the first step is to define an nftables chain that
nft add chain qubes custom-dnat-qubeDEST '{ type nat hook prerouting priority filter +1 ; policy accept; }'
```
-> Note: the name `custom-dnat-qubeDST` is arbitrary
+- **Note:** the name `custom-dnat-qubeDST` is arbitrary
-> Note: while we use a DNAT chain for a single qube, it's possible to have a single DNAT chain for multiple qubes
+- **Note:** while we use a DNAT chain for a single qube, it's possible to have a single DNAT chain for multiple qubes
Second step, code a natting firewall rule to route traffic on the outside interface for the service to the sys-firewall VM
@@ -312,8 +312,9 @@ Third step, code the appropriate new filtering firewall rule to allow new connec
nft add rule qubes custom-forward iifname ens6 ip saddr 192.168.x.y/24 ip daddr 10.137.1.z tcp dport 443 ct state new,established,related counter accept
```
-> Note: If you do not wish to limit the IP addresses connecting to the service, remove `ip saddr 192.168.x.y/24` from the rules
-> If you want to expose the service on multiple interfaces, repeat steps 2 and 3 above, for each interface. Alternatively, you can leave out the interface completely.
+- **Note:** If you do not wish to limit the IP addresses connecting to the service, remove `ip saddr 192.168.x.y/24` from the rules.
+
+- If you want to expose the service on multiple interfaces, repeat steps 2 and 3 above, for each interface. Alternatively, you can leave out the interface completely.
Verify the rules on the sys-net firewall correctly match the packets you want by looking at the counters: check for the counter lines in the chains `custom-forward` and `custom-dnat-qubeDEST`:
@@ -387,7 +388,7 @@ Third step, code the appropriate new filtering firewall rule to allow new connec
nft add rule qubes custom-forward iifgroup 1 ip saddr 192.168.x.y/24 ip daddr 10.137.0.xx tcp dport 443 ct state new,established,related counter accept
```
-> Note: If you do not wish to limit the IP addresses connecting to the service, remove `ip saddr 192.168.x.y/24` from the rules
+- **Note:** If you do not wish to limit the IP addresses connecting to the service, remove `ip saddr 192.168.x.y/24` from the rules
Once you have confirmed that the counters increase, store these commands in the script `/rw/config/qubes-firewall-user-script`
diff --git a/user/security-in-qubes/firewall_4.1.md b/user/security-in-qubes/firewall_4.1.md
index 5c00c9f90..7da45432e 100644
--- a/user/security-in-qubes/firewall_4.1.md
+++ b/user/security-in-qubes/firewall_4.1.md
@@ -10,8 +10,7 @@ title: Firewall 4.1
Introduction
----------------------------------
This page explains use of the firewall in Qubes 4.1, using `iptables`.
-From Qubes 4.2, all firewall components use `nftables`. For details of that usage see [here](../firewall/)
-
+From Qubes 4.2, all firewall components use `nftables`. For details of that usage see [here](../firewall/).
Understanding firewalling in Qubes
----------------------------------
@@ -60,14 +59,10 @@ Reconnecting qubes after a NetVM reboot
Normally Qubes doesn't let the user stop a NetVM if there are other qubes running which use it as their own NetVM.
But in case the NetVM stops for whatever reason (e.g. it crashes, or the user forces its shutdown via qvm-kill via terminal in Dom0), Qubes R4.0 will often automatically repair the connection.
-If it does not, then there is an easy way to restore the connection to the NetVM by issuing in dom0:
-
-` qvm-prefs netvm `
+If it does not, then there is an easy way to restore the connection to the NetVM by issuing in dom0: `qvm-prefs netvm `
Normally qubes do not connect directly to the actual NetVM which has networking devices, but rather to the default sys-firewall first, and in most cases it would be the NetVM that will crash, e.g. in response to S3 sleep/restore or other issues with WiFi drivers.
-In that case it is only necessary to issue the above command once, for the sys-firewall (this assumes default VM-naming used by the default Qubes installation):
-
-` qvm-prefs sys-firewall netvm sys-net `
+In that case it is only necessary to issue the above command once, for the sys-firewall (this assumes default VM-naming used by the default Qubes installation): `qvm-prefs sys-firewall netvm sys-net`
Network service qubes
---------------------
@@ -90,7 +85,7 @@ The sys-firewall-2 proxy ensures that:
If you adopt this model, you should be aware that all traffic will arrive at the `network service qube` appearing to originate from the IP address of `sys-firewall-2`.
-For the VPN service please also look at the [VPN documentation](https://github.com/Qubes-Community/Contents/blob/master/docs/configuration/vpn.md).
+For the VPN service please also look at the [VPN documentation](https://forum.qubes-os.org/t/configuring-a-proxyvm-vpn-gateway/19061).
Enabling networking between two qubes
-------------------------------------
@@ -155,11 +150,10 @@ Consider the following example. `mytcp-service` qube has a TCP service running o
- In untrusted, use the Qubes tool `qvm-connect-tcp`:
- ~~~
+ ```
[user@untrusted #]$ qvm-connect-tcp 444:@default:444
- ~~~
-
-> Note: The syntax is the same as SSH tunnel handler. The first `444` correspond to the localport destination of `untrusted`, `@default` the remote machine and the second `444` to the remote machine port.
+ ```
+- **Note:** The syntax is the same as SSH tunnel handler. The first `444` correspond to the localport destination of `untrusted`, `@default` the remote machine and the second `444` to the remote machine port.
The service of `mytcp-service` running on port `444` is now accessible in `untrusted` as `localhost:444`.
@@ -257,15 +251,16 @@ In order to allow a service present in a qube to be exposed to the outside world
As an example we can take the use case of a web server listening on port 443 that we want to expose on our physical interface eth0, but only to our local network 192.168.x.0/24.
-> Note: To have all interfaces available and configured, make sure the 3 qubes are up and running
+ - **Note:** To have all interfaces available and configured, make sure the 3 qubes are up and running
-> Note: [Issue #4028](https://github.com/QubesOS/qubes-issues/issues/4028) discusses adding a command to automate exposing the port.
+ - **Note:** [Issue #4028](https://github.com/QubesOS/qubes-issues/issues/4028) discusses adding a command to automate exposing the port.
**1. Identify the IP addresses you will need to use for sys-net, sys-firewall and the destination qube.**
You can get this information from the Settings Window for the qube, or by running this command in each qube:
`ifconfig | grep -i cast `
Note the IP addresses you will need.
+
> Note: The vifx.0 interface is the one used by qubes connected to this netvm so it is _not_ an outside world interface.
**2. Route packets from the outside world to the FirewallVM**
@@ -280,23 +275,23 @@ iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 443 -d 192.168.x.y -j DNAT
Code the appropriate new filtering firewall rule to allow new connections for the service
-```
-iptables -I FORWARD 2 -i eth0 -d 10.137.1.z -p tcp --dport 443 -m conntrack --ctstate NEW -j ACCEPT
-```
+ ```
+ iptables -I FORWARD 2 -i eth0 -d 10.137.1.z -p tcp --dport 443 -m conntrack --ctstate NEW -j ACCEPT
+ ```
-> If you want to expose the service on multiple interfaces, repeat the steps described in part 1 for each interface.
-> In Qubes R4, at the moment ([QubesOS/qubes-issues#3644](https://github.com/QubesOS/qubes-issues/issues/3644)), nftables is also used which imply that additional rules need to be set in a `qubes-firewall` nft table with a forward chain.
+ - If you want to expose the service on multiple interfaces, repeat the steps described in part 1 for each interface.
+ - In Qubes R4, at the moment ([QubesOS/qubes-issues#3644](https://github.com/QubesOS/qubes-issues/issues/3644)), nftables is also used which imply that additional rules need to be set in a `qubes-firewall` nft table with a forward chain.
`nft add rule ip qubes-firewall forward meta iifname eth0 ip daddr 10.137.1.z tcp dport 443 ct state new counter accept`
Verify you are cutting through the sys-net VM firewall by looking at its counters (column 2)
-```
-iptables -t nat -L -v -n
-iptables -L -v -n
-```
+ ```
+ iptables -t nat -L -v -n
+ iptables -L -v -n
+ ```
+ - **Note:** On Qubes R4, you can also check the nft counters
-> Note: On Qubes R4, you can also check the nft counters
```
nft list table ip qubes-firewall
@@ -358,7 +353,9 @@ if ! iptables -w -n -L FORWARD | grep --quiet MY-HTTPS; then
fi
~~~
-> Note: Again in R4 the following needs to be added:
+
+ - **Note:** Again in R4 the following needs to be added:
+
~~~
#############
@@ -389,9 +386,9 @@ Code the appropriate new filtering firewall rule to allow new connections for th
iptables -I FORWARD 2 -i eth0 -s 192.168.x.0/24 -d 10.137.0.xx -p tcp --dport 443 -m conntrack --ctstate NEW -j ACCEPT
```
-> Note: If you do not wish to limit the IP addresses connecting to the service, remove the ` -s 192.168.0.1/24 `
+ - **Note:** If you do not wish to limit the IP addresses connecting to the service, remove the ` -s 192.168.0.1/24 `
-> Note: On Qubes R4
+ - **Note:** On Qubes R4
```
nft add rule ip qubes-firewall forward meta iifname eth0 ip saddr 192.168.x.0/24 ip daddr 10.137.0.xx tcp dport 443 ct state new counter accept
diff --git a/user/security-in-qubes/mfa.md b/user/security-in-qubes/mfa.md
index af034e714..9ea5b532c 100644
--- a/user/security-in-qubes/mfa.md
+++ b/user/security-in-qubes/mfa.md
@@ -46,7 +46,7 @@ and then use it as an additional factor to login to your Qubes system.
google-authenticator
```
-3. Walk through the setup instructions 2 which will also generate your QR code for your auth app of choice:
+3. Walk through the setup instructions which will also generate your QR code for your auth app of choice:
```
Do you want me to update your “/home/user/.google_authenticator” file (y/n) y
@@ -60,7 +60,7 @@ and then use it as an additional factor to login to your Qubes system.
> **Warning**: in the next session if incorrectly performed, there is the risk of locking yourself out. Before procedding ensure that you have an up-to-date backup.
>
-> For advanced users, to make sure you can quickly recover, you can also open another loging session in a tty. To do this, you do ctrl+alt+F2 and login normally. Should anything go wrong, as long as you don't shut the computer down, you can still access this tty by entering the same key combination and reverting the changes. After you've opened this "backup" login, you can get to your graphical desktop with ctrl+alt+F1.
+> For advanced users, to make sure you can quickly recover, you can also open another loging session in a tty. To do this, you do `ctrl` + `alt` + `F2` and login normally. Should anything go wrong, as long as you don't shut the computer down, you can still access this tty by entering the same key combination and reverting the changes. After you've opened this "backup" login, you can get to your graphical desktop with `ctrl` + `alt` + `F1`.
Now we are going to add the authenticator as a login requirement:
@@ -89,7 +89,7 @@ Now we are going to add the authenticator as a login requirement:
sudo authselect select custom/mfa
```
-Now you can test by locking the screen with ctrl+alt+l. If it was successful and you are pleased with the results, restart your computer.
+Now you can test by locking the screen with `ctrl` + `alt` + `l` . If it was successful and you are pleased with the results, restart your computer.
**Note**: When logging in. the first thing you put is the TOTP secret and then the password. This is true in the screen locker and as well as the session manager (the login window that shows right after you put the disk encryption passphrase).
@@ -99,12 +99,12 @@ After this is done, its recommended to do a backup. This is because as long as y
The following assumes you haven't restarted your computer since setting up TOTP secret.
-1. Switch to TTY2 with ctrl+alt+F2.
+1. Switch to TTY2 with `ctrl` + `alt` + `F2` .
2. Revert to the original policy with:
```
sudo authselect select sssd
```
-3. Switch back to the graphical desktop with ctrl+alt+F1. You should be able to login normally (without multi-factor authentication).
+3. Switch back to the graphical desktop with `ctrl` + `alt` + `F1` . You should be able to login normally (without multi-factor authentication).
4. Change the mfa custom policy and apply it again.
#### Lost TOTP / authentication device?
@@ -120,7 +120,8 @@ The second option is recovery from a backup. It will work as long as you include
The YubiKey / NitroKey3 is a hardware authentication device manufactured by Yubico / NitroKey
to protect access to computers, networks, and online services that supports
one-time passwords (OTP), public-key cryptography, and authentication, and the
-Universal 2nd Factor (U2F) and FIDO2 protocols[1] developed by the FIDO Alliance.
+Universal 2nd Factor [(U2F)](https://en.wikipedia.org/wiki/Universal_2nd_Factor)
+and FIDO2 protocols developed by the [FIDO Alliance](https://en.wikipedia.org/wiki/FIDO_Alliance).
You can use a YubiKey / NitroKey3 to enhance the user authentication in Qubes. The following
instructions explain how to setup the YubiKey / NitroKey3 as an *additional* way to login.
@@ -157,26 +158,28 @@ Note that setting up both a YubiKey and a NitroKey3 is not supported.
1. Install YubiKey / NitroKey3 software in the template on which your USB VM is based.
Without this software the challenge-response / HOTP mechanism won't work.
- **YubiKey**
+ - **YubiKey**
- For Fedora.
+ - For Fedora.
- ```
- sudo dnf install ykpers
- ```
+ ```
+ sudo dnf install ykpers
+ ```
- For Debian.
+ - For Debian.
- ```
- sudo apt-get install yubikey-personalization
- ```
+ ```
+ sudo apt-get install yubikey-personalization
+ ```
- **NitroKey3**
+ - **NitroKey3**
- Follow the installation instructions on the official [NitroKey
+
+ - Follow the installation instructions on the official [NitroKey
website](https://docs.nitrokey.com/software/nitropy/all-platforms/installation).
+
- **WARNING**: *as of April 2024 the official instructions involve using pipx to
+ - **WARNING**: *as of April 2024 the official instructions involve using pipx to
install the pynitrokey package and its dependencies without any GPG
verification! This is not a recommended practice, but will soon be
fixed by NitroKey when they start providing release artifacts with
@@ -184,10 +187,12 @@ website](https://docs.nitrokey.com/software/nitropy/all-platforms/installation).
Proper packaging and distribution for Debian and perhaps Fedora is
also planned for the mid-long term.*
**Installing packages using pip or pipx is not recommended!**
-
- **both**
- Shut down your template. Then, either reboot your USB VM (so changes inside
+
+ - **both**
+
+
+ - Shut down your template. Then, either reboot your USB VM (so changes inside
the template take effect in your USB app qube) or install the packages inside
your USB VM as well if you would like to avoid rebooting it.
@@ -199,64 +204,72 @@ website](https://docs.nitrokey.com/software/nitropy/all-platforms/installation).
```
3. Configure your YubiKey / NitroKey3:
+
- **YubiKey**
+ - **YubiKey**
+
- Configure your YubiKey for challenge-response `HMAC-SHA1` mode. This can be
+ - Configure your YubiKey for challenge-response `HMAC-SHA1` mode. This can be
done on any qube, e.g. a disposable (you need to [attach the
YubiKey](https://www.qubes-os.org/doc/how-to-use-usb-devices/) to this app qube
-though) or directly on the sys-usb vm.
-
- You need to (temporarily) install the package "yubikey-personalization-gui" and
+though) or directly on the sys-usb vm. You need to (temporarily) install the package "yubikey-personalization-gui" and
run it by typing `yubikey-personalization-gui` in the command line.
- - In the program go to `Challenge-Response`,
- - select `HMAC-SHA1`,
- - choose `Configuration Slot 2`,
- - optional: enable `Require user input (button press)` (recommended),
- - use `fixed 64 bit input` for `HMAC-SHA1 mode`,
- - insert the YubiKey (if not done already) and make sure that it is attached
- to the vm,
- - press `Write Configuration` once you are ready.
+ - In the program go to `Challenge-Response`,
+ - select `HMAC-SHA1`,
+ - choose `Configuration Slot 2`,
+ - optional: enable `Require user input (button press)` (recommended),
+ - use `fixed 64 bit input` for `HMAC-SHA1 mode`,
+ - insert the YubiKey (if not done already) and make sure that it is attached
+ to the vm,
+ - press `Write Configuration` once you are ready.
+
+ - **NitroKey3**
- **NitroKey3**
- Set up a new NK3 Secrets App HOTP secret by attaching the NitroKey to your
+ - Set up a new NK3 Secrets App HOTP secret by attaching the NitroKey to your
USB qube and running the following commands in it:
- ```
- AESKEY=$(echo -n "your-20-digit-secret" | base32)
- nitropy nk3 secrets register --kind hotp --hash sha256 --digits-str 8 --counter-start 1 --touch-button loginxs $AESKEY
- ```
- Note that the 20 digit sequence can contain any printable ASCII character,
+
+ ```
+ AESKEY=$(echo -n "your-20-digit-secret" | base32)
+ nitropy nk3 secrets register --kind hotp --hash sha256 --digits-str 8 --counter-start 1 --touch-button loginxs $AESKEY
+ ```
+
+ - Note that the 20 digit sequence can contain any printable ASCII character,
e.g. letters, numbers, punctuation marks. The actual `Secret Key (base 32)`
is the base32 encoded form of that sequence.
- **both**
- We will call the `Secret Key (20 bytes hex)` (YubiKey) or `Secret Key (base 32)` `AESKEY`.
+ - **both**
+
- - It is recommended to keep a backup of your `AESKEY` in an offline VM used as a vault.
- - Consider keeping a backup of your `AESKEY` on paper and storing it in a safe place.
- - If you have multiple YubiKeys for backup purposes (in case one gets
- lost, stolen or breaks) you can write the same settings into other
-YubiKeys. For YubiKeys you can choose "Program multiple YubiKeys" in the program;
- make sure to select `Same secret for all keys` in this case. For NitroKeys you can set up
-the secret for multiple of them, but you must always use the same NitroKey, because the
-HOTP counter will be incremented in dom0 as well as the used NitroKey whenever you make use
-of this method. If you want to switch to a different NitroKey later, delete the file
-`/etc/qubes/yk-keys/nk-hotp-counter` in dom0 first to make it work with a fresh NitroKey 3.
-Do the same if for some reason your counters get desynchronized (it stops working), e.g. due
-to connectivity issues (NitroKey3A Minis are known to wear out quickly).
+ - We will call the `Secret Key (20 bytes hex)` (YubiKey) or `Secret Key (base 32)` `AESKEY`.
+
+ - It is recommended to keep a backup of your `AESKEY` in an offline VM used as a vault.
+ - Consider keeping a backup of your `AESKEY` on paper and storing it in a safe place.
+ - If you have multiple YubiKeys for backup purposes (in case one gets
+ lost, stolen or breaks) you can write the same settings into other
+ YubiKeys. For YubiKeys you can choose "Program multiple YubiKeys" in the program;
+ make sure to select `Same secret for all keys` in this case. For NitroKeys you can set up
+ the secret for multiple of them, but you must always use the same NitroKey, because the
+ HOTP counter will be incremented in dom0 as well as the used NitroKey whenever you make use
+ of this method. If you want to switch to a different NitroKey later, delete the file
+ `/etc/qubes/yk-keys/nk-hotp-counter` in dom0 first to make it work with a fresh NitroKey 3.
+ Do the same if for some reason your counters get desynchronized (it stops working), e.g. due
+ to connectivity issues (NitroKey3A Minis are known to wear out quickly).
4. **YubiKey**
- Paste your `AESKEY` into `/etc/qubes/yk-keys/yk-secret-key.hex` in dom0.
+
+ - Paste your `AESKEY` into `/etc/qubes/yk-keys/yk-secret-key.hex` in dom0.
Note that if you had previously used a NitroKey3 with this package, you *must* delete
the file `/etc/qubes/yk-keys/nk-hotp-secret` or its content!
- **NitroKey3**
- Create the file `/etc/qubes/yk-keys/nk-hotp-secret` in dom0 and paste your `AESKEY`
+ - **NitroKey3**
+
+
+ - Create the file `/etc/qubes/yk-keys/nk-hotp-secret` in dom0 and paste your `AESKEY`
(in base 32 format) into it.
5. As mentioned before, you need to define a new password that is only used in
@@ -264,22 +277,24 @@ to connectivity issues (NitroKey3A Minis are known to wear out quickly).
`/etc/qubes/yk-keys/login-pass` in dom0. This is considered safe as dom0 is
ultimately trusted anyway.
- However, if you prefer you can paste a hashed password instead into
+
+ - However, if you prefer you can paste a hashed password instead into
`/etc/qubes/yk-keys/login-pass-hashed.hex` in dom0.
- You can calculate your hashed password using the following two commands.
+
+ - You can calculate your hashed password using the following two commands.
First run the following command to store your password in a temporary variable `password`.
(This way your password will not leak to the terminal command history file.)
- ```
- read -r password
- ```
+ ```
+ read -r password
+ ```
- Now run the following command to calculate your hashed password.
+ - Now run the following command to calculate your hashed password.
- ```
- echo -n "$password" | openssl dgst -sha1 | cut -f2 -d ' '
- ```
+ ```
+ echo -n "$password" | openssl dgst -sha1 | cut -f2 -d ' '
+ ```
6. To enable multi-factor authentication for a service, you need to add
@@ -353,7 +368,7 @@ In dom0:
In your USB VM:
-3. Create udev hook.
+1. Create udev hook.
Store it in `/rw/config` to have it persist across VM restarts.
For example name the file `/rw/config/yubikey.rules`.
Add the following line:
@@ -362,7 +377,7 @@ In your USB VM:
ACTION=="remove", SUBSYSTEM=="usb", ENV{ID_SECURITY_TOKEN}=="1", RUN+="/usr/bin/qrexec-client-vm dom0 custom.LockScreen"
```
-4. Ensure that the udev hook is placed in the right place after VM restart.
+2. Ensure that the udev hook is placed in the right place after VM restart.
Append to `/rw/config/rc.local`:
```
@@ -370,13 +385,13 @@ In your USB VM:
udevadm control --reload
```
-5. Then make `/rw/config/rc.local` executable.
+3. Then make `/rw/config/rc.local` executable.
```
sudo chmod +x /rw/config/rc.local
```
-6. For changes to take effect, you need to call this script manually for the first time.
+4. For changes to take effect, you need to call this script manually for the first time.
```
sudo /rw/config/rc.local
diff --git a/user/security-in-qubes/split-gpg-2.md b/user/security-in-qubes/split-gpg-2.md
index 68cdb3aa1..83a36f8d7 100644
--- a/user/security-in-qubes/split-gpg-2.md
+++ b/user/security-in-qubes/split-gpg-2.md
@@ -121,7 +121,7 @@ If you want to generate a key on a smartcard or other hardware token, use `addca
## Advanced usage
There are a few option not described in this README.
-See the comments in the example (config and the source code)[https://github.com/QubesOS/qubes-app-linux-split-gpg2/blob/main/qubes-split-gpg2.conf.example].
+See the comments in the example [config and the source code](https://github.com/QubesOS/qubes-app-linux-split-gpg2/blob/main/qubes-split-gpg2.conf.example).
Similar to a smartcard, split-gpg2 only tries to protect the private key.
For advanced usages, consider if a specialized RPC service would be better.
diff --git a/user/security-in-qubes/split-gpg.md b/user/security-in-qubes/split-gpg.md
index 86966b2f4..c19096b13 100644
--- a/user/security-in-qubes/split-gpg.md
+++ b/user/security-in-qubes/split-gpg.md
@@ -303,7 +303,7 @@ In this example, the following keys are stored in the following locations (see b
* `sec` (master secret key)
- Depending on your needs, you may wish to create this as a **certify-only (C)** key, i.e., a key which is capable only of signing (a.k.a., "certifying") other keys.
+ - Depending on your needs, you may wish to create this as a **certify-only (C)** key, i.e., a key which is capable only of signing (a.k.a., "certifying") other keys.
This key may be created *without* an expiration date.
This is for two reasons.
First, the master secret key is never to leave the `vault` VM, so it is extremely unlikely ever to be obtained by an adversary (see below).
@@ -312,7 +312,7 @@ In this example, the following keys are stored in the following locations (see b
An adversary who does *not* possess the passphrase cannot use the key at all.
In either case, an expiration date provides no additional benefit.
- By the same token, however, having a passphrase on the key is of little value.
+ - By the same token, however, having a passphrase on the key is of little value.
An adversary who is capable of stealing the key from your `vault` would almost certainly also be capable of stealing the passphrase as you enter it.
An adversary who obtains the passphrase can then use it in order to change or remove the passphrase from the key.
Therefore, using a passphrase at all should be considered optional.
@@ -320,40 +320,40 @@ In this example, the following keys are stored in the following locations (see b
* `ssb` (secret subkey)
- Depending on your needs, you may wish to create two different subkeys: one for **signing (S)** and one for **encryption (E)**.
+ - Depending on your needs, you may wish to create two different subkeys: one for **signing (S)** and one for **encryption (E)**.
You may also wish to give these subkeys reasonable expiration dates (e.g., one year).
Once these keys expire, it is up to you whether to *renew* these keys by extending the expiration dates or to create *new* subkeys when the existing set expires.
- On the one hand, an adversary who obtains any existing encryption subkey (for example) will be able to use it in order to decrypt all emails (for example) which were encrypted to that subkey.
+ - On the one hand, an adversary who obtains any existing encryption subkey (for example) will be able to use it in order to decrypt all emails (for example) which were encrypted to that subkey.
If the same subkey were to continue to be used--and its expiration date continually extended--only that one key would need to be stolen (e.g., as a result of the `work-gpg` VM being compromised; see below) in order to decrypt *all* of the user's emails.
If, on the other hand, each encryption subkey is used for at most approximately one year, then an adversary who obtains the secret subkey will be capable of decrypting at most approximately one year's worth of emails.
- On the other hand, creating a new signing subkey each year without renewing (i.e., extending the expiration dates of) existing signing subkeys would mean that all of your old signatures would eventually read as "EXPIRED" whenever someone attempts to verify them.
+ - On the other hand, creating a new signing subkey each year without renewing (i.e., extending the expiration dates of) existing signing subkeys would mean that all of your old signatures would eventually read as "EXPIRED" whenever someone attempts to verify them.
This can be problematic, since there is no consensus on how expired signatures should be handled.
Generally, digital signatures are intended to last forever, so this is a strong reason against regularly retiring one's signing subkeys.
* `pub` (public key)
- This is the complement of the master secret key.
+ - This is the complement of the master secret key.
It can be uploaded to keyservers (or otherwise publicly distributed) and may be signed by others.
* `vault`
- This is a network-isolated VM.
+ - This is a network-isolated VM.
The initial master keypair and subkeys are generated in this VM.
The master secret key *never* leaves this VM under *any* circumstances.
No files or text is *ever* [copied](/doc/how-to-copy-and-move-files/#security) or [pasted](/doc/how-to-copy-and-paste-text/#security) into this VM under *any* circumstances.
* `work-gpg`
- This is a network-isolated VM.
+ - This is a network-isolated VM.
This VM is used *only* as the GPG backend for `work-email`.
The secret subkeys (but *not* the master secret key) are [copied](/doc/how-to-copy-and-move-files/#security) from the `vault` VM to this VM.
Files from less trusted VMs are *never* [copied](/doc/how-to-copy-and-move-files/#security) into this VM under *any* circumstances.
* `work-email`
- This VM has access to the mail server.
+ - This VM has access to the mail server.
It accesses the `work-gpg` VM via the Split GPG protocol.
The public key may be stored in this VM so that it can be attached to emails and for other such purposes.
diff --git a/user/security-in-qubes/vm-sudo.md b/user/security-in-qubes/vm-sudo.md
index 3001c367a..103644e82 100644
--- a/user/security-in-qubes/vm-sudo.md
+++ b/user/security-in-qubes/vm-sudo.md
@@ -59,9 +59,11 @@ user ALL=(ALL) NOPASSWD: ALL
#
# joanna.
```
+
The core of this statement continues to reflect the views of the Qubes developers.
Passwordless root is provided by the `qubes-core-agent-passwordless-root` package.
+
Details of the implementation are [here](/doc/vm-sudo-implementation).
[Minimal templates](/doc/templates/minimal/), which are intended for use by advanced users, do not have this package installed by default.
diff --git a/user/templates/debian/debian-upgrade.md b/user/templates/debian/debian-upgrade.md
index 12552f220..cf4d3ef22 100644
--- a/user/templates/debian/debian-upgrade.md
+++ b/user/templates/debian/debian-upgrade.md
@@ -179,7 +179,7 @@ command is required:
### Debian 10 ("Buster")
Please see [Debian's Buster upgrade
-instructions](https://www.debian.org/releases/buster/amd64/release-notes/ch-upgrading.en.html).
+instructions](https://www.debian.org/releases/buster/amd64/release-notes.en.txt).
### Debian 9 ("Stretch")
@@ -189,13 +189,11 @@ instructions](https://www.debian.org/releases/buster/amd64/release-notes/ch-upgr
* 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.
+ 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}`.
+ automatically; it should be disabled with `sudo systemctl disable apt-daily.{service,timer}`.
Relevant discussions:
@@ -205,12 +203,12 @@ Relevant discussions:
* [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/ch-upgrading.en.html).
+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/ch-upgrading.en.html).
+instructions](https://www.debian.org/releases/jessie/amd64/release-notes.en.txt).
### End-of-life (EOL) releases
diff --git a/user/templates/fedora/fedora-upgrade.md b/user/templates/fedora/fedora-upgrade.md
index a34bda37a..932f8b7dd 100644
--- a/user/templates/fedora/fedora-upgrade.md
+++ b/user/templates/fedora/fedora-upgrade.md
@@ -97,10 +97,10 @@ The same general procedure may be used to upgrade any template based on the stan
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.
+ - **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
+ - 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.
@@ -121,11 +121,7 @@ The same general procedure may be used to upgrade any template based on the stan
If this attempt is successful, proceed to step 4.
- * `dnf` may complain:
-
- `
- At least X MB more space needed on the / filesystem.
- `
+ - `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.)
diff --git a/user/templates/templates.md b/user/templates/templates.md
index 31ca18f8e..c53a288e5 100644
--- a/user/templates/templates.md
+++ b/user/templates/templates.md
@@ -121,6 +121,7 @@ You can manage your templates using the `Qubes Template Manager`, a GUI tool ava
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
```
@@ -129,9 +130,11 @@ 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=` option. E.g. :
+
```
$ qvm-template --enablerepo qubes-templates-community install
```
+
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`.
diff --git a/user/templates/windows/migrate-to-4-1.md b/user/templates/windows/migrate-to-4-1.md
index e5434c98a..8c8dd037a 100644
--- a/user/templates/windows/migrate-to-4-1.md
+++ b/user/templates/windows/migrate-to-4-1.md
@@ -33,6 +33,7 @@ While this is somewhat straightforward, things get difficult if QWT 4.0.1.3 was
## 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).
diff --git a/user/templates/windows/qubes-windows-tools-4-0.md b/user/templates/windows/qubes-windows-tools-4-0.md
index 830020c74..84470d0d3 100644
--- a/user/templates/windows/qubes-windows-tools-4-0.md
+++ b/user/templates/windows/qubes-windows-tools-4-0.md
@@ -32,16 +32,16 @@ Below is a breakdown of the feature availability depending on the windows versio
| Feature | Windows 7 x64 | Windows 10 x64 |
| ------------------------------------ | :------------: | :------------: |
-| Qubes Video Driver | + | - |
-| Qubes Network Setup | + | + |
-| Private Volume Setup (move profiles) | + | + |
-| File sender/receiver | + | + |
-| Clipboard Copy/Paste | + | + |
-| Application shortcuts | + | + |
-| Copy/Edit in Disposable VM | + | + |
-| Block device | + | + |
-| USB device | + | + |
-| Audio | - | - |
+| 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.
@@ -79,9 +79,9 @@ This will allow you to install the Qubes Windows Tools on Windows 10 both as a S
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.
+ - 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.
+ - **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.
@@ -98,7 +98,9 @@ This will allow you to install the Qubes Windows Tools on Windows 10 both as a S
12. Lastly to enable file copy operations to a Windows 10 VM the `default_user` property should be set the `` that you use to login to the Windows VM. This can be done via the following command on a `dom0` terminal: *(where `` is the name of your Windows 10 VM)*
- `qvm-prefs default_user `
+ ```
+ qvm-prefs default_user
+ ```
**Note:** If this property is not set or set to a wrong value, files copied to this VM are stored in the folder
@@ -165,6 +167,7 @@ Installing Xen's PV drivers in the VM will lower its resources usage when using
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).
@@ -317,8 +320,8 @@ To override global settings for a specific component, create a new key under the
Component-specific settings currently available:
-|**Component**|**Setting**|**Type**|**Description**|**Default value**|
-|:------------|:----------|:-------|:--------------|:----------------|
+| 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
@@ -332,11 +335,12 @@ If the VM is inaccessible (doesn't respond to qrexec commands, gui is not functi
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.
+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.|
diff --git a/user/templates/windows/qubes-windows-tools-4-1.md b/user/templates/windows/qubes-windows-tools-4-1.md
index d02f2dbf7..c5fd23aad 100644
--- a/user/templates/windows/qubes-windows-tools-4-1.md
+++ b/user/templates/windows/qubes-windows-tools-4-1.md
@@ -42,26 +42,27 @@ If you prefer to download the corresponding .rpm files for manual QWT installati
**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`
+**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 | + | - |
-| Qubes Network Setup | + | + |
-| Private Volume Setup (move profiles) | + | + |
-| File sender/receiver | + | + |
-| Clipboard Copy/Paste | + | + |
-| Application shortcuts | + | + |
-| Copy/Edit in Disposable VM | + | + |
-| Block device | + | + |
-| USB device | + | + |
-| Audio | + | + |
+| 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.
@@ -75,11 +76,11 @@ Qubes Windows Tools are open source and are distributed under a GPL license.
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 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` 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.
+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 `` is the name of your Windows VM)*
+**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* `` *is the name of your Windows VM)*
[user@dom0 ~] $ qvm-prefs qrexec_timeout 7200
@@ -125,33 +126,40 @@ Installing the Qubes Windows Tools on Windows 7, 8.1, 10 and 11 both as a Standa
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)
+ [](/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.
+ 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)
+ [](/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.
+ 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)
+ [](/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 `` is the name of your Windows VM)*:
+ 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* `` *is the name of your Windows VM)*:
+
- [user@dom0 ~] $ qvm-prefs
+ ```
+ [user@dom0 ~] $ qvm-prefs
+ ```
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 audio-model ich9
- [user@dom0 ~] $ qvm-features stubdom-qrexec 1
- [user@dom0 ~] $ qvm-features 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 timer-period 1000
- [user@dom0 ~] $ qvm-features out.latency 10000
- [user@dom0 ~] $ qvm-features out.buffer-length 4000
+ ```
+ [user@dom0 ~] $ qvm-features audio-model ich9
+ [user@dom0 ~] $ qvm-features stubdom-qrexec 1
+ [user@dom0 ~] $ qvm-features 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 timer-period 1000
+ [user@dom0 ~] $ qvm-features out.latency 10000
+ [user@dom0 ~] $ qvm-features 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.
@@ -170,16 +178,11 @@ Installing the Qubes Windows Tools on Windows 7, 8.1, 10 and 11 both as a Standa
- 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 `` that you use to login to the Windows VM. This can be done via the following command on a `dom0` terminal: *(where `` is the name of your Windows VM)*
-
- `[user@dom0 ~] $ qvm-prefs default_user `
+ 10. Lastly to enable file copy operations to a Windows VM, the `default_user` property of this VM should be set to the `` 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 default_user ` *(where* `` *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\
+ **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\`.
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.
@@ -188,6 +191,7 @@ Installing the Qubes Windows Tools on Windows 7, 8.1, 10 and 11 both as a Standa
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.
@@ -267,7 +271,7 @@ Windows qubes can be used as disposables, like any other Linux-based qubes. On c
- 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 `, *where `` is the name of your windows qube*.
+- 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 `, *where* `` *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 template_for_dispvms True` and `qvm-features 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 default_dispvm `.
@@ -277,7 +281,7 @@ Now you should have a menu `Disposable: ` containing the applications th
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.*
+**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
@@ -311,8 +315,8 @@ To override global settings for a specific component, create a new key under the
Component-specific settings currently available:
-|**Component**|**Setting**|**Type**|**Description**|**Default value**|
-|:------------|:----------|:-------|:--------------|:----------------|
+| 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
diff --git a/user/templates/windows/windows-qubes-4-0.md b/user/templates/windows/windows-qubes-4-0.md
index e1844e18b..919655ff2 100644
--- a/user/templates/windows/windows-qubes-4-0.md
+++ b/user/templates/windows/windows-qubes-4-0.md
@@ -16,11 +16,13 @@ title: How to install Windows qubes in Qubes OS 4.0
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)
@@ -29,6 +31,7 @@ Does not work:
- 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
@@ -219,6 +222,7 @@ At that point you should have a functional and stable Windows VM, although witho
## 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
~~~
@@ -231,6 +235,7 @@ when creating the VM. To have the user data stored in AppVMs depending on this t
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=
~~~
diff --git a/user/templates/windows/windows-qubes-4-1.md b/user/templates/windows/windows-qubes-4-1.md
index cbd2b3ba4..df28c6ce3 100644
--- a/user/templates/windows/windows-qubes-4-1.md
+++ b/user/templates/windows/windows-qubes-4-1.md
@@ -34,7 +34,7 @@ For better integration, a set of drivers and services, called Qubes Windows Tool
## 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 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).
@@ -46,6 +46,7 @@ For better integration, a set of drivers and services, called Qubes Windows Tool
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).
@@ -61,46 +62,49 @@ Unofficial “debloated” ISOs from projects like reviOS 18 or ameliorated 10 c
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".
+- 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
- ~~~
+
+ ~~~
+ 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
- ~~~
+
+ ~~~
+ 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:
@@ -109,19 +113,26 @@ These parameters are set for the following reasons:
- 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:
- ~~~
+ ~~~
+ /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:
@@ -135,6 +146,7 @@ These parameters are set for the following reasons:
- 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
~~~
@@ -153,43 +165,42 @@ These parameters are set for the following reasons:
- 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.
-
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:
+ - 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.
+ - 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:
+ - 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.
+ - 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 Windows 11 version 24H2, the following sequence of actions to use a local account instead of a Microsoft account has been proved working:
+ - 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.
- 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.
+ - 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!).
@@ -199,9 +210,11 @@ These parameters are set for the following reasons:
**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:
@@ -215,6 +228,7 @@ These parameters are set for the following reasons:
- 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:
~~~
@@ -256,6 +270,7 @@ If the user data have been moved to `Q:`, be sure not to user the option `Move U
AppVMs based on these templates can be created the normal way by using the Qube Manager or by specifying
+
~~~
qvm-create --class=AppVM --template=
~~~
@@ -264,7 +279,8 @@ On starting the AppVM, sometimes a message is displayed that the Xen PV Network
**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 changed to that of the template (e.g. 10.137.0.x) so that the AppVM can access the network, vis the CLI command in a dom0 terminal:
+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
~~~
diff --git a/user/troubleshooting/app-menu-shortcut-troubleshooting.md b/user/troubleshooting/app-menu-shortcut-troubleshooting.md
index 9da6ace8a..2ce02dbe0 100644
--- a/user/troubleshooting/app-menu-shortcut-troubleshooting.md
+++ b/user/troubleshooting/app-menu-shortcut-troubleshooting.md
@@ -30,20 +30,20 @@ After that, use the directional buttons (`>`, `>>`, `<` or `<<`) to customize wh
To update the list of available applications, use the `qvm-sync-appmenus` command in dom0, replacing `` by the qube name:
-```console
+```
$ qvm-sync-appmenus
```
When using the *Refresh Applications* button in a qube's settings, the command `qvm-sync-appmenus` is used at least one time. When refreshing an AppVM application, it is also run against the template. So the console equivalent of clicking the *Refresh button* is the following (always in dom0):
-```console
+```
$ qvm-sync-appmenus
$ qvm-sync-appmenus
```
In dom0, the `qvm-appmenus` tool allows the user to see the list of available applications (unstable feature), the whitelist of currently show application (unstable feature) and to change this list:
-```console
+```
$ qvm-appmenus --set-whitelist
```
diff --git a/user/troubleshooting/debian-and-whonix-update-troubleshooting.md b/user/troubleshooting/debian-and-whonix-update-troubleshooting.md
index 06afbca3a..36cde215c 100644
--- a/user/troubleshooting/debian-and-whonix-update-troubleshooting.md
+++ b/user/troubleshooting/debian-and-whonix-update-troubleshooting.md
@@ -95,11 +95,11 @@ W: A error occurred during the signature verification. The repository is not upd
Even though, `apt-get` will automatically ignore repositories with expired keys or signatures, you will not receive upgrades from that repository. Unless the issue is already known/documented, it should be reported so it can be further investigated.
-There are two possible reasons why this could happen, either there is an issue with the repository that the maintainers have to fix, or you are victim of a [Man-in-the-middle_attacks](https://www.whonix.org/wiki/Warning#Man-in-the-middle_attacks). The latter would not be a big issue and might go away after a while automatically or try to [change your Tor circuit](https://www.whonix.org/wiki/Arm#Arm)
+There are two possible reasons why this could happen, either there is an issue with the repository that the maintainers have to fix, or you are victim of a [Man-in-the-middle_attacks](https://www.whonix.org/wiki/Warning#Man-in-the-middle_attacks). The latter would not be a big issue and might go away after a while automatically or try to [change your Tor circuit](https://www.whonix.org/wiki/Arm#Arm).
-In past various apt repositories were signed with expired key. If you want to see how the documentation looked at that point, please click on expand on the right.
+In past various apt repositories were signed with expired key: [The Tor Project's apt repository key was expired](https://trac.torproject.org/projects/tor/ticket/12994).
-[The Tor Project's apt repository key was expired](https://trac.torproject.org/projects/tor/ticket/12994). You saw the following warning.
+You saw the following warning:
~~~
W: A error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: http://deb.torproject.org stable Release: The following signatures were invalid: KEYEXPIRED 1409325681 KEYEXPIRED 1409325681 KEYEXPIRED 1409325681 KEYEXPIRED 1409325681
diff --git a/user/troubleshooting/disk-troubleshooting.md b/user/troubleshooting/disk-troubleshooting.md
index 07798bf24..beaf8d4cc 100644
--- a/user/troubleshooting/disk-troubleshooting.md
+++ b/user/troubleshooting/disk-troubleshooting.md
@@ -32,9 +32,9 @@ As you can see, the `sudo lvs | head` command includes additional important colu
If your system is able to boot, but cannot load a desktop environment, it is possible to login to dom0 terminal with Alt + Ctrl + F2.
-If this does not work, check the size of /var/lib/qubes/qubes.xml.
-If it is zero, you'll need to use one of the file backup (stored in /var/lib/qubes/backup), hopefully you have the current data there.
-Find the most recent one and place in /var/lib/qubes/qubes.xml instead of the empty file.
+If this does not work, check the size of `/var/lib/qubes/qubes.xml`.
+If it is zero, you'll need to use one of the file backup (stored in `/var/lib/qubes/backup`), hopefully you have the current data there.
+Find the most recent one and place in `/var/lib/qubes/qubes.xml` instead of the empty file.
In any case you'll need some disk space to start the VM. Check `df -h` output if you have some.
If not, here are some hints how to free some disk space:
diff --git a/user/troubleshooting/gui-troubleshooting.md b/user/troubleshooting/gui-troubleshooting.md
index 819b7e6b4..0df5d71ac 100644
--- a/user/troubleshooting/gui-troubleshooting.md
+++ b/user/troubleshooting/gui-troubleshooting.md
@@ -32,9 +32,7 @@ Similarly, while working, the XScreenSaver dialog may pop up (indicating the scr
If you are experiencing the any of the above symptoms, try disabling the window compositor:
-`
- Q → System Tools → Window Manager Tweaks → Compositor → uncheck “Enable display compositing”
-`
+`Q → System Tools → Window Manager Tweaks → Compositor → uncheck “Enable display compositing”`
## Post installation, screen goes black and freezes following LUKS decryption
diff --git a/user/troubleshooting/hvm-troubleshooting.md b/user/troubleshooting/hvm-troubleshooting.md
index 98f87a9ee..070c37ecb 100644
--- a/user/troubleshooting/hvm-troubleshooting.md
+++ b/user/troubleshooting/hvm-troubleshooting.md
@@ -62,7 +62,7 @@ qvm-prefs kernel ""
## HVM crashes when booting from ISO
-If your HVM crashes when trying to boot an ISO, first ensure that ` qvm-prefs kernel` is empty, as shown above.
+If your HVM crashes when trying to boot an ISO, first ensure that `qvm-prefs kernel` is empty, as shown above.
If this doesn't help, then disable memory balancing and set the minimum memory to 2GB.
You can disable memory-balancing in the settings, under the “Advanced” tab.
diff --git a/user/troubleshooting/installation-troubleshooting.md b/user/troubleshooting/installation-troubleshooting.md
index 2a0c19360..6e2eae8b9 100644
--- a/user/troubleshooting/installation-troubleshooting.md
+++ b/user/troubleshooting/installation-troubleshooting.md
@@ -61,19 +61,20 @@ If that doesn't help, then disable one and try the other.
Visit the [UEFI Troubleshooting guide](/doc/uefi-troubleshooting/) if other errors arise during UEFI booting.
These errors may also occur due to an incompatible Nvidia graphics card. If you have one, follow the following instructions:
+
1. Disable secure/fast boot and use legacy mode
2. Enter GRUB, move the selection to the first choice, and then press the Tab key.
3. Now, you are in edit mode. Move the text cursor with your arrow key and after ``kernel=`` line, add:
- ```
- nouveau.modeset=0 rd.driver.blacklist=nouveau video=vesa:off
- ```
+ ```bash
+ nouveau.modeset=0 rd.driver.blacklist=nouveau video=vesa:off
+ ```
- If the above code doesn't fix the problem, replace it with:
+ If the above code doesn't fix the problem, replace it with:
- ```
- noexitboot=1 modprobe.blacklist=nouveau rd.driver.blacklist=nouveau --- intitrd.img
- ```
+ ```bash
+ noexitboot=1 modprobe.blacklist=nouveau rd.driver.blacklist=nouveau --- intitrd.img
+ ```
For more information, look at the [Nvidia Troubleshooting guide](https://forum.qubes-os.org/t/19021#disabling-nouveau).
diff --git a/user/troubleshooting/uefi-troubleshooting.md b/user/troubleshooting/uefi-troubleshooting.md
index 4a0fb4604..ae8b2f893 100644
--- a/user/troubleshooting/uefi-troubleshooting.md
+++ b/user/troubleshooting/uefi-troubleshooting.md
@@ -40,7 +40,7 @@ Some laptops cannot read from an external boot device larger than 8GB. If you en
## Installation completes successfully but then system crash/restarts on next boot
-Some Dell systems and probably others have [another bug in UEFI firmware](https://markmail.org/message/amw5336otwhdxi76).
+Some Dell systems and probably others have [another bug in UEFI firmware](https://web.archive.org/web/20170901231026/https://markmail.org/message/amw5336otwhdxi76).
These systems need `efi=attr=uc` enabled at all times.
Although this is enabled by default in the installer, it is disabled after the first stage of a successful install.
You can re-enable it either as part of the install process:
diff --git a/user/troubleshooting/update-troubleshooting.md b/user/troubleshooting/update-troubleshooting.md
index 5cbcf0815..60cc2feca 100644
--- a/user/troubleshooting/update-troubleshooting.md
+++ b/user/troubleshooting/update-troubleshooting.md
@@ -43,5 +43,6 @@ This can usually be fixed by updating via the command line.
In dom0, open a terminal and run `sudo qubes-dom0-update`.
Depending on your operating system, open a terminal in the templates and run:
+
* Fedora: `sudo dnf upgrade`
* Debian: `apt-get update && apt-get dist-upgrade`
diff --git a/user/troubleshooting/usb-troubleshooting.md b/user/troubleshooting/usb-troubleshooting.md
index 0a573127b..61c50fcbd 100644
--- a/user/troubleshooting/usb-troubleshooting.md
+++ b/user/troubleshooting/usb-troubleshooting.md
@@ -19,7 +19,7 @@ For guidance setting up a USB qube, see the [USB documentation](/doc/how-to-use-
Currently (until issue [1082](https://github.com/QubesOS/qubes-issues/issues/1082) gets implemented), if you remove the device before detaching it from the qube, Qubes OS (more precisely, `libvirtd`) will think that the device is still attached to the qube and will not allow attaching further devices under the same name.
This may be characterized by VM manager crashes and the error message: `Houston, we have a problem`.
The easiest way to recover from such a situation is to reboot the qube to which the device was attached.
-If this isn't an option, you can manually recover from the situation by following the instructions at the [Block Devices documentation](/doc/how-to-use-block-storage-devices/#what-if-i-removed-the-device-before-detaching-it-from-the-vm)
+If this isn't an option, you can manually recover from the situation by following the instructions at the [Block Devices documentation](/doc/how-to-use-block-storage-devices/#what-if-i-removed-the-device-before-detaching-it-from-the-vm).
## "Device attach failed" error
diff --git a/user/troubleshooting/vpn-troubleshooting.md b/user/troubleshooting/vpn-troubleshooting.md
index dbf2ccd43..8354083f6 100644
--- a/user/troubleshooting/vpn-troubleshooting.md
+++ b/user/troubleshooting/vpn-troubleshooting.md
@@ -46,5 +46,6 @@ sudo notify-send "$(hostname): Test notify-send OK" --icon=network-idle
You should see the `info` message appear on the top of your screen.
If that is the case then `notify-send` is not the issue.
If it is not, and you have an error of some sort you can:
+
1. Remove all calls to `notify-send` from scripts you are using to start VPN
2. Use another template qube that has a working `notify-send` or find proper guide and make your current template run `notify-send` work properly.