Git-Mirrors/Qubes-Community-Content
1
0
Fork 0
mirror of https://github.com/Qubes-Community/Contents.git synced 2024-10-01 01:05:51 -04:00
Code Issues Packages Projects Releases Wiki Activity

Merge branch 'installation-troubleshooting' of https://github.com/PROTechThor/qubes-doc into PROTechThor-installation-troubleshooting

Browse Source
This commit is contained in:
Andrew David Wong 2020-10-11 17:48:50 -05:00
commit d83d90ac25
10 changed files with 0 additions and 1222 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

177
troubleshooting/install-nvidia-driver.md
View File

@ -1,177 +0,0 @@
---
layout: doc
title: How to Install an Nvidia Driver
permalink: /doc/install-nvidia-driver/
redirect_from:
- /en/doc/install-nvidia-driver/
- /doc/InstallNvidiaDriver/
- /wiki/InstallNvidiaDriver/
---
# Nvidia proprietary driver installation
You can use rpm packages from rpmfusion, or you can build the driver yourself.
## Word of Caution
Proprietary (NVIDIA/AMD) drivers are known to be sometimes highly problematic, or completely unsupported.
Radeon driver support is prebaked in the Qubes kernel (v4.4.14-11) but only versions 4000-9000 give or take.
Support for newer cards is limited until AMDGPU support in the 4.5+ kernel, which isn't released yet for Qubes.
Built in Intel graphics, Radeon graphics (between that 4000-9000 range), and perhaps some prebaked NVIDIA card support that I don't know about. Those are your best bet for great Qubes support.
If you do happen to get proprietary drivers working on your Qubes system (via installing them), please take the time to go to the
[Hardware Compatibility List (HCL)](/doc/hcl/#generating-and-submitting-new-reports )
Add your computer, graphics card, and installation steps you did to get everything working.
Before continuing, you may wish to try the `kernel-latest` package from the `current` repository. This kernel may better support your card and if so, you would not have to rely on proprietary drivers. This can be installed from dom0 with:
~~~
sudo qubes-dom0-update kernel-latest
~~~
## RpmFusion packages
There are rpm packages with all necessary software on rpmfusion. The only package you have to compile is the kernel module (but there is a ready built src.rpm package).
### Download packages
You will need any Fedora 18 system to download and build packages. You can use Qubes AppVM for it, but it isn't necessary. To download packages from rpmfusion - add this repository to your yum configuration (instructions are on their website). Then download packages using yumdownloader:
~~~
yumdownloader --resolve xorg-x11-drv-nvidia
yumdownloader --source nvidia-kmod
~~~
### Build kernel package
You will need at least kernel-devel (matching your Qubes dom0 kernel), rpmbuild tool and kmodtool, and then you can use it to build the package:
~~~
yum install kernel-devel rpm-build kmodtool
rpmbuild --nodeps -D "kernels `uname -r`" --rebuild nvidia-kmod-260.19.36-1.fc13.3.src.rpm
~~~
In the above command, replace `uname -r` with kernel version from your Qubes dom0. If everything went right, you have now complete packages with nvidia drivers for the Qubes system. Transfer them to dom0 (e.g. using a USB stick) and install (using standard "yum install /path/to/file").
Then you need to disable nouveau (normally it is done by install scripts from nvidia package, but unfortunately it isn't compatible with Qubes...):
Edit /etc/default/grub:
~~~
GRUB_CMDLINE_LINUX="quiet rhgb nouveau.modeset=0 rd.driver.blacklist=nouveau video=vesa:off"
~~~
Regenerate grub configuration:
~~~
grub2-mkconfig -o /boot/grub2/grub.cfg
~~~
Reboot.
## Manual installation
This process is quite complicated: First - download the source from nvidia.com site. Here "NVIDIA-Linux-x86\_64-260.19.44.run" is used. Copy it to dom0. Every next step is done in dom0.
See [this page](/doc/copy-to-dom0/) for instructions on how to transfer files to Dom0 (where there is normally no networking).
**WARNING**: Nvidia doesn't sign their files. To make it worse, you are forced to download them over a plaintext connection. This means there are virtually dozens of possibilities for somebody to modify this file and provide you with a malicious/backdoored file. You should realize that installing untrusted files into your Dom0 is a bad idea. Perhaps it might be a better idea to just get a new laptop with integrated Intel GPU? You have been warned.
### Userspace components
Install libraries, Xorg driver, configuration utilities. This can by done by nvidia-installer:
~~~
./NVIDIA-Linux-x86_64-260.19.44.run --ui=none --no-x-check --keep --no-nouveau-check --no-kernel-module
~~~
### Kernel module
You will need:
- nvidia kernel module sources (left from previous step)
- kernel-devel package installed
- gcc, make, etc
This installation must be done manually, because nvidia-installer refused to install it on Xen kernel. Firstly ensure that kernel-devel package installed all needed files. This should consist of:
- */usr/src/kernels/2.6.34.1-12.xenlinux.qubes.x86\_64*
- */lib/modules/2.6.34.1-12.xenlinux.qubes.x86\_64/build* symlinked to the above directory
- */usr/src/kernels/2.6.34.1-12.xenlinux.qubes.x86\_64/arch/x64/include/mach-xen* should be present (if not - take it from kernel sources)
If all the files are not there correct the errors manually. To build the kernel module, enter *NVIDIA-Linux-x86\_64-260.19.44/kernel* directory and execute:
~~~
make
IGNORE_XEN_PRESENCE=1 CC="gcc -DNV_VMAP_4_PRESENT -DNV_SIGNAL_STRUCT_RLIM" make -f Makefile.kbuild
mv /lib/modules/2.6.34.1-12.xenlinux.qubes.x86_64/kernel/drivers/video/nvidia.ko /lib/modules/2.6.34.1-12.xenlinux.qubes.x86_64/extra/
~~~
Ignore any errors while inserting nvidia.ko (at the end of make phase).
### Disable nouveau:
~~~
cat /etc/modprobe.d/nouveau-disable.conf
# blacklist isn't enough...
install nouveau /bin/true
~~~
Add *rdblacklist=nouveau* option to /boot/grub/menu.lst (at the end of line containing *vmlinuz*).
### Configure Xorg
Finally, you should configure Xorg to use nvidia driver. You can use *nvidia-xconfig* or do it manually:
~~~
X -configure
mv /root/xorg.conf.new /etc/X11/xorg.conf
# replace Driver in Device section by "nvidia"
~~~
Reboot to verify all this works.
# Troubleshooting lack of video output during installation
Specifically, the notes below are aimed to help when the GRUB menu shows up fine, the installation environment starts loading, and then the display(s) go into standby mode. This is, typically, related to some sort of an issue with the kernel's KMS/video card modules.
## Initial setup.
*Note*: The steps below do *not* produce a fully-functional Qubes OS install. Rather, only a dom0 instance is functional, and there is no networking there. However, they can be used to gather data in order to troubleshoot video card issues and/or possible other basic kernel module issues.
1. Append `nomodeset ip=dhcp inst.nokill inst.vnc` to the kernel command line. Remove `rhgb` and `quiet` to see the kernel messages scroll by, which may help in further diagnostics.
* If DHCP is not available on the installation network, the syntax becomes a bit more involved. The full list of variants is documented in the [Dracut Command-line parameters] (http://man7.org/linux/man-pages/man7/dracut.cmdline.7.html)
2. The VGA console should switch into the installer's multi-virtual-terminal display. VNC may take a number of minutes to start, please be patient.
* Using the anaconda installer interface, switch to the "shell" TTY (ALT-F2), and use `ip a` command to display the IP addresses.
3. Using the Connect to the IP (remember the :1) using a VNC viewer.
4. Follow the installation UI.
* Since this won't be a usable install, skipping LUKS encryption is an option which will simplify this troubleshooting process.
* Do *not* reboot at the end of the installation.
5. Once the installation completes, use the local VGA console switch to TTY2 via ALT-F2
* Switch to the chroot of the newly-installed system via `chroot /mnt/sysinstall`
* Set the root password (this will also enable the root account login)
* Double-check that `/boot/grub2/grub.cfg` contains a `nomodeset` kernel parameter.
* Exit out of the chroot environment (`exit` or CTRL-D)
6. Reboot
*Note* If the kernel parameters do *not* include `quiet` and `rhgb`, the kernel messages can easily obscure the LUKS passphrase prompt. Additionally, each character entered will cause the LUKS passphrase prompt to repeat onto next line. Both of these are cosmetic. The trade-off between kernel messages and the easy-to-spot LUKS passphrase prompt is left as an exercise to the user.
## Gather initial `dmesg` output
If all is well, the newly-installed Qubes OS instance should allow for user root to log in.
Run `dmesg > dmesg.nomodeset.out` to gather an initial dmesg output.
## Gather the 'video no worky' `dmesg` output
1. Reboot and interrupt the Grub2's process, modifying the kernel parameters to no longer contain `nomodeset`.
* If the LUKS passphrase was set, blindly enter it.
2. Wait for the system to finish booting (about 5 minutes, typically).
3. Blindly switch to a TTY via CTRL-ALT-F2.
4. Blindly log in as user root
5. Blindly run `dmesg > dmesg.out`
6. Blindly run `reboot` (this will also serve to confirm that logging in as root, and running commands blindly is possible rather than, say, the kernel having hung or some such).
* Should this step fail, perhaps by the time step #3 was undertaken, the OS hasn't finished coming up yet. Please retry, possibly with a different TTY (say, 3 or 4 - so CTRL-ALT-F3?)
## Exfiltrate the dmesg outputs
Allow the system to boot normally, log in as user root, and sneakernet the files off the system for analysis, review, bug logging, et cetera.

65
troubleshooting/intel-igfx-troubleshooting.md
View File

@ -1,65 +0,0 @@
---
layout: doc
title: Intel Integrated Graphics Troubleshooting
permalink: /doc/intel-igfx-troubleshooting/
---
# Intel Integrated Graphics Troubleshooting #
## Software Rendering or Video Lags
If you are experiencing this issue, you will see extremely slow graphics updates.
You will be able to watch the screen and elements paint slowly from top to bottom.
You can confirm this is the issue by looking for a line similar to the following in your `/var/log/Xorg.0.log` file:
[ 131.769] (EE) AIGLX: reverting to software rendering
Newer versions of the Linux kernel have renamed the `i915.preliminary_hw_support=1` option to `i915.alpha_support=1`, so if you needed this kernel option in the past you will have to rename it or add it to your configuration files (follow either GRUB2 or EFI, not both):
* GRUB2: `/etc/default/grub`, `GRUB_CMDLINE_LINUX` line and
Rebuild grub config (`grub2-mkconfig -o /boot/grub2/grub.cfg`)
* EFI: `/boot/efi/EFI/qubes/xen.cfg`, `kernel=` line(s)
## IOMMU ##
Dom0 Kernels currently included in Qubes have issues related to VT-d (IOMMU) and some versions of the integrated Intel Graphics Chip.
Depending on the specific hardware / software combination the issues are quite wide ranging, from apparently harmless log errors, to VM window refresh issues, to complete screen corruption and crashes rendering the machine unusable with Qubes.
Such issues have been reported on at least the following machines:
* HP Elitebook 2540p
* Lenovo x201
* Lenovo x220
* Thinkpad T410
* Thinkpad T450s
Log errors only on :
* Librem 13v1
* Librem 15v2
The installer for Qubes 4.0 final has been updated to disable IOMMU for the integrated intel graphics by default.
However, users of 3.2 may experience issues on install or on kernel upgrades to versions higher than 3.18.x.
Disabling IOMMU for the integrated graphics chip is not a security issue, as the device currently lives in dom0 and is not passed to a VM.
This behaviour is planned to be changed as of Qubes 4.1, when passthrough capabilities will be required for the GUI domain <sup id="a1-1">[1](#f1)</sup>.
## Workaround for existing systems with VT-d enabled (grub / legacy mode) ##
Edit the startup parameters for Xen:
1. Open a terminal in dom0
2. Edit `/etc/default/grub` (e.g. `sudo nano /etc/default/grub`)
3. Add to the line `GRUB_CMDLINE_XEN_DEFAULT` the setting `iommu=no-igfx`, save and quit
4. Commit the change with`sudo grub2-mkconfig --output /boot/grub2/grub.cfg`
## Workaround for existing systems with VT-d enabled (UEFI) ##
Edit the startup parameters for Xen:
1. Open a terminal in dom0
2. Edit `/boot/efi/EFI/qubes/xen.cfg` (e.g. `sudo nano /boot/efi/EFI/qubes/xen.cfg`)
3. Add to the line `options` the setting `iommu=no-igfx`, save and quit
<b name="f1">1</b> <https://github.com/QubesOS/qubes-issues/issues/2841> [↩](#a1-1)

328
troubleshooting/macbook-troubleshooting.md
View File

@ -1,328 +0,0 @@
---
layout: doc
title: Apple MacBook Troubleshooting
permalink: /doc/macbook-troubleshooting/
---
Apple MacBook Troubleshooting
=============================
MacBook Air 13" mid 2011 (MacBookAir 4,2)
-----------------------------------------
In this section, I explain how to install Qubes on a MacBook Air 13" mid 2011
(MacBookAir 4,2).
This model has the following features:
* Dual Intel i7-2677M 1.80 Ghz CPU (2 dual cores)
* Intel HD Graphics 3000
* 4Gb RAM
* 256Gb SDD
* Broadcom BCM43224 802.11 a/b/g/n wifi and Bluetooth adapter
* Intel DSL2310 Thunderbolt controller
* It has 1 DVI/Thunderbolt display port, 2 USB2.0 ports, a Magsafe power
adapter, a standard 3.5mm audio jack and SD reader.
I first tried to install Qubes using the UEFI boot, but it failed. Not wanting
to waste too much time, I quickly opted for the legacy BIOS install.
### 1. Boot from Mac OS X (or Internet Recovery Image with `CMD`+`R` during bootup)
Run in a terminal [[1]]:
~~~
# diskutil list
(find your usb device)
# bless –device /dev/diskX –legacy –setBoot –nextonly # bless the disk not the partition
# reboot
~~~
Insert your Qubes 3.2 USB flash drive. The ISOLINUX boot screen should come up.
Install Qubes normally.
If you try to boot Qubes now, it will freeze while "setting up networking." You
need to put the Broadcom wireless device into PCI passtrough [[2],[3]]. Or, as
an alternative [remove it from your Mac][bluetooth-replacement] and Qubes will
boot up smoothly. If you choose to remove the card, jump to step 3.
### 2. Boot from Mac OS X again
Run in a terminal:
~~~
# diskutil list
(find your usb device)
# bless –device /dev/diskX –legacy –setBoot –nextonly # bless the disk not the partition
# reboot
~~~
Insert your Qubes 3.2 USB flash drive. The ISOLINUX boot screen should come up.
Select Troubleshooting and Boot the Rescue image. Enter your disk password when
prompted. Select continue and after mounting the HD filesystem and launching a
shell, `chroot` as instructed.
Then find your Bluetooth card:
~~~
# lspci
..
02:00.0 Network controller: Broadcom Corporation BCM43224 802.11a/b/g/n (rev 01)
…
# qvm-pci -a sys-net 02:00.0 # this assigns the device to sys-net VM
~~~
Then create `/etc/systemd/system/qubes-pre-netvm.service` with:
~~~
[Unit]
Description=Netvm fix for Broadcom
Before=qubes-netvm.service
[Service]
ExecStart=/bin/sh -c 'echo 02:00.0 > /sys/bus/pci/drivers/pciback/permissive'
Type=oneshot
RemainAfterExit=yes
[Install]
WantedBy=multi-user.target
~~~
Run:
~~~
systemctl enable qubes-pre-netvm.service
~~~
And that's it.
### 3. After reboot, boot Mac OS X again
Run in a terminal:
~~~
# diskutil list
(find the HD device where you installed Qubes)
# bless –device /dev/diskX –legacy –setBoot # bless the disk not the partition
# reboot
~~~
Results:
* System booted and running smoothly
* Youtube video: OK (including full screen after configuration)
* Trackpad: OK
* Audio control: OK
* Brightness control: OK
* Keyboard light control:OK
* SD card access: OK (tested at dom0)
* Lid-close suspend: OK
* Wifi: +10%-20% ICMP packet loss when comparing with OSX (have similar rates
with Tails Linux, more tests are required)
### References
1. <https://github.com/QubesOS/qubes-issues/issues/794>
2. <https://github.com/QubesOS/qubes-issues/issues/1261>
3. <https://www.qubes-os.org/doc/assigning-devices/>
MacBook Air 2012 (MacBookAir 5,1)
---------------------------------
Please see [this thread o the qubes-devel mailing list][macbook-air-2012-5-1].
[1]: https://github.com/QubesOS/qubes-issues/issues/794
[2]: https://github.com/QubesOS/qubes-issues/issues/1261
[3]: /doc/assigning-devices/
[bluetooth-replacement]: https://www.ifixit.com/Guide/MacBook+Air+13-Inch+Mid+2011+AirPort-Bluetooth+Card+Replacement/6360
[macbook-air-2012-5-1]: https://groups.google.com/d/topic/qubes-devel/uLDYGdKk_Dk/discussion
MacBook Pro Retina, 15 inch, Mid-2015 (MacBookPro 11,5)
-------------------------------------------------------
In this section, I explain how I installed Qubes 3.2 on a MacBook Pro Retina 2015 (MacBookPro 11,5).
Good news: the relevant stuff works.
Bad news: still some minor issue to investigate.
For the time being, my setup is just for testing purposes and help to bypass some blocking issues: do not use it in production or on machine where security is a concern!
I hope to improve it as soon as possible.
During my nights trying to get Qubes OS working, I faced two main and blocking issues:
* no boot, due to empty xen.cfg file
* system freeze, due to Broadcom BCM43602 wifi card
I am already using Qubes for my daily job on Intel NUC. For the time being, I installed Qubes on Macbook for test purposes. Later on I will review the security implications.
This model has the following features:
* 2,5 GHz Intel Core i7-4870HQ (2 quad cores)
* Dual Graphic Card
* Intel Iris Pro
* AMD Radeon R9 M370X
* 16Gb RAM
* 512Gb SDD
* Broadcom BCM43602 802.11ac wifi adapter
### 1. Reclaim space to be able to multiboot OSX
For security reasons, you should install Qubes using the whole disk. I preferred to keep OSX, so I shrunk OS partition:
* reboot in recovery mode
* run disk utility and shrink OSX partition, eg 150GB for OSX and the remaining space for Qubes OS
* reboot
### 2. Boot installer
Download and prepare a USB with Qubes 3.2
You can install Qubes using BIOS or UEFI:
* BIOS/CSM/Legacy: I have not been able to install using legacy, but I did not spend a lot of time on it.
* UEFI plain: grub menu appears, but any gave me a quick flash and returned the main menu. I can boot it manually fixing the grub.cfg file, adding commands linuexefi and initrdefi, pointing proper files in /efi/boot. After boot, I end up with no root file system.
* UEFI, using rEFInd: I have been successful, despite some issues to be fixed manually, after installation completion
* download [rEFInd] refind-bin-0.10.4.zip: this file is not signed, so decide if you trust it or not. SHA1 sum is 3d69c23b7d338419e5559a93cd6ae3ec66323b1e
* unzip it and run installer, which installs rEFIind on the internal SSD
* if installation fails due to SIP, reboot in recovery mode, open a terminal and issue command
~~~
csrutil disable
~~~
* reboot and you will see some icons
* choose Boot EFI\BOOT\xen.efi from ANACONDA
* after a while the graphical installer is up (keyboard and touchpad working)
### 3. Installation
* As a general rule, keep the default values proposed during installation: you can change them later on
* Keep English, as language, locale
* My Macbook has a US keyboard, so I cannot say what happens if you change keyboard layout
* DO NOT CHANGE the timezone, because it will trigger the wifi card, leading to a system freeze
* Choose the "installation destination": do not change anything and press DONE button
* Insert your password for Full Disk Encryption
* If you do not already have free space on internal SSD disk, you will be prompted to reclaim some space:
* If you shrunk OSX partition, disk utility left an empty partition: delete useless partition (e.g.: if you shrunk OSX partition, diskutil created an empty partition)
* Press on "reclaim space"
* Press on "begin installation"
* create your user and password
* after a while, installation completes
* DO NOT press "Reboot button"
Qubes OS is now installed, but you cannot boot it due to some issues, with bootloader configuration and wifi card.
You cannot Qubes boot using EFI/qubes/xen.efi because XEN bootloader configuration is broken.
You cannot even Qubes without XEN support, using GRUB2, because its configuration is broken too.
Let's fix it manually, switch to console, pressing Fn+CTRL+ALT+F2
### 4. Fix GRUB configuration
You can skip this section, but I found it very useful - during troubleshooting - to have a rescue system at hand. I could boot Qubes, without XEN support
Grub configuration file is using some wrong commands, which are not compatible with grub2-efi
~~~
chroot /mnt/sysimage
sed -i.bak -e "s/multiboot/chainloader/" -e "s/module.*--nounzip/initrdefi/" -e "s/module/linuxefi/" /etc/grub.d/20_linux_efi
exit
~~~
Now, despite XEN configuration is still broken, you have a rescue system booting vmlinux from rEFInd screen.
TBV1: chainloading XEN does not work, unless you specify the right disk prefix, eg: (hd1,gpt4)
TBV2: grub.cfg set the wrong disk in "set root" command
TBV3: in case you reach grub shell, you can
~~~
ls
~~~
and also reload config file and change it manualy before booting
~~~
configfile /EFI/qubes/grub.cfg
~~~
then press "e", edit grub cfg and boot pressing Fn+F10
### 5. Fix bootloader
* Fix grub2 configuration, which uses wrong command for EFI boot
* analyzing /mnt/sysimage/var/log/anaconda/program.log I found the faulty commands issues by Anaconda installer
~~~
chrooot /mnt/sysimage
~~~
* edit /boot/efi/EFI/qubes/xen.cfg file putting the following content
~~~
[global]
default=4.4.14-11.pvops.qubes.x868_64
[4.4.14-11.pvops.qubes.x868_64]
options=loglvl=all dom0_mem=min:1024M dom0_mem=max:4096M
kernel=vmlinuz-4.4.14-11.pvops.qubes.x86_64
ramdisk=initramfs-4.4.14-11.pvops.qubes.x86_64.img
~~~
* The main mistake is the efibootmgr, that needs the right commands. Just in case, re-apply all the commands, adapting to your own disk layout (-d /dev/sdxxx -p partition_number)
~~~
grep Running /mnt/sysimage/var/log/anaconda/program.log | tail -n 20
efibootmgr -b 0000 -B
efibootmgr -c -w -L Qubes -d /dev/sda -p 4 -l \\EFI\\qubes\\xen-4.6.1.efi
/usr/libexec/mactel-boot-setup
kernel-install add 4.4.14-11.pvops.qubes.x86_64 /boot/vmlinuz-4.4.14-11.pvops.qubes.x86_64
systemctl disable qubes-netvm
reboot
~~~
At rEFInd screen, choose Boot EFI/qubes/xen-4.6.1.efi
Everything should now be ok, Qubes OS boots using EFI and you will get the last setup screen
* select "Qubes OS", do not change anything and click on "Done"
* VMs are created, including NetVM
### 6. Fix pulseaudio, which locks CPU freezing the system often for 20 seconds
My Macbook has frequent freezes. Looking at journalctl output I saw that pulseaudio locks CPU for 20 seconds, very often.
You can fix this issue, killing audio support with this quick workaround:
* open a dom0 terminal, as root and edit /etc/pulse/client.conf
* add "autospawn = no"
* Then, as normal user, issue command "pulseaudio --kill"
### 7. Fix system freezes due to Broadcom BCM43602
* If you experience a system freeze, during VM setup, force a reboot and press OPTION key.
* You will reach grub shell
~~~
configfile /EFI/qubes/grub.cfg
~~~
press Fn+F10 to boot without XEN support
* Once booted, press Fn+CTRL+ALT+F4 to open a shell
* Log into system
~~~
sudo su -
systemctl disable qubes-netvm
~~~
Press Fn+F2 and complete setup
* reboot and you finally have your Qubes OS
* DO NOT launch sys-net machine
* Open its setting and remove wifi adapter from the Selected devices, using Qubes Manager or use the following command line. Get the BFD of the adapter and remove it. On my Macbook BFD is 04:00.0 and you will use it later on, also
~~~
qvm-pci -l sys-net
qvm-pci -d sys-net 04:00.0
~~~
Ok, setup is complete and we are almost done.
* Open a dom0 terminal
~~~
sudo su -
xl pci-assignable-list
echo 04:00.0 > /sys/bus/pci/drivers/pciback/permissive
qvm-start sys-net
xl pci-attach sys-net 04:00.0
~~~
These latest steps are required to launch sys-net with wifi access. They can be automated in a custom systemd service.
[rEFInd]: http://www.rodsbooks.com/refind/getting.html

159
troubleshooting/nvidia-troubleshooting.md
View File

@ -1,159 +0,0 @@
---
layout: doc
title: Nvidia Troubleshooting
permalink: /doc/nvidia-troubleshooting/
redirect_from:
- /en/doc/nvidia-troubleshooting/
- /doc/NvidiaTroubleshooting/
- /wiki/NvidiaTroubleshooting/
---
NVidia Troubleshooting Guide
============================
If you have an NVidia graphics card it will probably not work under Xen out of the box. If your system freezes during boot and you don't see the graphical login manager after you installed Xen, then this problem most likely affects you. The following steps should provide a work around so that you should be able to use your NVidia with X under Xen, however without any fancy "desktop effects".
Boot in failsafe
---------------------
Boot your system using the "failsafe" boot menu, that should have been automatically added to your `grub.conf` when you installed the Dom0 kernel.
If the X Window System doesn't start now, this is probably a non-Xen related issue and this guide will probably not help you.
Configure X with nouveau
---------------------
Assuming your X Window System works fine now when you booted from the "failsafe" configuration, do the next steps...
1. Do not log into X, but instead switch to a text console (press Ctrl-Alt-F2)
2. Log in as root
3. Switch to runlevel 3 (this should kill your X server):
~~~
init 3
~~~
4. Run X-autoconfiguration:
~~~
Xorg -configure
~~~
This should generate a file `xorg.conf.new` in the `/root` directory.
In most cases you can ignore any warning or error messages displayed by the X server, assuming it generated the xorg.conf.new file.
5. Edit this newly generated `xorg.conf.new` file and introduce the following two modifications:
First, uncomment the ShadowFB option, so that you should now have something like this:
~~~
Option "ShadowFB" # [<bool>]
~~~
Second, change the driver name to `nouveau` (you will probably have `nv` written there):
~~~
Driver "nouveau"
~~~
Save the modification, exit the editor.
6. Move the file to `/etc/X11` and rename it as `xorg.conf`:
~~~
mv /root/xorg.conf.new /etc/X11/xorg.conf
~~~
7. Verify that X will work with those new settings:
~~~
xinit
~~~
If you see a terminal window in the top left corner, it means you most likely succeeded, even if your keyboard or mouse do not work now (don't worry about them).
8. Reboot and let the system boot from the normal boot configuration. You should be able to use X under Xen now.
Disabling Nouveau
---------------------
If Qubes fails to properly boot after the GRUB Boot menu and you are stuck on a black screen that displays messages starting with `nouveau` then it means that the nouveau driver failed to launch properly.
One way to get rid of this for now is to disable nouveau.
Example error
~~~
nouveau E[ PGRAPH][0000:01:00.0] grctx template channel unload timeout
nouveau E[ PGRAPH][0000:01:00.0] failed to construct context
nouveau E[ PGRAPH][0000:01:00.0] init failed, -16
~~~
Tip: In case you only have an external monitor it is advised to attach it directly to a connector of the motherboard if it is present, this should ensure that you're using the integrated graphics card instead of the nvidia graphics card.
If you're seeing this error then that means another graphics card (most likely an integrated one) acted as failsafe. Disabling nouveau has the consequences of disabling nvidia support altogether.
1. Verify that that GRUB Boot Menu is displaying, you should be presented with two options and a progressbar/timer than goes rather fast.
~~~
Qubes
Qubes with advanced Xen options
~~~
2. Quickly press the "E" key before the time is up.
3. An editor will open up that allows you to temporarily change the grub options for the next boot.
4. Press the down arrow key and move the cursor to the line after the line with the kernel options. The line with the kernel options will look like this:
~~~
module /vmlinux-4.1.13-9.pvops.qubes.x86_64 placeholder root=/dev/mapper/qubes_dom0-root ro ... rhgb quiet
~~~
It is not an exact copy as it may differ from system to system.
Please note: choose the module that starts with `vmlinux`!
5. Press the left/right arrow keys to position the cursor at the end of kernel options line, after `rhgb quiet` in this case.
6. Add the following:
~~~
nouveau.modeset=0 rd.driver.blacklist=nouveau video=vesa:off
~~~
This will temporarily disable nouveau until next boot.
7. Press either the F10 key or Ctrl+X to start the boot process.
Qubes should now boot properly, if that's the case then we should make this change permanent such that the GRUB config knows to not run nouveau.
You'll have to do the following to make this change persistent, so that it will work properly on every boot :
1. Open a terminal (do this by clicking on Q > 'run command' > type 'terminal' and hit enter)
2. type following commands:
~~~
cd /etc/default/
sudo nano grub
~~~
3. Edit `GRUB_CMDLINE_LINUX`, add the following to it at the end:
~~~
nouveau.modeset=0 rd.driver.blacklist=nouveau video=vesa:off
~~~
4. ctrl + X and then y to save the file.
5. The final step is to compile the configuration file to something the bootloader can read.
~~~
sudo grub2-mkconfig -o /boot/grub2/grub.cfg
~~~

46
troubleshooting/out-of-memory.md
View File

@ -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).

36
troubleshooting/remove-vm-manually.md
View File

@ -1,36 +0,0 @@
---
layout: doc
title: How to Remove VMs Manually
permalink: /doc/remove-vm-manually/
---
How to Remove VMs Manually
==========================
How to Remove a TemplateVM Manually
-----------------------------------
Try the [normal method] before resorting to this.
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

58
troubleshooting/sony-vaio-tinkering.md
View File

@ -1,58 +0,0 @@
---
layout: doc
title: Sony Vaio Tinkering
permalink: /doc/sony-vaio-tinkering/
redirect_from:
- /en/doc/sony-vaio-tinkering/
- /doc/SonyVaioTinkering/
- /wiki/SonyVaioTinkering/
---
Instructions for getting your Sony Vaio Z laptop working with Qubes/Linux
=========================================================================
Sony Vaio Z are great laptops -- they are very powerful, yet compact. The newer models, starting from Z12 are, however, not very well supported by Linux kernels (at least 2.6.34 that we currently use in Dom0) and thus some tinkering is needed to get Qubes working on those machines.
Getting the graphics card working under Linux/Qubes OS
------------------------------------------------------
Newer models of Sony Vaio Z come with an "intelligent" GPU switch, that automatically chooses either Intel Integrated GPU (IGD) or the discrete NVIDIA GPU. This confuses the Linux graphics so much, that in most cases won't even be able to install a regular Linux on such a machine. Unfortunately, moving the switch into the "Stamina" position apparently doesn't work, and the automatic GPU switching is still active.
One solution that actually worked for me was to reflash the BIOS (I know, I know, this is scary) and to enable the so called "Advanced Menu" in the BIOS. This Advanced Menu allows you to choose the desired behaviour of the GPU switch, which in our case would be to set it to "Static" and then move the mechanical switch to the "Stamina" position, that enabled the Intel IGD (which is much better supported on Linux).
If you think you are ready to reflash you BIOS, here are the instructions that worked for me:
[http://forum.notebookreview.com/sony/473226-insyde-hacking-new-vaio-z-advanced-menu-bios.html](http://forum.notebookreview.com/sony/473226-insyde-hacking-new-vaio-z-advanced-menu-bios.html)
**WARNING**: We take absolutely no responsibility that the BIOS reflashing instructions given at the referenced forum are 1) valid, 2) non-malicious, and 3) work at all. Do this step at your own risk. Keep in mind that reflashing your BIOS might yield your system unusable. If you don't feel like taking this risk (which is a reasonable state of mind), look for a different notebook, or ask Sony Support to enable this option for you.
In practice I have downloaded the BIOS-patching tools, run them in a VM on a BIOS image I extracted from my laptop, diffed the two versions, and concluded that it doesn't *seem* malicious, and then bravely applied tha patched image. If you don't know what are you doing, just get a different laptop, really!
On a side note, we should note that allowing anybody to reflash the BIOS is really a bad idea from a security point of view (Hello Evil Maids!). Shame on you, Sony!
Getting the touchpad working during installation
------------------------------------------------
In order to get the touchpad working during installation you should pass the **~~~i8042.nopnp=1~~~** option to the kernel before the installer starts.
\<screenshot\>
Applying other fixes
--------------------
There are a few more fixes needed for Sony Vaio Z, and we have prepared a special package that you can install in Dom0 that applies them all. After the installation is complete, open console in Dom0 and do the following:
~~~
$ sudo bash
# qvm-dom0-networking up
# yum install qubes-core-dom0-vaio-fixes
# reboot
~~~
This script takes care about the following:
- Setting i8042.nopnp for your installed system
- Adding special option for the sound module (so you can get sound)
- Adding pm-suspend scripts that take care about restoring your screen after resume
... now, having done this all, you will surely feel unprecedented satisfaction and you will love your Vaio very much! ;)

94
troubleshooting/thinkpad-troubleshooting.md
View File

@ -1,94 +0,0 @@
---
layout: doc
title: Lenovo ThinkPad Troubleshooting
permalink: /doc/thinkpad-troubleshooting/
redirect_from:
- /doc/thinkpad_x201/
- /en/doc/thinkpad_x201/
- /doc/Thinkpad_X201/
- /wiki/Thinkpad_X201/
- /doc/lenovo450-tinkering/
- /en/doc/lenovo450-tinkering/
- /doc/Lenovo450Tinkering/
- /wiki/Lenovo450Tinkering/
---
# Lenovo ThinkPad Troubleshooting #
## Instructions to create USB installation medium for newer (UEFI-only) ThinkPads ##
Some newer ThinkPads (e.g. T470, T470p, [P51](https://www.svensemmler.org/blog/2017/12/17/qubes-on-thinkpad-p51.html), ThinkPad 25, but not the [P53](https://github.com/QubesOS/qubes-issues/issues/5851)) are likely to fail installation attempts made from a USB stick that was created with dd or Rufus, and even from a DVD burned using official ISO images - if the ThinkPad is configured for UEFI boot. If you don't want to use Legacy Mode as a workaround, the following instructions should help you create a Qubes Installation USB stick that works in UEFI-only mode.
In a nutshell, you need to use the Fedora livecd-tools to make a Qubes Installation USB Stick from the Qubes ISO image, then update the label on the partition of that USB stick to "BOOT", and then update the BOOT/EFI/BOOTX64.cfg file on the USB stick so that all labels point to BOOT. In more detail:
1. On your ThinkPad, enter the UEFI setup (press F1 at startup) and make sure to set at least the following options:
- *USB UEFI BIOS Support: Enabled*
- *UEFI/Legacy Boot: UEFI Only*
- *Secure Boot: Disabled*
2. On a different computer, create a "Fedora Live USB Stick": Download a current Fedora Live CD image, and put it onto a USB stick (e.g. using dd or Rufus). Start your ThinkPad from the Fedora Live USB Stick on your ThinkPad (Press F12 at startup to select boot device). Of course, you can alternatively start a different machine from the Fedora Live USB Stick, or use an existing Fedora installation. The next steps all occur within Fedora:
3. Install livecd-tools: `# dnf install livecd-tools`
4. Download the desired Qubes ISO image (or attach a storage device containing it), and verify the signatures as described in the Qubes installation guide. For these instructions, I assume the ISO image is at */run/media/liveuser/qsrc/Qubes-R4.0-rc3-x86_64.iso* (so whenever you see that path going forward in these instructions, replace it with whatever your own path is)
5. Within Fedora, attach the USB stick that you would like to turn into your Qubes Installation USB Stick. Use `dmesg` to figure out what the device name of that stick is. For these instructions, I assume it's */dev/sdd* (so whenever you see */dev/sdd* going forward in these instructions, replace it with whatever your actual device name is)
6. Make sure your target USB stick (presumed to be /dev/sdd) has no mounted partitions: ``# umount /dev/sdd*`` (the asterisk at the end makes sure to unmount all partitions if more than one exists). If none are mounted you'll get an error that you can ignore.
7. Use livecd-tools to copy the image: ``# livecd-iso-to-disk --format --efi /run/media/liveuser/qsrc/Qubes-R4.0-rc3-x86_64.iso /dev/sdd``. **This will erase everything on the drive. Make sure you specify the correct destination.** Then press ENTER when prompted to proceed. This process will take quite a while, be patient.
8. When imaging is complete, change the partition label to BOOT: ``# dosfslabel /dev/sdd1 BOOT``
9. Now create a mount point and mount the partition:
``# mkdir /mnt/qinst``
``# mount /dev/sdd1 /mnt/qinst/``
10. Use your favorite editor to edit the file */mnt/qinst/EFI/BOOT/BOOTX64.cfg*: Replace all instances of ``LABEL=Qubes-R4.0-rc3-x86_64`` with ``LABEL=BOOT``. There is typically no space in front of ``LABEL``, but there is a space at the end of the portion you replace.
11. Unmount the Qubes Installation USB stick: ``# umount /dev/sdd*`` and disconnect it.
That's it! You can now reboot the machine with the Qubes USB Installation stick attached, and press F12 to select it as the boot device at startup. Proceed to install Qubes OS normally. Enjoy!
## ThinkPads with Intel HD 3000 graphics ##
Several ThinkPad models have Intel HD 3000 graphics, including the T420s and the
T520. Some users with these laptops have experienced random reboots, which were
solved by adding `i915.enable_rc6=0` as a kernel parameter to
`GRUB_CMDLINE_LINUX` in the file `/etc/default/grub` in dom0.
## Instructions for getting your Lenovo Thinkpad X201 & X200 laptop working with Qubes/Linux ##
For being able to boot the installer from USB, you have to disable VT-d in the BIOS.
Enter the BIOS by hitting F1, go to Config - CPU and then disable VT-d there.
After the installation, you have to set a startup-parameter for Xen, to be able to activate VT-d again:
1. Open a terminal in dom0
2. Edit `/etc/default/grub`
3. Add to the line `GRUB_CMDLINE_XEN_DEFAULT` the setting `iommu=no-igfx`, save and quit
4. sudo `grub2-mkconfig --output /boot/grub2/grub.cfg`
Then reboot, enter BIOS and re-enable VT-d.
### Getting scrolling with the Trackpoint and the Middle Button to work ###
1. Create a script with the following content:
~~~
#!/bin/sh
xinput set-prop "TPPS/2 IBM TrackPoint" "Evdev Wheel Emulation" 1
xinput set-prop "TPPS/2 IBM TrackPoint" "Evdev Wheel Emulation Button" 2
xinput set-prop "TPPS/2 IBM TrackPoint" "Evdev Wheel Emulation Timeout" 200
xinput set-prop "TPPS/2 IBM TrackPoint" "Evdev Wheel Emulation Axes" 6 7 4 5
~~~
2. Add the script to the startup-items of your desktop environment.
## Instructions for getting your Lenovo 450 laptop working with Qubes/Linux ##
Lenovo 450 uses UEFI, so some settings are needed to get Qubes (or Fedora) to boot, otherwise Qubes install USB stick will reboot right after boot selector screen and not continue install.
### Setting UEFI options to get Qubes install to boot ###
1. Enable Legacy USB mode
2. Disable all Secure Boot and UEFI options, but leave this enabled: Config / USB / USB UEFI BIOS SUPPORT
3. Save settings and reboot
5. Install Qubes
... and now enjoy :) These settings may be needed also in other UEFI computers.

138
troubleshooting/updating-debian-and-whonix.md
View File

@ -1,138 +0,0 @@
---
layout: doc
title: Updating Debian and Whonix
permalink: /doc/troubleshooting/updating-debian-and-whonix/
---
Updating Debian and Whonix
==========================
Despite Qubes shipping with [Debian Templates](/doc/templates/debian/), most of Qubes core components run on Fedora and thus our documentation has better coverage for Fedora. However, Qubes has been working closely with the [Whonix](https://whonix.org) project which is based on Debian.
This troubleshooting guide is collection of tips about updating Whonix that also pertain to updating the normal Debian package manager. If you plan to use Debian heavily, **we highly recommend you install the Whonix templates and use them to update your normal Debian TemplateVM.**
*Note: some of the links on this page go to documentation on Whonix's website*
### Updating Error Messages
After running the commands to update Debian or Whonix, hopefully everything will complete perfectly.
~~~
sudo apt-get update && sudo apt-get dist-upgrade
~~~
However, if you see something like the following, then something went wrong.
~~~
W: Failed to fetch http://ftp.us.debian.org/debian/dist/jessie/contrib/binary-i386/Packages 404 Not Found
W: Failed to fetch http://ftp.us.debian.org/debian/dist/jessie/non-free/binary-i386/Packages 404 Not Found
E: Some index files failed to download. They have been ignored, or old ones used instead.
Err http://ftp.us.debian.org jessie Release.gpg
Could not resolve 'ftp.us.debian.org'
Err http://deb.torproject.org jessie Release.gpg
Could not resolve 'deb.torproject.org'
Err http://security.debian.org jessie/updates Release.gpg
Could not resolve 'security.debian.org'
Reading package lists... Done
W: Failed to fetch http://security.debian.org/dists/jessie/updates/Release.gpg Could not resolve 'security.debian.org'
W: Failed to fetch http://ftp.us.debian.org/debian/dists/jessie/Release.gpg Could not resolve 'ftp.us.debian.org'
W: Failed to fetch http://deb.torproject.org/torproject.org/dists/jessie/Release.gpg Could not resolve 'deb.torproject.org'
W: Some index files failed to download. They have been ignored, or old ones used instead.
~~~
This could be a temporary Tor exit relay or server failure that should fix itself. Here are some simple things to try:
- Check if your network connection is functional
- Try to [change your Tor circuit](https://www.whonix.org/wiki/Arm), then try again
- Running [whonixcheck](https://www.whonix.org/wiki/Whonixcheck) might also help diagnose the problem
Sometimes if you see a message such as:
~~~
Could not resolve 'security.debian.org'
~~~
It helps to run the following command:
~~~
nslookup security.debian.org
~~~
And then trying running the `update` and `upgrade` commands again.
~~~
sudo apt-get update && sudo apt-get dist-upgrade
~~~
*Please note: if you [disabled the Whonix APT Repository](https://www.whonix.org/wiki/Whonix-APT-Repository#Disable_Whonix_APT_Repository) you'll have to manually check for new Whonix releases and [manually install them from source code](https://www.whonix.org/wiki/Dev/Build_Documentation).*
### Never Install Unsigned Packages
If you see something like this:
~~~
WARNING: The following packages cannot be authenticated!
icedove
Install these packages without verification [y/N]?
~~~
Don't proceed! Press `N` and `<enter>`. Running `apt-get update` again should fix it. If not, something is broken or it's a [Man in the middle attack](https://www.whonix.org/wiki/Warning#Man-in-the-middle_attacks), which isn't that unlikely, since we are updating over Tor exit relays and some of them are malicious. Try to [change your Tor circuit](https://www.whonix.org/wiki/Arm#Arm).
### Signature Verification Warnings
There should be none at the moment. If there was such a warning, it would look like this:
~~~
W: A error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: http://deb.torproject.org stable Release: The following signatures were invalid: KEYEXPIRED 1409325681 KEYEXPIRED 1409325681 KEYEXPIRED 1409325681 KEYEXPIRED 1409325681
~~~
Even though, `apt-get` will automatically ignore repositories with expired keys or signatures, you will not receive upgrades from that repository. Unless the issue is already known/documented, it should be reported so it can be further investigated.
There are two possible reasons why this could happen, either there is an issue with the repository that the maintainers have to fix, or you are victim of a [Man-in-the-middle_attacks](https://www.whonix.org/wiki/Warning#Man-in-the-middle_attacks). The latter would not be a big issue and might go away after a while automatically or try to [change your Tor circuit](https://www.whonix.org/wiki/Arm#Arm)
In past various apt repositories were signed with expired key. If you want to see how the documentation looked at that point, please click on expand on the right.
[The Tor Project's apt repository key was expired](https://trac.torproject.org/projects/tor/ticket/12994). You saw the following warning.
~~~
W: A error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: http://deb.torproject.org stable Release: The following signatures were invalid: KEYEXPIRED 1409325681 KEYEXPIRED 1409325681 KEYEXPIRED 1409325681 KEYEXPIRED 1409325681
W: Failed to fetch http://deb.torproject.org/torproject.org/dists/stable/Release
W: Some index files failed to download. They have been ignored, or old ones used instead.
~~~
It had already been [reported](https://trac.torproject.org/projects/tor/ticket/12994). There was no immediate danger. You could have just ignored it. Just make sure, you never install unsigned packages as explained above.
If you were to see other signature verification errors, those should be reported, but it shouldn't happen at this time.
### Changed Configuration Files
If you see something like the following.
~~~
Setting up ifupdown ...
Configuration file /etc/network/interfaces
==> Modified (by you or by a script) since installation.
==> Package distributor has shipped an updated version.
What would you like to do about it ? Your options are:
Y or I : install the package maintainer's version
N or O : keep your currently-installed version
D : show the differences between the versions
Z : background this process to examine the situation
The default action is to keep your current version.
*** interfaces (Y/I/N/O/D/Z) [default=N] ? N
~~~
Be careful. If the updated file isn't coming from Whonix specific package (some are called `whonix-...`), then press `n`. Otherwise anonymity/privacy/security settings deployed with Whonix might get lost. If you are an advanced user and know better, you can of course manually check the difference and merge them.
How could you find out if the file is coming from a Whonix specific package or not?
* Whonix specific packages are sometimes called `whonix-...`. In the example above it's saying `Setting up ifupdown ...`, so the file isn't coming from a Whonix specific package. In this case, you should press `n` as advised in the paragraph above.
* If the package name does include `whonix-...`, it's a Whonix specific package. In that case, your safest bet should be pressing `y`, but then you would lose your customized settings. You can re-add them afterwards. Such conflicts will hopefully rarely happen, if you use [Whonix modular flexible .d style configuration folders](https://www.whonix.org/wiki/Whonix_Configuration_Files).

121
troubleshooting/wireless-troubleshooting.md
View File

@ -1,121 +0,0 @@
---
layout: doc
title: Wireless Troubleshooting
permalink: /doc/wireless-troubleshooting/
redirect_from:
- /en/doc/wireless-troubleshooting/
---
Wireless Troubleshooting Guide
==============================
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 ###
First, determine which kernel module corresponds to your wireless card. There are several ways to do this.
The easiest is via the output of `lspci -k` in your sys-net VM:
~~~
[user@sys-net ~]$ lspci -k
00:00.0 Network controller: Intel Corporation Wireless 8260 (rev 3a)
Subsystem: Intel Corporation Device 0130
Kernel driver in use: iwlwifi
Kernel modules: iwlwifi
~~~
Here we see that the machine in question has an Intel wireless card, being used by the `iwlwifi` kernel module.
### Checking logs for relevant messages ###
View the output of `dmesg` in sys-net, and check if you see a bunch of wireless related errors. Depending on your hardware, they may look like the following (or not):
~~~
iwlwifi 0000:00:00.0: loaded firmware version 16.242414.0 op_mode iwlmvm
iwlwifi 0000:00:00.0: Detected Intel(R) Dual Band Wireless AC 8260, REV=0x208
...
IPv6: ADDRCONF(NETDEV_UP): wlp0s0: link is not ready
iwlwifi 0000:00:00.0: L1 Enabled - LTR Enabled
iwlwifi 0000:00:00.0: L1 Enabled - LTR Enabled
iwlwifi 0000:00:00.0: Failed to load firmware chunk!
iwlwifi 0000:00:00.0: Could not load the [0] uCode section
iwlwifi 0000:00:00.0: Failed to start INIT ucode: -110
iwlwifi 0000:00:00.0: Failed to run INIT ucode: -110
...
iwlwifi 0000:00:00.0: Direct firmware load for iwlwifi-8000C-18.ucode failed with error -2
~~~
### Seeing what modules you have loaded ###
You can check which drivers are currently loaded with `lsmod`, and view details about a module with `modinfo <module_name>`.
For example, we list what modules we have loaded:
~~~
[user@sys-net ~]$ lsmod
Module Size Used by
iwlmvm 315392 0
iwlwifi 155648 1 iwlmvm
mac80211 708608 1 iwlmvm
cfg80211 557056 3 iwlwifi,mac80211,iwlmvm
...
~~~
and check one:
~~~
[user@sys-net ~]$ modinfo iwlmvm | grep -E '^(description|author|depends):'
author: Copyright(c) 2003- 2015 Intel Corporation <ilw@linux.intel.com>
description: The new Intel(R) wireless AGN driver for Linux
depends: iwlwifi,mac80211,cfg80211
~~~
Hey, it's our wireless driver!
Now, check if reloading the module makes wireless work again:
~~~
[user@sys-net ~]$ sudo rmmod iwlmvm
[user@sys-net ~]$ sudo modprobe iwlmvm
~~~
and try reconnecting to a network that is known to work.
If that is successful, see below about having Qubes automatically reload the driver for you. If not, try also reloading some dependent modules, in our example we must also reload iwlwifi:
~~~
[user@sys-net ~]$ modinfo iwlwifi | grep -E '^(description|author|depends):'
author: Copyright(c) 2003- 2015 Intel Corporation <ilw@linux.intel.com>
description: Intel(R) Wireless WiFi driver for Linux
depends: cfg80211
~~~
~~~
[user@sys-net ~]$ sudo rmmod iwlmvm
[user@sys-net ~]$ sudo rmmod iwlwifi
[user@sys-net ~]$ sudo modprobe iwlwifi # note the reverse order of loading/unloading
[user@sys-net ~]$ sudo modprobe iwlmvm
~~~
Automatically reloading drivers 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`.
In the above example, it would look like this:
~~~
[user@sys-net config]$ cat /rw/config/suspend-module-blacklist
# You can list here modules you want to be unloaded before going to sleep. This
# file is used only if the VM has any PCI device assigned. Modules will be
# automatically loaded after resume.
iwlmvm
iwlwifi
~~~