From 062e7489a6066e62a4dd3756e2f98d4cfe578c57 Mon Sep 17 00:00:00 2001 From: PROTechThor Date: Sun, 18 Oct 2020 07:16:20 +0100 Subject: [PATCH 1/8] Add Disk Troubleshooting --- doc.md | 2 +- user/troubleshooting/disk-troubleshooting.md | 96 ++++++++++++++++++++ user/troubleshooting/out-of-memory.md | 46 ---------- 3 files changed, 97 insertions(+), 47 deletions(-) create mode 100644 user/troubleshooting/disk-troubleshooting.md delete mode 100644 user/troubleshooting/out-of-memory.md diff --git a/doc.md b/doc.md index f782dfe9..37364941 100644 --- a/doc.md +++ b/doc.md @@ -122,7 +122,7 @@ Core documentation for Qubes users. * [Installation Troubleshooting](/doc/installation-troubleshooting) * [UEFI Troubleshooting](/doc/uefi-troubleshooting/) - * [Home directory is out of disk space error](/doc/out-of-memory/) + * [Disk Troubleshooting](/doc/disk-troubleshooting/) * [Installing on system with new AMD GPU (missing firmware problem)](https://groups.google.com/group/qubes-devel/browse_thread/thread/e27a57b0eda62f76) * [How to install an Nvidia driver in dom0](/doc/install-nvidia-driver/) * [Nvidia troubleshooting guide](/doc/nvidia-troubleshooting/) diff --git a/user/troubleshooting/disk-troubleshooting.md b/user/troubleshooting/disk-troubleshooting.md new file mode 100644 index 00000000..d281bdf1 --- /dev/null +++ b/user/troubleshooting/disk-troubleshooting.md @@ -0,0 +1,96 @@ +--- +layout: doc +title: Disk Troubleshooting +permalink: /doc/disk-troubleshooting/ +redirect_from: +- /en/doc/out-of-memory/ +- /doc/OutOfmemory/ +- /wiki/OutOfmemory/ +- /doc/out-of-memory/ +--- + +# Disk Troubleshooting Guide # + +## "Out of disk space" error ## + +VMs (especially templates) use pre-allocated space. +The default private storage max size is 2 GB, but it's very easy to increase as needed. +If the disk is completely full, you will get an `Out of disk space` error that may crash your system because Dom0 does not have enough disk space to work. +So it's good practice to regularly check disk space usage with the command `df -h` in dom0 terminal. + +A system that's out of space should be able to boot, but may be unable to load a desktop manager. +In this case it is possible to login to dom0 terminal with Alt + Ctrl + F2. +To recover disk space it may be possible to delete files in a userVM by connecting to the userVM terminal: + +~~~ +qvm-start +qvm-console-dispvm +~~~ + +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: + +1. Clean yum cache. + + ~~~ + sudo yum clean all + ~~~ + +2. Delete `.img` files of a less important VM, which can be found in `/var/lib/qubes/appvms/`. + Then, when the system is working again, clean up the rest. + + ~~~ + qvm-remove + ~~~ + + With this method, you lose the data of one VM, but it'll work more reliably. + +3. Decrease the filesystem safety margin (5% by default). + + ~~~ + sudo tune2fs -m 4 /dev/mapper/vg_dom0-lv_root + ~~~ + +4. Remove some unneeded files in dom0 home (if you have any, most likely not). + +## Can't resize VM storage / "resize2fs: Permission denied" error ## + +[Resizing a volume](/doc/resize-disk-image/) in the Qubes interface should be a straightforward process. +But sometimes, an attempt to resize will look like it worked, when it in fact fails silently. +If you then try the same operation in the dom0 console using the `qvm-volume extend` command, it fails with the error message: `resize2fs: Permission denied to resize filesystem`. +This error indicates that a `resize2fs` will not work, unless `fsck` is run first. +Qubes OS utilities cannot yet handle this case. + +To fix this issue: + +1. In the dom0 terminal get a root console on the vm (eg. sys-usb) with: + + ~~~ + sudo xl console -t pv sys-usb + ~~~ + +2. Unmount everything mounted on the private volume `/dev/xvdb partition`. +There are typically several mounts listed in `/etc/mtab`. + +3. When you attempt to unmount the `/home` directory using the `umount /home` command, you will encounter an error because there are processes using the `/home` directory. You can view a list of these processes with the `fuser` command: + + ~~~ + fuser -m /home + ~~~ + +Kill these process until they are all gone using `kill `. + +4. Finally, run: + + ~~~ + umount /home + fsck /dev/xvdb + resize2fs /dev/xvdb + ~~~ + +After restarting your VM, everything should now work as expected. +The private volume size shown externally in the VM's settings interface is the same as that seen within the VM. diff --git a/user/troubleshooting/out-of-memory.md b/user/troubleshooting/out-of-memory.md deleted file mode 100644 index 869da993..00000000 --- a/user/troubleshooting/out-of-memory.md +++ /dev/null @@ -1,46 +0,0 @@ ---- -layout: doc -title: Out of Memory -permalink: /doc/out-of-memory/ -redirect_from: -- /en/doc/out-of-memory/ -- /doc/OutOfmemory/ -- /wiki/OutOfmemory/ ---- - -VMs (especially templates) use pre-allocated space. The default private storage max size is 2 GB, but it's very easy to increase as needed. If the disk is completely full, you will get an `Out of disk space` error that may crash your system because Dom0 does not have enough disk space to work. So it's good practice to regularly check disk space usage with the command `df -h` in dom0 terminal. - -A system that's out of space should be able to boot, but may be unable to load a desktop manager. In this case it is possible to login to dom0 terminal with Alt + Ctrl + F2. To recover disk space it may be possible to delete files in a userVM by connecting to the userVM terminal: - -~~~ -qvm-start -qvm-console-dispvm -~~~ - -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: - -1. Clean yum cache. - - ~~~ - sudo yum clean all - ~~~ - -2. Delete `.img` files of a less important VM, which can be found in `/var/lib/qubes/appvms/`. - Then, when the system is working again, clean up the rest. - - ~~~ - qvm-remove - ~~~ - - With this method, you lose the data of one VM, but it'll work more reliably. - -3. Decrease the filesystem safety margin (5% by default). - - ~~~ - sudo tune2fs -m 4 /dev/mapper/vg_dom0-lv_root - ~~~ - -4. Remove some unneeded files in dom0 home (if you have any, most likely not). - From f1e6afeb14383fa5a898251ea3b0f5693aea5340 Mon Sep 17 00:00:00 2001 From: PROTechThor Date: Sun, 18 Oct 2020 07:20:05 +0100 Subject: [PATCH 2/8] Revert "Add Disk Troubleshooting" This reverts commit 062e7489a6066e62a4dd3756e2f98d4cfe578c57. --- doc.md | 2 +- user/troubleshooting/disk-troubleshooting.md | 96 -------------------- user/troubleshooting/out-of-memory.md | 46 ++++++++++ 3 files changed, 47 insertions(+), 97 deletions(-) delete mode 100644 user/troubleshooting/disk-troubleshooting.md create mode 100644 user/troubleshooting/out-of-memory.md diff --git a/doc.md b/doc.md index 37364941..f782dfe9 100644 --- a/doc.md +++ b/doc.md @@ -122,7 +122,7 @@ Core documentation for Qubes users. * [Installation Troubleshooting](/doc/installation-troubleshooting) * [UEFI Troubleshooting](/doc/uefi-troubleshooting/) - * [Disk Troubleshooting](/doc/disk-troubleshooting/) + * [Home directory is out of disk space error](/doc/out-of-memory/) * [Installing on system with new AMD GPU (missing firmware problem)](https://groups.google.com/group/qubes-devel/browse_thread/thread/e27a57b0eda62f76) * [How to install an Nvidia driver in dom0](/doc/install-nvidia-driver/) * [Nvidia troubleshooting guide](/doc/nvidia-troubleshooting/) diff --git a/user/troubleshooting/disk-troubleshooting.md b/user/troubleshooting/disk-troubleshooting.md deleted file mode 100644 index d281bdf1..00000000 --- a/user/troubleshooting/disk-troubleshooting.md +++ /dev/null @@ -1,96 +0,0 @@ ---- -layout: doc -title: Disk Troubleshooting -permalink: /doc/disk-troubleshooting/ -redirect_from: -- /en/doc/out-of-memory/ -- /doc/OutOfmemory/ -- /wiki/OutOfmemory/ -- /doc/out-of-memory/ ---- - -# Disk Troubleshooting Guide # - -## "Out of disk space" error ## - -VMs (especially templates) use pre-allocated space. -The default private storage max size is 2 GB, but it's very easy to increase as needed. -If the disk is completely full, you will get an `Out of disk space` error that may crash your system because Dom0 does not have enough disk space to work. -So it's good practice to regularly check disk space usage with the command `df -h` in dom0 terminal. - -A system that's out of space should be able to boot, but may be unable to load a desktop manager. -In this case it is possible to login to dom0 terminal with Alt + Ctrl + F2. -To recover disk space it may be possible to delete files in a userVM by connecting to the userVM terminal: - -~~~ -qvm-start -qvm-console-dispvm -~~~ - -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: - -1. Clean yum cache. - - ~~~ - sudo yum clean all - ~~~ - -2. Delete `.img` files of a less important VM, which can be found in `/var/lib/qubes/appvms/`. - Then, when the system is working again, clean up the rest. - - ~~~ - qvm-remove - ~~~ - - With this method, you lose the data of one VM, but it'll work more reliably. - -3. Decrease the filesystem safety margin (5% by default). - - ~~~ - sudo tune2fs -m 4 /dev/mapper/vg_dom0-lv_root - ~~~ - -4. Remove some unneeded files in dom0 home (if you have any, most likely not). - -## Can't resize VM storage / "resize2fs: Permission denied" error ## - -[Resizing a volume](/doc/resize-disk-image/) in the Qubes interface should be a straightforward process. -But sometimes, an attempt to resize will look like it worked, when it in fact fails silently. -If you then try the same operation in the dom0 console using the `qvm-volume extend` command, it fails with the error message: `resize2fs: Permission denied to resize filesystem`. -This error indicates that a `resize2fs` will not work, unless `fsck` is run first. -Qubes OS utilities cannot yet handle this case. - -To fix this issue: - -1. In the dom0 terminal get a root console on the vm (eg. sys-usb) with: - - ~~~ - sudo xl console -t pv sys-usb - ~~~ - -2. Unmount everything mounted on the private volume `/dev/xvdb partition`. -There are typically several mounts listed in `/etc/mtab`. - -3. When you attempt to unmount the `/home` directory using the `umount /home` command, you will encounter an error because there are processes using the `/home` directory. You can view a list of these processes with the `fuser` command: - - ~~~ - fuser -m /home - ~~~ - -Kill these process until they are all gone using `kill `. - -4. Finally, run: - - ~~~ - umount /home - fsck /dev/xvdb - resize2fs /dev/xvdb - ~~~ - -After restarting your VM, everything should now work as expected. -The private volume size shown externally in the VM's settings interface is the same as that seen within the VM. diff --git a/user/troubleshooting/out-of-memory.md b/user/troubleshooting/out-of-memory.md new file mode 100644 index 00000000..869da993 --- /dev/null +++ b/user/troubleshooting/out-of-memory.md @@ -0,0 +1,46 @@ +--- +layout: doc +title: Out of Memory +permalink: /doc/out-of-memory/ +redirect_from: +- /en/doc/out-of-memory/ +- /doc/OutOfmemory/ +- /wiki/OutOfmemory/ +--- + +VMs (especially templates) use pre-allocated space. The default private storage max size is 2 GB, but it's very easy to increase as needed. If the disk is completely full, you will get an `Out of disk space` error that may crash your system because Dom0 does not have enough disk space to work. So it's good practice to regularly check disk space usage with the command `df -h` in dom0 terminal. + +A system that's out of space should be able to boot, but may be unable to load a desktop manager. In this case it is possible to login to dom0 terminal with Alt + Ctrl + F2. To recover disk space it may be possible to delete files in a userVM by connecting to the userVM terminal: + +~~~ +qvm-start +qvm-console-dispvm +~~~ + +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: + +1. Clean yum cache. + + ~~~ + sudo yum clean all + ~~~ + +2. Delete `.img` files of a less important VM, which can be found in `/var/lib/qubes/appvms/`. + Then, when the system is working again, clean up the rest. + + ~~~ + qvm-remove + ~~~ + + With this method, you lose the data of one VM, but it'll work more reliably. + +3. Decrease the filesystem safety margin (5% by default). + + ~~~ + sudo tune2fs -m 4 /dev/mapper/vg_dom0-lv_root + ~~~ + +4. Remove some unneeded files in dom0 home (if you have any, most likely not). + From 57d66a7146f5c9c8241317cd0384bb05c182d1df Mon Sep 17 00:00:00 2001 From: PROTechThor Date: Sun, 18 Oct 2020 10:08:03 +0100 Subject: [PATCH 3/8] Add PCI Troubleshooting --- doc.md | 1 + user/common-tasks/pci-devices.md | 29 +--- user/troubleshooting/pci-troubleshooting.md | 140 ++++++++++++++++++++ 3 files changed, 143 insertions(+), 27 deletions(-) create mode 100644 user/troubleshooting/pci-troubleshooting.md diff --git a/doc.md b/doc.md index f782dfe9..d839f890 100644 --- a/doc.md +++ b/doc.md @@ -122,6 +122,7 @@ Core documentation for Qubes users. * [Installation Troubleshooting](/doc/installation-troubleshooting) * [UEFI Troubleshooting](/doc/uefi-troubleshooting/) + * [PCI Troubleshooting](/doc/pci-troubleshooting/) * [Home directory is out of disk space error](/doc/out-of-memory/) * [Installing on system with new AMD GPU (missing firmware problem)](https://groups.google.com/group/qubes-devel/browse_thread/thread/e27a57b0eda62f76) * [How to install an Nvidia driver in dom0](/doc/install-nvidia-driver/) diff --git a/user/common-tasks/pci-devices.md b/user/common-tasks/pci-devices.md index e84b0ea7..e1228dd6 100644 --- a/user/common-tasks/pci-devices.md +++ b/user/common-tasks/pci-devices.md @@ -81,30 +81,7 @@ For example, if `00_1a.0` is the BDF of the device you want to attach to the "wo ## Possible Issues ## - -### DMA Buffer Size ### - -VMs with attached PCI devices in Qubes have allocated a small buffer for DMA operations (called swiotlb). -By default it is 2MB, but some devices need a larger buffer. -To change this allocation, edit VM's kernel parameters (this is expressed in 512B chunks): - - # qvm-prefs netvm |grep kernelopts - kernelopts : iommu=soft swiotlb=2048 (default) - # qvm-prefs -s netvm kernelopts "iommu=soft swiotlb=8192" - - -This is [known to be needed][ml1] for the Realtek RTL8111DL Gigabit Ethernet Controller. - - -### PCI Passthrough Issues ### - -Sometimes the PCI arbitrator is too strict. -There is a way to enable permissive mode for it. -See also: [this thread][ml2] and the Xen wiki's [PCI passthrough] page. -At other times, you may instead need to disable the FLR requirement on a device. - -Both can be achieved during attachment with `qvm-pci` as described below. - +Visit the [PCI Troubleshooting guide](pci-troubleshoot) to see issues that may arise due to PCI devices and how to troubleshoot them. ## Additional Attach Options ## @@ -166,9 +143,7 @@ or [USB]:/doc/usb-devices/ [appmenu]: /attachment/wiki/Devices/qubes-appmenu-select.png [domain manager icon]: /attachment/wiki/Devices/qubes-logo-icon.png +[pci-troubleshoot]:/doc/pci-troubleshooting [qvm-device]: /doc/device-handling/#general-qubes-device-widget-behavior-and-handling [side channel attacks]: https://en.wikipedia.org/wiki/Side-channel_attack -[ml1]: https://groups.google.com/group/qubes-devel/browse_thread/thread/631c4a3a9d1186e3 -[ml2]: https://groups.google.com/forum/#!topic/qubes-users/Fs94QAc3vQI -[PCI passthrough]: https://wiki.xen.org/wiki/Xen_PCI_Passthrough diff --git a/user/troubleshooting/pci-troubleshooting.md b/user/troubleshooting/pci-troubleshooting.md new file mode 100644 index 00000000..c7d4905b --- /dev/null +++ b/user/troubleshooting/pci-troubleshooting.md @@ -0,0 +1,140 @@ +--- +layout: doc +title: PCI Troubleshooting +permalink: /doc/pci-troubleshooting/ +--- + +# PCI troubleshooting # + +## DMA errors ## + +VMs with attached PCI devices in Qubes have allocated a small buffer for DMA operations (called swiotlb). +By default, it is 2MB, but some devices (such as the [Realtek RTL8111DL Gigabit Ethernet Controller](https://groups.google.com/group/qubes-devel/browse_thread/thread/631c4a3a9d1186e3)) need a larger DMA buffer size. +Without a larger buffer, you will face DMA errors such as `Failed to map TX DMA`. + +To change this allocation, edit VM's kernel parameters (this is expressed in 512B chunks) by running the following in a dom0 terminal: + + # qvm-prefs netvm |grep kernelopts + kernelopts : iommu=soft swiotlb=2048 (default) + # qvm-prefs -s netvm kernelopts "iommu=soft swiotlb=8192" + +## PCI Passthrough Issues ## + +Sometimes the PCI arbitrator is too strict, which may cause errors such as `Unable to reset PCI device` and other PCI-related errors. +There is a way to enable permissive mode for it. +See also: [this thread](https://groups.google.com/forum/#!topic/qubes-users/Fs94QAc3vQI) and the Xen wiki's [PCI passthrough](https://wiki.xen.org/wiki/Xen_PCI_Passthrough) page. +Other times, you may instead need to disable the FLR requirement on a device. + +Both can be achieved during attachment with `qvm-pci` as described [PCI Devices documentaton](/doc/pci-devices/#additional-attach-options). + +## "Unable to reset PCI device" errors ## + +### libvirt.libvirtError: internal error: Unable to reset PCI device [...]: internal error: Active [...] devices on bus with [...], not doing bus reset ### + +After running `qvm-start sys-net`, you may encounter an error message which begins with `libvirt.libvirtError: internal error: Unable to reset PCI device`. + +This issue is likely to occur if you have the same device assigned to more than one +VM. +When you try to start sys-net with the `qvm-start sys-net` command, there is already a VM running (e.g., autostarting) with one or more of the same devices as those assigned to sys-net. + +To fix the error, remove the offending PCI device. + +#### Using the Qubes interface #### + +From the "Selected" panel in sys-net, navigate to VM Settings, then Devices. There, you can remove the offending PCI device(s) and keep the desired PCI device. + +#### Using the command line #### + +1. To see all the PCI available devices, enter the `lspci` command into the dom0 terminal. Each device will be listed on a line, for example: + + ~~~ + 0000:03:00.0 Audio device: Intel Corporation Haswell-ULT HD Audio Controller (rev 0b) + ~~~ +In the above output, the BDF (Bus Device Function) of the device is `0000:03:00.0` + +2. Now that you can see all the PCI devices and their BDFs, you can decide which to remove and which to keep. +Imagine we faced the following error message: + + ~~~ + libvirt.libvirtError: internal error: Unable to reset PCI device 0000:03:00.1: internal error: Active 0000:03:00.0 devices on bus with 0000:03:00.1, not doing bus reset + ~~~ +In the above case, the device `0000:03:00.1` is the device which we want to use. But we are facing the `Unable to reset PCI device` error because another device, `0000:03:00.0`, is active. +To fix this error and get device `0000:03:00.1` to work, we must first remove the offending device `0000:03:00.0` + + ~~~ + sudo su + echo -n "1" > /sys/bus/pci/devices/0000:03:00.0/remove + ~~~ + +3. In order to make this change persistent, create a file `/etc/systemd/system/qubes-pre-netvm.service` and add the following: + + ~~~ + [Unit] + Description=Netvm fixup + Before=qubes-netvm.service + + [Service] + ExecStart=/bin/sh -c 'echo -n "1" > /sys/bus/pci/devices/0000:03:00.0/remove' + Type=oneshot + RemainAfterExit=yes + + [Install] + WantedBy=multi-user.target + ~~~ +Finally, run `systemctl enable qubes-pre-netvm.service` and it will now persist between reboots. + +### Domain [...] has failed to start: internal error: Unable to reset PCI device [...]: no FLR, PM reset or bus reset available ### + +This is a [PCI passthrough issue](/doc/pci-troubleshooting/#pci-passthrough-issues), which occurs when PCI arbitrator is too strict. +There is a way to enable permissive mode for it. +Sometimes, you may instead need to disable the FLR requirement on a device. +Both can be achieved during attachment with `qvm-pci` as described below. + +NOTE: The `permissive` flag increases attack surface and possibility of [side channel attacks](https://en.wikipedia.org/wiki/Side-channel_attack). +While using the `no-strict-reset` flag, do not require PCI device to be reset before attaching it to another VM. This may leak usage data even without malicious intent. Both `permissive` and `no-strict-reset` options may not be necessary and you should try one first, then the other, before using both. + +~~~ +qvm-pci attach --persistent --option permissive=true --option no-strict-reset=true sys-usb dom0: +~~~ + +Be sure to replace `` with the BDF of your PCI device, which can be be obtained from running `qvm-pci`. + +You can also configure strict reset directly from the Qubes interface by following these steps: + +1. Go to the sys-net VM settings + +2. Go to Devices + +3. Make sure the device is in the right field + +4. Click "Configure strict reset for PCI devices" + +5. Select the device, click OK and apply + +## Broadcom BCM43602 Wi-Fi card causes system freeze ## + +You may face the problem where the BCM43602 Wi-Fi chip causes a system freeze whenever it is attached to a VM. To fix this problem on a Macbook, follow the steps in [Macbook Troubleshooting](/doc/macbook-troubleshooting/#7-fix-system-freezes-due-to-broadcom-bcm43602). + +For other non-Macbook machines, it is advisable to replace the Broadcom BCM43602 with one known to work on Qubes, such as the Atheros AR9462. + +Note that your computer manufacturer may have added a Wi-Fi card whitelist in your BIOS, which will prevent booting your computer if you have a non-listed wireless card. +It is possible bypass this limitation by removing the whitelist, disabling a check for it or modifying the whitelist to replace device ID of a whitelisted WiFi card with device ID of your new WiFi card. + +## Wireless card stops working after dom0 update ## + +There have been many instances where a Wi-Fi card stops working after a dom0 update. +If you run `sudo dmesg` in sys-net, you may see errors beginning with `iwlwifi`. +You can fix the problem by going to the sys-net VM's settings and changing the VM kernel to the previous version. + +## Attached devices in Windows HVM stop working on suspend/resume ## + +After the whole system gets suspended into S3 sleep and subsequently resumed, some attached devices may stop working. +Refer to [Suspend/Resume Troubleshooting](/doc/suspend-resume-troubleshooting/#attached-devices-in-Windows-HVM-stop-working-on-suspendresume) for a solution. + +## PCI device not available in dom0 after unassigning from a qube ## + +After assigning a PCI device to a qube, then unassigning it/shutting down the qube, the device is not available in dom0. +This is an intended feature. +A device which was previously assigned to a less trusted qube could attack dom0 if it were automatically reassigned there. +Look at the [FAQs](/faq/#i-assigned-a-pci-device-to-a-qube-then-unassigned-itshut-down-the-qube-why-isnt-the-device-available-in-dom0) to learn how to re-enable the device in dom0. + From a02fbd381fcc6b4f8d29ed152d211e0d9e30105b Mon Sep 17 00:00:00 2001 From: Enjeck Cleopatra <32180937+PROTechThor@users.noreply.github.com> Date: Sun, 18 Oct 2020 10:50:36 +0100 Subject: [PATCH 4/8] Fix spelling errors --- user/troubleshooting/pci-troubleshooting.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/user/troubleshooting/pci-troubleshooting.md b/user/troubleshooting/pci-troubleshooting.md index c7d4905b..dbc735cd 100644 --- a/user/troubleshooting/pci-troubleshooting.md +++ b/user/troubleshooting/pci-troubleshooting.md @@ -25,7 +25,7 @@ There is a way to enable permissive mode for it. See also: [this thread](https://groups.google.com/forum/#!topic/qubes-users/Fs94QAc3vQI) and the Xen wiki's [PCI passthrough](https://wiki.xen.org/wiki/Xen_PCI_Passthrough) page. Other times, you may instead need to disable the FLR requirement on a device. -Both can be achieved during attachment with `qvm-pci` as described [PCI Devices documentaton](/doc/pci-devices/#additional-attach-options). +Both can be achieved during attachment with `qvm-pci` as described [PCI Devices documentation](/doc/pci-devices/#additional-attach-options). ## "Unable to reset PCI device" errors ## @@ -35,7 +35,7 @@ After running `qvm-start sys-net`, you may encounter an error message which begi This issue is likely to occur if you have the same device assigned to more than one VM. -When you try to start sys-net with the `qvm-start sys-net` command, there is already a VM running (e.g., autostarting) with one or more of the same devices as those assigned to sys-net. +When you try to start sys-net with the `qvm-start sys-net` command, there is already a VM running (e.g., auto-starting) with one or more of the same devices as those assigned to sys-net. To fix the error, remove the offending PCI device. @@ -131,9 +131,9 @@ You can fix the problem by going to the sys-net VM's settings and changing the V After the whole system gets suspended into S3 sleep and subsequently resumed, some attached devices may stop working. Refer to [Suspend/Resume Troubleshooting](/doc/suspend-resume-troubleshooting/#attached-devices-in-Windows-HVM-stop-working-on-suspendresume) for a solution. -## PCI device not available in dom0 after unassigning from a qube ## +## PCI device not available in dom0 after being unassigned from a qube ## -After assigning a PCI device to a qube, then unassigning it/shutting down the qube, the device is not available in dom0. +After you assign a PCI device to a qube, then unassign it/shut down the qube, the device is not available in dom0. This is an intended feature. A device which was previously assigned to a less trusted qube could attack dom0 if it were automatically reassigned there. Look at the [FAQs](/faq/#i-assigned-a-pci-device-to-a-qube-then-unassigned-itshut-down-the-qube-why-isnt-the-device-available-in-dom0) to learn how to re-enable the device in dom0. From 21ffea448c6f96e527c12bf1fff3d83448adfc6c Mon Sep 17 00:00:00 2001 From: Enjeck Cleopatra <32180937+PROTechThor@users.noreply.github.com> Date: Sun, 18 Oct 2020 11:16:48 +0100 Subject: [PATCH 5/8] Add new section about network adapter --- user/troubleshooting/pci-troubleshooting.md | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/user/troubleshooting/pci-troubleshooting.md b/user/troubleshooting/pci-troubleshooting.md index dbc735cd..38cfd153 100644 --- a/user/troubleshooting/pci-troubleshooting.md +++ b/user/troubleshooting/pci-troubleshooting.md @@ -138,3 +138,10 @@ This is an intended feature. A device which was previously assigned to a less trusted qube could attack dom0 if it were automatically reassigned there. Look at the [FAQs](/faq/#i-assigned-a-pci-device-to-a-qube-then-unassigned-itshut-down-the-qube-why-isnt-the-device-available-in-dom0) to learn how to re-enable the device in dom0. +## Network adapter does not work ## + +You may have an adapter (wired, wireless), that is not compatible with open-source drivers shipped by Qubes. +You may need to install a binary blob, which provides drivers, from the linux-firmware package. + +Open a terminal and run `sudo dnf install linux-firmware` in the TemplateVM upon which your NetVM is based. +You have to restart the NetVM after the TemplateVM has been shut down. From e7ae5f86dba7383ad951dbb4afc5f320e74e40cf Mon Sep 17 00:00:00 2001 From: Enjeck Cleopatra <32180937+PROTechThor@users.noreply.github.com> Date: Mon, 19 Oct 2020 15:11:38 +0100 Subject: [PATCH 6/8] Add info about larger swiotlb value --- user/troubleshooting/pci-troubleshooting.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/user/troubleshooting/pci-troubleshooting.md b/user/troubleshooting/pci-troubleshooting.md index 38cfd153..7fc87a6d 100644 --- a/user/troubleshooting/pci-troubleshooting.md +++ b/user/troubleshooting/pci-troubleshooting.md @@ -18,6 +18,8 @@ To change this allocation, edit VM's kernel parameters (this is expressed in 512 kernelopts : iommu=soft swiotlb=2048 (default) # qvm-prefs -s netvm kernelopts "iommu=soft swiotlb=8192" +The `8192` value is the default value and some devices may require a larger value (like `16384`). + ## PCI Passthrough Issues ## Sometimes the PCI arbitrator is too strict, which may cause errors such as `Unable to reset PCI device` and other PCI-related errors. From 5d7daf471075e321d023100dcd5fd64044cb8c59 Mon Sep 17 00:00:00 2001 From: PROTechThor Date: Sun, 25 Oct 2020 05:59:34 +0100 Subject: [PATCH 7/8] Fix links --- user/advanced-configuration/disposablevm-customization.md | 4 ++-- user/common-tasks/pci-devices.md | 2 +- user/troubleshooting/pci-troubleshooting.md | 2 +- 3 files changed, 4 insertions(+), 4 deletions(-) diff --git a/user/advanced-configuration/disposablevm-customization.md b/user/advanced-configuration/disposablevm-customization.md index 716a1ede..1e14eddd 100644 --- a/user/advanced-configuration/disposablevm-customization.md +++ b/user/advanced-configuration/disposablevm-customization.md @@ -286,7 +286,7 @@ Using DisposableVMs in this manner is ideal for untrusted qubes which require pe ### Starting the DisposableVMs -Prior to starting the new VMs, users should ensure that no other VMs such as the old `sys-net` and `sys-usb` VMs are running. This is because no two VMs can share the same PCI device while both running. It is recommended that users detach the PCI devices from the old VMs without deleting them. This will allow users to reattach the PCI devices if the newly created DisposableVMs fail to start. +Prior to starting the new VMs, users should ensure that no other VMs such as the old `sys-net` and `sys-usb` VMs are running. This is because no two VMs can share the same PCI device while both running. It is recommended that users detach the PCI devices from the old VMs without deleting them. This will allow users to reattach the PCI devices if the newly created DisposableVMs fail to start. Detach PCI device from VM: @@ -295,7 +295,7 @@ Prior to starting the new VMs, users should ensure that no other VMs such as the ### Troubleshooting -If the `disp-sys-usb` does not start, it could be due to a PCI passthrough problem. For more details on this issue along with possible solutions, users can look [here](/doc/pci-devices/#pci-passthrough-issues). +If the `disp-sys-usb` does not start, it could be due to a PCI passthrough problem. For more details on this issue along with possible solutions, users can look [here](/doc/pci-troubleshooting/#pci-passthrough-issues). ## Deleting DisposableVMs diff --git a/user/common-tasks/pci-devices.md b/user/common-tasks/pci-devices.md index e1228dd6..750272be 100644 --- a/user/common-tasks/pci-devices.md +++ b/user/common-tasks/pci-devices.md @@ -81,7 +81,7 @@ For example, if `00_1a.0` is the BDF of the device you want to attach to the "wo ## Possible Issues ## -Visit the [PCI Troubleshooting guide](pci-troubleshoot) to see issues that may arise due to PCI devices and how to troubleshoot them. +Visit the [PCI Troubleshooting guide](/doc/pci-troubleshooting/) to see issues that may arise due to PCI devices and how to troubleshoot them. ## Additional Attach Options ## diff --git a/user/troubleshooting/pci-troubleshooting.md b/user/troubleshooting/pci-troubleshooting.md index 7fc87a6d..8dcabc7e 100644 --- a/user/troubleshooting/pci-troubleshooting.md +++ b/user/troubleshooting/pci-troubleshooting.md @@ -131,7 +131,7 @@ You can fix the problem by going to the sys-net VM's settings and changing the V ## Attached devices in Windows HVM stop working on suspend/resume ## After the whole system gets suspended into S3 sleep and subsequently resumed, some attached devices may stop working. -Refer to [Suspend/Resume Troubleshooting](/doc/suspend-resume-troubleshooting/#attached-devices-in-Windows-HVM-stop-working-on-suspendresume) for a solution. +Refer to [Suspend/Resume Troubleshooting](/doc/suspend-resume-troubleshooting/#attached-devices-in-windows-hvm-stop-working-on-suspendresume) for a solution. ## PCI device not available in dom0 after being unassigned from a qube ## From cf242bdbdf169765c9ac3009964b998507d5b5bf Mon Sep 17 00:00:00 2001 From: Enjeck Cleopatra <32180937+PROTechThor@users.noreply.github.com> Date: Sun, 25 Oct 2020 06:01:03 +0100 Subject: [PATCH 8/8] Update pci-devices.md --- user/common-tasks/pci-devices.md | 1 - 1 file changed, 1 deletion(-) diff --git a/user/common-tasks/pci-devices.md b/user/common-tasks/pci-devices.md index 750272be..c6fd76ff 100644 --- a/user/common-tasks/pci-devices.md +++ b/user/common-tasks/pci-devices.md @@ -143,7 +143,6 @@ or [USB]:/doc/usb-devices/ [appmenu]: /attachment/wiki/Devices/qubes-appmenu-select.png [domain manager icon]: /attachment/wiki/Devices/qubes-logo-icon.png -[pci-troubleshoot]:/doc/pci-troubleshooting [qvm-device]: /doc/device-handling/#general-qubes-device-widget-behavior-and-handling [side channel attacks]: https://en.wikipedia.org/wiki/Side-channel_attack