7.3 KiB
Infrequently Asked Questions
Troubleshooting
How can I disable Xen Meltdown mitigations?
Set xpti=false
option in Xen command line (xen.gz option in grub, or options= line in xen.cfg for UEFI).
How can I switch R4.0 stubdomains back to qemu-traditional?
qvm-features VMNAME linux-stubdom ''
How can I upgrade everything to testing?
dom0: sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing --clean
(or --check-only instead for dom0).
fedora: sudo dnf update --enablerepo=qubes-vm-*-current-testing --refresh
debian/whonix: sudo apt-get update -t *-testing && sudo apt-get dist-upgrade -t *-testing
This way, you don't need to edit any files for debian/whonix to get the testing.
If you also want to increase reliability further, you can make a dependency/cache check with "sudo apt-get check", which is normally very quick.
For that, under debian/whonix do: sudo apt-get check && sudo apt-get update -t *-testing && sudo apt-get dist-upgrade -t *-testing
.
VM fail to start after hard power off
I realized that some VMs refuse to start after a hard power-off (hold power button for 10s).
When running qvm-start test
I get vm-test-private missing
.
But this thin volume is actually there.
Also the volume vm-test-private-snap
is still present.
Try this in dom0:
sudo pvscan --cache --activate ay
sudo systemctl restart qubesd
qvm-start test
Slow VM startup
Use tools like 'systemd-analyze blame' as your guide.
Another service that shows up with significant time is wpa_supplicant.
You can have it start only for network VMs by creating /lib/systemd/system/wpa_supplicant.service.d/20_netvms
with the following:
[Unit]
ConditionPathExists=/var/run/qubes/this-is-netvm
Xen passthrough compatible video cards
- https://en.wikipedia.org/wiki/List_of_IOMMU-supporting_hardware#AMD
- http://www.overclock.net/t/1307834/xen-vga-passthrough-compatible-graphics-adapters
- https://wiki.xenproject.org/wiki/Xen_VGA_Passthrough_Tested_Adapters#ATI.2FAMD_display_adapters
Where are VM log files kept?
In the /var/log/libvirst/libxl/
, /var/log/qubes/
and /var/log/xen/console/
directories.
Development
What is a good IDE for Qubes?
QtCreator.
What is the process flow when starting an AppVM under Qubes R4.x?
- qvm-start sends a request to qubesd, using Admin API
- qubesd starts required netvm (recursively), if needed
- qubesd request qmemman to allocate needed memory for new VM (according to VM's 'memory' property)
- qubesd calls into appropriate storage pool driver to prepare for VM startup (create copy-on-write layers etc)
- qubesd gathers needed VM properties etc and builds libvirt VM configuration (XML format, can be seen using
virsh dumpxml
) - qubesd calls into libvirt to start the VM (but in paused mode)
- libvirt setup the VM using libxl, this include starting stubdomain if needed
- qubesd start auxiliary processes, including:
- qrexec-daemon
- qubesdb-daemon (and fill its content)
- libvirt unpause the VM
- qvm-start-gui process (running separately from qubesd, as part of dom0 user GUI session) starts gui daemon
See "source" link here.
What is the process flow when opening a link/file in another VM ?
- in an AppVM ('srcVM') a link - or file - is set to be opened with the graphical "open in VM" or "open in dispVM" extensions (or respectively with the
/usr/bin/qvm-open-in-vm
or/usr/bin/qvm-open-in-dvm
command line tools) - in src VM, the destination VM is hardcoded to '$dispvm' if dispVMs are used (
/usr/bin/qvm-open-in-dvm
is a simple wrapper to/usr/bin/qvm-open-in-vm
) - in srcVM,
/usr/lib/qubes/qrexec-client-vm
is called, which in turn executes thequbes.OpenURL
RPC service to send the url to dstVM - in dstVM,
/etc/qubes-rpc/qubes.OpenURL
is called upon reception of thequbes.OpenURL
RPC event above, which validates the url and executes/usr/bin/qubes-open
- in dstVM,
/usr/bin/qubes-open
executesxdg-open
, which then opens the url/file with the program registered to handle the associated mime type (for additional info see the freedesktop specifications).
How can I contribute to developing Qubes Windows Tools for R4.0?
See this post and thread.
What are some undocumented QWT registry keys?
MaxFPS, UseDirtyBits.
Tweaks
How can I set environment variables for a VM?
Either add to /etc/environment
or create ~/.envsrc
and set a variable there, then create .xsessionrc
and source ~/.envsrc
.
See this thread.
How would I enable sudo authentication in a Template?
There are two ways to do this now:
-
Follow this Qubes doc to get the yes/no auth prompts for sudo.
-
Remove the 'qubes-core-agent-passwordless-root' package.
This second way means that sudo no longer works for a normal user.
Instead, any root access in the VM must be done from dom0 with a command like qvm-run -u root vmname command
.
How can I provision a VM with a larger/non-standard swap and /tmp?
Fedora's /tmp uses tmpfs ; it's mounted by systemd at boot time.
See systemctl status tmp.mount
and /usr/lib/systemd/system/tmp.mount.d/30_qubes.conf
to increase its size.
Alternatively you can increase the size afterwards with mount -o remount,size=5G /tmp/
.
If you need to have a disk based tmp you'll have to mask the systemd unit (systemctl mask tmp.mount
) and put a fstab entry for /tmp.
Alternatively you can add swap with a file inside the vm but it's a bit ugly:
dd if=/dev/zero of=swapfile bs=1M count=1000
mkswap swapfile
swapon swapfile
Manually install Whonix 14 templates
sudo qubes-dom0-update --enablerepo=qubes-dom0-unstable qubes-core-admin-addon-whonix
sudo qubes-dom0-update --enablerepo=qubes-dom0-unstable qubes-template-whonix-gw-14
qvm-create sys-whonix-14 --class AppVM --template whonix-gw-14 --label black
qvm-prefs sys-whonix-14 provides_network True
qvm-tags whonix-gw-14 a whonix-updatevm
sudo qubes-dom0-update --enablerepo=qubes-dom0-unstable qubes-template-whonix-ws-14
qvm-features whonix-ws-14 whonix-ws 1
qvm-create whonix-ws-dvm-14 --class AppVM --template whonix-ws-14 --label green
qvm-features whonix-ws-dvm-14 appmenus-dispvm 1
qvm-prefs whonix-ws-dvm-14 template_for_dispvms true
qvm-prefs whonix-ws-dvm-14 netvm sys-whonix-14
qvm-prefs whonix-ws-dvm-14 default_dispvm whonix-ws-dvm-14
qvm-tags whonix-ws-14 a whonix-updatevm
To use the new sys-whonix-14
for your UpdateVM, perform the following steps:
qubes-prefs updatevm sys-whonix-14
Then, edit /etc/qubes-rpc/policy/qubes.UpdatesProxy
and modify the top lines:
$type:TemplateVM $default allow,target=sys-whonix
$tag:whonix-updatevm $default allow,target=sys-whonix
to become:
$type:TemplateVM $default allow,target=sys-whonix-14
$tag:whonix-updatevm $default allow,target=sys-whonix-14
Thanks to all mailing list contributors, from where most of these came.