Merge branch 'master' into usb-troubleshooting
This commit is contained in:
Enjeck Cleopatra
GitHub
commit
cb727f6bed
|
|
@ -7,6 +7,9 @@ permalink: /doc/package-contributions/
|
|||
Package Contributions
|
||||
=====================
|
||||
|
||||
_This page is for developers who wish to contribute packages.
|
||||
If you want to install contributed packages, please see [installing contributed packages]._
|
||||
|
||||
We're very grateful to the talented and hard-working community members who contribute software packages to Qubes OS.
|
||||
This page explains the inclusion criteria and procedures for such packages, as well as the roles and responsibilities of those involved.
|
||||
|
||||
|
|
@ -94,6 +97,7 @@ If you do not wish to be the maintainer of your package, please let us know.
|
|||
If you do not act on your maintainer duties for a given package for an extended period of time and after at least one reminder, we will assume that you no longer wish to be the maintainer for that package.
|
||||
|
||||
|
||||
[installing contributed packages]: /doc/installing-contributed-packages/
|
||||
[Inclusion Criteria]: #inclusion-criteria
|
||||
[Contribution Procedure]: #contribution-procedure
|
||||
[Update Procedure]: #update-procedure
|
||||
|
|
|
|||
25
doc.md
25
doc.md
|
|
@ -122,17 +122,12 @@ Core documentation for Qubes users.
|
|||
|
||||
* [Installation Troubleshooting](/doc/installation-troubleshooting)
|
||||
* [UEFI Troubleshooting](/doc/uefi-troubleshooting/)
|
||||
* [Suspend/Resume Troubleshooting](/doc/suspend-resume-troubleshooting/)
|
||||
* [VM Troubleshooting](/doc/vm-troubleshooting/)
|
||||
* [HVM Troubleshooting](/doc/hvm-troubleshooting/)
|
||||
* [Disk Troubleshooting](/doc/disk-troubleshooting/)
|
||||
* [PCI Troubleshooting](/doc/pci-troubleshooting/)
|
||||
* [USB Troubleshooting](/doc/usb-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/)
|
||||
* [Lenovo ThinkPad Troubleshooting](/doc/thinkpad-troubleshooting/)
|
||||
* [Apple MacBook Troubleshooting](/doc/macbook-troubleshooting/)
|
||||
* [Getting Sony Vaio Z laptop to work with Qubes](/doc/sony-vaio-tinkering/)
|
||||
* [Fixing wireless on suspend & resume](/doc/wireless-troubleshooting/)
|
||||
* [How to remove VMs manually](/doc/remove-vm-manually/)
|
||||
* [Intel Integrated Graphics Troubleshooting](/doc/intel-igfx-troubleshooting/)
|
||||
|
||||
### Reference Pages
|
||||
|
||||
|
|
@ -275,6 +270,16 @@ For more, please see [Qubes Community Documentation](https://github.com/Qubes-Co
|
|||
* [Dark Theme in Dom0 and DomU](/doc/dark-theme/)
|
||||
* [Safely Removing TemplateVM Packages (Example: Thunderbird)](/doc/removing-templatevm-packages/)
|
||||
|
||||
### 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/)
|
||||
* [Lenovo ThinkPad Troubleshooting](/doc/thinkpad-troubleshooting/)
|
||||
* [Apple MacBook Troubleshooting](/doc/macbook-troubleshooting/)
|
||||
* [Getting Sony Vaio Z laptop to work with Qubes](/doc/sony-vaio-tinkering/)
|
||||
* [Intel Integrated Graphics Troubleshooting](/doc/intel-igfx-troubleshooting/)
|
||||
|
||||
### Building Guides
|
||||
|
||||
* [Building a TemplateVM based on a new OS (ArchLinux example)](/doc/building-non-fedora-template/)
|
||||
|
|
|
|||
|
|
@ -14,41 +14,7 @@ Tips for Linux in HVM domain
|
|||
How to fix bootup kernel error
|
||||
-------------------------------
|
||||
|
||||
The HVM may pause on boot, showing a fixed cursor.
|
||||
After a while a series of warnings may be shown similar to this:
|
||||
|
||||
BUG: soft lockup - CPU#0 stuck for 23s! [systemd-udevd:244]
|
||||
|
||||
To fix this:
|
||||
|
||||
1. Kill the HVM.
|
||||
1. Start the HVM
|
||||
1. Press "e" at the grub screen to edit the boot parameters
|
||||
1. Find the /vmlinuz line, and edit it to replace "rhgb" with "modprobe.blacklist=bochs_drm"
|
||||
1. Press "Ctrl-x" to start the HVM
|
||||
|
||||
If this solves the problem then you will want to make the change permanent:
|
||||
|
||||
1. Edit the file `/etc/default/grub`.
|
||||
1. Find the line which starts:
|
||||
~~~
|
||||
GRUB_CMDLINE_LINUX=
|
||||
~~~
|
||||
1. Remove this text from that line:
|
||||
~~~
|
||||
rhgb
|
||||
~~~
|
||||
1. Add this text to that line:
|
||||
~~~
|
||||
modprobe.blacklist=bochs_drm
|
||||
~~~
|
||||
1. Run this command:
|
||||
~~~
|
||||
grub2-mkconfig --output=/boot/grub2/grub.cfg
|
||||
~~~
|
||||
|
||||
The HVM should now start normally.
|
||||
|
||||
If the HVM pauses on boot and shows a series of warnings, visit [HVM Troubleshooting](/doc/hvm-troubleshooting/#hvm-pauses-on-boot-followed-by-kernel-error) for a fix.
|
||||
|
||||
Screen resolution
|
||||
-----------------
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -0,0 +1,51 @@
|
|||
---
|
||||
layout: doc
|
||||
title: Installing contributed packages
|
||||
permalink: /doc/installing-contributed-packages/
|
||||
---
|
||||
|
||||
# Installing contributed packages
|
||||
|
||||
_This page is for users who wish to install contributed packages.
|
||||
If you want to contribute a package, please see [package contributions]._
|
||||
|
||||
|
||||
Qubes OS contributed packages are available under the [QubesOS-contrib] GitHub Project.
|
||||
This is a place where our community can [contribute Qubes OS related packages, additions and various customizations][package contributions].
|
||||
|
||||
## Installing the repositories
|
||||
|
||||
If you want to install one of these packages, first you need to enable the repository in your system (dom0 and/or templates). This can be done by installing the `qubes-repo-contrib` package. This package includes the repository definition and keys necessary to download, verify, and install [QubesOS-contrib] packages.
|
||||
|
||||
In dom0, use `qubes-dom0-update`:
|
||||
|
||||
sudo qubes-dom0-update qubes-repo-contrib
|
||||
|
||||
In a Fedora-based template, use `dnf`:
|
||||
|
||||
sudo dnf install qubes-repo-contrib
|
||||
|
||||
In a Debian-based template, use `apt`:
|
||||
|
||||
sudo apt update && sudo apt install qubes-repo-contrib
|
||||
|
||||
The new repository definition will be in the usual location for your distro, and it will follow the naming pattern `qubes-contrib-*`, depending on your Qubes release and whether it is in dom0 or a TemplateVM.
|
||||
For example, in a Fedora TemplateVM on Qubes 4.0, the new repository definition would be:
|
||||
|
||||
/etc/yum.repos.d/qubes-contrib-vm-r4.0.repo
|
||||
|
||||
## Installing packages
|
||||
|
||||
After you've installed the repositories, you can install contributed packages.
|
||||
|
||||
**Note:** The first time you install a contrib package in dom0, you must use the `--clean` flag.
|
||||
|
||||
For example, to install `qvm-screenshot-tool` in dom0:
|
||||
|
||||
sudo qubes-dom0-update --clean qvm-screenshot-tool
|
||||
|
||||
Please see the package's README for specific installation and setup instructions.
|
||||
|
||||
[package contributions]: /doc/package-contributions/
|
||||
[QubesOS-contrib]: https://github.com/QubesOS-contrib/
|
||||
|
||||
|
|
@ -355,12 +355,7 @@ The output should look like this:
|
|||
|
||||
#### Troubleshooting
|
||||
|
||||
In case of problems, you can access the VM console using `qvm-console-dispvm VMNAME` in dom0, then access the GRUB menu.
|
||||
You need to call it just after starting the VM (until `GRUB_TIMEOUT` expires); for example, in a separate dom0 terminal window.
|
||||
|
||||
In any case you can later access the VM's logs (especially the VM console log `/var/log/xen/console/guest-VMNAME.log`).
|
||||
|
||||
You can always set the kernel back to some dom0-provided value to fix a VM kernel installation.
|
||||
In case of problems, visit the [VM Troubleshooting guide](/doc/vm-troubleshooting/#vm-kernel-troubleshooting) to learn how to access the VM console, view logs and fix a VM kernel installation.
|
||||
|
||||
|
||||
[dom0-kernel-upgrade]: /doc/software-update-dom0/#kernel-upgrade
|
||||
|
|
|
|||
|
|
@ -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](/doc/pci-troubleshooting/) to see issues that may arise due to PCI devices and how to troubleshoot them.
|
||||
|
||||
## Additional Attach Options ##
|
||||
|
||||
|
|
@ -168,7 +145,4 @@ or
|
|||
[domain manager icon]: /attachment/wiki/Devices/qubes-logo-icon.png
|
||||
[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
|
||||
|
||||
|
|
|
|||
|
|
@ -122,6 +122,10 @@ sudo qubes-dom0-update --enablerepo=qubes-dom0-unstable
|
|||
To enable or disable any of these repos permanently, change the corresponding `enabled` value to `1` in
|
||||
`/etc/yum.repos.d/qubes-dom0.repo`.
|
||||
|
||||
## Contributed package repository
|
||||
|
||||
Please see [installing contributed packages].
|
||||
|
||||
## Kernel upgrade
|
||||
|
||||
This section describes upgrading the kernel in dom0 and domUs.
|
||||
|
|
@ -219,4 +223,5 @@ For example: sys-whonix.
|
|||
[testing]: /doc/testing/
|
||||
[troubleshooting newer hardware]: /doc/newer-hardware-troubleshooting/
|
||||
[Managing VM kernel]: /doc/managing-vm-kernel/
|
||||
[installing contributed packages]: /doc/installing-contributed-packages/
|
||||
|
||||
|
|
|
|||
|
|
@ -43,6 +43,9 @@ Advanced users can execute the standard update command for that operating system
|
|||
|
||||
If you wish to install updates that are still in [testing], you must enable the appropriate testing repositories.
|
||||
|
||||
## Contributed package repository
|
||||
|
||||
Please see [installing contributed packages].
|
||||
|
||||
### Fedora
|
||||
|
||||
|
|
@ -314,4 +317,5 @@ Note that the app will autostart only when the AppVM starts. If you would like t
|
|||
[RPM Fusion]: http://rpmfusion.org/
|
||||
[service framework]: /doc/qubes-service/
|
||||
[How to Reinstall a TemplateVM]: /doc/reinstall-template/
|
||||
[installing contributed packages]: /doc/installing-contributed-packages/
|
||||
|
||||
|
|
|
|||
|
|
@ -103,17 +103,7 @@ The lesson is that you should carefully look at what is being installed to your
|
|||
|
||||
### Package installation errors in Qubes 4.0
|
||||
|
||||
By default, templates in 4.0 only have a loopback interface.
|
||||
|
||||
Some packages will throw an error on installation in this situation.
|
||||
For example, Samba expects to be configured using a network interface post installation.
|
||||
|
||||
One solution is to add a dummy interface to allow the package to install correctly:
|
||||
|
||||
ip link add d0 type dummy
|
||||
ip addr add 192.168.0.1/24 dev d0
|
||||
ip link set d0 up
|
||||
|
||||
If some packages throw installation errors, see [this guide.](/doc/vm-troubleshooting/#fixing-package-installation-errors)
|
||||
|
||||
[TemplateVM]: /doc/templates/
|
||||
[Minimal TemplateVMs]: /doc/templates/minimal/
|
||||
|
|
|
|||
|
|
@ -0,0 +1,145 @@
|
|||
---
|
||||
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 ##
|
||||
|
||||
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.
|
||||
Running the `df -h` command in dom0 terminal will show some information, but not include all the relevant details.
|
||||
The Qubes user interface provides a disk space widget.
|
||||
If you are unable to access the interface, the command line version is running `sudo lvs | head` and looking at top entry for LVM pool.
|
||||
For example:
|
||||
|
||||
~~~
|
||||
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert
|
||||
pool00 qubes_dom0 twi-aotz-- 453.17g 89.95 69.78
|
||||
root qubes_dom0 Vwi-aotz-- 453.17g pool00 5.87
|
||||
swap qubes_dom0 -wi-ao---- 7.57g
|
||||
~~~
|
||||
|
||||
If you run `df -h`, it only shows the information in the `root` line (which is already included in the `pool00` line).
|
||||
As you can see, the `sudo lvs | head` command includes additional important columns `Data%` and `Meta%`, shown in the above example to have the values 89% and 69% respectively.
|
||||
|
||||
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.
|
||||
|
||||
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 dnf 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 <VMname>
|
||||
~~~
|
||||
|
||||
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). Also look for unneeded files in `/var/log` in dom0, and `/var/log/qubes`.
|
||||
|
||||
The above steps applies to old VM disks format. These steps may work on Qubes 4.0, but are not default anymore. By default, Qubes 4.0 now uses LVM. The equivalent steps are:
|
||||
|
||||
1. Get a list of VM disks using `sudo lvs`.
|
||||
|
||||
2. Use `sudo lvremove qubes_dom0/<name>` to remove backup copies of some less important VMs -- entries with `-back` in their name.
|
||||
|
||||
3. If that isn't enough, remove actual disks of less important VMs. NOTE: You will lose the data of that VM, but your system will resume working.
|
||||
|
||||
For example:
|
||||
|
||||
~~~
|
||||
$ sudo lvs
|
||||
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert
|
||||
pool00 qubes_dom0 twi-aotz-- 453.17g 89.95 69.78
|
||||
root qubes_dom0 Vwi-aotz-- 453.17g pool00 5.87
|
||||
swap qubes_dom0 -wi-ao---- 7.57g
|
||||
(...)
|
||||
vm-d10test-private qubes_dom0 Vwi-a-tz-- 2.00g pool00 vm-d10test-private-1600961860-back 29.27
|
||||
vm-d10test-private-1600961860-back qubes_dom0 Vwi-a-tz-- 2.00g pool00 4.87
|
||||
vm-d10test-standalone-private qubes_dom0 Vwi-a-tz-- 2.00g pool00 vm-d10test-standalone-private-1580772439-back 4.90
|
||||
vm-d10test-standalone-private-1580772439-back qubes_dom0 Vwi-a-tz-- 2.00g pool00 4.87
|
||||
vm-d10test-standalone-root qubes_dom0 Vwi-a-tz-- 10.00g pool00 vm-d10test-standalone-root-1580772439-back 43.37
|
||||
vm-d10test-standalone-root-1580772439-back qubes_dom0 Vwi-a-tz-- 10.00g pool00 42.05
|
||||
vm-debian-10-my-private qubes_dom0 Vwi-a-tz-- 2.00g pool00 4.96
|
||||
vm-debian-10-my-root qubes_dom0 Vwi-a-tz-- 10.00g pool00 vm-debian-10-my-root-1565013689-back 57.99
|
||||
vm-debian-10-my-root-1565013689-back qubes_dom0 Vwi-a-tz-- 10.00g pool00 56.55
|
||||
vm-debian-10-private qubes_dom0 Vwi-a-tz-- 2.00g pool00 4.94
|
||||
vm-debian-10-root qubes_dom0 Vwi-a-tz-- 10.00g pool00 vm-debian-10-root-1601126126-back 93.44
|
||||
vm-debian-10-root-1601126126-back qubes_dom0 Vwi-a-tz-- 10.00g pool00 88.75
|
||||
(...)
|
||||
$ sudo lvremove qubes_dom0/vm-d10test-standalone-root-1580772439-back
|
||||
Do you really want to remove and DISCARD active logical volume qubes_dom0/vm-d10test-standalone-root-1580772439-back? [y/n]: y
|
||||
Logical volume "vm-d10test-standalone-root-1580772439-back" successfully removed
|
||||
~~~
|
||||
|
||||
After freeing some initial space, it may be possible to recover more space by deleting files in a userVM after connecting to the userVM terminal:
|
||||
|
||||
~~~
|
||||
qvm-start <VMname>
|
||||
qvm-console-dispvm <VMname>
|
||||
~~~
|
||||
|
||||
Since `qvm-console-dispvm` requires working graphical user interface login, you must first free enough space to be able to start a VM and login to graphical UI.
|
||||
|
||||
## 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:
|
||||
|
||||
~~~
|
||||
qvm-console-dispvm 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 <process ID>`.
|
||||
|
||||
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.
|
||||
|
|
@ -0,0 +1,65 @@
|
|||
---
|
||||
layout: doc
|
||||
title: HVM Troubleshooting
|
||||
permalink: /doc/hvm-troubleshooting/
|
||||
|
||||
---
|
||||
|
||||
# HVM Troubleshooting #
|
||||
|
||||
## HVM pauses on boot, followed by kernel error ##
|
||||
|
||||
The HVM may pause on boot, showing a fixed cursor.
|
||||
After a while a series of warnings may be shown similar to this:
|
||||
|
||||
BUG: soft lockup - CPU#0 stuck for 23s! [systemd-udevd:244]
|
||||
|
||||
To fix this:
|
||||
|
||||
1. Kill the HVM.
|
||||
1. Start the HVM
|
||||
1. Press "e" at the grub screen to edit the boot parameters
|
||||
1. Find the /vmlinuz line, and edit it to replace "rhgb" with "modprobe.blacklist=bochs_drm"
|
||||
1. Press "Ctrl-x" to start the HVM
|
||||
|
||||
If this solves the problem then you will want to make the change permanent:
|
||||
|
||||
1. Edit the file `/etc/default/grub`.
|
||||
1. Find the line which starts:
|
||||
~~~
|
||||
GRUB_CMDLINE_LINUX=
|
||||
~~~
|
||||
1. Remove this text from that line:
|
||||
~~~
|
||||
rhgb
|
||||
~~~
|
||||
1. Add this text to that line:
|
||||
~~~
|
||||
modprobe.blacklist=bochs_drm
|
||||
~~~
|
||||
1. Run this command:
|
||||
~~~
|
||||
grub2-mkconfig --output=/boot/grub2/grub.cfg
|
||||
~~~
|
||||
|
||||
The HVM should now start normally.
|
||||
|
||||
## Can't start an OS in an HVM / "Probing EDD (edd=off to disable!... ok" message ##
|
||||
|
||||
If you see a screen popup with SeaBios and 4 lines, last one being `Probing EDD (edd=off to disable!... ok`, then enter the following command from a `dom0` prompt:
|
||||
|
||||
qvm-prefs <HVMname> kernel ""
|
||||
|
||||
## HVM crashes when booting from ISO ##
|
||||
If your HVM crashes when trying to boot an ISO, first ensure that ` qvm-prefs <HVMname> 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.
|
||||
|
||||
To give the VM a RAM of 2GB, open a terminal in `dom0` and enter:
|
||||
|
||||
qvm-prefs <HVMname> memory 2000
|
||||
|
||||
## 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. To know how to make the devices work, see [Suspend/resume Troubleshooting](/doc/suspend-resume-troubleshooting/#attached-devices-in-windows-hvm-stop-working-on-suspendresume).
|
||||
|
|
@ -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 <VMname>
|
||||
qvm-console-dispvm <VMname>
|
||||
~~~
|
||||
|
||||
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 <VMname>
|
||||
~~~
|
||||
|
||||
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).
|
||||
|
||||
|
|
@ -0,0 +1,149 @@
|
|||
---
|
||||
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"
|
||||
|
||||
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.
|
||||
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 documentation](/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., 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.
|
||||
|
||||
#### 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:<BDF_OF_DEVICE>
|
||||
~~~
|
||||
|
||||
Be sure to replace `<BDF_OF_DEVICE>` 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 being unassigned from a qube ##
|
||||
|
||||
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.
|
||||
|
||||
## 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.
|
||||
|
|
@ -1,19 +1,18 @@
|
|||
---
|
||||
layout: doc
|
||||
title: Wireless Troubleshooting
|
||||
permalink: /doc/wireless-troubleshooting/
|
||||
title: Suspend/Resume Troubleshooting
|
||||
permalink: /doc/suspend-resume-troubleshooting/
|
||||
redirect_from:
|
||||
- /en/doc/wireless-troubleshooting/
|
||||
- /doc/wireless-troubleshooting/
|
||||
---
|
||||
|
||||
Wireless Troubleshooting Guide
|
||||
==============================
|
||||
# Troubleshooting problems relating to suspend/resume #
|
||||
|
||||
## Network-Manager says “Device not ready” on suspend/resume ##
|
||||
|
||||
These instructions may help with suspend/resume issues for more devices than just wireless cards, that is just the (unfortunately not uncommon) example used here.
|
||||
|
||||
Resetting wireless cards by reloading drivers
|
||||
---------------------------------------------
|
||||
|
||||
If your wireless card works, but after suspending and resuming your computer, the Network-Manager applet just says "Device not ready", then try un-loading and re-loading the driver.
|
||||
|
||||
### Determining your wireless card driver ###
|
||||
|
|
@ -104,8 +103,7 @@ depends: cfg80211
|
|||
[user@sys-net ~]$ sudo modprobe iwlmvm
|
||||
~~~
|
||||
|
||||
Automatically reloading drivers on suspend/resume
|
||||
-------------------------------------------------
|
||||
## Drivers do not reload automatically on suspend/resume ##
|
||||
|
||||
If reloading the driver (which resets the hardware into a known-state) resolves your issue when done manually, you can have Qubes automatically un/reload them on suspend & resume by listing the relevant modules in `/rw/config/suspend-module-blacklist`.
|
||||
|
||||
|
|
@ -119,3 +117,18 @@ In the above example, it would look like this:
|
|||
iwlmvm
|
||||
iwlwifi
|
||||
~~~
|
||||
|
||||
## Power consumption increases on suspend/resume ##
|
||||
|
||||
This problem is related to the software method used to disable sibling threads and how it interacts with suspend/resume.
|
||||
To solve the problem, disable hyper-threading in the BIOS. This [external guide](https://www.pcmag.com/news/how-to-disable-hyperthreading) explains how to disable hyper-threading.
|
||||
Since Qubes does disable hyperthreading by default (by not using secondary threads), you won't pay any performance cost.
|
||||
|
||||
## 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. To make the devices work, they should be restarted within the VM.
|
||||
This can be achieved under a Windows HVM by opening the Device Manager, selecting the actual device (such as a USB controller), 'Disabling' the device, and then 'Enabling' the device again.
|
||||
This is illustrated on the screenshot below:
|
||||
|
||||
|
||||
|
||||
|
|
@ -0,0 +1,73 @@
|
|||
---
|
||||
layout: doc
|
||||
title: VM Troubleshooting
|
||||
permalink: /doc/vm-troubleshooting/
|
||||
redirect_from:
|
||||
- /doc/remove-vm-manually/
|
||||
---
|
||||
|
||||
# VM troubleshooting #
|
||||
|
||||
## VM Kernel troubleshooting ##
|
||||
|
||||
This troubleshoot applies to the non-default kernel choice described in the [Managing VM docs](https://www.qubes-os.org/doc/managing-vm-kernel/#using-kernel-installed-in-the-vm).
|
||||
|
||||
In case of problems, you can access the VM console using `qvm-console-dispvm VMNAME` in dom0, then access the GRUB menu.
|
||||
You need to call it just after starting the VM (until `GRUB_TIMEOUT` expires); for example, in a separate dom0 terminal window.
|
||||
|
||||
In any case you can later access the VM's logs (especially the VM console log `/var/log/xen/console/guest-VMNAME.log`).
|
||||
|
||||
You can always set the kernel back to some dom0-provided value to fix a VM kernel installation.
|
||||
|
||||
## Qubes starts, but no VMs load ##
|
||||
|
||||
First, try to start a particular VM, check any failure message and direct further steps based on that.
|
||||
|
||||
This issue has been seen to occur if a dom0 update is interrupted halfway through and/or a hard power off is done without shutting down Qubes, which results in files getting corrupted.
|
||||
|
||||
## Can not uninstall a VM / “ERROR: VM installed by package manager: template-vm-name”
|
||||
|
||||
Try the [normal method] before resorting to this method to remove a VM manually.
|
||||
All of the following commands should be executed in a dom0 terminal.
|
||||
|
||||
When a template is marked as 'installed by package manager', but cannot be uninstalled there, trying to uninstall manually will result in the error "ERROR: VM installed by package manager: template-vm-name". Do as follows to be able to uninstall the template:
|
||||
|
||||
1. Check the state of `installed_by_rpm`
|
||||
|
||||
$ qvm-prefs template-vm-name
|
||||
|
||||
2. If `installed_by_rpm - True]`, mark the template as not installed by package manager
|
||||
|
||||
$ qvm-prefs template-vm-name installed_by_rpm false
|
||||
|
||||
3. Re-check the state of `installed_by_rpm`
|
||||
|
||||
- If `installed_by_rpm - False`, remove the template like you would a regular qube:
|
||||
|
||||
$ qvm-remove template-vm-name
|
||||
|
||||
- If `installed_by_rpm` remains `True`, reboot your computer to bring qubes.xml in sync with qubesd, and try again to remove the template.
|
||||
|
||||
|
||||
[normal method]: /doc/templates/#uninstalling
|
||||
|
||||
|
||||
## Fixing package installation errors ##
|
||||
|
||||
By default, templates in 4.0 only have a loopback interface.
|
||||
|
||||
Some packages will throw an error on installation in this situation.
|
||||
For example, Samba expects to be configured using a network interface post installation.
|
||||
|
||||
One solution is to add a dummy interface to allow the package to install correctly:
|
||||
|
||||
ip link add d0 type dummy
|
||||
ip addr add 192.168.0.1/24 dev d0
|
||||
ip link set d0 up
|
||||
|
||||
## "Cannot connect to qrexec agent" error ##
|
||||
|
||||
If you face this error when starting a VM, look into the VM logs at `/var/log/xen/console/guest-VMNAME.log`.
|
||||
Common reasons that may be revealed are: too low memory, corrupted files or a VM crash on startup.
|
||||
|
||||
If the error occurs as a result of too little initial memory, increase the initial memory from 200MB to 400MB by navigating to VM settings » Advanced » Initial memory.
|
||||
Loading…
Reference in New Issue