diff --git a/developer/general/doc-guidelines.md b/developer/general/doc-guidelines.md index 79bb1d26..55f8d9a8 100644 --- a/developer/general/doc-guidelines.md +++ b/developer/general/doc-guidelines.md @@ -18,6 +18,22 @@ The documentation is a community effort. Volunteers work hard trying to keep eve If you notice a problem or some way it can be improved, please [edit the documentation][contribute]! +Security +-------- + +All pull requests against [qubes-doc] must pass review prior to be merged, except in the case of [external documentation] (see [#4693]). +This process is designed to ensure that contributed text is accurate and non-malicious. +This process is a best effort that should provide a reasonable degree of assurance, but it is not foolproof. +For example, all text characters are checked for ANSI escape sequences. +However, binaries, such as images, are simply checked to ensure they appear or function the way they should when the website is rendered. +They are not further analyzed in an attempt to determine whether they are malicious. + +Once a pull request passes review, the reviewer should add a signed comment stating, "Passed review as of ``" (or similar). +The documentation maintainer then verifies that the pull request is mechanically sound (no merge conflicts, broken links, ANSI escapes, etc.). +If so, the documentation maintainer then merges the pull request, adds a PGP-signed tag to the latest commit (usually the merge commit), then pushes to the remote. +In cases in which another reviewer is not required, the documentation maintainer may review the pull request (in which case no signed comment is necessary, since it would be redundant with the signed tag). + + Questions, problems, and improvements ------------------------------------- @@ -304,4 +320,5 @@ Please try to write good commit messages, according to the [git-commit]: /doc/coding-style/#commit-message-guidelines [render the site locally]: https://github.com/QubesOS/qubesos.github.io#instructions [qubes-attachment]: https://github.com/QubesOS/qubes-attachment - +[external documentation]: /doc/#external-documentation +[#4693]: https://github.com/QubesOS/qubes-issues/issues/4693 diff --git a/doc.md b/doc.md index dcfeecd2..d95aa586 100644 --- a/doc.md +++ b/doc.md @@ -126,6 +126,8 @@ Core documentation for Qubes users. * [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/) * [GUI Troubleshooting](/doc/gui-troubleshooting/) ### Reference Pages diff --git a/introduction/faq.md b/introduction/faq.md index 516491a7..3ea75e7f 100644 --- a/introduction/faq.md +++ b/introduction/faq.md @@ -278,7 +278,7 @@ This website is hosted on [GitHub Pages][] ([why?][]). Therefore, it is largely outside of our control. We don't consider this a problem, however, since we explicitly [distrust the infrastructure]. For this reason, we don't think that anyone should place undue trust in the live version of this site on the Web. -Instead, if you want to obtain your own trustworthy copy of this website in a secure way, you should clone our [website repo], [verify the PGP signatures on the commits and/or tags] signed by the [doc-signing keys], then either [render the site on your local machine][render] or simply read the source, the vast majority of which was [intentionally written in Markdown so as to be readable as plain text for this very reason][Markdown]. +Instead, if you want to obtain your own trustworthy copy of this website in a secure way, you should clone our [website repo], [verify the PGP signatures on the commits and/or tags] signed by the [doc-signing keys] (which indicates that the content has undergone review per our [documentation guidelines]), then either [render the site on your local machine][render] or simply read the source, the vast majority of which was [intentionally written in Markdown so as to be readable as plain text for this very reason][Markdown]. We've gone to special effort to set all of this up so that no one has to trust the infrastructure and so that the contents of this website are maximally available and accessible. ### What does it mean to "distrust the infrastructure"? @@ -487,43 +487,7 @@ Enable "debug mode" in the qube's settings, either by checking the box labeled " ### I created a usbVM and assigned usb controllers to it. Now the usbVM wont boot. This is probably because one of the controllers does not support reset. -In Qubes R2 any such errors were ignored. In Qubes R3.x they are not. -In R4.x, devices that are automatically added to sys-net and sys-usb on install but do not support FLR will be attached with the no-strict-reset option, but see the related warning in the last sentence in this answer. - -A device that does not support reset is not ideal and generally should not be assigned to a VM. - -Most likely the offending controller is a USB 3.0 device. -You can remove this controller from the usbVM, and see if this allows the VM to boot. -Alternatively you may be able to disable USB 3.0 in the BIOS. -If the BIOS does not have the option to disable USB 3.0, try running the following command in dom0 to [force USB 2.0 modes for the USB ports][force_usb2]: - - lspci -nn | grep USB | cut -d '[' -f3 | cut -d ']' -f1 | xargs -I@ setpci -H1 -d @ d0.l=0 - - -Errors suggesting this issue: - - - in `xl dmesg` output: - - (XEN) [VT-D] It's disallowed to assign 0000:00:1a.0 with shared RMRR at dbe9a000 for Dom19. - (XEN) XEN_DOMCTL_assign_device: assign 0000:00:1a.0 to dom19 failed (-1) - - - during `qvm-start sys-usb`: - - internal error: Unable to reset PCI device [...] no FLR, PM reset or bus reset available. - - -Another solution would be to set the pci_strictreset option in dom0: - - - In Qubes R4.x, when attaching the PCI device to the VM (where `` can be obtained from running `qvm-pci`): - - qvm-pci attach --persistent --option no-strict-reset=true usbVM dom0: - - - In Qubes R3.x, by modifying the VM's properties: - - qvm-prefs usbVM -s pci_strictreset false - -These options allow the VM to ignore the error and the VM will start. -Please review the notes in the `qvm-prefs` man page and [here][assign_devices] and be aware of the potential risks. +See the [USB Troubleshooting guide](/doc/usb-troubleshooting/#usbvm-does-not-boot-after-creating-and-assigning-usb-controllers-to-it). ### I assigned a PCI device to a qube, then unassigned it/shut down the qube. Why isn't the device available in dom0? diff --git a/introduction/intro.html b/introduction/intro.html index 94469289..9aa959eb 100644 --- a/introduction/intro.html +++ b/introduction/intro.html @@ -186,8 +186,8 @@ redirect_from:

- - + Qube Manager
@@ -268,8 +268,8 @@ redirect_from:

- - + Qubes desktop screenshot
diff --git a/introduction/screenshots.md b/introduction/screenshots.md index 0f15d5f6..2b85df3f 100644 --- a/introduction/screenshots.md +++ b/introduction/screenshots.md @@ -11,19 +11,19 @@ redirect_from: Select Qubes OS Screenshots =========================== -[![r32-xfce-desktop.png](/attachment/wiki/QubesScreenshots/r32-xfce-desktop.png)](/attachment/wiki/QubesScreenshots/r32-xfce-desktop.png) +[![r4.1-xfce-desktop.png](/attachment/wiki/QubesScreenshots/r4.1-xfce-desktop.png)](/attachment/wiki/QubesScreenshots/r4.1-xfce-desktop.png) The default desktop environment is Xfce4. * * * * * -[![r2b2-kde-start-menu.png](/attachment/wiki/QubesScreenshots/r2b2-kde-start-menu.png)](/attachment/wiki/QubesScreenshots/r2b2-kde-start-menu.png) +[![r4.1-xfce-start-menu.png](/attachment/wiki/QubesScreenshots/r4.1-xfce-start-menu.png)](/attachment/wiki/QubesScreenshots/r4.1-xfce-start-menu.png) Starting applications from different domains (AppVMs) is very easy. * * * * * -[![r2b2-kde-three-domains-at-work.png](/attachment/wiki/QubesScreenshots/r2b2-kde-three-domains-at-work.png)](/attachment/wiki/QubesScreenshots/r2b2-kde-three-domains-at-work.png) +[![r4.1-xfce-three-domains-at-work.png](/attachment/wiki/QubesScreenshots/r4.1-xfce-three-domains-at-work.png)](/attachment/wiki/QubesScreenshots/r4.1-xfce-three-domains-at-work.png) In this example, the word processor runs in the “work” domain, which has been assigned the “green” label. It is fully isolated from other domains, such as the “untrusted” domain (assigned the “red” label -- “Watch out!”, “Danger!”) used for random Web browsing, news reading, as well as from the "work-web" domain (assigned the "yellow" label), which is used for work-related Web browsing that is not security critical. Apps from different domains run in different AppVMs and have different X servers, filesystems, etc. Notice the different color frames (labels) and VM names in the titlebars. These are drawn by the trusted Window Manager running in Dom0, and apps running in domains cannot fake them: @@ -41,61 +41,60 @@ Windows AppVMs are fully integrated with the rest of the Qubes OS system, which * * * * * -[![r2b2-xfce4-programmers-desktop-2.png](/attachment/wiki/QubesScreenshots/r2b2-xfce4-programmers-desktop-2.png)](/attachment/wiki/QubesScreenshots/r2b2-xfce4-programmers-desktop-2.png) +[![r4.1-xfce-programmers-desktop.png](/attachment/wiki/QubesScreenshots/r4.1-xfce-programmers-desktop.png)](/attachment/wiki/QubesScreenshots/r4.1-xfce-programmers-desktop.png) Here we see Xfce4.10 Window Manager running in Dom0 (instead of KDE as on previous screens). Qubes supports customized Xfce4 in dom0 beginning with R2 Beta 2! * * * * * -[![password-prompt.png](/attachment/wiki/QubesScreenshots/password-prompt.png)](/attachment/wiki/QubesScreenshots/password-prompt.png) +[![r4.1-password-prompt.png](/attachment/wiki/QubesScreenshots/r4.1-password-prompt.png)](/attachment/wiki/QubesScreenshots/r4.1-password-prompt.png) It is always clearly visible to which domain a given window belongs. Here it’s immediately clear that the passphrase-prompting window belongs to some domain with the “green” label. When we look at the titlebar, we see “[work]”, which is the name of the actual domain. Theoretically, the untrusted application (here, the “red” Firefox) beneath the prompt window could draw a similar looking window within its contents. In practice, this would be very hard, because it doesn’t know, e.g., the exact decoration style that is in use. However, if this is a concern, the user can simply try to move the more trusted window onto some empty space on the desktop such that no other window is present beneath it. Or, better yet, use the Expose-like effect (available via a hot-key). A malicious application from an untrusted domain cannot spoof the whole desktop because the trusted Window Manager will never let any domain “own” the whole screen. Its titlebar will always be visible. * * * * * -[![r2b2-kde-tray-icons.png](/attachment/wiki/QubesScreenshots/r2b2-kde-tray-icons.png)](/attachment/wiki/QubesScreenshots/r2b2-kde-tray-icons.png) +[![r4.1-xfce-tray-icons.png](/attachment/wiki/QubesScreenshots/r4.1-xfce-tray-icons.png)](/attachment/wiki/QubesScreenshots/r4.1-xfce-tray-icons.png) Qubes is all about seamless integration from the user’s point of view. Here you can see how it virtualizes tray icons from other domains. Notice the network icon in a red frame. This icon is in fact managed by the Network Manager running in a separate NetVM. The notes icon (with the green frame around it) has been drawn by the note-taking app running in the work domain (which has the "green" label). * * * * * -[![r2b2-manager-and-netvm-network-prompt.png](/attachment/wiki/QubesScreenshots/r2b2-manager-and-netvm-network-prompt.png)](/attachment/wiki/QubesScreenshots/r2b2-manager-and-netvm-network-prompt.png) - -All the networking runs in a special, unprivileged NetVM. (Notice the red frame around the Network Manager dialog box on the screen above.) This means that in the event that your network card driver, Wi-Fi stack, or DHCP client is compromised, the integrity of the rest of the system will not be affected! This feature requires Intel VT-d or AMD IOMMU hardware (e.g., Core i5/i7 systems). +[![r4.1-manager-and-sysnet-network-prompt.png](/attachment/wiki/QubesScreenshots/r4.1-manager-and-sysnet-network-prompt.png)](/attachment/wiki/QubesScreenshots/r4.1-manager-and-sysnet-network-prompt.png) +All the networking runs in a special, unprivileged NetVM. (Notice the red frame around the Network Manager dialog box on the screen above.) This means that in the event that your network card driver, Wi-Fi stack, or DHCP client is compromised, the integrity of the rest of the system will not be affected! This feature requires Intel VT-d or AMD IOMMU hardware (e.g., Core i5/i7 systems) * * * * * -[![r2b2-software-update.png](/attachment/wiki/QubesScreenshots/r2b2-software-update.png)](/attachment/wiki/QubesScreenshots/r2b2-software-update.png) +[![r4.1-software-update.png](/attachment/wiki/QubesScreenshots/r4.1-software-update.png)](/attachment/wiki/QubesScreenshots/r4.1-software-update.png) Qubes lets you update all the software in all the domains all at once, in a centralized way. This is possible thanks to Qubes' unique TemplateVM technology. Note that the user is not required to shut down any AppVMs (domains) for the update process. This can be done later, at a convenient moment, and separately for each AppVM. * * * * * -[![copy-paste-1.png](/attachment/wiki/QubesScreenshots/copy-paste-1.png)](/attachment/wiki/QubesScreenshots/copy-paste-1.png) [![copy-paste-2.png](/attachment/wiki/QubesScreenshots/copy-paste-2.png)](/attachment/wiki/QubesScreenshots/copy-paste-2.png) +[![r4.1-copy-paste.png](/attachment/wiki/QubesScreenshots/r4.1-copy-paste.png)](/attachment/wiki/QubesScreenshots/r4.1-copy-paste.png) Qubes supports secure copy-and-paste operations between AppVMs. Only the user can initiate a copy or paste operation using a special key combination (Ctrl-Shift-C/V). Other AppVMs have no access to the clipboard buffer, so they cannot steal data from the clipboard. Only the user decides which AppVM should be given access to the clipboard. (This is done by selecting the destination AppVM’s window and pressing the Ctrl-Shift-V combination.) * * * * * -[!["r2b2-copy-to-other-appvm-1.png](/attachment/wiki/QubesScreenshots/r2b2-copy-to-other-appvm-1.png)](/attachment/wiki/QubesScreenshots/r2b2-copy-to-other-appvm-1.png) [![r2b2-copy-to-other-appvm-3.png](/attachment/wiki/QubesScreenshots/r2b2-copy-to-other-appvm-3.png)](/attachment/wiki/QubesScreenshots/r2b2-copy-to-other-appvm-3.png) +[!["r4.1-copy-to-other-appvm-1.png](/attachment/wiki/QubesScreenshots/r4.1-copy-to-other-appvm-1.png)](/attachment/wiki/QubesScreenshots/r4.1-copy-to-other-appvm-1.png) [![r4.1-copy-to-other-appvm-3.png](/attachment/wiki/QubesScreenshots/r4.1-copy-to-other-appvm-2.png)](/attachment/wiki/QubesScreenshots/r4.1-copy-to-other-appvm-2.png) Qubes also supports secure file copying between AppVMs. * * * * * -[![r2b2-open-in-dispvm-1.png](/attachment/wiki/QubesScreenshots/r2b2-open-in-dispvm-1.png)](/attachment/wiki/QubesScreenshots/r2b2-open-in-dispvm-1.png) [![r2b2-open-in-dispvm-3.png](/attachment/wiki/QubesScreenshots/r2b2-open-in-dispvm-3.png)](/attachment/wiki/QubesScreenshots/r2b2-open-in-dispvm-3.png) +[![r4.1-open-in-dispvm-1.png](/attachment/wiki/QubesScreenshots/r4.1-open-in-dispvm-1.png)](/attachment/wiki/QubesScreenshots/r4.1-open-in-dispvm-1.png) [![r4.1-open-in-dispvm-2.png](/attachment/wiki/QubesScreenshots/r4.1-open-in-dispvm-2.png)](/attachment/wiki/QubesScreenshots/r4.1-open-in-dispvm-2.png) Qubes' unique DisposableVMs (DispVMs) allow the user to open any file in a disposable VM in a matter of seconds! A file can be edited in a disposable VM, and any changes are projected back onto the original file. Currently, there is no way to mark files to be automatically opened in a disposable VM (one needs to right-click on the file and choose the "Open in DisposableVM" option), but this is planned for the R2 Beta 3 release. * * * * * -[![r2b2-convert-to-trusted-pdf-3.png](/attachment/wiki/QubesScreenshots/r2b2-convert-to-trusted-pdf-3.png)](/attachment/wiki/QubesScreenshots/r2b2-convert-to-trusted-pdf-3.png) [![r2b2-converting-pdf-2.png](/attachment/wiki/QubesScreenshots/r2b2-converting-pdf-2.png)](/attachment/wiki/QubesScreenshots/r2b2-converting-pdf-2.png) +[![r4.1-convert-to-trusted-pdf-1.png](/attachment/wiki/QubesScreenshots/r4.1-convert-to-trusted-pdf-1.png)](/attachment/wiki/QubesScreenshots/r4.1-convert-to-trusted-pdf-1.png) [![r4.1-converting-pdf.png](/attachment/wiki/QubesScreenshots/r4.1-converting-pdf.png)](/attachment/wiki/QubesScreenshots/r4.1-converting-pdf.png) Qubes provides an advanced infrastructure for programming inter-VM services, such as a PDF converter for untrusted files (which is described in [this article](https://blog.invisiblethings.org/2013/02/21/converting-untrusted-pdfs-into-trusted.html)). * * * * * -[![r2b1-manager-firewall.png](/attachment/wiki/QubesScreenshots/r2b1-manager-firewall.png)](/attachment/wiki/QubesScreenshots/r2b1-manager-firewall.png) +[![r4.1-manager-firewall.png](/attachment/wiki/QubesScreenshots/r4.1-manager-firewall.png)](/attachment/wiki/QubesScreenshots/r4.1-manager-firewall.png) Qubes provides a dedicated firewall that itself runs in an isolated FirewallVM. @@ -103,21 +102,9 @@ Qubes provides a dedicated firewall that itself runs in an isolated FirewallVM. And some more screenshots: -[![r2b2-xfce4-start-menu-3.png](/attachment/wiki/QubesScreenshots/r2b2-xfce4-start-menu-3.png)](/attachment/wiki/QubesScreenshots/r2b2-xfce4-start-menu-3.png) +[![r4.1-xfce-start-menu.png](/attachment/wiki/QubesScreenshots/r4.1-xfce-start-menu.png)](/attachment/wiki/QubesScreenshots/r4.1-xfce-start-menu.png) -[![r2b2-kde-red-and-green-terminals.png](/attachment/wiki/QubesScreenshots/r2b2-kde-red-and-green-terminals.png)](/attachment/wiki/QubesScreenshots/r2b2-kde-red-and-green-terminals.png) +[![r4.1-xfce-red-and-green-terminals.png](/attachment/wiki/QubesScreenshots/r4.1-xfce-red-and-green-terminals.png)](/attachment/wiki/QubesScreenshots/r4.1-xfce-red-and-green-terminals.png) [![r2b3-windows-seamless-2.png](/attachment/wiki/QubesScreenshots/r2b3-windows-seamless-2.png)](/attachment/wiki/QubesScreenshots/r2b3-windows-seamless-2.png) -* * * * * - -The following screenshots, [courtesy of Qubes user nalu](https://groups.google.com/d/topic/qubes-users/KhfzF19NG1s/discussion), demonstrate some of the ways in which KDE can be customized to work with Qubes: - -[![r3rc1-nalu-desktop-1.png](/attachment/wiki/QubesScreenshots/r3rc1-nalu-desktop-1.png)](/attachment/wiki/QubesScreenshots/r3rc1-nalu-desktop-1.png) - -[![r3rc1-nalu-desktop-2.png](/attachment/wiki/QubesScreenshots/r3rc1-nalu-desktop-2.png)](/attachment/wiki/QubesScreenshots/r3rc1-nalu-desktop-2.png) - -[![r3rc1-nalu-desktop-3.png](/attachment/wiki/QubesScreenshots/r3rc1-nalu-desktop-3.png)](/attachment/wiki/QubesScreenshots/r3rc1-nalu-desktop-3.png) - -[![r3rc1-nalu-desktop-4.png](/attachment/wiki/QubesScreenshots/r3rc1-nalu-desktop-4.png)](/attachment/wiki/QubesScreenshots/r3rc1-nalu-desktop-4.png) - 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/advanced-configuration/resize-disk-image.md b/user/advanced-configuration/resize-disk-image.md index a2e438be..aa008f12 100644 --- a/user/advanced-configuration/resize-disk-image.md +++ b/user/advanced-configuration/resize-disk-image.md @@ -30,7 +30,7 @@ Increasing the size of Disk Images There are several disk images which can be easily extended, but pay attention to the overall consumed space of your sparse/thin disk images. In most cases, the GUI tool Qube Settings (available for every qube from the Start menu, and also in the Qube Manager) will allow you to easily increase maximum disk image size. -![vm-settings-disk-image.png](/attachment/wiki/DiskSize/vm-settings-disk-image.png) +![vm-settings-disk-image.png](/attachment/wiki/DiskSize/r4.1-vm-settings-disk-image.png) In case of standalone qubes and templates, just change the Disk Storage settings above. In case of template-based qubes, the private storage (the /home directory and user files) can be changed in the qube's own settings, but the system root image is [inherited from the template](/getting-started/), and so it must be changed in the template settings. diff --git a/user/common-tasks/disposablevm.md b/user/common-tasks/disposablevm.md index 3e7c452a..a0f6e205 100644 --- a/user/common-tasks/disposablevm.md +++ b/user/common-tasks/disposablevm.md @@ -95,7 +95,7 @@ This app is running in its own dedicated VM -- a DisposableVM created for the pu Once you close the viewing application the whole DisposableVM will be destroyed. If you have edited the file and saved the changes, the changed file will be saved back to the original AppVM, overwriting the original. -![r1-open-in-dispvm-1.png](/attachment/wiki/DisposableVms/r1-open-in-dispvm-1.png) ![r1-open-in-dispvm-2.png](/attachment/wiki/DisposableVms/r1-open-in-dispvm-2.png) +![r4.1-open-in-dispvm-1.png](/attachment/wiki/DisposableVms/r4.1-open-in-dispvm-1.png) ![r4.1-open-in-dispvm-2.png](/attachment/wiki/DisposableVms/r4.1-open-in-dispvm-2.png) ## Opening a fresh web browser instance in a new DisposableVM ## @@ -105,7 +105,7 @@ This can be done easily using the Start Menu: just go to **Application Menu -\> Wait a few seconds until a web browser starts. Once you close the viewing application the whole DisposableVM will be destroyed. -![r1-open-in-dispvm-3.png](/attachment/wiki/DisposableVms/r1-open-in-dispvm-3.png) +![r4.1-open-in-dispvm-3.png](/attachment/wiki/DisposableVms/r4.1-open-in-dispvm-3.png) ## Opening a file in a DisposableVM via command line (from AppVM) ## diff --git a/user/common-tasks/getting-started.md b/user/common-tasks/getting-started.md index 18729c39..01563286 100644 --- a/user/common-tasks/getting-started.md +++ b/user/common-tasks/getting-started.md @@ -45,7 +45,7 @@ For example, you could use the colors to show that qubes belong to the same doma You might use three or four qubes for work activities and give them all the same distinct color label, for instance. It's entirely up to you. -![snapshot_40.png](/attachment/wiki/GettingStarted/snapshot_40.png) +![snapshot_40.png](/attachment/wiki/GettingStarted/r4.1-snapshot_40.png) In addition to qubes and templates, there's one special domain called [dom0], where many system tools and the desktop manager run. This is where you log in to the system. @@ -77,7 +77,7 @@ Alternatively, you can use a suite of GUI tools, most of which are available thr - The **Disk Space Widget** will notify you if you're ever running out of disk space. - The **Updates Widget** will inform you when template updates are available. -![q40_widgets.png](/attachment/wiki/GettingStarted/q40_widgets.png) +![q40_widgets.png](/attachment/wiki/GettingStarted/r4.1-q40_widgets.png) For an overview of the entire system, you can use the **Qube Manager** (go to the Application Launcher → System Tools → Qube Manager), which displays the states of all the qubes in your system. @@ -91,9 +91,9 @@ You can start apps directly from the Application Launcher or the Application Fin Each qube has its own menu directory under the scheme `Domain: `. After navigating into one of these directories, simply click on the application you'd like to start: -![menu1.png](/attachment/wiki/GettingStarted/menu1.png) +![menu1.png](/attachment/wiki/GettingStarted/r4.1-menu1.png) -![menu2.png](/attachment/wiki/GettingStarted/menu2.png) +![menu2.png](/attachment/wiki/GettingStarted/r4.1-menu2.png) By default, each qube's menu contains only a few shortcuts. If you'd like to add more, enter the qube's **Qube Settings** and add them on the Applications tab. diff --git a/user/common-tasks/managing-appvm-shortcuts.md b/user/common-tasks/managing-appvm-shortcuts.md index e098e514..837d7a42 100644 --- a/user/common-tasks/managing-appvm-shortcuts.md +++ b/user/common-tasks/managing-appvm-shortcuts.md @@ -14,7 +14,7 @@ Managing shortcuts to applications in AppVMs For ease of use Qubes aggregates shortcuts to applications that are installed in AppVMs and shows them in one "start menu" in dom0. Clicking on such shortcut runs the assigned application in its AppVM. -![dom0-menu.png"](/attachment/wiki/ManagingAppVmShortcuts/dom0-menu.png) +![dom0-menu.png"](/attachment/wiki/ManagingAppVmShortcuts/r4.1-dom0-menu.png) To make applications newly installed via the OS's package manager show up in the menu, use the `qvm-sync-appmenus` command (Linux VMs do this automatically): @@ -22,7 +22,7 @@ To make applications newly installed via the OS's package manager show up in the After that, select the *Add more shortcuts* entry in the VM's submenu to customize which applications are shown: -![dom0-appmenu-select.png"](/attachment/wiki/ManagingAppVmShortcuts/dom0-appmenu-select.png) +![dom0-appmenu-select.png"](/attachment/wiki/ManagingAppVmShortcuts/r4.1-dom0-appmenu-select.png) The above image shows that Windows HVMs are also supported (provided that Qubes Tools are installed). diff --git a/user/common-tasks/pci-devices.md b/user/common-tasks/pci-devices.md index e84b0ea7..c6fd76ff 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](/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 diff --git a/user/security-in-qubes/firewall.md b/user/security-in-qubes/firewall.md index 17e305b0..2220eb64 100644 --- a/user/security-in-qubes/firewall.md +++ b/user/security-in-qubes/firewall.md @@ -30,7 +30,7 @@ How to edit rules In order to edit rules for a given qube, select it in the Qubes Manager and press the "firewall" button: -![r2b1-manager-firewall.png](/attachment/wiki/QubesFirewall/r2b1-manager-firewall.png) +![r4.1-manager-firewall.png](/attachment/wiki/QubesFirewall/r4.1-manager-firewall.png) *R4.0 note:* ICMP and DNS are no longer accessible in the GUI, but can be changed via `qvm-firewall` described below. Connections to Updates Proxy are no longer made over network so can not be allowed or blocked with firewall rules (see [R4.0 Updates proxy](https://www.qubes-os.org/doc/software-update-vm/) for more detail. diff --git a/user/troubleshooting/disk-troubleshooting.md b/user/troubleshooting/disk-troubleshooting.md new file mode 100644 index 00000000..c7891dd3 --- /dev/null +++ b/user/troubleshooting/disk-troubleshooting.md @@ -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 + ~~~ + + 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/` 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 +qvm-console-dispvm +~~~ + +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 `. + +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). - diff --git a/user/troubleshooting/pci-troubleshooting.md b/user/troubleshooting/pci-troubleshooting.md new file mode 100644 index 00000000..8dcabc7e --- /dev/null +++ b/user/troubleshooting/pci-troubleshooting.md @@ -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: +~~~ + +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 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. diff --git a/user/troubleshooting/usb-troubleshooting.md b/user/troubleshooting/usb-troubleshooting.md new file mode 100644 index 00000000..2cf294eb --- /dev/null +++ b/user/troubleshooting/usb-troubleshooting.md @@ -0,0 +1,83 @@ +--- +layout: doc +title: USB Troubleshooting +permalink: /doc/usb-troubleshooting/ +--- + +# USB troubleshooting # + +## disp-sys-usb does not start ## +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, look at [PCI passthrough issues](/doc/pci-troubleshooting/#pci-passthrough-issues). + +## Can't attach a USB device / USB device not showing in qvm-usb ## + +To successfully attach a USB device, you require a VM dedicated to handling the USB input and output. +For guidance setting up a USB qube, see the [USB documentation](/doc/usb-devices/#creating-and-using-a-usb-qube). + +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/block-devices/#what-if-i-removed-the-device-before-detaching-it-from-the-vm) + +## "Device attach failed" error + +Upon trying to attach a USB device using the `qvm-usb -a vm-name device-vm-name:device` command, you may face the error `Device attach failed: no device info received, connection failed, check backend side for details`. +This error mainly arises due to problems specific to the particular device, such as the device being incompatible with qvm-usb or a broken cable. + +## usbVM does not boot after creating and assigning USB controllers to it ## + +This is probably because one of the controllers does not support reset. +In Qubes R2 any such errors were ignored. In Qubes R3.x they are not. +In R4.x, devices that are automatically added to sys-net and sys-usb on install but do not support FLR will be attached with the no-strict-reset option, but see the related warning in the last sentence in this answer. + +A device that does not support reset is not ideal and generally should not be assigned to a VM. + +Most likely the offending controller is a USB 3.0 device. +You can remove this controller from the usbVM, and see if this allows the VM to boot. +Alternatively you may be able to disable USB 3.0 in the BIOS. +If the BIOS does not have the option to disable USB 3.0, try running the following command in dom0 to [force USB 2.0 modes for the USB ports][force_usb2]: + + lspci -nn | grep USB | cut -d '[' -f3 | cut -d ']' -f1 | xargs -I@ setpci -H1 -d @ d0.l=0 + + +Errors suggesting this issue: + + - in `xl dmesg` output: + + (XEN) [VT-D] It's disallowed to assign 0000:00:1a.0 with shared RMRR at dbe9a000 for Dom19. + (XEN) XEN_DOMCTL_assign_device: assign 0000:00:1a.0 to dom19 failed (-1) + + - during `qvm-start sys-usb`: + + internal error: Unable to reset PCI device [...] no FLR, PM reset or bus reset available. + + +Another solution would be to set the pci_strictreset option in dom0: + + - In Qubes R4.x, when attaching the PCI device to the VM (where `` can be obtained from running `qvm-pci`): + + qvm-pci attach --persistent --option no-strict-reset=true usbVM dom0: + + - In Qubes R3.x, by modifying the VM's properties: + + qvm-prefs usbVM -s pci_strictreset false + +These options allow the VM to ignore the error and the VM will start. +Please review the notes in the `qvm-prefs` man page and [here][assign_devices] and be aware of the potential risks. + + +## Can't use keyboard or mouse after creating sys-usb ## + +You risk locking yourself out of your computer if you have a USB keyboard and use full disk encryption alongside sys-usb. +On boot, the keyboard may be inactive, preventing you from entering your LUKS decryption password. + +When you enable a USB qube, it hides all the USB controllers from dom0, even before it gets started. +So, if your only keyboard is on USB, you should undo this hiding. + +To solve the problem, disable the USB qube by not having it autostart, or unassigning your USB controller(s) from it. If you had created the USB qube by checking the box in the installer, then your USB controller(s) are probably hidden from dom0. To unhide them, reverse the procedure described in the [USB Qubes documentation](https://www.qubes-os.org/doc/usb-qubes/#how-to-hide-all-usb-controllers-from-dom0) (under "How to hide all USB controllers from dom0"). That is, remove `rd.qubes.hide_all_usb`, instead of adding it. + +Note that this procedure will attach your USB controllers to dom0, so do this only with USB devices you trust. + +If your computer has a PS/2 port, you may instead use a PS/2 keyboard to enter the LUKS password. +