Git-Mirrors/qubes-doc
1
0
Fork 0
mirror of https://github.com/QubesOS/qubes-doc.git synced 2025-08-06 05:34:27 -04:00
Code Issues Projects Releases Packages Wiki Activity

Use console lexer instead of bash with a prompt

Browse source
This commit is contained in:
parulin 2025-07-27 02:03:08 -04:00
parent ba609d123e
commit b53776e1eb
No known key found for this signature in database
GPG key ID: BC3830B42F4BF1F5
49 changed files with 256 additions and 256 deletions
Download patch file Download diff file Expand all files Collapse all files

4
developer/building/development-workflow.rst
View file

@ -17,7 +17,7 @@ The best way to write and contribute code is to create a git repo somewhere (e.g
**Example:**
.. code:: bash
.. code:: console
$ cd qubes-builder/artifacts/sources/qubes-manager
$ git remote add abel git@GitHub.com:abeluck/qubes-manager.git
@ -290,7 +290,7 @@ You will also need to setup qrexec policy in dom0 (``/etc/qubes-rpc/policy/local
Usage:
.. code:: bash
.. code:: console
[user@source core-agent-linux]$ git remote add testbuilder "ext::git-qrexec testbuilder 3 core-agent-linux"
[user@source core-agent-linux]$ git push testbuilder master

16
developer/building/qubes-builder-v2.rst
View file

@ -31,7 +31,7 @@ This is a simple setup using a docker executor. This is a good default choice; i
.. code:: bash
.. code:: console
$ sudo dnf install $(cat dependencies-fedora.txt)
$ test -f /usr/share/qubes/marker-vm && sudo dnf install qubes-gpg-split
@ -43,7 +43,7 @@ This is a simple setup using a docker executor. This is a good default choice; i
.. code:: bash
.. code:: console
$ sudo apt install $(cat dependencies-debian.txt)
$ test -f /usr/share/qubes/marker-vm && sudo apt install qubes-gpg-split
@ -60,7 +60,7 @@ This is a simple setup using a docker executor. This is a good default choice; i
4. If you haven’t previously used docker in the current qube, you need to set up some permissions. In particular, the user has to be added to the ``docker`` group:
.. code:: bash
.. code:: console
$ sudo usermod -aG docker user
@ -68,7 +68,7 @@ This is a simple setup using a docker executor. This is a good default choice; i
5. Finally, you need to generate a docker image:
.. code:: bash
.. code:: console
$ tools/generate-container-image.sh docker
@ -124,7 +124,7 @@ Using Builder v2
To fetch sources - in this example, for the ``core-admin-client`` package, you can use the following command:
.. code:: bash
.. code:: console
$ ./qb -c core-admin-client package fetch
@ -133,21 +133,21 @@ This will fetch the sources for the listed package and place them in ``artifacts
To build a package (from sources in the ``artifacts/sources`` directory), use:
.. code:: bash
.. code:: console
$ ./qb -c core-admin-client package fetch prep build
or, if you want to build for a specific target (``host-fc37`` is a ``dom0`` using Fedora 37, ``vm-fc40`` would be a qube using Fedora 40 etc.), use:
.. code:: bash
.. code:: console
$ ./qb -c core-admin-client -d host-fc37 package fetch prep build
If you want to fetch the entire Qubes OS source use the following:
.. code:: bash
.. code:: console
$ ./qb package fetch

2
developer/building/qubes-iso-building.rst
View file

@ -32,7 +32,7 @@ Create a standalone AppVM from the Fedora template. Set private storage to at le
Once you’ve built the development AppVM, open a Terminal window to it and install the necessary dependencies (see :doc:`QubesBuilder </developer/building/qubes-builder>` for more info):
.. code:: bash
.. code:: console
$ sudo dnf install git createrepo rpm-build rpm-sign make python3-sh rpmdevtools rpm-sign dialog perl-open python3-pyyaml perl-Digest-MD5 perl-Digest-SHA

4
developer/code/code-signing.rst
View file

@ -13,7 +13,7 @@ Generating a Key
Alex Cabal has written an excellent `guide <https://alexcabal.com/creating-the-perfect-gpg-keypair/>`__ on creating a PGP keypair. Below, we reproduce just the minimum steps in generating a keypair using GnuPG. Please read Cabal’s full guide for further important details.
.. code:: bash
.. code:: console
$ gpg --gen-key
gpg (GnuPG) 2.2.27; Copyright (C) 2021 Free Software Foundation, Inc.
@ -75,7 +75,7 @@ Replace 6E2F4E7AF50A5827 with your key ID, preferably the **long keyID** which i
.. code:: bash
.. code:: console
$ gpg --send-keys --keyserver hkps://keyserver.ubuntu.com 6E2F4E7AF50A5827
gpg: sending key 6E2F4E7AF50A5827 to hkps://keyserver.ubuntu.com

4
developer/debugging/automated-tests.rst
View file

@ -39,7 +39,7 @@ Our test runner runs mostly the same as the standard one, but it has some nice a
You can use ``python3 -m qubes.tests.run -h`` to get usage information:
.. code:: bash
.. code:: console
[user@dom0 ~]$ python3 -m qubes.tests.run -h
usage: run.py [-h] [--verbose] [--quiet] [--list] [--failfast] [--no-failfast]
@ -82,7 +82,7 @@ You can use ``python3 -m qubes.tests.run -h`` to get usage information:
For instance, to run only the tests for the fedora-21 template, you can use the ``-l`` option, then filter the list:
.. code:: bash
.. code:: console
[user@dom0 ~]$ python3 -m qubes.tests.run -l | grep fedora-21
network/VmNetworking_fedora-21/test_000_simple_networking

12
developer/debugging/mount-lvm-image.rst
View file

@ -7,7 +7,7 @@ You want to read your LVM image (e.g., there is a problem where you can’t star
1: make the image available for qubesdb. From dom0 terminal:
.. code:: bash
.. code:: console
# Example: /dev/qubes_dom0/vm-debian-9-tmp-root
[user@dom0]$ dev=$(basename $(readlink /dev/YOUR_LVM_VG/YOUR_LVM_IMAGE))
@ -16,7 +16,7 @@ You want to read your LVM image (e.g., there is a problem where you can’t star
2: Create a new disposable VM
.. code:: bash
.. code:: console
[user@dom0]$ qvm-run -v --dispvm=YOUR_DVM_TEMPLATE --service qubes.StartApp+xterm &
@ -25,28 +25,28 @@ You want to read your LVM image (e.g., there is a problem where you can’t star
From the GUI, or from the command line:
.. code:: bash
.. code:: console
[user@dom0]$ qvm-block attach NEWLY_CREATED_DISPVM dom0:$dev
4: Mount the partition you want to, and do what you want with it
.. code:: bash
.. code:: console
[user@dispXXXX]$ mount /dev/xvdiX /mnt/
5: Umount and kill the VM
.. code:: bash
.. code:: console
[user@dispXXXX]$ umount /mnt/
6: Remove the image from qubesdb
.. code:: bash
.. code:: console
[user@dom0]$ qubesdb-rm /qubes-block-devices/$dev/

6
developer/debugging/safe-remote-ttys.rst
View file

@ -17,7 +17,7 @@ To a different VM
As an example of forwarding terminal output to another VM on the same machine:
.. code:: bash
.. code:: console
$ mkfifo /tmp/foo
$ qvm-run -p some-vm 'xterm -e "cat 0<&5" 5<&0' </tmp/foo >/dev/null 2>&1 &
@ -31,7 +31,7 @@ To a different machine
In this case over SSH (from a network-connected VM):
.. code:: bash
.. code:: console
$ mkfifo /tmp/foo
$ qvm-run -p some-vm \
@ -55,7 +55,7 @@ Terminal size
It is up to you to ensure the sizes of the local and remote terminal are the same, otherwise things may display incorrectly (especially in interactive programs). Depending on your shell, the size of your local (blind) terminal is likely stored in the ``$LINES`` and ``$COLUMNS`` variables.
.. code:: bash
.. code:: console
$ echo $COLUMNS $LINES
80 24

22
developer/services/qrexec.rst
View file

@ -20,7 +20,7 @@ Qrexec is built on top of *vchan*, a Xen library providing data links between VM
The ``qrexec-client`` command is used to make connections to VMs from dom0. For example, the following command creates an empty file called ``hello-world.txt`` in the home folder of ``someVM``:
.. code:: bash
.. code:: console
$ qrexec-client -e -d someVM user:'touch hello-world.txt'
@ -28,7 +28,7 @@ The ``qrexec-client`` command is used to make connections to VMs from dom0. For
The string before the colon specifies which user will run the command. The ``-e`` flag tells ``qrexec-client`` to exit immediately after sending the execution request and receiving a status code from ``qrexec-agent`` (if the process creation succeeded). With this option, no further data is passed between the domains. The following command demonstrates an open channel between dom0 and someVM (in this case, a remote shell):
.. code:: bash
.. code:: console
$ qrexec-client -d someVM user:bash
@ -85,7 +85,7 @@ Making an RPC call
From outside of dom0, RPC calls take the following form:
.. code:: bash
.. code:: console
$ qrexec-client-vm target_vm_name RPC_ACTION_NAME rpc_client_path client arguments
@ -93,7 +93,7 @@ From outside of dom0, RPC calls take the following form:
For example:
.. code:: bash
.. code:: console
$ qrexec-client-vm work qubes.StartApp+firefox
@ -103,7 +103,7 @@ Note that only stdin/stdout is passed between RPC server and client – notably,
It is also possible to call service without specific client program – in which case server stdin/out will be connected with the terminal:
.. code:: bash
.. code:: console
$ qrexec-client-vm target_vm_name RPC_ACTION_NAME
@ -167,7 +167,7 @@ Be very careful when coding and adding a new RPC service. Unless the offered fun
For example, this command will run the ``firefox`` command in a DisposableVM based on ``work``:
.. code:: bash
.. code:: console
$ qvm-run --dispvm=work firefox
@ -175,7 +175,7 @@ For example, this command will run the ``firefox`` command in a DisposableVM bas
By contrast, consider this command:
.. code:: bash
.. code:: console
$ qvm-run --dispvm=work --service qubes.StartApp+firefox
@ -203,7 +203,7 @@ The argument is specified in the second column of the policy line, as +ARGUMENT.
When calling a service that takes an argument, just add the argument to the service name separated with ``+``.
.. code:: bash
.. code:: console
$ qrexec-client-vm target_vm_name RPC_ACTION_NAME+ARGUMENT
@ -263,7 +263,7 @@ This will allow our client and server to communicate.
Before we make the call, ensure that the client and server scripts have executable permissions. Finally, invoke the RPC service.
.. code:: bash
.. code:: console
$ qrexec-client-vm anotherVM test.Add /usr/bin/our_test_add_client 1 2
@ -309,7 +309,7 @@ Now we create the policy file in dom0, at ``/etc/qubes/policy.d/30-test.policy``
With this done, we can run some tests. Invoke RPC from ``source_vm1`` via
.. code:: bash
.. code:: console
[user@source_vm1] $ qrexec-client-vm target_vm test.File+testfile1
@ -317,7 +317,7 @@ With this done, we can run some tests. Invoke RPC from ``source_vm1`` via
We should get the contents of ``/home/user/testfile1`` printed to the terminal. Invoking the service from ``source_vm2`` should result in a denial, but ``testfile2`` should work.
.. code:: bash
.. code:: console
[user@source_vm2] $ qrexec-client-vm target_vm test.File+testfile1
Request refused

4
developer/services/qrexec2.rst
View file

@ -17,7 +17,7 @@ Typically, the first thing that a ``qrexec-client`` instance does is to send a r
E.g., to start a primitive shell in a VM type the following in Dom0 console:
.. code:: bash
.. code:: console
[user@dom0 ~]$ /usr/lib/qubes/qrexec-client -d <vm name> user:bash
@ -147,7 +147,7 @@ We will show the necessary files to create a simple RPC call that adds two integ
- Policy file in dom0 (``/etc/qubes-rpc/policy/test.Add``)
.. code:: bash
.. code::
$anyvm $anyvm ask

4
introduction/faq.rst
View file

@ -570,7 +570,7 @@ For Debian:
.. code:: bash
.. code:: console
$ sudo apt install vlc
@ -589,7 +589,7 @@ For Fedora:
.. code:: bash
.. code:: console
$ sudo dnf install vlc

4
project-security/security-pack.rst
View file

@ -79,7 +79,7 @@ The following example demonstrates one method of obtaining the qubes-secpack and
4. Verify signed Git tags.
.. code:: bash
.. code:: console
$ cd qubes-secpack/
$ git tag -v `git describe`
@ -97,7 +97,7 @@ The following example demonstrates one method of obtaining the qubes-secpack and
5. Verify detached PGP signatures.
.. code:: bash
.. code:: console
$ cd canaries/
$ gpg --verify canary-001-2015.txt.sig.joanna canary-001-2015.txt

44
project-security/verifying-signatures.rst
View file

@ -51,14 +51,14 @@ Once you have appropriate OpenPGP software installed, there are several ways to
- If you’re on Qubes OS, it’s available in every qube (`except dom0 <https://github.com/QubesOS/qubes-issues/issues/2544>`__):
.. code:: bash
.. code:: console
$ gpg2 --import /usr/share/qubes/qubes-master-key.asc
- If you’re on Fedora, you can get it in the `distribution-gpg-keys <https://github.com/xsuchy/distribution-gpg-keys>`__ package:
.. code:: bash
.. code:: console
$ dnf install distribution-gpg-keys
$ gpg2 --import /usr/share/distribution-gpg-keys/qubes/*
@ -68,14 +68,14 @@ Once you have appropriate OpenPGP software installed, there are several ways to
- Fetch it with GPG:
.. code:: bash
.. code:: console
$ gpg2 --fetch-keys https://keys.qubes-os.org/keys/qubes-master-signing-key.asc
- Get it from a public `keyserver <https://en.wikipedia.org/wiki/Key_server_%28cryptographic%29#Keyserver_examples>`__ (specified on first use with ``--keyserver <URI>`` along with keyserver options to include key signatures), e.g.:
.. code:: bash
.. code:: console
$ gpg2 --keyserver-options no-self-sigs-only,no-import-clean --keyserver hkp://keyserver.ubuntu.com --recv-keys 0x427F11FD0FAA4B080123F01CDDFA1A3E36879494
@ -94,7 +94,7 @@ Once you have appropriate OpenPGP software installed, there are several ways to
Once you have the key as a file, import it:
.. code:: bash
.. code:: console
$ gpg2 --import /<PATH_TO_FILE>/qubes-master-signing-key.asc
@ -213,7 +213,7 @@ Now, when you import any of the release signing keys and many Qubes team member
As a final sanity check, make sure the QMSK is in your keyring with the correct trust level.
.. code:: bash
.. code:: console
$ gpg2 -k "Qubes Master Signing Key"
pub rsa4096 2010-04-01 [SC]
@ -242,21 +242,21 @@ After you have completed these two prerequisite steps, the next step is to obtai
- If you have access to an existing Qubes installation, the release keys are available in dom0 in ``/etc/pki/rpm-gpg/RPM-GPG-KEY-qubes-*``. These can be :ref:`copied <user/how-to-guides/how-to-copy-from-dom0:copying *from* dom0>` into other qubes for further use. In addition, every other qube contains the release key corresponding to that installation’s release in ``/etc/pki/rpm-gpg/RPM-GPG-KEY-qubes-*``. If you wish to use one of these keys, make sure to import it into your keyring, e.g.:
.. code:: bash
.. code:: console
$ gpg2 --import /etc/pki/rpm-gpg/RPM-GPG-KEY-qubes-*
- Fetch it with GPG:
.. code:: bash
.. code:: console
$ gpg2 --keyserver-options no-self-sigs-only,no-import-clean --fetch-keys https://keys.qubes-os.org/keys/qubes-release-X-signing-key.asc
- Download it as a file. You can find the RSK for your Qubes release on the `downloads <https://www.qubes-os.org/downloads/>`__ page. You can also download all the currently used developers’ signing keys, RSKs, and the Qubes Master Signing Key from the :doc:`Qubes security pack </project-security/security-pack>` and the `Qubes keyserver <https://keys.qubes-os.org/keys/>`__. Once you’ve downloaded your RSK, import it with GPG:
.. code:: bash
.. code:: console
$ gpg2 --keyserver-options no-self-sigs-only,no-import-clean --import ./qubes-release-X-signing-key.asc
@ -265,7 +265,7 @@ After you have completed these two prerequisite steps, the next step is to obtai
Now that you have the correct RSK, you simply need to verify that it is signed by the QMSK:
.. code:: bash
.. code:: console
$ gpg2 --check-signatures "Qubes OS Release X Signing Key"
pub rsa4096 YYYY-MM-DD [SC]
@ -281,7 +281,7 @@ This is just an example, so the output you receive may not look exactly the same
As a final sanity check, make sure the RSK is in your keyring with the correct trust level:
.. code:: bash
.. code:: console
$ gpg2 -k "Qubes OS Release X Signing Key"
pub rsa4096 YYYY-MM-DD [SC]
@ -351,7 +351,7 @@ If the filename of your ISO is ``Qubes-RX-x86_64.iso``, then the name of the dig
Four digests have been computed for this ISO. The hash functions used, in order from top to bottom, are MD5, SHA-1, SHA-256, and SHA-512. One way to verify that the ISO you downloaded matches any of these hash values is by using the respective ``*sum`` command:
.. code:: bash
.. code:: console
$ md5sum -c Qubes-RX-x86_64.iso.DIGESTS
Qubes-RX-x86_64.iso: OK
@ -371,7 +371,7 @@ The ``OK`` response tells us that the hash value for that particular hash functi
Another way is to use ``openssl`` to compute each hash value, then compare them to the contents of the digest file:
.. code:: bash
.. code:: console
$ openssl dgst -md5 Qubes-RX-x86_64.iso
MD5(Qubes-RX-x86_64.iso)= 3c951138b8b9867d8657f173c1b58b82
@ -387,7 +387,7 @@ Another way is to use ``openssl`` to compute each hash value, then compare them
However, it is possible that an attacker replaced ``Qubes-RX-x86_64.iso`` with a malicious ISO, computed the hash values for that malicious ISO, and replaced the values in ``Qubes-RX-x86_64.iso.DIGESTS`` with his own set of values. Therefore, we should also verify the authenticity of the listed hash values. Since ``Qubes-RX-x86_64.iso.DIGESTS`` is a clearsigned PGP file, we can use GPG to verify the signature in the digest file:
.. code:: bash
.. code:: console
$ gpg2 -v --verify Qubes-RX-x86_64.iso.DIGESTS
gpg: armor header: Hash: SHA256
@ -423,7 +423,7 @@ Every Qubes ISO is released with a **detached PGP signature** file, which you ca
Download both the ISO and its signature file. Put both of them in the same directory, then navigate to that directory. Now, you can verify the ISO by executing this GPG command in the directory that contains both files:
.. code:: bash
.. code:: console
$ gpg2 -v --verify Qubes-RX-x86_64.iso.asc Qubes-RX-x86_64.iso
gpg: armor header: Version: GnuPG v1
@ -449,7 +449,7 @@ This section will walk through an example of re-verifying the installer on such
Now, our goal is to perform the same verification steps as we did with the original ISO, except, this time, we’ll be reading the installer data directly from the write-protected USB drive instead of from the original ISO file. First, let’s compute the SHA-256 hash value of the data on the drive. (This assumes you’re already familiar with `how to verify the cryptographic hash values of Qubes ISOs <#how-to-verify-the-cryptographic-hash-values-of-qubes-isos>`__.) In order to do this, we have to know the exact size, in bytes, of the original ISO. There are two ways to get this information: from the ISO itself and from the Qubes website. Here’s an example of the first way:
.. code:: bash
.. code:: console
$ dd if=/dev/sdX bs=1M count=$(stat -c %s /path/to/iso) iflag=count_bytes | sha256sum
@ -472,7 +472,7 @@ Now, reading the number of bytes directly from the ISO is fine, but you may be c
Therefore, in order to make things a bit more difficult for your hypothetical adversary, you may instead wish to perform the re-verification in an environment that has never seen the original ISO, e.g., a separate offline computer or a fresh VM the storage space of which is too small to hold the ISO. (**Note:** If you’re doing this in Qubes, you can attach the block device from sys-usb to a separate new qube. You don’t have to perform the re-verification directly in sys-usb.) In that case, you’ll have to obtain the size of the ISO in bytes and enter it into the above command manually. You can, of course, obtain the size by simply using the ``stat -c %s /path/to/iso`` command from above on the machine that has the ISO. You can also obtain it from the Qubes website by hovering over any ISO download button on the `downloads page <https://www.qubes-os.org/downloads/>`__. (You can also view these values directly in the downloads page’s `source data <https://github.com/QubesOS/qubesos.github.io/blob/master/_data/downloads.yml>`__.) Once you have the exact size of the ISO in bytes, simply insert it into the same command, for example:
.. code:: bash
.. code:: console
$ dd if=/dev/sdX bs=1M count=5791285248 iflag=count_bytes | sha256sum
@ -481,7 +481,7 @@ If you wish to compute the values of other hash functions, you can replace ``sha
In addition to checking hash values, you can also use GnuPG to verify the detached PGP signature directly against the data on the USB drive. (This assumes you’re already familiar with `how to verify detached PGP signatures on Qubes ISOs <#how-to-verify-detached-pgp-signatures-on-qubes-isos>`__.)
.. code:: bash
.. code:: console
$ dd if=/dev/sdX bs=1M count=<ISO_SIZE> iflag=count_bytes | gpg -v --verify Qubes-RX-x86_64.iso.asc -
gpg: Signature made <TIME>
@ -520,14 +520,14 @@ How to verify a signature on a Git tag
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
.. code:: bash
.. code:: console
$ git tag -v <tag name>
or
.. code:: bash
.. code:: console
$ git verify-tag <tag name>
@ -536,14 +536,14 @@ How to verify a signature on a Git commit
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
.. code:: bash
.. code:: console
$ git log --show-signature <commit ID>
or
.. code:: bash
.. code:: console
$ git verify-commit <commit ID>

4
user/advanced-topics/awesomewm.rst
View file

@ -24,7 +24,7 @@ Installation
AwesomeWM can be installed with the standard dom0 installation mechanisms.
.. code:: bash
.. code:: console
$ sudo qubes-dom0-update awesome
@ -37,7 +37,7 @@ Development
To :doc:`contribute code </introduction/contributing>` you may clone the AwesomeWM repository as follows:
.. code:: bash
.. code:: console
$ git clone https://github.com/QubesOS/qubes-desktop-linux-awesome

18
user/advanced-topics/disposable-customization.rst
View file

@ -12,14 +12,14 @@ Introduction
A :doc:`disposable </user/how-to-guides/how-to-use-disposables>` can be based on any :ref:`app qube <user/reference/glossary:app qube>`. You can also choose to use different :ref:`disposable templates <user/reference/glossary:disposable template>` for different disposables. To prepare an app qube to be a disposable template, you need to set the ``template_for_dispvms`` property:
.. code:: bash
.. code:: console
[user@dom0 ~]$ qvm-prefs <DISPOSABLE_TEMPLATE> template_for_dispvms True
Additionally, if you want to have menu entries for starting applications in disposables based on this app qube (instead of in the app qube itself), you can achieve that with the ``appmenus-dispvm`` feature:
.. code:: bash
.. code:: console
[user@dom0 ~]$ qvm-features <DISPOSABLE_TEMPLATE> appmenus-dispvm 1
@ -38,7 +38,7 @@ Creating a new disposable template
In Qubes 4.0, you’re no longer restricted to a single disposable template. Instead, you can create as many as you want. Whenever you start a new disposable, you can choose to base it on whichever disposable template you like. To create a new disposable template:
.. code:: bash
.. code:: console
[user@dom0 ~]$ qvm-create --template <TEMPLATE> --label red <DISPOSABLE_TEMPLATE>
[user@dom0 ~]$ qvm-prefs <DISPOSABLE_TEMPLATE> template_for_dispvms True
@ -47,7 +47,7 @@ In Qubes 4.0, you’re no longer restricted to a single disposable template. Ins
Optionally, set it as the default disposable template:
.. code:: bash
.. code:: console
[user@dom0 ~]$ qubes-prefs default_dispvm <DISPOSABLE_TEMPLATE>
@ -66,7 +66,7 @@ It is possible to change the settings for each new disposable. This can be done
1. Start a terminal in the ``<DISPOSABLE_TEMPLATE>`` qube (or another disposable template) by running the following command in a dom0 terminal. (If you enable ``appmenus-dispvm`` feature (as explained at the top), applications menu for this VM (``<DISPOSABLE_TEMPLATE>``) will be “Disposable: ” (instead of “Domain: ”) and entries there will start new disposable based on that VM (``<DISPOSABLE_TEMPLATE>``). Not in that VM (``<DISPOSABLE_TEMPLATE>``) itself).
.. code:: bash
.. code:: console
[user@dom0 ~]$ qvm-run -a <DISPOSABLE_TEMPLATE> gnome-terminal
@ -173,7 +173,7 @@ Deleting disposables
While working in a disposable, you may want to open a document in another disposable. For this reason, the property ``default_dispvm`` may be set to the name of your disposable in a number of qubes:
.. code:: bash
.. code:: console
[user@dom0 ~]$ qvm-prefs <QUBE> | grep default_dispvm
default_dispvm - <DISPOSABLE_TEMPLATE>
@ -181,14 +181,14 @@ While working in a disposable, you may want to open a document in another dispos
This will prevent the deletion of the disposable template. In order to fix this, you need to unset the ``default_dispvm`` property:
.. code:: bash
.. code:: console
[user@dom0 ~]$ qvm-prefs <QUBE> default_dispvm ""
You can then delete the disposable template:
.. code:: bash
.. code:: console
[user@dom0 ~]$ qvm-remove <DISPOSABLE_TEMPLATE>
This will completely remove the selected VM(s)
@ -197,7 +197,7 @@ You can then delete the disposable template:
If you still encounter a problem, you may have forgotten to clean an entry. Looking at the system logs will help you:
.. code:: bash
.. code:: console
[user@dom0 ~]$ journalctl | tail

2
user/advanced-topics/how-to-install-software-in-dom0.rst
View file

@ -30,7 +30,7 @@ How to install a specific package
To install additional packages in dom0 (usually not recommended):
.. code:: bash
.. code:: console
$ sudo qubes-dom0-update anti-evil-maid

14
user/advanced-topics/i3.rst
View file

@ -8,7 +8,7 @@ i3 (window manager)
i3 is part of the stable repository (as of Qubes R3.1) and can be installed by using the :doc:`dom0 update mechanism </user/advanced-topics/how-to-install-software-in-dom0>`. To install the i3 window manager and the its Qubes specific configuration:
.. code:: bash
.. code:: console
$ sudo qubes-dom0-update i3 i3-settings-qubes
@ -47,7 +47,7 @@ Getting the code
Clone the i3-qubes repository here:
.. code:: bash
.. code:: console
$ git clone https://github.com/QubesOS/qubes-desktop-linux-i3
@ -62,14 +62,14 @@ Building
You’ll need to install the build dependencies, which are listed in build-deps.list. You can verify them and then install them with:
.. code:: bash
.. code:: console
$ sudo dnf install -y $(cat build-deps.list)
This used to be more complicated, but I finally redid this and use the same buildsystem that’s used by Qubes OS for XFCE. It’s just a Makefile that helps you get the sources and start off the build:
.. code:: bash
.. code:: console
$ make get-sources
$ make verify-sources
@ -86,14 +86,14 @@ You should now have your i3 rpm in ``./rpm/x86_64/i3-4.8-3.fc20.x86_64.rpm``. Pr
Now in dom0, copy in the rpm:
.. code:: bash
.. code:: console
$ qvm-run --pass-io <src_domain> 'cat </path/to/rpm_in_src_domain>' > i3.rpm
Now that the rpm is in dom0 we can proceed with installing it. i3 has some dependencies that we can easily install with:
.. code:: bash
.. code:: console
$ sudo qubes-dom0-update perl-AnyEvent-I3 xorg-x11-apps \\
rxvt-unicode xcb-util-wm perl-JSON-XS xcb-util-cursor \\
@ -102,7 +102,7 @@ Now that the rpm is in dom0 we can proceed with installing it. i3 has some depen
After that you can just install the generated rpm like any other local package:
.. code:: bash
.. code:: console
$ sudo yum localinstall i3.rpm

6
user/advanced-topics/kde.rst
View file

@ -12,7 +12,7 @@ Installation
Prior to R3.2, KDE was the default desktop environment in Qubes. Beginning with R3.2, however, :doc:`XFCE is the new default desktop environment </developer/releases/3_2/release-notes>`. Nonetheless, it is still possible to install KDE by issuing this command in dom0:
.. code:: bash
.. code:: console
$ sudo qubes-dom0-update kde-settings-qubes
@ -56,7 +56,7 @@ You can also change your default login manager (lightdm) to the new KDE default:
- disable the lightdm service:
.. code:: bash
.. code:: console
$ sudo systemctl disable lightdm
@ -64,7 +64,7 @@ You can also change your default login manager (lightdm) to the new KDE default:
- enable the sddm service:
.. code:: bash
.. code:: console
$ sudo systemctl enable sddm

18
user/advanced-topics/managing-vm-kernels.rst
View file

@ -22,7 +22,7 @@ By default, VMs kernels are provided by dom0. (See :ref:`here <user/advanced-top
To select which kernel a given VM will use, you can either use Qubes Manager (VM settings, advanced tab), or the ``qvm-prefs`` tool:
.. code:: bash
.. code:: console
[user@dom0 ~]$ qvm-prefs -s my-appvm kernel
Missing kernel version argument!
@ -40,7 +40,7 @@ To select which kernel a given VM will use, you can either use Qubes Manager (VM
To check/change the default kernel you can either go to “Global settings” in Qubes Manager, or use the ``qubes-prefs`` tool:
.. code:: bash
.. code:: console
[user@dom0 ~]$ qubes-prefs
clockvm : sys-net
@ -54,7 +54,7 @@ To check/change the default kernel you can either go to “Global settings” in
To view kernel options, you can use the GUI VM Settings tool; to view and change them, use ``qvm-prefs`` commandline tool:
.. code:: bash
.. code:: console
[user@dom0 ~]$ qvm-prefs -g work kernelopts
nopat
@ -67,7 +67,7 @@ Installing different kernel using Qubes kernel package
VM kernels are packaged by the Qubes team in the ``kernel-qubes-vm`` packages. Generally, the system will keep the three newest available versions. You can list them with the ``rpm`` command:
.. code:: bash
.. code:: console
[user@dom0 ~]$ rpm -qa 'kernel-qubes-vm*'
kernel-qubes-vm-3.18.10-2.pvops.qubes.x86_64
@ -79,7 +79,7 @@ If you want a more recent version, you can check the ``qubes-dom0-unstable`` rep
To check available versions in the ``qubes-dom0-unstable`` repository:
.. code:: bash
.. code:: console
[user@dom0 ~]$ sudo qubes-dom0-update --enablerepo=qubes-dom0-unstable --action=list kernel-qubes-vm
Using sys-firewall as UpdateVM to download updates for Dom0; this may take some time...
@ -100,7 +100,7 @@ To check available versions in the ``qubes-dom0-unstable`` repository:
Installing a new version from ``qubes-dom0-unstable`` repository:
.. code:: bash
.. code:: console
[user@dom0 ~]$ sudo qubes-dom0-update --enablerepo=qubes-dom0-unstable kernel-qubes-vm
Using sys-firewall as UpdateVM to download updates for Dom0; this may take some time...
@ -165,7 +165,7 @@ It is possible to package a kernel installed in dom0 as a VM kernel. This makes
To prepare such a VM kernel, you need to install the ``qubes-kernel-vm-support`` package in dom0 and also have matching kernel headers installed (``kernel-devel`` package in the case of a Fedora kernel package). You can install requirements using ``qubes-dom0-update``:
.. code:: bash
.. code:: console
[user@dom0 ~]$ sudo qubes-dom0-update qubes-kernel-vm-support kernel-devel
Using sys-firewall as UpdateVM to download updates for Dom0; this may take some time...
@ -209,7 +209,7 @@ To prepare such a VM kernel, you need to install the ``qubes-kernel-vm-support``
Then you can call the ``qubes-prepare-vm-kernel`` tool to actually package the kernel. The first parameter is kernel version (exactly as seen by the kernel), the second one (optional) is short name. This is visible in Qubes Manager and the ``qvm-prefs`` tool.
.. code:: bash
.. code:: console
[user@dom0 ~]$ sudo qubes-prepare-vm-kernel 4.1.9-6.pvops.qubes.x86_64 4.1.qubes
--> Building files for 4.1.9-6.pvops.qubes.x86_64 in /var/lib/qubes/vm-kernels/4.1.qubes
@ -406,7 +406,7 @@ Update initramfs.
The output should look like this:
.. code:: bash
.. code:: console
$ sudo dkms autoinstall -k 3.16.0-4-amd64

2
user/advanced-topics/rpc-policy.rst
View file

@ -12,7 +12,7 @@ This document explains the basics of RPC policies in Qubes. For more information
Here’s an example of an RPC policy file in dom0:
.. code:: bash
.. code:: console
[user@dom0 user ~]$ cat /etc/qubes-rpc/policy/qubes.FileCopy
(...)

24
user/advanced-topics/salt.rst
View file

@ -139,7 +139,7 @@ Enabling Top Files and Applying the States
Now, because we use custom extensions to manage top files (instead of just enabling them all), to enable a particular top file you should issue command:
.. code:: bash
.. code:: console
$ qubesctl top.enable my-new-vm
@ -147,7 +147,7 @@ Now, because we use custom extensions to manage top files (instead of just enabl
To list all enabled top files:
.. code:: bash
.. code:: console
$ qubesctl top.enabled
@ -155,7 +155,7 @@ To list all enabled top files:
And to disable one:
.. code:: bash
.. code:: console
$ qubesctl top.disable my-new-vm
@ -163,7 +163,7 @@ And to disable one:
To apply the states to dom0 and all VMs:
.. code:: bash
.. code:: console
$ qubesctl --all state.apply
@ -279,7 +279,7 @@ This should be put in ``/srv/salt/my-new-vm.sls`` or another ``.sls`` file. A se
To enable the particular top file you should issue the command:
.. code:: bash
.. code:: console
$ qubesctl top.enable my-new-vm
@ -287,7 +287,7 @@ To enable the particular top file you should issue the command:
To apply the state:
.. code:: bash
.. code:: console
$ qubesctl state.apply
@ -319,7 +319,7 @@ Then the appropriate top file (``/srv/salt/mc-everywhere.top``):
Now you need to enable the top file:
.. code:: bash
.. code:: console
$ qubesctl top.enable mc-everywhere
@ -327,7 +327,7 @@ Now you need to enable the top file:
And apply the configuration:
.. code:: bash
.. code:: console
$ qubesctl --all state.apply
@ -540,7 +540,7 @@ Whonix Workstation template
Updates dom0. Example (executed in dom0):
.. code:: bash
.. code:: console
$ sudo qubesctl --show-output state.sls update.qubes-dom0
@ -552,7 +552,7 @@ Updates dom0. Example (executed in dom0):
Updates domUs. Example to update all templates (executed in dom0):
.. code:: bash
.. code:: console
$ sudo qubesctl --show-output --skip-dom0 --templates state.sls update.qubes-vm
@ -644,7 +644,7 @@ If the log does not contain useful information:
.. code:: bash
.. code:: console
$ export PATH="/usr/lib/qubes-vm-connector/ssh-wrapper:$PATH"
$ salt-ssh "$target_vm" $salt_command
@ -668,7 +668,7 @@ Using fedora-24-minimal
The fedora-24-minimal package is missing the ``sudo`` package. You can install it via:
.. code:: bash
.. code:: console
$ qvm-run -p -u root fedora-24-minimal-template 'dnf install -y sudo'

6
user/advanced-topics/standalones-and-hvms.rst
View file

@ -223,7 +223,7 @@ Just like normal app qubes, HVMs can also be cloned either using the command ``q
The cloned qube will get identical root and private images and will essentially be identical to the original qube, except that it will get a different MAC address for the networking interface:
.. code:: bash
.. code:: console
[joanna@dom0 ~]$ qvm-prefs my-new-vm
autostart D False
@ -313,7 +313,7 @@ The cloned qube will get identical root and private images and will essentially
Note that the MAC addresses differ between those two otherwise identical qubes. The IP addresses assigned by Qubes will also be different, of course, to allow networking to function properly:
.. code:: bash
.. code:: console
[joanna@dom0 ~]$ qvm-ls -n
@ -325,7 +325,7 @@ Note that the MAC addresses differ between those two otherwise identical qubes.
If, for any reason, you would like to make sure that the two qubes have the same MAC address, you can use ``qvm-prefs`` to set a fixed MAC address:
.. code:: bash
.. code:: console
[joanna@dom0 ~]$ qvm-prefs my-new-vm-copy -s mac 00:16:3E:5E:6C:05
[joanna@dom0 ~]$ qvm-prefs my-new-vm-copy

2
user/downloading-installing-upgrading/installation-guide-4.1.rst
View file

@ -51,7 +51,7 @@ Linux ISO to USB
On Linux, if you choose to use a USB drive, copy the ISO onto the USB device, e.g. using ``dd``:
.. code:: bash
.. code:: console
$ sudo dd if=Qubes-RX-x86_64.iso of=/dev/sdY status=progress bs=1048576 conv=fsync

2
user/downloading-installing-upgrading/installation-guide.rst
View file

@ -51,7 +51,7 @@ Linux ISO to USB
On Linux, if you choose to use a USB drive, copy the ISO onto the USB device, e.g. using ``dd``:
.. code:: bash
.. code:: console
$ sudo dd if=Qubes-RX-x86_64.iso of=/dev/sdY status=progress bs=1048576 conv=fsync

2
user/downloading-installing-upgrading/upgrade/2b2.rst
View file

@ -64,7 +64,7 @@ Installing new template
Qubes R2 Beta2 brings new fedora-18-x64 template (based on Fedora 18). You can install it from Qubes installation DVD. Insert installation DVD into your drive and issue following commands:
.. code:: bash
.. code:: console
$ sudo -s
# mkdir -p /mnt/cdrom

2
user/downloading-installing-upgrading/upgrade/3_0.rst
View file

@ -150,7 +150,7 @@ Because of above limitations, you will need to configure some of those manually.
1. Check the VM network parameters, you will need them later:
.. code:: bash
.. code:: console
[user@dom0 ~]$ qvm-ls -n custom-template
-------------------+----+--------+-------+------+-------------+-------+-------------+---------+-------------+

14
user/how-to-guides/backup-emergency-restore-v2.rst
View file

@ -11,7 +11,7 @@ The Qubes backup system has been designed with emergency disaster recovery in mi
1. Untar the main backup file.
.. code:: bash
.. code:: console
[user@restore ~]$ tar -i -xvf qubes-backup-2013-12-26-123456
backup-header
@ -33,7 +33,7 @@ The Qubes backup system has been designed with emergency disaster recovery in mi
2. Set the backup passphrase environment variable. While this isn’t strictly required, it will be handy later and will avoid saving the passphrase in the shell’s history.
.. code:: bash
.. code:: console
[user@restore ~]$ read -r backup_pass
@ -41,7 +41,7 @@ The Qubes backup system has been designed with emergency disaster recovery in mi
3. Verify the integrity of the ``private.img`` file which houses your data.
.. code:: bash
.. code:: console
[user@restore ~]$ cd vm1/
[user@restore vm1]$ openssl dgst -sha512 -hmac "$backup_pass" private.img.000
@ -59,7 +59,7 @@ The Qubes backup system has been designed with emergency disaster recovery in mi
4. Decrypt the ``private.img`` file.
.. code:: bash
.. code:: console
[user@restore vm1]$ openssl enc -d -md MD5 -pass pass:"$backup_pass" -aes-256-cbc -in private.img.000 -out private.img.dec.000
@ -84,7 +84,7 @@ The Qubes backup system has been designed with emergency disaster recovery in mi
5. Decompress the decrypted ``private.img`` file.
.. code:: bash
.. code:: console
[user@restore vm1]$ zforce private.img.dec.*
[user@restore vm1]$ gunzip private.img.dec.000.gz
@ -99,7 +99,7 @@ The Qubes backup system has been designed with emergency disaster recovery in mi
6. Untar the decrypted and decompressed ``private.img`` file.
.. code:: bash
.. code:: console
[user@restore vm1]$ tar -M -xvf private.img.dec.000
vm1/private.img
@ -126,7 +126,7 @@ The Qubes backup system has been designed with emergency disaster recovery in mi
7. Mount the private.img file and access your data.
.. code:: bash
.. code:: console
[user@restore vm1]$ sudo mkdir /mnt/img
[user@restore vm1]$ sudo mount -o loop vm1/private.img /mnt/img/

20
user/how-to-guides/backup-emergency-restore-v3.rst
View file

@ -11,7 +11,7 @@ The Qubes backup system has been designed with emergency disaster recovery in mi
1. Untar the main backup file.
.. code:: bash
.. code:: console
[user@restore ~]$ tar -i -xvf qubes-backup-2015-06-05T123456
backup-header
@ -33,7 +33,7 @@ The Qubes backup system has been designed with emergency disaster recovery in mi
2. Set the backup passphrase environment variable. While this isn’t strictly required, it will be handy later and will avoid saving the passphrase in the shell’s history.
.. code:: bash
.. code:: console
[user@restore ~]$ read -r backup_pass
@ -41,7 +41,7 @@ The Qubes backup system has been designed with emergency disaster recovery in mi
3. Verify the integrity of the ``backup-header`` file, which contains basic information about your backup.
.. code:: bash
.. code:: console
[user@restore ~]$ openssl dgst -sha512 -hmac "$backup_pass" backup-header
HMAC-SHA512(backup-header)= 5b266783e116fe3b2601a54c249ca5f5f96d421dfe6828eeaeb2dcd014e9e945c27b3d7b0f952f5d55c927318906d9c360f387b0e1f069bb8195e96543e2969c
@ -58,7 +58,7 @@ The Qubes backup system has been designed with emergency disaster recovery in mi
4. Read the ``backup-header``. You’ll need some of this information later. The file will look similar to this:
.. code:: bash
.. code:: console
[user@restore ~]$ cat backup-header
version=3
@ -73,7 +73,7 @@ The Qubes backup system has been designed with emergency disaster recovery in mi
5. Verify the integrity of the ``private.img`` file which houses your data.
.. code:: bash
.. code:: console
[user@restore ~]$ cd vm1/
[user@restore vm1]$ openssl dgst -sha512 -hmac "$backup_pass" private.img.000
@ -91,7 +91,7 @@ The Qubes backup system has been designed with emergency disaster recovery in mi
6. Decrypt the ``private.img`` file.
.. code:: bash
.. code:: console
[user@restore vm1]$ find -name 'private.img.*[0-9]' | sort -V | xargs cat | openssl enc -d -md MD5 -pass pass:"$backup_pass" -aes-256-cbc -out private.img.dec
@ -100,7 +100,7 @@ The Qubes backup system has been designed with emergency disaster recovery in mi
7. Decompress the decrypted ``private.img`` file.
.. code:: bash
.. code:: console
[user@restore vm1]$ zforce private.img.dec
private.img.dec -- replaced with private.img.dec.gz
@ -109,7 +109,7 @@ The Qubes backup system has been designed with emergency disaster recovery in mi
**Note:** If your backup was compressed with a program other than ``gzip``, you must substitute the correct compression program. This information is contained in the ``backup-header`` file (see step 4). For example, if you used ``bzip2``, then you should do this:
.. code:: bash
.. code:: console
[user@restore vm1]$ mv private.img.dec private.img.dec.bz2
[user@restore vm1]$ bunzip2 private.img.dec.bz2
@ -118,7 +118,7 @@ The Qubes backup system has been designed with emergency disaster recovery in mi
8. Untar the decrypted and decompressed ``private.img`` file.
.. code:: bash
.. code:: console
[user@restore vm1]$ tar -xvf private.img.dec
vm1/private.img
@ -127,7 +127,7 @@ The Qubes backup system has been designed with emergency disaster recovery in mi
9. Mount the private.img file and access your data.
.. code:: bash
.. code:: console
[user@restore vm1]$ sudo mkdir /mnt/img
[user@restore vm1]$ sudo mount -o loop vm1/private.img /mnt/img/

32
user/how-to-guides/backup-emergency-restore-v4.rst
View file

@ -19,7 +19,7 @@ Here are instructions for obtaining a compiled ``scrypt`` binary. This example u
1. If you’re not on Qubes 4.X, :ref:`import and authenticate the Release 4 Signing Key <project-security/verifying-signatures:how to import and authenticate release signing keys>`.
.. code:: bash
.. code:: console
[user@restore ~]$ sudo rpm --import qubes-release-4-signing-key.asc
@ -27,14 +27,14 @@ Here are instructions for obtaining a compiled ``scrypt`` binary. This example u
2. Download the ``scrypt`` RPM.
.. code:: bash
.. code:: console
[user@restore ~]$ dnf download scrypt
Or, if that doesn’t work:
.. code:: bash
.. code:: console
[user@restore ~]$ curl -O https://yum.qubes-os.org/r4.0/current/vm/fc28/rpm/scrypt-1.2.1-1.fc28.x86_64.rpm
@ -42,7 +42,7 @@ Here are instructions for obtaining a compiled ``scrypt`` binary. This example u
3. Verify the signature on the ``scrypt`` RPM.
.. code:: bash
.. code:: console
[user@restore ~]$ rpm -K scrypt-*.rpm
scrypt-*.rpm: digests signatures OK
@ -52,7 +52,7 @@ Here are instructions for obtaining a compiled ``scrypt`` binary. This example u
4. Install ``rpmdevtools``.
.. code:: bash
.. code:: console
[user@restore ~]$ sudo dnf install rpmdevtools
@ -60,7 +60,7 @@ Here are instructions for obtaining a compiled ``scrypt`` binary. This example u
5. Extract the ``scrypt`` binary from the RPM and make it conveniently available.
.. code:: bash
.. code:: console
[user@restore ~]$ rpmdev-extract scrypt-*.rpm
[user@restore ~]$ alias scrypt="$PWD/scrypt-*/usr/bin/scrypt"
@ -77,7 +77,7 @@ Emergency recovery instructions
1. Untar the backup metadata from the main backup file.
.. code:: bash
.. code:: console
[user@restore ~]$ tar -i -xvf qubes-backup-2023-04-05T123456 \
backup-header backup-header.hmac qubes.xml.000.enc
@ -89,7 +89,7 @@ Emergency recovery instructions
2. Set the backup passphrase environment variable. While this isn’t strictly required, it will be handy later and will avoid saving the passphrase in the shell’s history.
.. code:: bash
.. code:: console
[user@restore ~]$ read -r backup_pass
@ -98,7 +98,7 @@ Emergency recovery instructions
3. Verify the integrity of ``backup-header`` using ``backup-header.hmac`` (an encrypted *and integrity protected* version of ``backup-header``).
.. code:: bash
.. code:: console
[user@restore ~]$ set +H
[user@restore ~]$ echo "backup-header!$backup_pass" |\
@ -117,7 +117,7 @@ Emergency recovery instructions
4. Read ``backup-header``.
.. code:: bash
.. code:: console
[user@restore ~]$ cat backup-header
version=4
@ -131,7 +131,7 @@ Emergency recovery instructions
5. Set ``backup_id`` to the value in the last line of ``backup-header``. (Note that there is a hyphen in ``backup-id`` in the file, whereas there is an underscore in ``backup_id`` in the variable you’re setting.)
.. code:: bash
.. code:: console
[user@restore ~]$ backup_id=20230405T123455-1234
@ -139,7 +139,7 @@ Emergency recovery instructions
6. Verify and decrypt, decompress, and extract the ``qubes.xml`` file.
.. code:: bash
.. code:: console
[user@restore ~]$ echo "$backup_id!qubes.xml.000!$backup_pass" |\
scrypt dec -P qubes.xml.000.enc | gzip -d | tar -xv
@ -155,7 +155,7 @@ Emergency recovery instructions
7. Search inside of the ``qubes.xml`` file for the ``backup-path`` of the qube whose data you wish to restore. If you install the ``xmlstarlet`` package, the following command will convert ``qubes.xml`` to a friendlier listing for this purpose:
.. code:: bash
.. code:: console
[user@restore ~]$ xmlstarlet sel -T -t -m //domain \
-v 'concat(.//property[@name="name"], " ", .//feature[@name="backup-path"])' \
@ -182,7 +182,7 @@ Emergency recovery instructions
The example output above shows that the backup file includes a qube named ``personal`` and a qube named ``vault``, with ``backup-path`` values of ``vm123/`` and ``vm321/`` respectively. (Every other listed qube was not selected to be included in the backup file.) Use the corresponding value to untar the necessary data files of the qube:
.. code:: bash
.. code:: console
[user@restore ~]$ tar -i -xvf qubes-backup-2023-04-05T123456 vm123/
@ -190,7 +190,7 @@ Emergency recovery instructions
8. Verify and decrypt the backed up data, decompress it, and extract it.
.. code:: bash
.. code:: console
[user@restore ~]$ find vm123/ -name 'private.img.*.enc' | sort -V | while read f_enc; do \
f_dec=${f_enc%.enc}; \
@ -204,7 +204,7 @@ Emergency recovery instructions
9. Mount ``private.img`` and access your data.
.. code:: bash
.. code:: console
[user@restore ~]$ sudo mkdir /mnt/img
[user@restore ~]$ sudo mount -o loop vm123/private.img /mnt/img/

2
user/how-to-guides/how-to-back-up-restore-and-migrate.rst
View file

@ -15,7 +15,7 @@ Backing up changes to dom0
When backing up dom0 using the Qubes backup tool (explained below), only the home directory is backed up. Therefore, if there are files outside of the home directory you wish to save, you should copy them into the home directory prior to creating a backup. Here is an example of how to back up Qubes config files and RPC policies:
.. code:: bash
.. code:: console
$ mkdir -p ~/backup/etc/qubes/
$ cp -a /etc/qubes/* ~/backup/etc/qubes/

14
user/how-to-guides/how-to-install-software.rst
View file

@ -52,7 +52,7 @@ If you are still using the distribution package manager, updates will likely sti
If you are using another installation method fetching remote resources, you might still be able to use the updates proxy by making the tools aware of the proxy. For many tools, it is enough to export the following environment variables in your shell session before proceeding:
.. code:: bash
.. code:: console
$ export HTTP_PROXY=http://127.0.0.1:8082 http_proxy=$HTTP_PROXY \
HTTPS_PROXY=$HTTP_PROXY https_proxy=$HTTPS_PROXY \
@ -300,7 +300,7 @@ Snap packages do not use the normal update channels for Debian and Fedora (apt a
1. In the **template** you must install ``snapd`` and ``qubes-snapd-helper``. Open a terminal in the template and run:
.. code:: bash
.. code:: console
[user@fedora-36-snap-demo ~]$ sudo dnf install snapd qubes-snapd-helper
Last metadata expiration check: 0:33:05 ago on Thu 03 Nov 2022 04:34:06.
@ -346,14 +346,14 @@ Snap packages do not use the normal update channels for Debian and Fedora (apt a
This is expected and you can safely continue.
Shutdown the template:
.. code:: bash
.. code:: console
[user@fedora-36-snap-demo ~]$ sudo shutdown -h now
2. Now open the **app qube** in which you would like to install the Snap application and run a terminal:
.. code:: bash
.. code:: console
[user@snap-demo-app qube ~]$ snap install <package>
@ -377,7 +377,7 @@ If you want a desktop app to start automatically every time a qube starts you ca
2. List the names of the available desktop shortcuts by running the command ``ls /usr/share/applications`` and find the exact name of the shortcut to the app you want to autostart:
.. code:: bash
.. code:: console
[user@example-app qube ~]$ ls /usr/share/applications/
bluetooth-sendto.desktop
@ -390,7 +390,7 @@ If you want a desktop app to start automatically every time a qube starts you ca
3. Create the autostart directory:
.. code:: bash
.. code:: console
[user@example-app qube ~]$ mkdir -p ~/.config/autostart
@ -398,7 +398,7 @@ If you want a desktop app to start automatically every time a qube starts you ca
4. Make a link to the desktop app file you’d like to start in the autostart directory. For example, the command below will link the Thunderbird app into the autostart directory:
.. code:: bash
.. code:: console
[user@example-app qube ~]$ ln -s /usr/share/applications/mozilla-thunderbird.desktop ~/.config/autostart/mozilla-thunderbird.desktop

6
user/how-to-guides/how-to-update.rst
View file

@ -159,7 +159,7 @@ First, ensure that your UpdateVM contains the ``fwupd-qubes-vm`` package. This p
In a dom0 terminal, install the ``fwupd-qubes-dom0`` package:
.. code:: bash
.. code:: console
$ sudo qubes-dom0-update fwupd-qubes-dom0
@ -167,7 +167,7 @@ In a dom0 terminal, install the ``fwupd-qubes-dom0`` package:
Once the package is installed:
.. code:: bash
.. code:: console
$ sudo qubes-fwupdmgr get-devices
@ -185,7 +185,7 @@ If so, `adjust your BIOS settings <https://github.com/fwupd/fwupd/wiki/PluginFla
Once resolved, in a dom0 terminal:
.. code:: bash
.. code:: console
$ sudo qubes-fwupdmgr get-devices
$ sudo qubes-fwupdmgr refresh

6
user/security-in-qubes/ctap-proxy.rst
View file

@ -53,7 +53,7 @@ These instructions assume that there is a ``sys-usb`` qube that holds the USB st
In dom0:
.. code:: bash
.. code:: console
$ sudo qubes-dom0-update qubes-ctap-dom0
$ qvm-service --enable work qubes-ctap-proxy
@ -64,7 +64,7 @@ The above assumes a ``work`` qube in which you would like to enable ctap. Repeat
In Fedora templates:
.. code:: bash
.. code:: console
$ sudo dnf install qubes-ctap
@ -72,7 +72,7 @@ In Fedora templates:
In Debian templates:
.. code:: bash
.. code:: console
$ sudo apt install qubes-ctap

18
user/security-in-qubes/firewall.rst
View file

@ -143,7 +143,7 @@ In order to allow networking from qube A (client) to qube B (server) follow thes
.. code:: bash
.. code:: console
[user@sys-firewall ~]$ sudo -i
[root@sys-firewall user]# echo "nft add rule ip qubes custom-forward ip saddr 10.137.2.25 ip daddr 10.137.2.6 ct state new,established,related counter accept" >> /rw/config/qubes-firewall-user-script
@ -154,7 +154,7 @@ In order to allow networking from qube A (client) to qube B (server) follow thes
.. code:: bash
.. code:: console
[user@B ~]$ sudo -i
[root@B user]# echo "nft add rule qubes custom-input ip saddr 10.137.2.25 accept" >> /rw/config/rc.local
@ -181,7 +181,7 @@ Consider the following example. ``mytcp-service`` qube has a TCP service running
- In untrusted, use the Qubes tool ``qvm-connect-tcp``:
.. code:: bash
.. code:: console
[user@untrusted #]$ qvm-connect-tcp 444:@default:444
@ -195,7 +195,7 @@ The service of ``mytcp-service`` running on port ``444`` is now accessible in ``
Here ``@default`` is used to hide the destination qube which is specified in the Qubes RPC policy by ``target=mytcp-service``. Equivalent call is to use the tool as follow:
.. code:: bash
.. code:: console
[user@untrusted #]$ qvm-connect-tcp ::444
@ -215,7 +215,7 @@ Consider now the case where someone prefers to specify the destination qube and
in ``/etc/qubes/policy.d/30-user-networking.policy`` and in untrusted, use the tool as follow:
.. code:: bash
.. code:: console
[user@untrusted #]$ qvm-connect-tcp 10444:mytcp-service:444
@ -235,7 +235,7 @@ One can go further than the previous examples by redirecting different ports to
In that case, calling ``qvm-connect-tcp`` like previous examples, will still bind TCP port ``444`` of ``mytcp-service`` to ``untrusted`` but now, calling it with port ``445``
.. code:: bash
.. code:: console
[user@untrusted #]$ qvm-connect-tcp ::445
@ -420,7 +420,7 @@ In this example, we can see 7 packets in the forward rule, and 3 packets in the
Once you have confirmed that the counters increase, store the commands used in the previous steps in ``/rw/config/qubes-firewall-user-script`` so they get set on sys-net start-up:
.. code:: bash
.. code:: console
[user@sys-net user]$ sudo -i
[root@sys-net user]# nano /rw/config/qubes-firewall-user-script
@ -479,7 +479,7 @@ Third step, code the appropriate new filtering firewall rule to allow new connec
Once you have confirmed that the counters increase, store these commands in the script ``/rw/config/qubes-firewall-user-script``
.. code:: bash
.. code:: console
[user@sys-net user]$ sudo -i
[root@sys-net user]# nano /rw/config/qubes-firewall-user-script
@ -522,7 +522,7 @@ The according rule to allow the traffic is:
To make it persistent, you need to add this command in the script ``/rw/config/rc.local``:
.. code:: bash
.. code:: console
[user@qubeDEST user]$ sudo -i
[root@qubeDEST user]# echo 'nft add rule qubes custom-input tcp dport 443 ip daddr 10.137.0.xx ct state new,established,related counter accept' >> /rw/config/rc.local

12
user/security-in-qubes/firewall_4.1.rst
View file

@ -131,7 +131,7 @@ In order to allow networking between qubes A and B follow these steps:
.. code:: bash
.. code:: console
[user@sys-firewall ~]$ sudo bash
[root@sys-firewall user]# echo "iptables -I FORWARD 2 -s 10.137.2.25 -d 10.137.2.6 -j ACCEPT" >> /rw/config/qubes-firewall-user-script
@ -143,7 +143,7 @@ In order to allow networking between qubes A and B follow these steps:
.. code:: bash
.. code:: console
[user@B ~]$ sudo bash
[root@B user]# echo "iptables -I INPUT -s 10.137.2.25 -j ACCEPT" >> /rw/config/rc.local
@ -171,7 +171,7 @@ Consider the following example. ``mytcp-service`` qube has a TCP service running
- In untrusted, use the Qubes tool ``qvm-connect-tcp``:
.. code:: bash
.. code:: console
[user@untrusted #]$ qvm-connect-tcp 444:@default:444
@ -185,7 +185,7 @@ The service of ``mytcp-service`` running on port ``444`` is now accessible in ``
Here ``@default`` is used to hide the destination qube which is specified in the Qubes RPC policy by ``target=mytcp-service``. Equivalent call is to use the tool as follow:
.. code:: bash
.. code:: console
[user@untrusted #]$ qvm-connect-tcp ::444
@ -205,7 +205,7 @@ Consider now the case where someone prefers to specify the destination qube and
in ``/etc/qubes/policy.d/30-user-networking.policy`` and in untrusted, use the tool as follow:
.. code:: bash
.. code:: console
[user@untrusted #]$ qvm-connect-tcp 10444:mytcp-service:444
@ -225,7 +225,7 @@ One can go further than the previous examples by redirecting different ports to
In that case, calling ``qvm-connect-tcp`` like previous examples, will still bind TCP port ``444`` of ``mytcp-service`` to ``untrusted`` but now, calling it with port ``445``
.. code:: bash
.. code:: console
[user@untrusted #]$ qvm-connect-tcp ::445

24
user/security-in-qubes/split-gpg.rst
View file

@ -29,7 +29,7 @@ Configuring Split GPG
In dom0, make sure the ``qubes-gpg-split-dom0`` package is installed.
.. code:: bash
.. code:: console
[user@dom0 ~]$ sudo qubes-dom0-update qubes-gpg-split-dom0
@ -38,7 +38,7 @@ Make sure you have the ``qubes-gpg-split`` package installed in the template you
For Debian or Whonix:
.. code:: bash
.. code:: console
[user@debian-10 ~]$ sudo apt install qubes-gpg-split
@ -46,7 +46,7 @@ For Debian or Whonix:
For Fedora:
.. code:: bash
.. code:: console
[user@fedora-32 ~]$ sudo dnf install qubes-gpg-split
@ -60,7 +60,7 @@ First, create a dedicated app qube for storing your keys (we will be calling it
Make sure that gpg is installed there. At this stage you can add the private keys you want to store there, or you can now set up Split GPG and add the keys later. To check which private keys are in your GPG keyring, use:
.. code:: bash
.. code:: console
[user@work-gpg ~]$ gpg -K
/home/user/.gnupg/secring.gpg
@ -73,7 +73,7 @@ Make sure that gpg is installed there. At this stage you can add the private key
This is pretty much all that is required. However, you might want to modify the default timeout: this tells the backend for how long the user’s approval for key access should be valid. (The default is 5 minutes.) You can change this via the ``QUBES_GPG_AUTOACCEPT`` environment variable. You can override it e.g. in ``~/.profile``:
.. code:: bash
.. code:: console
[user@work-gpg ~]$ echo "export QUBES_GPG_AUTOACCEPT=86400" >> ~/.profile
@ -88,7 +88,7 @@ Configuring the client apps to use Split GPG backend
Normally it should be enough to set the ``QUBES_GPG_DOMAIN`` to the GPG backend domain name and use ``qubes-gpg-client`` in place of ``gpg``, e.g.:
.. code:: bash
.. code:: console
[user@work-email ~]$ export QUBES_GPG_DOMAIN=work-gpg
[user@work-email ~]$ gpg -K
@ -116,7 +116,7 @@ Advanced Configuration
The ``qubes-gpg-client-wrapper`` script sets the ``QUBES_GPG_DOMAIN`` variable automatically based on the content of the file ``/rw/config/gpg-split-domain``, which should be set to the name of the GPG backend VM. This file survives the app qube reboot, of course.
.. code:: bash
.. code:: console
[user@work-email ~]$ sudo bash
[root@work-email ~]$ echo "work-gpg" > /rw/config/gpg-split-domain
@ -158,7 +158,7 @@ In ``work-email``, use the Thunderbird config editor (found at the bottom of pre
You need to obtain your key ID which should be **exactly 16 characters**. Enter the command ``qubes-gpg-client-wrapper -K --keyid-format long``:
.. code:: bash
.. code:: console
[user@work-email ~]$ qubes-gpg-client-wrapper -K --keyid-format long
/home/user/.gnupg/pubring.kbx
@ -170,7 +170,7 @@ You need to obtain your key ID which should be **exactly 16 characters**. Enter
.. code:: bash
.. code:: console
[user@work-email ~]$ qubes-gpg-client-wrapper --armor --export 777402E6D301615C > 777402E6D301615C.asc
@ -218,7 +218,7 @@ The Keybase service does not preserve/pass the ``QUBES_GPG_DOMAIN`` environment
The following command will configure Keybase to use ``/usr/bin/qubes-gpg-client-wrapper`` instead of its built-in GPG client:
.. code:: bash
.. code:: console
$ keybase config set gpg.command /usr/bin/qubes-gpg-client-wrapper
@ -246,7 +246,7 @@ Git can be configured to utilize Split GPG, something useful if you would like t
Your key id is the public id of your signing key, which can be found by running ``qubes-gpg-client --list-keys``. In this instance, the key id is E142F75A6B1B610E0E8F874FB45589245791CACB.
.. code:: bash
.. code:: console
[user@work-email ~]$ qubes-gpg-client --list-keys
/home/user/.gnupg/pubring.kbx
@ -276,7 +276,7 @@ Importing public keys
Use ``qubes-gpg-import-key`` in the client app qube to import the key into the GPG backend VM.
.. code:: bash
.. code:: console
[user@work-email ~]$ export QUBES_GPG_DOMAIN=work-gpg
[user@work-email ~]$ qubes-gpg-import-key ~/Downloads/marmarek.asc

22
user/templates/debian/debian-upgrade.rst
View file

@ -18,7 +18,7 @@ Summary instructions for Debian templates
**Important:** The prompt on each line indicates where each command should be entered: ``dom0``, ``debian-<old>``, or ``debian-<new>``, where ``<old>`` is the Debian version number *from* which you are upgrading, and ``<new>`` is the Debian version number *to* which you are upgrading. The instructions may differ for certain releases. See `release-specific notes <#release-specific-notes>`__ for any instructions specific to your particular release.
.. code:: bash
.. code:: console
[user@dom0 ~]$ qvm-clone debian-<old> debian-<new>
[user@dom0 ~]$ qvm-run -a debian-<new> gnome-terminal
@ -42,14 +42,14 @@ These instructions will show you how to upgrade Debian templates. The same gener
1. Ensure the existing template is not running.
.. code:: bash
.. code:: console
[user@dom0 ~]$ qvm-shutdown debian-<old>
2. Clone the existing template and start a terminal in the new template.
.. code:: bash
.. code:: console
[user@dom0 ~]$ qvm-clone debian-<old> debian-<new>
[user@dom0 ~]$ qvm-run -a debian-<new> gnome-terminal
@ -57,7 +57,7 @@ These instructions will show you how to upgrade Debian templates. The same gener
3. Update your ``apt`` repositories to use the new release’s code name instead of the old release’s code name. (This can be done manually with a text editor, but ``sed`` can be used to automatically update the files.)
.. code:: bash
.. code:: console
[user@debian-<new> ~]$ sudo sed -i 's/<old-name>/<new-name>/g' /etc/apt/sources.list
[user@debian-<new> ~]$ sudo sed -i 's/<old-name>/<new-name>/g' /etc/apt/sources.list.d/qubes-r4.list
@ -66,7 +66,7 @@ These instructions will show you how to upgrade Debian templates. The same gener
4. Update the package lists and upgrade. During the process, it may prompt you to overwrite the file ``qubes-r4.list``. You should overwrite this file.
.. code:: bash
.. code:: console
[user@debian-<new> ~]$ sudo apt update
[user@debian-<new> ~]$ sudo apt upgrade
@ -76,7 +76,7 @@ These instructions will show you how to upgrade Debian templates. The same gener
5. (Optional) Remove unnecessary packages that were previously installed.
.. code:: bash
.. code:: console
[user@debian-<new> ~]$ sudo apt-get autoremove
@ -84,7 +84,7 @@ These instructions will show you how to upgrade Debian templates. The same gener
6. (Optional) Clean cached packages from ``/var/cache/apt``.
.. code:: bash
.. code:: console
[user@debian-<new> ~]$ sudo apt-get clean
@ -92,7 +92,7 @@ These instructions will show you how to upgrade Debian templates. The same gener
7. (Optional) Trim the new template. (This should :ref:`no longer be necessary <user/templates/templates:important notes>`, but it does not hurt. Some users have `reported <https://github.com/QubesOS/qubes-issues/issues/5055>`__ that it makes a difference.)
.. code:: bash
.. code:: console
[user@debian-<new> ~]$ sudo fstrim -av
[user@dom0 ~]$ qvm-shutdown debian-<new>
@ -102,7 +102,7 @@ These instructions will show you how to upgrade Debian templates. The same gener
8. Shut down the new template.
.. code:: bash
.. code:: console
[user@dom0 ~]$ qvm-shutdown debian-<new>
@ -111,7 +111,7 @@ These instructions will show you how to upgrade Debian templates. The same gener
10. (Optional) Make the new template the global default.
.. code:: bash
.. code:: console
[user@dom0 ~]$ qubes-prefs --set default_template debian-<new>
@ -140,7 +140,7 @@ Please see `Debian’s Bullseye upgrade instructions <https://www.debian.org/rel
This means that, when upgrading from Buster to Bullseye, an additional ``sed`` command is required:
.. code:: bash
.. code:: console
[user@dom0 ~]$ qvm-clone debian-10 debian-11
[user@dom0 ~]$ qvm-run -a debian-11 gnome-terminal

2
user/templates/debian/debian.rst
View file

@ -11,7 +11,7 @@ Installing
To :ref:`install <user/templates/templates:installing>` a specific Debian template that is not currently installed in your system, use the Qubes Template Manager, or use the following command in a dom0 terminal:
.. code:: bash
.. code:: console
$ qvm-template install XX

26
user/templates/fedora/fedora-upgrade.rst
View file

@ -18,7 +18,7 @@ Summary instructions for standard Fedora templates
**Note:** The prompt on each line indicates where each command should be entered: ``dom0``, ``fedora-<old>``, or ``fedora-<new>``, where ``<old>`` is the Fedora version number *from* which you are upgrading, and ``<new>`` is the Fedora version number *to* which you are upgrading.
.. code:: bash
.. code:: console
[user@dom0 ~]$ qvm-clone fedora-<old> fedora-<new>
[user@dom0 ~]$ truncate -s 5GB /var/tmp/template-upgrade-cache.img
@ -47,14 +47,14 @@ These instructions will show you how to upgrade the standard Fedora template. Th
1. Ensure the existing template is not running.
.. code:: bash
.. code:: console
[user@dom0 ~]$ qvm-shutdown fedora-<old>
2. Clone the existing template and start a terminal in the new template.
.. code:: bash
.. code:: console
[user@dom0 ~]$ qvm-clone fedora-<old> fedora-<new>
[user@dom0 ~]$ qvm-run -a fedora-<new> gnome-terminal
@ -62,7 +62,7 @@ These instructions will show you how to upgrade the standard Fedora template. Th
3. Attempt the upgrade process in the new template.
.. code:: bash
.. code:: console
[user@fedora-<new> ~]$ sudo dnf clean all
[user@fedora-<new> ~]$ sudo dnf --releasever=<new> distro-sync --best --allowerasing
@ -86,7 +86,7 @@ These instructions will show you how to upgrade the standard Fedora template. Th
- If ``dnf`` reports that you do not have enough free disk space to proceed with the upgrade process, create an empty file in dom0 to use as a cache and attach it to the template as a virtual disk.
.. code:: bash
.. code:: console
[user@dom0 ~]$ truncate -s 5GB /var/tmp/template-upgrade-cache.img
[user@dom0 ~]$ dev=$(sudo losetup -f --show /var/tmp/template-upgrade-cache.img)
@ -94,7 +94,7 @@ These instructions will show you how to upgrade the standard Fedora template. Th
Then reattempt the upgrade process, but this time use the virtual disk as a cache.
.. code:: bash
.. code:: console
[user@fedora-<new> ~]$ sudo mkfs.ext4 /dev/xvdi
[user@fedora-<new> ~]$ sudo mount /dev/xvdi /mnt/removable
@ -111,7 +111,7 @@ These instructions will show you how to upgrade the standard Fedora template. Th
4. Check that you are on the correct (new) Fedora release. Do this check only after completing the upgrade process. This is *not* a troubleshooting procedure for fixing download issues from the repository. This check simply verifies that your clone has successfully been upgraded.
.. code:: bash
.. code:: console
[user@fedora-<new> ~]$ cat /etc/fedora-release
@ -119,7 +119,7 @@ These instructions will show you how to upgrade the standard Fedora template. Th
5. (Optional) Trim the new template. (This should :ref:`no longer be necessary <user/templates/templates:important notes>`, but it does not hurt. Some users have `reported <https://github.com/QubesOS/qubes-issues/issues/5055>`__ that it makes a difference.)
.. code:: bash
.. code:: console
[user@fedora-<new> ~]$ sudo fstrim -av
[user@dom0 ~]$ qvm-shutdown fedora-<new>
@ -129,14 +129,14 @@ These instructions will show you how to upgrade the standard Fedora template. Th
6. Shut down the new template.
.. code:: bash
.. code:: console
[user@dom0 ~]$ qvm-shutdown fedora-<new>
7. Remove the cache file, if you created one.
.. code:: bash
.. code:: console
[user@dom0 ~]$ sudo losetup -d $dev
[user@dom0 ~]$ rm /var/tmp/template-upgrade-cache.img
@ -144,7 +144,7 @@ These instructions will show you how to upgrade the standard Fedora template. Th
8. Set the template-name, which is used by the Qubes updater.
.. code:: bash
.. code:: console
[user@dom0 ~]$ qvm-features fedora-<new> template-name fedora-<new>
@ -153,7 +153,7 @@ These instructions will show you how to upgrade the standard Fedora template. Th
10. (Optional) Make the new template the global default.
.. code:: bash
.. code:: console
[user@dom0 ~]$ qubes-prefs --set default_template fedora-<new>
@ -168,7 +168,7 @@ Summary instructions for Fedora Minimal templates
**Note:** The prompt on each line indicates where each command should be entered: ``dom0``, ``fedora-<old>``, or ``fedora-<new>``, where ``<old>`` is the Fedora version number *from* which you are upgrading, and ``<new>`` is the Fedora version number *to* which you are upgrading.
.. code:: bash
.. code:: console
[user@dom0 ~]$ qvm-clone fedora-<old>-minimal fedora-<new>-minimal
[user@dom0 ~]$ qvm-run -u root -a fedora-<new>-minimal xterm

2
user/templates/fedora/fedora.rst
View file

@ -11,7 +11,7 @@ Installing
To :ref:`install <user/templates/templates:installing>` a specific Fedora template that is not currently installed in your system, use the Qubes Template Manager, or use the following command in a dom0 terminal:
.. code:: bash
.. code:: console
$ qvm-template install XX

12
user/templates/minimal-templates.rst
View file

@ -44,21 +44,21 @@ Installation
The minimal templates can be installed with the following type of command:
.. code:: bash
.. code:: console
[user@dom0 ~]$ sudo qubes-dom0-update qubes-template-<DISTRO_NAME>-<RELEASE_NUMBER>-minimal
If your desired version is not found, it may still be in :doc:`testing </user/downloading-installing-upgrading/testing>`. You may wish to try again with the testing repository enabled:
.. code:: bash
.. code:: console
[user@dom0 ~]$ sudo qubes-dom0-update --enablerepo=qubes-templates-itl-testing qubes-template-<DISTRO_NAME>-<RELEASE_NUMBER>-minimal
If you would like to install a community distribution, try the install command by enabling the community repository:
.. code:: bash
.. code:: console
[user@dom0 ~]$ sudo qubes-dom0-update --enablerepo=qubes-templates-community qubes-template-<DISTRO_NAME>-<RELEASE_NUMBER>-minimal
@ -71,7 +71,7 @@ Passwordless root
It is an intentional design choice for :doc:`Passwordless Root Access in VMs </user/security-in-qubes/vm-sudo>` to be optional in minimal templates. Since the minimal templates are *minimal*, they are not configured for passwordless root by default. To update or install packages, execute the following command in dom0:
.. code:: bash
.. code:: console
[user@dom0 ~]$ qvm-run -u root <DISTRO_NAME>-<RELEASE_NUMBER>-minimal xterm
@ -102,7 +102,7 @@ Fedora
The following list provides an overview of which packages are needed for which purpose. As usual, the required packages are to be installed in the running template with the following command (replace ``packages`` with a space-delimited list of packages to be installed):
.. code:: bash
.. code:: console
[user@your-new-clone ~]$ sudo dnf install packages
@ -188,7 +188,7 @@ Debian
The following list provides an overview of which packages are needed for which purpose. As usual, the required packages are to be installed in the running template with the following command (replace ``packages`` with a space-delimited list of packages to be installed):
.. code:: bash
.. code:: console
[user@your-new-clone ~]$ sudo apt install packages

8
user/templates/templates.rst
View file

@ -103,7 +103,7 @@ You can manage your templates using the ``Qubes Template Manager``, a GUI tool a
At the command line in dom0, ``qvm-template list --available`` will show available templates. To install a template, use:
.. code:: bash
.. code:: console
$ qvm-template install <template_name>
@ -113,7 +113,7 @@ You can also use ``qvm-template`` to upgrade or reinstall templates.
Repository (repo) definitions are stored in dom0 in ``/etc/qubes/repo-templates`` and associated keys in ``/etc/qubes/repo-templates/keys``. There are additional repos for testing releases and community templates. To temporarily enable any of these repos, use the ``--enablerepo=<repo-name>`` option. E.g. :
.. code:: bash
.. code:: console
$ qvm-template --enablerepo qubes-templates-community install <template_name>
@ -164,7 +164,7 @@ To remove a template, the graphical ``Qube Manager`` (Qubes Menu > Qubes Tools >
Alternatively, to remove a template via the command line in dom0:
.. code:: bash
.. code:: console
$ qvm-template remove <TEMPLATE_NAME>
@ -172,7 +172,7 @@ Alternatively, to remove a template via the command line in dom0:
<TEMPLATE_NAME> is the first column from the output of:
.. code:: bash
.. code:: console
$ qvm-template list --installed

4
user/templates/windows/qubes-windows-tools-4-0.rst
View file

@ -269,13 +269,13 @@ Once you start a Windows-based AppVM with Qubes Tools installed, you can easily
Also, the inter-VM services work as usual – e.g. to request opening a document or URL in the Windows AppVM from another VM:
.. code:: bash
.. code:: console
[user@work ~]$ qvm-open-in-vm work-win7 roadmap.pptx
.. code:: bash
.. code:: console
[user@work ~]$ qvm-open-in-vm work-win7 https://invisiblethingslab.com

14
user/templates/windows/qubes-windows-tools-4-1.rst
View file

@ -136,7 +136,7 @@ The Xen PV Drivers bundled with QWT are signed by a Linux Foundation certificate
**Warning:** it is recommended to increase the default value of Windows VM’s ``qrexec_timeout`` property from 60 (seconds) to, for example, 300. During one of the first reboots after Windows Tools installation Windows user profiles are moved onto the private VM’s virtual disk (private.img) and this operation can take some time. Moving profiles and, later on, updating a Windows installation, is performed in an early boot phase when ``qrexec`` is not yet running, so timeout may occur with the default value. To change the property use this command in ``dom0``: *(where* ``<VMname>`` *is the name of your Windows VM)*
.. code:: bash
.. code:: console
[user@dom0 ~] $ qvm-prefs <VMname> qrexec_timeout 7200
@ -215,14 +215,14 @@ Installing the Qubes Windows Tools on Windows 7, 8.1, 10 and 11 both as a Standa
6. Qubes will automatically detect that the tools have been installed in the VM and will set appropriate properties for the VM, such as ``qrexec_installed``, ``guiagent_installed``, and ``default_user``. This can be verified (but is not required) using the ``qvm-prefs`` command *(where* ``<VMname>`` *is the name of your Windows VM)*:
.. code:: bash
.. code:: console
[user@dom0 ~] $ qvm-prefs <VMname>
It is advisable to set some other parameters in order to enable audio and USB block device access, synchronize the Windows clock with the Qubes clock, and so on:
.. code:: bash
.. code:: console
[user@dom0 ~] $ qvm-features <VMname> audio-model ich9
[user@dom0 ~] $ qvm-features <VMname> stubdom-qrexec 1
@ -231,7 +231,7 @@ Installing the Qubes Windows Tools on Windows 7, 8.1, 10 and 11 both as a Standa
For audio, the parameter ``audio-model`` can be selected as ``ich6`` or ``ich9``; select the value that gives the best audio quality. Audio quality may also be improved by setting the following parameters, but this can depend on the Windows version and on your hardware:
.. code:: bash
.. code:: console
[user@dom0 ~] $ qvm-features <VMname> timer-period 1000
[user@dom0 ~] $ qvm-features <VMname> out.latency 10000
@ -295,7 +295,7 @@ Using Windows AppVMs in seamless mode
Once you start a Windows-based AppVM with Qubes Tools installed, you can easily start individual applications from the VM (note the ``-a`` switch used here, which will auto-start the VM if it is not running):
.. code:: bash
.. code:: console
[user@dom0 ~] $ qvm-run -a my-win-appvm explorer.exe
@ -305,7 +305,7 @@ Once you start a Windows-based AppVM with Qubes Tools installed, you can easily
Also, the inter-VM services work as usual – e.g. to request opening a document or URL in the Windows AppVM from another VM:
.. code:: bash
.. code:: console
[user@dom0 ~] $ qvm-open-in-vm my-win-appvm roadmap.pptx
@ -554,7 +554,7 @@ Updates
When we publish a new QWT version, it’s usually pushed to the ``current-testing`` or ``unstable`` repository first. To use versions from current-testing, run this in dom0:
.. code:: bash
.. code:: console
[user@dom0 ~] $ sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing qubes-windows-tools

8
user/templates/xfce-templates.rst
View file

@ -13,28 +13,28 @@ Installation
The Fedora Xfce templates can be installed with the following command (where ``X`` is your desired distro and version number):
.. code:: bash
.. code:: console
[user@dom0 ~]$ sudo qubes-dom0-update qubes-template-X-xfce
If your desired version is not found, it may still be in :doc:`testing </user/downloading-installing-upgrading/testing>`. You may wish to try again with the testing repository enabled:
.. code:: bash
.. code:: console
[user@dom0 ~]$ sudo qubes-dom0-update --enablerepo=qubes-templates-itl-testing qubes-template-X-xfce
If you would like to install a community distribution such as Gentoo, try the install command by enabling the community repository:
.. code:: bash
.. code:: console
[user@dom0 ~]$ sudo qubes-dom0-update --enablerepo=qubes-templates-community qubes-template-X-xfce
If your desired version is not found, it may still be in :doc:`testing </user/downloading-installing-upgrading/testing>`. You may wish to try again with the testing repository enabled:
.. code:: bash
.. code:: console
[user@dom0 ~]$ sudo qubes-dom0-update --enablerepo=qubes-templates-community-testing qubes-template-X-xfce

12
user/troubleshooting/app-menu-shortcut-troubleshooting.rst
View file

@ -27,7 +27,7 @@ With the command-line interface
To update the list of available applications, use the ``qvm-sync-appmenus`` command in dom0, replacing ``<QUBE_NAME>`` by the qube name:
.. code:: bash
.. code:: console
$ qvm-sync-appmenus <QUBE_NAME>
@ -35,7 +35,7 @@ To update the list of available applications, use the ``qvm-sync-appmenus`` comm
When using the *Refresh Applications* button in a qube’s settings, the command ``qvm-sync-appmenus`` is used at least one time. When refreshing an AppVM application, it is also run against the template. So the console equivalent of clicking the *Refresh button* is the following (always in dom0):
.. code:: bash
.. code:: console
$ qvm-sync-appmenus <APPVM_NAME>
$ qvm-sync-appmenus <TEMPLATE_NAME>
@ -44,7 +44,7 @@ When using the *Refresh Applications* button in a qube’s settings, the command
In dom0, the ``qvm-appmenus`` tool allows the user to see the list of available applications (unstable feature), the whitelist of currently show application (unstable feature) and to change this list:
.. code:: bash
.. code:: console
$ qvm-appmenus --set-whitelist <FILE_PATH> <QUBE_NAME>
@ -152,7 +152,7 @@ What if a removed application is still in the app menu?
First, try this in dom0:
.. code:: bash
.. code:: console
$ qvm-appmenus --update --force <QUBE_NAME>
@ -160,7 +160,7 @@ First, try this in dom0:
You can also try:
.. code:: bash
.. code:: console
$ qvm-appmenus --remove <QUBE_NAME>
@ -186,7 +186,7 @@ The line starting with ``Exec=`` points out the exact command run by dom0 to sta
It’s possible to run the command to check the output, by copying this line without ``Exec=``, and remove ``-q`` (quiet option). But it could be more useful to run it in the qube, with the ``qubes.StartApp`` service:
.. code:: bash
.. code:: console
$ /etc/qubes-rpc/qubes.StartApp <APPLICATION_NAME>

2
user/troubleshooting/disk-troubleshooting.rst
View file

@ -67,7 +67,7 @@ The above steps applies to old VM disks format. These steps may work on Qubes 4.
For example:
.. code:: bash
.. code:: console
$ sudo lvs
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert

2
user/troubleshooting/installation-troubleshooting.rst
View file

@ -31,7 +31,7 @@ There are a variety of other problems that could arise when using a USB installa
This error message is related to the faulty creation of the USB installation medium. If you receive this error message during installation, please make sure you have followed the instructions on :ref:`how to write your ISO to a USB key <user/downloading-installing-upgrading/installation-guide:copying the iso onto the installation medium>`. Specifically, the ``dd`` command listed on that page has been verified to solve this issue on multiple Qubes installation versions.
.. code:: bash
.. code:: console
$ sudo dd if=Qubes-RX-x86_64.iso of=/dev/sdY status=progress bs=1048576 && sync

14
user/troubleshooting/resume-suspend-troubleshooting.rst
View file

@ -21,7 +21,7 @@ First, determine which kernel module corresponds to your wireless card. There ar
The easiest is via the output of ``lspci -k`` in your sys-net VM:
.. code:: bash
.. code:: console
[user@sys-net ~]$ lspci -k
00:00.0 Network controller: Intel Corporation Wireless 8260 (rev 3a)
@ -64,7 +64,7 @@ You can check which drivers are currently loaded with ``lsmod``, and view detail
For example, we list what modules we have loaded:
.. code:: bash
.. code:: console
[user@sys-net ~]$ lsmod
Module Size Used by
@ -78,7 +78,7 @@ For example, we list what modules we have loaded:
and check one:
.. code:: bash
.. code:: console
[user@sys-net ~]$ modinfo iwlmvm | grep -E '^(description|author|depends):'
author: Copyright(c) 2003- 2015 Intel Corporation <ilw@linux.intel.com>
@ -91,7 +91,7 @@ Hey, it’s our wireless driver!
Now, check if reloading the module makes wireless work again:
.. code:: bash
.. code:: console
[user@sys-net ~]$ sudo rmmod iwlmvm
[user@sys-net ~]$ sudo modprobe iwlmvm
@ -102,7 +102,7 @@ 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:
.. code:: bash
.. code:: console
[user@sys-net ~]$ modinfo iwlwifi | grep -E '^(description|author|depends):'
author: Copyright(c) 2003- 2015 Intel Corporation <ilw@linux.intel.com>
@ -111,7 +111,7 @@ If that is successful, see below about having Qubes automatically reload the dri
.. code:: bash
.. code:: console
[user@sys-net ~]$ sudo rmmod iwlmvm
[user@sys-net ~]$ sudo rmmod iwlwifi
@ -128,7 +128,7 @@ If reloading the driver (which resets the hardware into a known-state) resolves
In the above example, it would look like this:
.. code:: bash
.. code:: console
[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

8
user/troubleshooting/vm-troubleshooting.rst
View file

@ -33,7 +33,7 @@ When a template is marked as ‘installed by package manager’, but cannot be u
1. Check the state of ``installed_by_rpm``
.. code:: bash
.. code:: console
$ qvm-prefs template-vm-name
@ -41,7 +41,7 @@ When a template is marked as ‘installed by package manager’, but cannot be u
2. If ``installed_by_rpm - True``, mark the template as not installed by package manager
.. code:: bash
.. code:: console
$ qvm-prefs template-vm-name installed_by_rpm false
@ -53,7 +53,7 @@ When a template is marked as ‘installed by package manager’, but cannot be u
- If ``installed_by_rpm - False``, remove the template like you would a regular qube:
.. code:: bash
.. code:: console
$ qvm-remove template-vm-name
@ -95,7 +95,7 @@ If the error occurs as a result of too little initial memory, increase the initi
For example:
.. code:: bash
.. code:: console
[user@dom0 ~]$ sudo qubes-dom0-update --enablerepo=qubes-templates-itl qubes-template-debian-10
Using sys-whonix as UpdateVM to download updates for Dom0; this may take some time...