diff --git a/developer/building/development-workflow.rst b/developer/building/development-workflow.rst
index 07c8742ac9..3432d4d3af 100644
--- a/developer/building/development-workflow.rst
+++ b/developer/building/development-workflow.rst
@@ -17,7 +17,7 @@ The best way to write and contribute code is to create a git repo somewhere (e.g
 
 **Example:**
 
-.. code:: console
+.. code-block:: console
 
       $ cd qubes-builder/artifacts/sources/qubes-manager
       $ git remote add abel git@GitHub.com:abeluck/qubes-manager.git
@@ -38,7 +38,7 @@ Prepare fresh version of kernel sources, with Qubes-specific patches applied
 
 In ``qubes-builder/artifacts/sources/linux-kernel``:
 
-.. code:: console
+.. code-block:: console
 
       $ make prep
 
@@ -46,7 +46,7 @@ In ``qubes-builder/artifacts/sources/linux-kernel``:
 
 The resulting tree will be in kernel-<VERSION>/linux-<VERSION>:
 
-.. code:: console
+.. code-block:: console
 
       $ ls -ltrd kernel*/linux*
       drwxr-xr-x 23 user user 4096 Nov  5 09:50 kernel-3.4.18/linux-3.4.18
@@ -60,7 +60,7 @@ Go to the kernel tree and update the version
 
 In ``qubes-builder/artifacts/sources/linux-kernel``:
 
-.. code:: console
+.. code-block:: console
 
       $ cd kernel-3.4.18/linux-3.4.18
 
@@ -72,7 +72,7 @@ Changing the config
 
 In ``kernel-3.4.18/linux-3.4.18``:
 
-.. code:: console
+.. code-block:: console
 
       $ cp ../../config .config
       $ make oldconfig
@@ -81,7 +81,7 @@ In ``kernel-3.4.18/linux-3.4.18``:
 
 Now change the configuration. For example, in ``kernel-3.4.18/linux-3.4.18``:
 
-.. code:: console
+.. code-block:: console
 
       $ make menuconfig
 
@@ -89,7 +89,7 @@ Now change the configuration. For example, in ``kernel-3.4.18/linux-3.4.18``:
 
 Copy the modified config back into the kernel tree:
 
-.. code:: console
+.. code-block:: console
 
       $ cp .config ../../../config
 
@@ -101,7 +101,7 @@ Patching the code
 
 TODO: describe the workflow for patching the code, below are some random notes, not working well
 
-.. code:: console
+.. code-block:: console
 
       $ ln -s ../../patches.xen
       $ export QUILT_PATCHES=patches.xen
@@ -131,7 +131,7 @@ You might want to take a moment here to review (git diff, git status), commit yo
 
 To actually build RPMs, in qubes-builder:
 
-.. code:: console
+.. code-block:: console
 
       $ ./qb -c linux-kernel package fetch prep build
 
@@ -169,7 +169,7 @@ Syncing dom0 files
 
 TODO: edit this script to be more generic
 
-.. code:: bash
+.. code-block:: bash
 
       #!/bin/sh
 
@@ -202,7 +202,7 @@ Apply qvm-tools
 
 TODO: make it more generic
 
-.. code:: bash
+.. code-block:: bash
 
       #!/bin/sh
 
@@ -217,7 +217,7 @@ Copy from dom0 to an appvm
 ^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 
-.. code:: bash
+.. code-block:: bash
 
       #/bin/sh
       #
@@ -242,7 +242,7 @@ Below example assumes that you use ``builder-RX`` directory in target VM to stor
 
 Service file (save in ``/usr/local/etc/qubes-rpc/local.Git`` in target VM):
 
-.. code:: bash
+.. code-block:: bash
 
       #!/bin/sh
 
@@ -271,7 +271,7 @@ Service file (save in ``/usr/local/etc/qubes-rpc/local.Git`` in target VM):
 
 Client script (save in ``~/bin/git-qrexec`` in source VM):
 
-.. code:: bash
+.. code-block:: bash
 
       #!/bin/sh
 
@@ -285,7 +285,7 @@ You will also need to setup qrexec policy in dom0 (``/etc/qubes-rpc/policy/local
 
 Usage:
 
-.. code:: console
+.. code-block:: 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
@@ -294,7 +294,7 @@ Usage:
 
 You can create ``~/bin/add-remote`` script to ease adding remotes:
 
-.. code:: bash
+.. code-block:: bash
 
       #!/bin/sh
 
@@ -325,7 +325,7 @@ RPM packages - yum repo
 
 In source VM, grab `linux-yum <https://github.com/QubesOS/qubes-linux-yum>`__ repository (below is assumed you’ve made it in ``~/repo-yum-upload`` directory) and replace ``update_repo.sh`` script with:
 
-.. code:: bash
+.. code-block:: bash
 
       #!/bin/sh
 
@@ -342,7 +342,7 @@ In source VM, grab `linux-yum <https://github.com/QubesOS/qubes-linux-yum>`__ re
 
 In target VM, setup actual yum repository (also based on `linux-yum <https://github.com/QubesOS/qubes-linux-yum>`__, this time without modifications). You will also need to setup some gpg key for signing packages (it is possible to force yum to install unsigned packages, but it isn’t possible for ``qubes-dom0-update`` tool). Fill ``~/.rpmmacros`` with key description:
 
-.. code:: text
+.. code-block:: text
 
       %_gpg_name Test packages signing key
 
@@ -350,7 +350,7 @@ In target VM, setup actual yum repository (also based on `linux-yum <https://git
 
 Then setup ``local.UpdateYum`` qrexec service (``/usr/local/etc/qubes-rpc/local.UpdateYum``):
 
-.. code:: bash
+.. code-block:: bash
 
       #!/bin/sh
 
@@ -388,7 +388,7 @@ If you want to access the repository from network, you need to setup HTTP server
 
 Usage: setup ``builder.conf`` in source VM to use your dummy-uploader repository:
 
-.. code:: bash
+.. code-block:: bash
 
       LINUX_REPO_BASEDIR = ../../repo-yum-upload/r3.1
 
@@ -396,7 +396,7 @@ Usage: setup ``builder.conf`` in source VM to use your dummy-uploader repository
 
 Then use ``make update-repo-unstable`` to upload the packages. You can also specify selected components on command line, then build them and upload to the repository:
 
-.. code:: console
+.. code-block:: console
 
       $ make COMPONENTS="core-agent-linux gui-agent-linux linux-utils" qubes update-repo-unstable
 
@@ -404,7 +404,7 @@ Then use ``make update-repo-unstable`` to upload the packages. You can also spec
 
 On the test machine, add yum repository (``/etc/yum.repos.d``) pointing at just configured HTTP server. For example:
 
-.. code:: ini
+.. code-block:: ini
 
       [local-test]
       name=Test
@@ -432,7 +432,7 @@ Steps are mostly the same as in the case of yum repo. The only details that diff
 
 ``update_repo.sh`` script:
 
-.. code:: bash
+.. code-block:: bash
 
       #!/bin/sh
 
@@ -450,7 +450,7 @@ Steps are mostly the same as in the case of yum repo. The only details that diff
 
 ``local.UpdateApt`` service code (``/usr/local/etc/qubes-rpc/local.UpdateApt`` in repo-serving VM):
 
-.. code:: bash
+.. code-block:: bash
 
       #!/bin/sh
 
@@ -487,7 +487,7 @@ Steps are mostly the same as in the case of yum repo. The only details that diff
 
 ``update-local-repo.sh``:
 
-.. code:: bash
+.. code-block:: bash
 
       #!/bin/sh
 
@@ -547,7 +547,7 @@ Steps are mostly the same as in the case of yum repo. The only details that diff
 
 Usage: add this line to ``/etc/apt/sources.list`` on test machine (adjust host and path):
 
-.. code:: text
+.. code-block:: text
 
       deb http://local-test.lan/linux-deb/r3.1 jessie-unstable main
 
diff --git a/developer/building/qubes-builder-v2.rst b/developer/building/qubes-builder-v2.rst
index abf60c42f2..b92c68a3d5 100644
--- a/developer/building/qubes-builder-v2.rst
+++ b/developer/building/qubes-builder-v2.rst
@@ -20,7 +20,7 @@ This is a simple setup using a docker or podman executor. This is a good default
 
 2. Clone the qubes-builder v2 repository into a location of your choice:
 
-   .. code:: console
+   .. code-block:: console
 
          $ git clone https://github.com/QubesOS/qubes-builderv2
          $ cd qubes-builderv2/
@@ -31,14 +31,14 @@ This is a simple setup using a docker or podman executor. This is a good default
 
    - for Fedora, use:
 
-      .. code:: console
+      .. code-block:: console
 
          $ sudo dnf install $(cat dependencies-fedora.txt)
          $ test -f /usr/share/qubes/marker-vm && sudo dnf install qubes-gpg-split
 
    - for Debian (note: some Debian packages require Debian version 13 or later), use:
 
-      .. code:: console
+      .. code-block:: console
 
          $ sudo apt install $(cat dependencies-debian.txt)
          $ test -f /usr/share/qubes/marker-vm && sudo apt install qubes-gpg-split
@@ -47,7 +47,7 @@ This is a simple setup using a docker or podman executor. This is a good default
 
 4. If you haven’t previously used docker in the current qube, you need to set up some permissions (nothing needs to be done here if you're using `podman`). In particular, the user has to be added to the ``docker`` group:
 
-   .. code:: console
+   .. code-block:: console
 
          $ sudo usermod -aG docker user
 
@@ -57,17 +57,17 @@ This is a simple setup using a docker or podman executor. This is a good default
 
    Depending on your choice of a container runtime, run one of:
 
-   .. code:: console
+   .. code-block:: console
 
          $ tools/generate-container-image.sh docker
 
-   .. code:: console
+   .. code-block:: console
 
          $ tools/generate-container-image.sh podman
 
    If you are using ``docker`` and an app qube, as ``/var/lib/docker`` is not persistent by default, you also need to use :doc:`bind-dirs </user/advanced-topics/bind-dirs>` to avoid repeating this step after reboot, adding the following to the ``/rw/config/qubes-bind-dirs.d/docker.conf`` file in this qube:
 
-   .. code:: bash
+   .. code-block:: bash
 
          binds+=( '/var/lib/docker' )
 
@@ -78,7 +78,7 @@ Configuration
 
 To use Qubes OS Builder v2, you need to have a ``builder.yml`` configuration file. You can use one of the sample files from the ``example-configs/`` directory; for a more readable ``builder.yml``, you can also include one of the files from that directory in your ``builder.yml``. An example ``builder.yml`` is:
 
-.. code:: yaml
+.. code-block:: yaml
 
       # include configuration relevant for the current release
       include:
@@ -109,7 +109,7 @@ To use Qubes OS Builder v2, you need to have a ``builder.yml`` configuration fil
 If you want use the ``podman`` executor, you have to enable socket activation, with:
 
 
-   .. code:: console
+   .. code-block:: console
 
          # systemctl --user enable --now podman.socket
 
@@ -118,7 +118,7 @@ Using Builder v2
 
 To fetch sources - in this example, for the ``core-admin-client`` package, you can use the following command:
 
-.. code:: console
+.. code-block:: console
 
       $ ./qb -c core-admin-client package fetch
 
@@ -126,19 +126,19 @@ 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:: console
+.. code-block:: 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:: console
+.. code-block:: 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:: console
+.. code-block:: console
 
       $ ./qb package fetch
 
diff --git a/developer/building/qubes-builder.rst b/developer/building/qubes-builder.rst
index aaa7f33ac3..d5dc57e9e6 100644
--- a/developer/building/qubes-builder.rst
+++ b/developer/building/qubes-builder.rst
@@ -55,7 +55,7 @@ In order to use it, you should use an rpm-based distro, like Fedora :), and shou
 
 Usually you can install those packages by just issuing:
 
-.. code:: console
+.. code-block:: console
 
       $ sudo dnf install gnupg git createrepo rpm-build make wget rpmdevtools python3-sh dialog rpm-sign dpkg-dev debootstrap python3-pyyaml devscripts perl-Digest-MD5 perl-Digest-SHA
 
@@ -65,14 +65,14 @@ The build system creates build environments in chroots and so no other packages
 The build system is configured via builder.conf file. You can use the setup.sh script to create and modify this file. Alternatively, you can copy the provided default builder.conf, and modify it as needed, e.g.:
 
 
-.. code:: console
+.. code-block:: console
 
       $ cp example-configs/qubes-os-master.conf builder.conf
 
 
 Edit the builder.conf file and set the following variables:
 
-.. code:: bash
+.. code-block:: bash
 
       NO_SIGN=1
 
@@ -81,7 +81,7 @@ One additional useful requirement is that ‘sudo root’ must work without any
 
 Additionally, if building with signing enabled (NO_SIGN is not set), you must adjust ``\~/.rpmmacros`` file so that it points to the GPG key used for package signing, e.g.:
 
-.. code:: text
+.. code-block:: text
 
       %_signature gpg
       %_gpg_path /home/user/.gnupg
@@ -94,14 +94,14 @@ So, to build Qubes you would do:
 
 Import the Qubes master key:
 
-.. code:: console
+.. code-block:: console
 
       $ gpg --recv-keys 0xDDFA1A3E36879494
 
 
 Verify its fingerprint, set as 'trusted'. This is described :doc:`here </project-security/verifying-signatures>`.
 
-.. code:: console
+.. code-block:: console
 
       $ wget https://keys.qubes-os.org/keys/qubes-developers-keys.asc
       $ gpg --import qubes-developers-keys.asc
@@ -112,42 +112,42 @@ Verify its fingerprint, set as 'trusted'. This is described :doc:`here </project
 
 Verify its integrity:
 
-.. code:: console
+.. code-block:: console
 
       $ git tag -v `git describe`
 
 
 Copy the example ``builder.conf``:
 
-.. code:: console
+.. code-block:: console
 
       $ cp example-configs/qubes-os-master.conf builder.conf
 
 
 Edit the builder.conf file and set the following variables:
 
-.. code:: bash
+.. code-block:: bash
 
       # NO_SIGN="1"
 
 
 Download all components:
 
-.. code:: console
+.. code-block:: console
 
       $ make get-sources
 
 
 And now to build all Qubes RPMs (this will take a few hours):
 
-.. code:: console
+.. code-block:: console
 
       $ make qubes
 
 
 ... and then to build the ISO
 
-.. code:: console
+.. code-block:: console
 
       $ make iso
 
@@ -156,7 +156,7 @@ And this should produce a shiny new ISO.
 
 You can also build selected component separately. Eg. to compile only gui virtualization agent/daemon:
 
-.. code:: console
+.. code-block:: console
 
       $ make gui-daemon
 
@@ -185,7 +185,7 @@ You can also modify sources somehow if you wish. Here are some basic steps:
 
 3. Download unmodified sources
 
-   .. code:: console
+   .. code-block:: console
 
          $ make get-sources
 
@@ -196,14 +196,14 @@ You can also modify sources somehow if you wish. Here are some basic steps:
 
 6. ``get-sources`` is already done, so continue with the next one. You can skip ``sign-all`` if you’ve disabled signing
 
-   .. code:: console
+   .. code-block:: console
 
          $ make vmm-xen core-admin linux-kernel gui-daemon template desktop-linux-kde installer-qubes-os manager linux-dom0-updates
 
 
 7. build iso installation image
 
-   .. code:: console
+   .. code-block:: console
 
          $ make iso
 
@@ -220,7 +220,7 @@ For building just a few selected packages, it’s very useful to download pre-bu
 
 Before creating the ``chroot``, add this to your ``builder.conf``:
 
-.. code:: bash
+.. code-block:: bash
 
       USE_QUBES_REPO_VERSION = $(RELEASE)
 
@@ -228,7 +228,7 @@ Before creating the ``chroot``, add this to your ``builder.conf``:
 
 It will add the ‘current’ Qubes repository to your ``chroot`` environment. Next, specify which components (``gcc``, for example) you want to download instead of compiling:
 
-.. code:: bash
+.. code-block:: bash
 
       COMPONENTS := $(filter-out gcc,$(COMPONENTS))
 
@@ -238,7 +238,7 @@ Alternatively, edit the actual COMPONENTS list which is defined in the included
 
 If you also want to use the ‘current-testing’ repository, add this to your configuration:
 
-.. code:: bash
+.. code-block:: bash
 
       USE_QUBES_REPO_TESTING = 1
 
@@ -256,7 +256,7 @@ Code verification keys management
 
 :doc:`QubesBuilder </developer/building/qubes-builder>` by default verifies signed tags on every downloaded code. Public keys used for that are stored in ``keyrings/git``. By default Qubes developers’ keys are imported automatically, but if you need some additional keys (for example your own), you can add them using:
 
-.. code:: bash
+.. code-block:: bash
 
       GNUPGHOME=$PWD/keyrings/git gpg --import /path/to/key.asc
       GNUPGHOME=$PWD/keyrings/git gpg --edit-key ID_OF_JUST_IMPORTED_KEY
diff --git a/developer/building/qubes-iso-building.rst b/developer/building/qubes-iso-building.rst
index 1c9ec82605..3989886114 100644
--- a/developer/building/qubes-iso-building.rst
+++ b/developer/building/qubes-iso-building.rst
@@ -15,14 +15,14 @@ Fedora 36 (and 37) has been successfully used to build Qubes R4.1 with the below
 
 **Notes:** On modern Fedora system (like Fedora 37) SeLinux is enforced by default and is blocking the build system. You would get error like “can’t create transaction lock on /…/rpm/.rpm.lock (Permission denied)”. You can set SeLinux to permissive mode with
 
-.. code:: console
+.. code-block:: console
 
       $ sudo setenforce 0
 
 
 In ``dom0``, install the Fedora 36 (or 37) template if you don’t already have it.
 
-.. code:: console
+.. code-block:: console
 
       $ sudo qubes-dom0-update qubes-template-fedora-36
 
@@ -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:: console
+.. code-block:: 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
 
@@ -40,20 +40,20 @@ Once you’ve built the development AppVM, open a Terminal window to it and inst
 
 Get the necessary keys to verify the sources (run these and other commands below as a regular user, not root):
 
-.. code:: console
+.. code-block:: console
 
       $ wget https://keys.qubes-os.org/keys/qubes-master-signing-key.asc
       $ gpg --import qubes-master-signing-key.asc
       $ gpg --edit-key 36879494
       $ fpr
 
-.. code:: output
+.. code-block:: output
 
       # Verify fingerprint! See Note below!
       # Once verified, set trust to *ultimate*
       # (Typical sequence is trust, 5, Y, q)
 
-.. code:: console
+.. code-block:: console
 
       $ wget https://keys.qubes-os.org/keys/qubes-developers-keys.asc
       $ gpg --import qubes-developers-keys.asc
@@ -64,7 +64,7 @@ Get the necessary keys to verify the sources (run these and other commands below
 
 Now let’s bootstrap the builder. Unfortunately, the builder cannot verify itself (the classic Chicken and Egg problem), so we need to verify the signature manually:
 
-.. code:: console
+.. code-block:: console
 
       $ git clone https://github.com/QubesOS/qubes-builder.git
       $ cd qubes-builder
@@ -82,12 +82,12 @@ Build using setup script
 
 Let’s configure the builder first (see :ref:`procedure <developer/building/qubes-iso-building:build using manual steps>` at bottom if you would prefer to manually configure):
 
-.. code:: console
+.. code-block:: console
 
       $ cd ~/qubes-builder
       $ ./setup
 
-.. code:: output
+.. code-block:: output
 
       # Select Yes to add Qubes Master Signing Key
       # Select Yes to add Qubes OS Signing Key
@@ -105,11 +105,11 @@ Let’s configure the builder first (see :ref:`procedure <developer/building/qub
 
 Once it completes downloading, re-run ``setup`` to add the Whonix templates:
 
-.. code:: console
+.. code-block:: console
 
       $ ./setup
 
-.. code:: output
+.. code-block:: output
 
       # Choose the same options as above, except at templates select:
       # fc36, bullseye, whonix-gateway-16, whonix-workstation-16
@@ -118,7 +118,7 @@ Once it completes downloading, re-run ``setup`` to add the Whonix templates:
 
 Continue the build process with:
 
-.. code:: console
+.. code-block:: console
 
       $ make install-deps
       $ make get-sources
@@ -131,7 +131,7 @@ You may also want to add ``COMPONENTS := $(filter-out gcc,$(COMPONENTS))`` to by
 
 Finally, if you are making a test build, use:
 
-.. code:: console
+.. code-block:: console
 
       $ make qubes
       $ make iso
@@ -140,7 +140,7 @@ Finally, if you are making a test build, use:
 
 Or for a fully signed build (this requires setting ``SIGN_KEY`` in ``builder.conf``):
 
-.. code:: console
+.. code-block:: console
 
       $ make qubes
       $ make sign-all
@@ -158,7 +158,7 @@ Instead of using ``./setup``, you can manually configure the build. The script t
 
 If you will be building Whonix templates:
 
-.. code:: console
+.. code-block:: console
 
       $ cd ~
       $ gpg --keyserver pgp.mit.edu --recv-keys 916B8D99C38EAF5E8ADC7A2A8D66066A2EEACCDA
@@ -168,7 +168,7 @@ If you will be building Whonix templates:
 
 **Note:** It’s very important to check the fingerprint displayed against multiple sources such as the `Whonix web site <https://www.whonix.org/wiki/Whonix_Signing_Key>`__, etc. It should look something like this:
 
-.. code:: output
+.. code-block:: output
 
       pub   rsa4096 2014-01-16 [SC] [expires: 2026-01-23]
             Key fingerprint = 916B 8D99 C38E AF5E 8ADC  7A2A 8D66 066A 2EEA CCDA
@@ -183,7 +183,7 @@ If you will be building Whonix templates:
 
 Next, prepare the Git keyring directory and copy them in:
 
-.. code:: console
+.. code-block:: console
 
       $ export GNUPGHOME=~/qubes-builder/keyrings/git
       $ mkdir --parents "$GNUPGHOME"
@@ -195,7 +195,7 @@ Next, prepare the Git keyring directory and copy them in:
 
 Copy one of the example configurations:
 
-.. code:: console
+.. code-block:: console
 
       $ cd ~/qubes-builder
       $ cp example-configs/qubes-os-master.conf builder.conf
@@ -206,7 +206,7 @@ Edit ``builder.conf``, referring to ``doc/Configuration.md`` for a description o
 
 Continue the build process with:
 
-.. code:: console
+.. code-block:: console
 
       $ make install-deps
       $ make get-sources
@@ -218,7 +218,7 @@ When building the Whonix templates, you will often need to add/update the ``WHON
 
 Finally, if you are making a test build, use:
 
-.. code:: console
+.. code-block:: console
 
       $ make qubes
       $ make iso
@@ -227,7 +227,7 @@ Finally, if you are making a test build, use:
 
 Or for a fully signed build (this requires setting ``SIGN_KEY`` in ``builder.conf``):
 
-.. code:: console
+.. code-block:: console
 
       $ make qubes
       $ make sign-all
diff --git a/developer/code/code-signing.rst b/developer/code/code-signing.rst
index c547534fbc..244f3d503c 100644
--- a/developer/code/code-signing.rst
+++ b/developer/code/code-signing.rst
@@ -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:: console
+.. code-block:: console
 
       $ gpg --gen-key
       gpg (GnuPG) 2.2.27; Copyright (C) 2021 Free Software Foundation, Inc.
@@ -68,14 +68,14 @@ In the example below, we will use ``keyserver.ubuntu.com``.
 
 Replace 6E2F4E7AF50A5827 with your key ID, preferably the **long keyID** which is the last 16 hex digits of the long number in the second line of the output above:
 
-.. code:: output
+.. code-block:: output
 
       pub   rsa3072 2021-12-30 [SC] [expires: 2023-12-30]
             87975838063F97A968D503266E2F4E7AF50A5827
 
 
 
-.. code:: console
+.. code-block:: console
 
       $ gpg --send-keys --keyserver hkps://keyserver.ubuntu.com 6E2F4E7AF50A5827
       gpg: sending key 6E2F4E7AF50A5827 to hkps://keyserver.ubuntu.com
@@ -89,7 +89,7 @@ If you’re submitting a patch via GitHub (or a similar Git server), please sign
 
 1. Set up Git to use your key:
 
-   .. code:: console
+   .. code-block:: console
 
          $ git config --global user.signingkey <KEYID>
 
@@ -97,14 +97,14 @@ If you’re submitting a patch via GitHub (or a similar Git server), please sign
 
 2. Set up Git to sign your commits with your key:
 
-   .. code:: console
+   .. code-block:: console
 
          $ git config --global commit.gpgsign true
 
 
    Alternatively, manually specify when a commit is to be signed:
 
-   .. code:: console
+   .. code-block:: console
 
          $ git commit -S
 
@@ -114,14 +114,14 @@ If you’re submitting a patch via GitHub (or a similar Git server), please sign
 
    This is useful for example, if you have a commit back in the git history which you like to sign now without rewriting the history.
 
-   .. code:: console
+   .. code-block:: console
 
          $ git tag -s <tag_name> -m "<tag_message>"
 
 
    You can also create an alias to make this easier. Edit your ``~/.gitconfig`` file. In the ``[alias]`` section, add ``stag`` to create signed tags and ``spush`` to create signed tags and push them.
 
-   .. code:: ini
+   .. code-block:: ini
 
          [alias]
          stag = "!bash -c 'id=\"`git rev-parse --verify HEAD`\"; tag_name="signed_tag_for_${id:0:8}"; git tag -s "$tag_name" -m \"Tag for commit $id\"; echo \"$tag_name\"'"
@@ -130,7 +130,7 @@ If you’re submitting a patch via GitHub (or a similar Git server), please sign
 
    You may also find it convenient to have an alias for verifying the tag on the latest commit:
 
-   .. code:: ini
+   .. code-block:: ini
 
          vtag = !git tag -v `git describe`
 
@@ -170,14 +170,14 @@ In this case, you have several options to sign the commit:
 
 1. Amend the commit and replace it with a signed commit. You can use this command to create a new signed commit:
 
-   .. code:: console
+   .. code-block:: console
 
          $ git commit --amend -S
 
 
    This also rewrites the commit so you need to push it forcefully:
 
-   .. code:: console
+   .. code-block:: console
 
          $ git push -f
 
@@ -185,7 +185,7 @@ In this case, you have several options to sign the commit:
 
 2. Create a signed tag for the unsigned commit. If the commit is back in history and you do not want to change it, you can create a signed tag for this commit and push the signature. You can use the alias from above:
 
-   .. code:: console
+   .. code-block:: console
 
          $ git checkout <commit>
          $ git spush
diff --git a/developer/code/coding-style.rst b/developer/code/coding-style.rst
index 759daceaca..707a3167ac 100644
--- a/developer/code/coding-style.rst
+++ b/developer/code/coding-style.rst
@@ -55,7 +55,7 @@ General typographic conventions
 
 - **Comments should be indented together with the code**, e.g. like this:
 
-  .. code:: c
+  .. code-block:: c
 
         for (...) {
             // The following code finds PGP private key matching the given public key in O(1)
@@ -120,7 +120,7 @@ General programming style guidelines
 
 - Do **not** use comments for code fragments where it is immediately clear what the code does. E.g. avoid constructs like this:
 
-  .. code:: c
+  .. code-block:: c
 
         // Return window id
         int get_window_id (...) {
@@ -132,7 +132,7 @@ General programming style guidelines
 
 - Do **not** use comments to disable code fragments. In production code there should really be no commented or disabled code fragments. If you really, really have a good reason to retain some fragment of unused code, use #if or #ifdef to disable it, e.g.:
 
-  .. code:: c
+  .. code-block:: c
 
         #if 0
             (...)   // Some unused code here
@@ -141,7 +141,7 @@ General programming style guidelines
 
   … and preferably use some descriptive macro instead of just ``0``, e.g.:
 
-  .. code:: c
+  .. code-block:: c
 
         #if USE_OLD_WINDOW_TRAVERSING
             (...)   // Some unused code here
@@ -214,7 +214,7 @@ Security coding guidelines
 
 - Use ``untrusted_`` prefix for all variables that hold values read from untrusted party and which have not yet been verified to be decent, e.g.:
 
-  .. code:: c
+  .. code-block:: c
 
         read_struct(untrusted_conf);
         /* sanitize start */
diff --git a/developer/code/source-code.rst b/developer/code/source-code.rst
index 6b8e6c1f59..8832dda32b 100644
--- a/developer/code/source-code.rst
+++ b/developer/code/source-code.rst
@@ -19,7 +19,7 @@ All of our repositories are available under the `QubesOS GitHub account <https:/
 
 To clone a repository:
 
-.. code:: console
+.. code-block:: console
 
       $ git clone https://github.com/QubesOS/qubes-<repo_name>.git <repo_name>
 
@@ -27,7 +27,7 @@ To clone a repository:
 
 e.g.:
 
-.. code:: console
+.. code-block:: console
 
       $ git clone https://github.com/QubesOS/qubes-core-admin.git core-admin
 
@@ -37,7 +37,7 @@ To build Qubes you do not need to download all these repositories. If you use :d
 
 If you really do want to clone **all** of the repositories, you can use these commands:
 
-.. code:: console
+.. code-block:: console
 
       $ curl "https://api.github.com/orgs/QubesOS/repos?page=1&per_page=100" | grep -e 'clone_url*' | cut -d \" -f 4 | xargs -L1 git clone
       $ curl "https://api.github.com/orgs/QubesOS/repos?page=2&per_page=100" | grep -e 'clone_url*' | cut -d \" -f 4 | xargs -L1 git clone
@@ -46,7 +46,7 @@ If you really do want to clone **all** of the repositories, you can use these co
 
 To update (git fetch) **all** of these repositories :
 
-.. code:: console
+.. code-block:: console
 
       $ find . -mindepth 1 -maxdepth 1 -type d -exec git -C {} fetch --tags --recurse-submodules=on-demand --all \;
 
diff --git a/developer/debugging/automated-tests.rst b/developer/debugging/automated-tests.rst
index a08f17292d..09c6da4068 100644
--- a/developer/debugging/automated-tests.rst
+++ b/developer/debugging/automated-tests.rst
@@ -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:: console
+.. code-block:: 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:: console
+.. code-block:: console
 
       [user@dom0 ~]$ python3 -m qubes.tests.run -l | grep fedora-21
       network/VmNetworking_fedora-21/test_000_simple_networking
@@ -109,7 +109,7 @@ For instance, to run only the tests for the fedora-21 template, you can use the
 
 Some developers script this part, so you can provide arguments to the script and it handles ``qubesd``. Save the following contents to :file:`~/run-tests`:
 
-.. code:: console
+.. code-block:: console
 
     #!/bin/sh
     set -eu
@@ -123,13 +123,13 @@ Some developers script this part, so you can provide arguments to the script and
 
 And run:
 
-.. code:: console
+.. code-block:: console
 
     ~/run-tests -L INFO -o /tmp/tests.log <TEST_NAME>
 
 You might even almost complete test names and shell expansion:
 
-.. code:: console
+.. code-block:: console
 
     ~/run-tests qubes.tests.integ.dispvm_perf/TC_00_DispVMPerf_debian-{12,13}-xfce/test_0{0,1,2}
 
@@ -142,7 +142,7 @@ Example test run:
 
 Tests are also compatible with nose2 test runner, so you can use this instead:
 
-.. code:: console
+.. code-block:: console
 
       $ sudo systemctl stop qubesd; sudo -E nose2 -v --plugin nose2.plugins.loader.loadtests qubes.tests; sudo systemctl start qubesd
 
@@ -165,7 +165,7 @@ The below example however will assume that you set up a build environment as des
 
 Assuming you cloned the ``qubes-builder`` repository to your home directory inside a fedora VM, you can use the following commands to run the unit tests:
 
-.. code:: console
+.. code-block:: console
 
       $ cd ~
       $ sudo dnf install python3-pip lvm2 python35 python3-virtualenv
@@ -214,7 +214,7 @@ Editing ``__init__.py``
 
 You’ll also need to add your test at the bottom of the ``__init__.py`` file, in the method ``def load_tests``, in the for loop with ``modname``. Again, given the hypothetical ``example.py`` test:
 
-.. code:: python
+.. code-block:: python
 
       for modname in (
               'qubes.tests.basic',
@@ -234,7 +234,7 @@ Testing PyQt applications
 
 When testing (Py)QT applications, it’s useful to create a separate QApplication object for each test. But QT framework does not allow multiple QApplication objects in the same process at the same time. This means it’s critical to reliably cleanup the previous instance before creating a new one. This turns out to be a non-trivial task, especially if *any* test uses the event loop. Failure to perform proper cleanup in many cases results in SEGV. Below you can find steps for the proper cleanup:
 
-.. code:: python
+.. code-block:: python
 
       import asyncio
       import quamash
@@ -357,7 +357,7 @@ Notes:
 
 Examples:
 
-.. code:: console
+.. code-block:: console
 
     # Only this PR
     openQArun
diff --git a/developer/debugging/mount-lvm-image.rst b/developer/debugging/mount-lvm-image.rst
index dbc19b618e..cf4c5c5769 100644
--- a/developer/debugging/mount-lvm-image.rst
+++ b/developer/debugging/mount-lvm-image.rst
@@ -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:: console
+.. code-block:: 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:: console
+.. code-block:: 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:: console
+.. code-block:: 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:: console
+.. code-block:: console
 
       [user@dispXXXX]$ mount /dev/xvdiX /mnt/
 
 
 5: Umount and kill the VM
 
-.. code:: console
+.. code-block:: console
 
       [user@dispXXXX]$ umount /mnt/
 
 
 6: Remove the image from qubesdb
 
-.. code:: console
+.. code-block:: console
 
       [user@dom0]$ qubesdb-rm /qubes-block-devices/$dev/
 
diff --git a/developer/debugging/safe-remote-ttys.rst b/developer/debugging/safe-remote-ttys.rst
index cb53a527b0..e8b395784a 100644
--- a/developer/debugging/safe-remote-ttys.rst
+++ b/developer/debugging/safe-remote-ttys.rst
@@ -17,7 +17,7 @@ To a different VM
 
 As an example of forwarding terminal output to another VM on the same machine:
 
-.. code:: console
+.. code-block:: 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:: console
+.. code-block:: 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:: console
+.. code-block:: console
 
       $ echo $COLUMNS $LINES
       80 24
@@ -68,7 +68,7 @@ A note on serial consoles
 
 If your machine has a serial console, you may with to use that, but note that a similar split-I/O model should be used to ensure Dom0 integrity. If you use the serial console as normal (via e.g. getty on ttyX, and logging in as normal), then the machine at the end of the serial cable could compromise your machine! Ideally, you would take input from your trusted keyboard, and only send the output over the serial cable via e.g. disabling getty and using:
 
-.. code:: console
+.. code-block:: console
 
       $ script -f /dev/ttyS0
 
diff --git a/developer/debugging/test-bench.rst b/developer/debugging/test-bench.rst
index 4a64cc20b2..14ce37c240 100644
--- a/developer/debugging/test-bench.rst
+++ b/developer/debugging/test-bench.rst
@@ -35,7 +35,7 @@ Internet access is intentionally disabled by default in dom0. But to ease the de
 
 4. Save the following script in ``/home/user/bin/dom0_network.sh`` and make it executable. It should enable your network card in dom0. *Be sure to adjust the script’s variables to suit your needs.*
 
-   .. code:: bash
+   .. code-block:: bash
 
          #!/bin/sh
 
@@ -78,7 +78,7 @@ Internet access is intentionally disabled by default in dom0. But to ease the de
 
 6. You’ll need to run the above script on every startup. To automate this save the following systemd service ``/etc/systemd/system/dom0-network-direct.service``
 
-   .. code:: systemd
+   .. code-block:: systemd
 
          [Unit]
          Description=Connect network to dom0
@@ -94,7 +94,7 @@ Internet access is intentionally disabled by default in dom0. But to ease the de
 
 7. Then, enable and start the SSH Server and the script on boot:
 
-   .. code:: console
+   .. code-block:: console
 
          $ sudo systemctl enable sshd
          $ sudo systemctl start sshd
@@ -117,7 +117,7 @@ Because of the above reason, some additional configurations need to be done to y
 
 The following commands should work for you, but do keep in mind that the provisioning scripts are designed for the `openQA environment <https://openqa.qubes-os.org/>`__ and not your specific local testing system. Run the following in ``dom0``:
 
-.. code:: console
+.. code-block:: console
 
       # For future reference the following commands are an adaptation of
       # https://github.com/marmarek/openqa-tests-qubesos/blob/master/tests/update.pm
@@ -155,7 +155,7 @@ SSH
 
 Arrange firewall so you can reach the testbench from your ``qubes-dev`` VM. Generate SSH key in ``qubes-dev``:
 
-.. code:: console
+.. code-block:: console
 
       $ ssh-keygen -t ecdsa -b 521
 
@@ -163,7 +163,7 @@ Arrange firewall so you can reach the testbench from your ``qubes-dev`` VM. Gene
 
 Add the following section in ``.ssh/config`` in ``qubes-dev``:
 
-.. code:: text
+.. code-block:: text
 
       Host testbench
           # substitute username in testbench
@@ -187,7 +187,7 @@ This step is optional, but very helpful. Put these scripts somewhere in your ``$
 
 ``qtb-runtests``:
 
-.. code:: bash
+.. code-block:: bash
 
       #!/bin/sh
 
@@ -196,7 +196,7 @@ This step is optional, but very helpful. Put these scripts somewhere in your ``$
 
 ``qtb-install``:
 
-.. code:: bash
+.. code-block:: bash
 
       #!/bin/sh
 
@@ -220,7 +220,7 @@ This step is optional, but very helpful. Put these scripts somewhere in your ``$
 
 ``qtb-iterate``:
 
-.. code:: bash
+.. code-block:: bash
 
       #!/bin/sh
 
@@ -247,7 +247,7 @@ I (woju) have those two git hooks. They ensure tests are passing (or are marked
 
 ``core-admin/.git/hooks/pre-commit``: (you may retain also the default hook, here omitted for readability)
 
-.. code:: bash
+.. code-block:: bash
 
       #!/bin/sh
 
@@ -258,7 +258,7 @@ I (woju) have those two git hooks. They ensure tests are passing (or are marked
 
 ``core-admin/.git/hooks/pre-push``:
 
-.. code:: bash
+.. code-block:: bash
 
       #!/bin/sh
 
diff --git a/developer/debugging/windows-debugging.rst b/developer/debugging/windows-debugging.rst
index dd0d047163..8ca9f6d82b 100644
--- a/developer/debugging/windows-debugging.rst
+++ b/developer/debugging/windows-debugging.rst
@@ -45,7 +45,7 @@ You will need to create a :doc:`custom libvirt config <core-admin:libvirt>` for
 
 
 
-.. code:: xml+jinja
+.. code-block:: xml+jinja
 
 
       {% extends 'libvirt/xen.xml' %}
@@ -98,7 +98,7 @@ Host and target preparation
 
   - ``kdnet`` should show that the NIC is supported, note the busparams:
 
-    .. code:: text
+    .. code-block:: text
 
           Network debugging is supported on the following NICs:
           busparams=0.6.0, Intel(R) PRO/1000 MT Network Connection, KDNET is running on this NIC.
@@ -117,7 +117,7 @@ Host and target preparation
 
 - Reboot ``target-vm``, debugging should start:
 
-  .. code:: text
+  .. code-block:: text
 
         Waiting to reconnect...
         Connected to target 10.137.0.19 on port 50000 on local IP 10.137.0.20.
diff --git a/developer/general/developing-gui-applications.rst b/developer/general/developing-gui-applications.rst
index 007efb2892..58e3dcaae8 100644
--- a/developer/general/developing-gui-applications.rst
+++ b/developer/general/developing-gui-applications.rst
@@ -13,7 +13,7 @@ Where you would normally provide the Qubes object, use the ``qubesadmin.tests.mo
 
 For example, the following code can be used to run the ``qui-domains`` tool using the mock Qubes object (this code would replace the initial part of the main function):
 
-.. code:: python
+.. code-block:: python
 
       def main():
           ''' main function '''
@@ -32,7 +32,7 @@ For example, the following code can be used to run the ``qui-domains`` tool usin
 
 To run a mocked program without installing it in a qube, remember to extend PYTHONPATH appropriately, for example:
 
-.. code:: console
+.. code-block:: console
 
       ~/qubes-sources/manager $ PYTHONPATH=../core-admin-client:. python3 qui/tray/domains.py
 
@@ -49,7 +49,7 @@ The mock Qubes object has a collection of expected Qubes RPC calls and the respo
 
 If you need more calls, you can add them to the mock object using the following syntax (the following example adds listing available vm kernels):
 
-.. code:: python
+.. code-block:: python
 
       mock_app.expected_calls[('dom0', 'admin.pool.volume.List', 'linux-kernel', None)] = \
           b'0\x006.1.57-1.fc37\n6.1.43-1.fc37\ncustom_kernel\n'
@@ -57,7 +57,7 @@ If you need more calls, you can add them to the mock object using the following
 
 If error should be thrown, you need to provide the error code and name, for example:
 
-.. code:: python
+.. code-block:: python
 
       mock_app.expected_calls[("vmname", "admin.vm.property.Get", "property_name", None)] = \
           b'2\x00QubesNoSuchPropertyError\x00\x00No such property\x00'
@@ -85,7 +85,7 @@ Extending the mock Qubes object
 
 To collect information to modify this script, you can use the wrapper function to wrap and output all qubesd calls used by a program running on a live qubes instance.
 
-.. code:: python
+.. code-block:: python
 
       qapp = qubesadmin.Qubes()
       import qubesadmin.tests.mock_app as mock_app
@@ -99,7 +99,7 @@ Writing tests
 
 The same mock Qubes can also be used to write tests. You can use the wrappers above to check which calls are made when certain actions are performed, and add them to the mock objects in the following way:
 
-.. code:: python
+.. code-block:: python
 
       # this is an excerpt from tests for Qubes Global Config tool
           clockvm_combo.set_active_id('test-blue')
diff --git a/developer/general/gsoc.rst b/developer/general/gsoc.rst
index caef042cfb..a6530ded5f 100644
--- a/developer/general/gsoc.rst
+++ b/developer/general/gsoc.rst
@@ -49,7 +49,7 @@ A project proposal is what you will be judged upon. Write a clear proposal on wh
 
 Below is the application template:
 
-.. code:: markdown
+.. code-block:: markdown
 
       # Introduction
 
diff --git a/developer/general/how-to-edit-the-rst-documentation.rst b/developer/general/how-to-edit-the-rst-documentation.rst
index 5bbe4512d9..cdf5c75c2a 100644
--- a/developer/general/how-to-edit-the-rst-documentation.rst
+++ b/developer/general/how-to-edit-the-rst-documentation.rst
@@ -159,20 +159,20 @@ Tips & Tricks
 - Pull upstream changes into your fork regularly. Diverging too far from main can be cumbersome to update at a later stage.
 - To pull in upstream changes:
 
-  .. code:: console
+  .. code-block:: console
 
    $ git remote add upstream https://github.com/QubesOS/qubes-doc.git
    $ git fetch upstream
 
 - Check the log and the current changes, before merging:
 
-  .. code:: console
+  .. code-block:: console
 
    $ git log upstream/main
 
 - Then merge the changes that you fetched:
 
-  .. code:: console
+  .. code-block:: console
 
    $ git merge upstream/main
 
@@ -255,7 +255,7 @@ The first part (before the colon) is the path of the file as with the `:doc: rol
 
 **When referencing some kind of code** use the corresponding role, eventually prefixed by the sub-project, as in:
 
-.. code:: rst
+.. code-block:: rst
 
    See :py:class:`core-admin:qubes.vm.dispvm.DispVM`
 
diff --git a/developer/general/how-to-edit-the-website.rst b/developer/general/how-to-edit-the-website.rst
index 37c96862da..1c8f33670e 100644
--- a/developer/general/how-to-edit-the-website.rst
+++ b/developer/general/how-to-edit-the-website.rst
@@ -75,7 +75,7 @@ Quick intro to Jekyll
 
 The main `qubesos.github.io <https://github.com/QubesOS/qubesos.github.io>`__ contains the following directories:
 
-.. code:: bash
+.. code-block:: bash
 
   ├── data          # ← YAML files with key‑value pairs used throughout the site
   │   └── *.yml     # e.g. site settings, navigation menus
@@ -158,13 +158,13 @@ This can be useful for making sure that your changes render the way you expect,
 
 1. Create a template qube:
 
-.. code:: console
+.. code-block:: console
 
   $ qvm-clone debian-12-minimal jekyll-tvm
 
 2. Install packages:
 
-.. code:: console
+.. code-block:: console
 
   $ apt install qubes-core-agent-networking
   $ apt install ruby-full build-essential zlib1g-dev vim
@@ -174,7 +174,7 @@ This can be useful for making sure that your changes render the way you expect,
 
 3. Create a ``jekyll-app-vm`` based on the ``jekyll-tvm`` template, install and configure in ``jekyll-app-vm``:
 
-.. code:: console
+.. code-block:: console
 
   $ echo '# Install Ruby Gems to ~/gems' >> ~/.bashrc
   $ echo 'export GEM_HOME="$HOME/gems"' >> ~/.bashrc
diff --git a/developer/general/rst-documentation-style-guide.rst b/developer/general/rst-documentation-style-guide.rst
index 13edb358e4..140bc3b818 100644
--- a/developer/general/rst-documentation-style-guide.rst
+++ b/developer/general/rst-documentation-style-guide.rst
@@ -28,10 +28,10 @@ provided by `Docutils <https://www.docutils.org/>`__ and extended by `Sphinx <ht
 Directives are used to insert non-paragraph content, such as images, tables, and code blocks.
 Example directives are:
 
-.. code:: rst
+.. code-block:: rst
 
    .. image::
-   .. code::
+   .. code-block::
    .. figure::
 
 Directives start with ``..``, followed by directive name, arguments, options, and indented content.
@@ -42,7 +42,7 @@ Images
 To include images (without a caption), use the ``image`` directive.
 You need to specify the path to the image and an alt text.
 
-.. code:: rst
+.. code-block:: rst
 
   .. image:: path/to/image.png
      :alt: Alternative text
@@ -64,7 +64,7 @@ Lists
 
 Nested lists must be separated from the parent list items by blank lines:
 
-.. code:: rst
+.. code-block:: rst
 
   - Item 1
   - Item 2
@@ -76,7 +76,7 @@ Nested lists must be separated from the parent list items by blank lines:
 
 Numbered lists can be autonumbered using the ``#`` sign.
 
-.. code:: rst
+.. code-block:: rst
 
   #. Item 1
   #. Item 2
@@ -96,9 +96,9 @@ or `code-block <https://www.sphinx-doc.org/en/master/usage/restructuredtext/dire
 
 By specifying the language, you enable pygments, which show syntax color coding for that code sample (see `here <https://pygments.org/languages/>`__ for a list of supported languages).
 
-.. code:: rst
+.. code-block:: rst
 
-   .. code:: language
+   .. code-block:: language
 
       code
 
@@ -108,15 +108,15 @@ Use ``[...]`` for anything omitted.
 
 For inlining small code snippets you can use the `code role <https://www.sphinx-doc.org/en/master/usage/restructuredtext/roles.html#role-code>`__ as in
 
-.. code:: rst
+.. code-block:: rst
 
    :code:`:term:`qube``
 
 You can add line numbers to code examples with the ``:linenos:`` parameter.
 
-.. code:: rst
+.. code-block:: rst
 
-    .. code:: python
+    .. code-block:: python
       :linenos:
 
        def hello_world():
@@ -125,50 +125,50 @@ You can add line numbers to code examples with the ``:linenos:`` parameter.
 
 You can have certain lines with the ``:emphasize-lines:`` parameter.
 
-.. code:: rst
+.. code-block:: rst
 
- .. code:: python
+ .. code-block:: python
    :emphasize-lines: 1,3,4
 
 
 
 For Python use ``python``.
 
-.. code:: rst
+.. code-block:: rst
 
-    .. code:: python
+    .. code-block:: python
 
       string_var = 'python'
 
 For Bash use ``bash``.
 
-.. code:: rst
+.. code-block:: rst
 
-    .. code:: bash
+    .. code-block:: bash
 
        #!/bin/bash
 
 For a terminal session use ``console``.
 
-.. code:: rst
+.. code-block:: rst
 
-    .. code:: console
+    .. code-block:: console
 
        $ echo "Hello"
 
 For text output use ``output``.
 
-.. code:: rst
+.. code-block:: rst
 
-    .. code:: output
+    .. code-block:: output
 
        some output
 
 For text use ``text``.
 
-.. code:: rst
+.. code-block:: rst
 
-    .. code:: text
+    .. code-block:: text
 
        some text
 
@@ -180,7 +180,7 @@ We adhere to the list tables directive by docutils as described `here <https://d
 
 A simple example would be:
 
-    .. code:: rst
+    .. code-block:: rst
 
         .. list-table::
            :widths: 15 10
@@ -204,7 +204,7 @@ They are typically styled as colored text boxes, usually accompanied by icons pr
 
 Here are examples of several types of alerts:
 
-.. code:: rst
+.. code-block:: rst
 
      .. hint::
         If you would like to avoid prefixing commands with [...]
@@ -235,7 +235,7 @@ These render as:
 
 You can also provide a `custom title to the admonition <https://www.sphinx-doc.org/en/master/usage/restructuredtext/directives.html#directive-admonition>`_:
 
-.. code:: rst
+.. code-block:: rst
 
    .. admonition:: Did you know?
 
@@ -252,7 +252,7 @@ Glossary
 
 Most of the `glossaries <https://www.sphinx-doc.org/en/master/usage/restructuredtext/directives.html#glossary>`__ are present in :file:`/user/reference/glossary.rst`, like:
 
-.. code:: rst
+.. code-block:: rst
 
    .. glossary::
 
@@ -275,7 +275,7 @@ and thus enhance the readability and consistency of the documentation.
 
 Syntax is as follows:
 
-.. code:: rst
+.. code-block:: rst
 
    :rolename:`content`
 
@@ -306,7 +306,7 @@ Cross-referencing a page
 
 To cross-reference a page, use the `doc role <https://www.sphinx-doc.org/en/master/usage/restructuredtext/roles.html#role-doc>`__ with a path. To get a link to the file called :file:`intro.rst` in the :file:`introduction/` directory, use:
 
-  .. code:: rst
+  .. code-block:: rst
 
    :doc:`/introduction/intro`
 
@@ -317,7 +317,7 @@ Cross-referencing a section with a header
 
 To cross-reference a section with a header, use the `ref role <https://www.sphinx-doc.org/en/master/usage/restructuredtext/roles.html#role-ref>`__ with a path and the reStructuredText content of the header, separated by a colon:
 
-  .. code:: rst
+  .. code-block:: rst
 
    :ref:`introduction/intro:What is Qubes OS?`
 
@@ -325,13 +325,13 @@ Note that with the `ref role <https://www.sphinx-doc.org/en/master/usage/restruc
 
 You can get a list of the generated labels after building the documentation. If your build directory is :file:`_build/html`, run the following:
 
-.. code:: console
+.. code-block:: console
 
    [~/qubes-doc] $ python3 -m sphinx.ext.intersphinx _build/html/objects.inv
 
 You can also run that command against the current online version of the docs:
 
-.. code:: console
+.. code-block:: console
 
    $ python3 -m sphinx.ext.intersphinx https://doc.qubes-os.org/en/latest/objects.inv
 
@@ -350,7 +350,7 @@ Frequently linked sections, especially when they have a long name can be referen
 
 First, you have to create a custom label, **only use lowercase alphanumeric characters and hyphens**:
 
-.. code:: rst
+.. code-block:: rst
 
    .. _disposable-with-pci-devices:
 
@@ -365,7 +365,7 @@ Now, to reference this label, use the custom label instead of the path and the h
 
    * - reStructuredText markup
      - output
-   * - .. code:: rst
+   * - .. code-block:: rst
 
           :ref:`disposable-with-pci-devices`
 
@@ -388,7 +388,7 @@ Most cross-references can generate an automatic title. If it doesn't fit the sen
 
    * - reStructuredText markup
      - output
-   * - .. code:: rst
+   * - .. code-block:: rst
 
           :ref:`without PCI devices <disposable-with-pci-devices>`
 
@@ -411,7 +411,7 @@ To do such a cross-reference, use the usual cross-reference syntax but with the
 
    * - reStructuredText markup
      - output
-   * - .. code:: rst
+   * - .. code-block:: rst
 
           :doc:`core-admin:index`
 
@@ -425,7 +425,7 @@ Even if it works without it, **always prefix the external cross-references** wit
 
    Intersphinx `can list all the available links <https://www.sphinx-doc.org/en/master/usage/extensions/intersphinx.html#showing-all-links-of-an-intersphinx-mapping-file>`__ to another project with the following command:
 
-   .. code:: console
+   .. code-block:: console
 
        python3 -m sphinx.ext.intersphinx https://dev.qubes-os.org/projects/core-admin/en/latest/objects.inv
 
@@ -445,7 +445,7 @@ You can create a reference to `any documented python objects <https://www.sphinx
 
    * - reStructuredText markup
      - output
-   * - .. code:: rst
+   * - .. code-block:: rst
 
           :option:`core-admin-client:qubes-prefs --help`
      - :option:`core-admin-client:qubes-prefs --help`
@@ -458,7 +458,7 @@ You can create a reference to `any documented python objects <https://www.sphinx
 
    * - reStructuredText markup
      - output
-   * - .. code:: rst
+   * - .. code-block:: rst
 
           :py:class:`core-admin:qubes.vm.dispvm.DispVM`
 
@@ -472,7 +472,7 @@ Do not use a :ref:`custom title <customizing-text-link>` to shorten the link lab
 
    * - reStructuredText markup
      - output
-   * - .. code:: rst
+   * - .. code-block:: rst
 
           :py:class:`~core-admin:qubes.vm.dispvm.DispVM`
 
@@ -480,7 +480,7 @@ Do not use a :ref:`custom title <customizing-text-link>` to shorten the link lab
 
 **If a cross-reference points to a missing reference** (i.e.: reference to a removed component), prefix the reference with an exclamation mark (``!``). If the function :py:func:`!old_function` has been removed but is still referenced, to discuss the old implementation use:
 
-.. code:: rst
+.. code-block:: rst
 
    :py:func:`!old_function`
 
@@ -489,13 +489,13 @@ Hyperlink to other websites syntax
 
 Use `embedded links <https://www.sphinx-doc.org/en/master/usage/restructuredtext/basics.html#external-links>`__ like
 
-.. code:: rst
+.. code-block:: rst
 
     `website <https://example.com/>`__
 
 **Do not use reference-style links** like
 
-.. code:: rst
+.. code-block:: rst
 
    Some text link_
 
@@ -536,7 +536,7 @@ Although possible, using a level under the paragraph level should be avoided.
 
 Here is a simple example of a page with a title and three nested levels of heading:
 
-.. code:: rst
+.. code-block:: rst
 
   ==========
   Main Title
@@ -561,19 +561,19 @@ Emphasis and Italics
 
 - *Italics*: Use single asterisks
 
- .. code:: rst
+ .. code-block:: rst
 
     *italics*
 
 - **Bold**: Use double asterisks.
 
- .. code:: rst
+ .. code-block:: rst
 
     **bold**
 
 - ``Monospace``: Use backticks.
 
- .. code:: rst
+ .. code-block:: rst
 
     ``monospace``
 
@@ -620,11 +620,11 @@ Writing command-line examples
 
    * - reStructuredText markup
      - output
-   * - .. code:: rst
+   * - .. code-block:: rst
 
           Open a terminal in dom0 and run:
 
-          .. code:: console
+          .. code-block:: console
 
              [user@dom0] $ cd test
              [user@dom0 ~/test] $ echo Hello
@@ -632,7 +632,7 @@ Writing command-line examples
 
      - Open a terminal in dom0 and run:
 
-       .. code:: console
+       .. code-block:: console
 
           [user@dom0] $ cd test
           [user@dom0 ~/test] $ echo Hello
@@ -654,46 +654,46 @@ Writing command-line examples
        - output
 
      * - minimal
-       - .. code:: rst
+       - .. code-block:: rst
 
-            .. code:: console
+            .. code-block:: console
 
                $ cd test
 
-       - .. code:: console
+       - .. code-block:: console
 
             $ cd test
 
      * - qube name
-       - .. code:: rst
+       - .. code-block:: rst
 
-            .. code:: console
+            .. code-block:: console
 
                [dom0] $ cd test
 
-       - .. code:: console
+       - .. code-block:: console
 
             [dom0] $ cd test
 
      * - with path
-       - .. code:: rst
+       - .. code-block:: rst
 
-            .. code:: console
+            .. code-block:: console
 
                [dom0 /tmp] $ cd test
 
-       - .. code:: console
+       - .. code-block:: console
 
             [dom0 /tmp] $ cd test
 
      * - full
-       - .. code:: rst
+       - .. code-block:: rst
 
-            .. code:: console
+            .. code-block:: console
 
                [user@dom0 /tmp] $ cd test
 
-       - .. code:: console
+       - .. code-block:: console
 
             [user@dom0 /tmp] $ cd test
 
@@ -701,7 +701,7 @@ Writing command-line examples
 
    **Don’t try to add comments inside the code block**. For example, *don’t* do this:
 
-   .. code:: console
+   .. code-block:: console
 
       # Navigate to the new directory
       $ cd test
@@ -717,7 +717,7 @@ Variable names in commands
 
 **Syntactically distinguish variables in commands**. For example, this is ambiguous:
 
-.. code:: console
+.. code-block:: console
 
      $ qvm-run --dispvm=disposable-template --service qubes.StartApp+xterm
 
@@ -725,7 +725,7 @@ Variable names in commands
 
 It should instead be:
 
-.. code:: console
+.. code-block:: console
 
      $ qvm-run --dispvm=<DISPOSABLE_TEMPLATE> --service qubes.StartApp+xterm
 
@@ -832,7 +832,7 @@ Cheatsheet: Headings
 
    * - Markdown markup
      - reStructuredText markup
-   * - .. code:: markdown
+   * - .. code-block:: markdown
 
           [...]
           # Title
@@ -847,7 +847,7 @@ Cheatsheet: Headings
           #### Paragraph
           [...]
 
-     - .. code:: rst
+     - .. code-block:: rst
 
         =====
         Title
@@ -872,35 +872,35 @@ Cheatsheet: Hyperlinks and cross-references
    * - Markdown markup
      - reStructuredText markup
 
-   * - .. code:: markdown
+   * - .. code-block:: markdown
 
           [Link Text](/doc/path/to/some-file)
 
-     - .. code:: rst
+     - .. code-block:: rst
 
           :doc:`/path/to/some-file`
 
-   * - .. code:: markdown
+   * - .. code-block:: markdown
 
           [Link Text](/doc/path/to/some-file#some-title)
 
-     - .. code:: rst
+     - .. code-block:: rst
 
           :ref:`/path/to/some-file:Some title`
 
-   * - .. code:: markdown
+   * - .. code-block:: markdown
 
           a [qube](/doc/glossary#qube)
 
-     - .. code:: rst
+     - .. code-block:: rst
 
           :term:`qube`
 
-   * - .. code:: markdown
+   * - .. code-block:: markdown
 
           [Link Text](http://example.com)
 
-     - .. code:: rst
+     - .. code-block:: rst
 
           `Link Text <http://example.com>`__
 
@@ -914,31 +914,31 @@ Cheatsheet: Text Decorations
    * - Markdown markup
      - reStructuredText markup
 
-   * - .. code:: markdown
+   * - .. code-block:: markdown
 
          *Italic* or _Italic_
 
-     - .. code:: rst
+     - .. code-block:: rst
 
         *Italic*
 
-   * - .. code:: markdown
+   * - .. code-block:: markdown
 
           **Bold** or __Bold__
 
-     - .. code:: rst
+     - .. code-block:: rst
 
           **Bold**
 
-   * - .. code:: markdown
+   * - .. code-block:: markdown
 
           ~~Strikethrough~~
 
-     - .. code:: rst
+     - .. code-block:: rst
 
           :strike:`Strikethrough`
 
-   * - .. code:: markdown
+   * - .. code-block:: markdown
 
           ***Bold and italic***
 
@@ -960,7 +960,7 @@ Cheatsheet: Lists
    * - Markdown markup
      - reStructuredText markup
 
-   * - .. code:: markdown
+   * - .. code-block:: markdown
 
           - Item 1
           - Item 2
@@ -972,7 +972,7 @@ Cheatsheet: Lists
              a. Subitem 1
              b. Subitem 2
 
-     - .. code:: rst
+     - .. code-block:: rst
 
           - Item 1
           - Item 2
@@ -998,14 +998,14 @@ Cheatsheet: Tables
    * - Markdown markup
      - reStructuredText markup
 
-   * - .. code:: markdown
+   * - .. code-block:: markdown
 
           | Header 1 | Header 2 |
           |----------|----------|
           | Cell 1   | Cell 2   |
           | Cell 3   | Cell 4   |
 
-     - .. code:: rst
+     - .. code-block:: rst
 
           .. list-table::
              :widths: 10 10
@@ -1032,14 +1032,14 @@ Cheatsheet: Code Blocks
    * - Markdown markup
      - reStructuredText markup
 
-   * - .. code:: markdown
+   * - .. code-block:: markdown
 
           ```python
           print("Hello, world!")
           ```
-     - .. code:: rst
+     - .. code-block:: rst
 
-          .. code:: python
+          .. code-block:: python
 
               print("Hello, world!")
 
@@ -1057,14 +1057,14 @@ Alerts and Warnings
    * - Markdown markup
      - reStructuredText markup
 
-   * - .. code:: markdown
+   * - .. code-block:: markdown
 
           <div class="alert alert-info" role="alert">
             <i class="fa fa-info-circle"></i>
             <b>Note:</b> This is a note
           </div>
 
-     - .. code:: rst
+     - .. code-block:: rst
 
           .. note::
 
@@ -1091,7 +1091,7 @@ List of the roles used in documentation
 
    * - `:guilabel: <https://www.sphinx-doc.org/en/master/usage/restructuredtext/roles.html#role-guilabel>`__
 
-     - .. code:: rst
+     - .. code-block:: rst
 
         :guilabel:`&Apply`
 
@@ -1099,7 +1099,7 @@ List of the roles used in documentation
 
    * - `:file: <https://www.sphinx-doc.org/en/master/usage/restructuredtext/roles.html#role-file>`__
 
-     - .. code:: rst
+     - .. code-block:: rst
 
         :file:`~/QubesIncoming/disp{XXXX}`
 
@@ -1107,7 +1107,7 @@ List of the roles used in documentation
 
    * - `:program: <https://www.sphinx-doc.org/en/master/usage/restructuredtext/roles.html#role-program>`__
 
-     - .. code:: rst
+     - .. code-block:: rst
 
         :program:`qvm-copy`
 
@@ -1115,7 +1115,7 @@ List of the roles used in documentation
 
    * - `:menuselection: <https://www.sphinx-doc.org/en/master/usage/restructuredtext/roles.html#role-menuselection>`__
 
-     - .. code:: rst
+     - .. code-block:: rst
 
         :menuselection:`Settings --> &Advanced`
 
@@ -1123,7 +1123,7 @@ List of the roles used in documentation
 
    * - `:samp: <https://www.sphinx-doc.org/en/master/usage/restructuredtext/roles.html#role-samp>`__
 
-     - .. code:: rst
+     - .. code-block:: rst
 
         :samp:`disp{XXXX}`
 
@@ -1131,7 +1131,7 @@ List of the roles used in documentation
 
    * - `:kbd: <https://www.sphinx-doc.org/en/master/usage/restructuredtext/roles.html#role-kbd>`__
 
-     - .. code:: rst
+     - .. code-block:: rst
 
         :kbd:`Ctrl`
 
@@ -1139,7 +1139,7 @@ List of the roles used in documentation
 
    * - `:abbr: <https://www.sphinx-doc.org/en/master/usage/referencing.html#role-abbr>`__
 
-     - .. code:: rst
+     - .. code-block:: rst
 
         :abbr:`OCR (Optical Character Recognition)`
 
@@ -1147,7 +1147,7 @@ List of the roles used in documentation
 
    * - `:code: <https://www.sphinx-doc.org/en/master/usage/referencing.html#role-code>`__
 
-     - .. code:: rst
+     - .. code-block:: rst
 
           :code:`qvm-ls --help`
 
@@ -1155,7 +1155,7 @@ List of the roles used in documentation
 
    * - `:mimetype: <https://www.sphinx-doc.org/en/master/usage/referencing.html#role-mimetype>`__
 
-     - .. code:: rst
+     - .. code-block:: rst
 
         :mimetype:`application/pdf`
 
diff --git a/developer/general/usability-ux.rst b/developer/general/usability-ux.rst
index c3f9515e87..f428d8fb3a 100644
--- a/developer/general/usability-ux.rst
+++ b/developer/general/usability-ux.rst
@@ -124,7 +124,7 @@ By using the same term throughout an interface, a user can create a mental model
 
 It is easy to add words like ``Domain`` before items in a list or menu in an attempt to be descriptive, such as:
 
-.. code:: text
+.. code-block:: text
 
       Menu
       - Domain: work
@@ -137,7 +137,7 @@ The repeated use of the word ``Domain`` requires a user to read it for each item
 
 It is more efficient to group things under headings instead as this allows the eye to easily scan the uniqueness of the items. (As per our previous example:)
 
-.. code:: text
+.. code-block:: text
 
       Domains
       - Work
diff --git a/developer/general/website-style-guide.rst b/developer/general/website-style-guide.rst
index 3e6c923d42..54e969c490 100644
--- a/developer/general/website-style-guide.rst
+++ b/developer/general/website-style-guide.rst
@@ -39,7 +39,7 @@ Indentation example
 
 Here’s an example that follows the indentation rules:
 
-.. code:: html
+.. code-block:: html
 
       <table>
         <tr>
@@ -97,7 +97,7 @@ Image linking
 
 To add an image to a page, use the following syntax in the main document.
 
-.. code:: markdown
+.. code-block:: markdown
 
   [![Image Title](/attachment/doc/image.png)](/attachment/doc/image.png)
 
@@ -143,7 +143,7 @@ Do not use Markdown syntax for styling
 
 For example, there is a common temptation to use block quotations (created by beginning lines with the ``>`` character) in order to stylistically distinguish some portion of text from the rest of the document, e.g.:
 
-.. code:: markdown
+.. code-block:: markdown
 
       > **Note:** This is an important note!
 
@@ -163,7 +163,7 @@ There are two problems with this:
 
 Instead, an example of an appropriate way to stylistically distinguish a portion of text is by using :ref:`developer/general/website-style-guide:alerts`. Consider also that extra styling and visual distinction may not even be necessary. In most cases, traditional writing methods are perfectly sufficient, e.g.,:
 
-.. code:: markdown
+.. code-block:: markdown
 
       **Note:** This is an important note.
 
@@ -177,7 +177,7 @@ Alerts
 
 Alerts are sections of HTML used to draw the reader’s attention to important information, such as warnings, and for stylistic purposes. They are typically styled as colored text boxes, usually accompanied by icons. Alerts should generally be used somewhat sparingly, so as not to cause `alert fatigue <https://en.wikipedia.org/wiki/Alarm_fatigue>`__ and since they must be written in HTML instead of Markdown, which makes the source less readable and more difficult to work with for localization and automation purposes. Here are examples of several types of alerts and their recommended icons:
 
-.. code:: html
+.. code-block:: html
 
       <div class="alert alert-success" role="alert">
         <i class="fa fa-check-circle"></i>
@@ -230,7 +230,7 @@ When providing command-line examples:
 
 - Tell the reader where to open a terminal (dom0 or a specific domU), and show the command along with its output (if any) in a code block, e.g.:
 
-  .. code:: markdown
+  .. code-block:: markdown
 
         Open a terminal in dom0 and run:
         ```
@@ -242,7 +242,7 @@ When providing command-line examples:
 - Precede each command with the appropriate command prompt: At a minimum, the prompt should contain a trailing ``#`` (for the user ``root``) or ``$`` (for other users) on Linux systems and ``>`` on Windows systems, respectively.
 - Don’t try to add comments inside the code block. For example, *don’t* do this:
 
-  .. code:: markdown
+  .. code-block:: markdown
 
         Open a terminal in dom0 and run:
         ```
diff --git a/developer/releases/1_0/release-notes.rst b/developer/releases/1_0/release-notes.rst
index 1fd7d45f4d..1aa1aeca10 100644
--- a/developer/releases/1_0/release-notes.rst
+++ b/developer/releases/1_0/release-notes.rst
@@ -17,7 +17,7 @@ Known issues
 
 - On systems with more than 8GB of RAM there is problem with DisposableVM. To fix it, limit maximum memory allocation for DispVM to 3GB
 
-  .. code:: console
+  .. code-block:: console
 
         $ qvm-prefs -s fedora-17-x64-dvm maxmem 3072
         $ qvm-create-default-dvm --default-template --default-script
@@ -56,7 +56,7 @@ From Qubes 1.0 Beta 3
 
 If you have Qubes Beta 3 currently installed on your system, you must reinstall from scratch, as we offer no direct upgrade option in the installer (sorry). However, we do offer tools for smooth migration of your AppVMs. In order to do that, please backup your AppVMs using the ``qvm-backup`` tool :doc:`as usual </user/how-to-guides/how-to-back-up-restore-and-migrate>`. Then, after you install Qubes 1.0 rc1, you can restore them using ``qvm-backup-restore`` tool. However, because we have changed the default template in RC1, you should tell qvm-back-restore about that by passing ``--replace-template`` option:
 
-.. code:: console
+.. code-block:: console
 
       $ qvm-backup-restore <backup_dir> --replace-template=fedora-15-x64:fedora-17-x64
 
diff --git a/developer/releases/4_0/release-notes.rst b/developer/releases/4_0/release-notes.rst
index f7739a0821..eb62aa8afd 100644
--- a/developer/releases/4_0/release-notes.rst
+++ b/developer/releases/4_0/release-notes.rst
@@ -65,7 +65,7 @@ Security Notes
 
   3. In the window that opens, enter this command:
 
-     .. code:: console
+     .. code-block:: console
 
            $ sudo nano /etc/yum.repos.d/qubes-dom0.repo
 
@@ -86,7 +86,7 @@ Security Notes
 
   3. In the window that opens, enter the command for your version:
 
-     .. code:: console
+     .. code-block:: console
 
            [Qubes 3.2] $ sudo gedit /etc/yum.repos.d/qubes-r3.repo
            [Qubes 4.0] $ sudo gedit /etc/yum.repos.d/qubes-r4.repo
diff --git a/developer/releases/4_2/release-notes.rst b/developer/releases/4_2/release-notes.rst
index 3c431b1efc..269f443ff6 100644
--- a/developer/releases/4_2/release-notes.rst
+++ b/developer/releases/4_2/release-notes.rst
@@ -91,7 +91,7 @@ Notes
 
   - Users who wish to opt for the more restrictive 4.2.0 and 4.2.1 behavior can do so by modifying their RPC policy rules. To switch a single rule to the more restrictive behavior, change ``*`` in the argument column to ``+`` (i.e., change “any argument” to “only empty”). To use the more restrictive behavior globally, add the following “deny” rule before all other relevant rules:
 
-    .. code:: text
+    .. code-block:: text
 
           qubes.Filecopy    +allow-all-names    @anyvm    @anyvm    deny
 
diff --git a/developer/services/admin-api.rst b/developer/services/admin-api.rst
index 30cb17a769..fe6d310d1a 100644
--- a/developer/services/admin-api.rst
+++ b/developer/services/admin-api.rst
@@ -762,7 +762,7 @@ Not all settings needs to be set.
 
 Example backup profile:
 
-.. code:: yaml
+.. code-block:: yaml
 
    # Backup only selected VMs
    include:
@@ -780,7 +780,7 @@ Example backup profile:
 
 And slightly more advanced one:
 
-.. code:: yaml
+.. code-block:: yaml
 
    # Include all VMs with a few exceptions
    include:
diff --git a/developer/services/qrexec-internals.rst b/developer/services/qrexec-internals.rst
index 11fa684541..19c16f7c15 100644
--- a/developer/services/qrexec-internals.rst
+++ b/developer/services/qrexec-internals.rst
@@ -109,7 +109,7 @@ Qrexec protocol details
 
 The qrexec protocol is message-based. All messages share a common header followed by an optional data packet.
 
-.. code:: c
+.. code-block:: c
 
       /* uniform for all peers, data type depends on message type */
       struct msg_header {
@@ -120,7 +120,7 @@ The qrexec protocol is message-based. All messages share a common header followe
 
 When two peers establish connection, the server sends ``MSG_HELLO`` followed by ``peer_info`` struct:
 
-.. code:: c
+.. code-block:: c
 
       struct peer_info {
          uint32_t version; /* qrexec protocol version */
@@ -142,7 +142,7 @@ dom0: request execution of ``cmd`` in domX
 
 - **dom0**: ``qrexec-client`` is invoked in **dom0** as follows:
 
-  .. code:: console
+  .. code-block:: console
 
         $ qrexec-client -d domX [-l local_program] user:cmd
 
@@ -189,7 +189,7 @@ domX: request execution of service ``admin.Service`` in dom0
 
 - **domX**: ``qrexec-client-vm`` is invoked as follows:
 
-  .. code:: console
+  .. code-block:: console
 
         $ qrexec-client-vm dom0 admin.Service [local_program] [params]
 
@@ -215,7 +215,7 @@ domX: request execution of service ``admin.Service`` in dom0
 
 - **dom0**: If the RPC is allowed, ``qrexec-policy`` will launch a ``qrexec-client`` with the right command:
 
-  .. code:: console
+  .. code-block:: console
 
         $ qrexec-client -d dom0 -c domX,X,SOCKET11 "QUBESRPC admin.Service domX name dom0"
 
@@ -258,7 +258,7 @@ domX: invoke execution of qubes service ``qubes.Service`` in domY
 
 - **domX**: ``qrexec-client-vm`` is invoked as follows:
 
-  .. code:: console
+  .. code-block:: console
 
         $ qrexec-client-vm domY qubes.Service [local_program] [params]
 
@@ -276,7 +276,7 @@ domX: invoke execution of qubes service ``qubes.Service`` in domY
 
 - **dom0**: If the RPC is allowed, ``qrexec-policy`` will launch a ``qrexec-client`` with the right command:
 
-  .. code:: console
+  .. code-block:: console
 
         $ qrexec-client -d domY -c domX,X,SOCKET11 user:cmd "DEFAULT:QUBESRPC qubes.Service domX"
 
diff --git a/developer/services/qrexec-socket-services.rst b/developer/services/qrexec-socket-services.rst
index a4a10805f9..0906a5fd37 100644
--- a/developer/services/qrexec-socket-services.rst
+++ b/developer/services/qrexec-socket-services.rst
@@ -15,7 +15,7 @@ When a Qubes RPC service is invoked, qrexec searches for a file that handles it
 
 Before passing user input, the socket service will receive a null-terminated service descriptor, i.e. the part after ``QUBESRPC``. When running in a VM, this is:
 
-.. code:: text
+.. code-block:: text
 
       <service_name> <source>\0
 
@@ -23,7 +23,7 @@ Before passing user input, the socket service will receive a null-terminated ser
 
 When running in dom0, it is:
 
-.. code:: text
+.. code-block:: text
 
       <service_name> <source> <target_type> <target>\0
 
@@ -81,7 +81,7 @@ Systemd unit files
 
 **/lib/systemd/user/qubes-qrexec-policy-agent.service**: This is the service configuration.
 
-.. code:: systemd
+.. code-block:: systemd
 
       [Unit]
       Description=Qubes remote exec policy agent
@@ -100,7 +100,7 @@ Systemd unit files
 
 **/lib/systemd/user/qubes-qrexec-policy-agent.socket**: This is the socket file that will activate the service.
 
-.. code:: systemd
+.. code-block:: systemd
 
       [Unit]
       Description=Qubes remote exec policy agent socket
@@ -120,7 +120,7 @@ Note the ``ConditionUser`` and ``ConditionGroup`` that ensure that the socket an
 
 Start the socket using ``systemctl --user start``. Enable it using ``systemctl --user enable``, so that it starts automatically.
 
-.. code:: console
+.. code-block:: console
 
       $ systemctl --user start qubes-qrexec-policy-agent.socket
       $ systemctl --user enable qubes-qrexec-policy-agent.socket
@@ -129,7 +129,7 @@ Start the socket using ``systemctl --user start``. Enable it using ``systemctl -
 
 Alternatively, you can enable the service by creating a symlink:
 
-.. code:: console
+.. code-block:: console
 
       $ sudo ln -s /lib/systemd/user/qubes-qrexec-policy-agent.socket /lib/systemd/user/sockets.target.wants/
 
@@ -141,7 +141,7 @@ Link in qubes-rpc
 
 ``qrexec-policy-agent`` will handle a Qubes RPC service called ``policy.Ask``, so we add a link:
 
-.. code:: console
+.. code-block:: console
 
       $ sudo ln -s /var/run/qubes/policy-agent.sock /etc/qubes-rpc/policy.Ask
 
@@ -155,7 +155,7 @@ Socket activation in systemd works by starting our program with the socket file
 
 Install the Python systemd library:
 
-.. code:: console
+.. code-block:: console
 
       $ sudo dnf install python3-systemd
 
@@ -163,7 +163,7 @@ Install the Python systemd library:
 
 Here is the server code:
 
-.. code:: python
+.. code-block:: python
 
       import os
       import asyncio
@@ -236,7 +236,7 @@ Using the service
 
 The service is invoked in the same way as a standard Qubes RPC service:
 
-.. code:: console
+.. code-block:: console
 
       $ echo <input_data> | qrexec-client -d domX 'DEFAULT:QUBESRPC policy.Ask'
 
@@ -244,7 +244,7 @@ The service is invoked in the same way as a standard Qubes RPC service:
 
 You can also connect to it locally, but remember to include the service descriptor:
 
-.. code:: console
+.. code-block:: console
 
       $ echo -e 'policy.Ask dom0\0<input data>' | nc -U /etc/qubes-rpc/policy.Ask
 
diff --git a/developer/services/qrexec.rst b/developer/services/qrexec.rst
index 88b9c213ad..0f4962c1af 100644
--- a/developer/services/qrexec.rst
+++ b/developer/services/qrexec.rst
@@ -18,7 +18,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:: console
+.. code-block:: console
 
       $ qrexec-client -e -d someVM user:'touch hello-world.txt'
 
@@ -26,7 +26,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:: console
+.. code-block:: console
 
       $ qrexec-client -d someVM user:bash
 
@@ -65,7 +65,7 @@ Policy files
 
 Policies are defined in lines with the following format:
 
-.. code:: text
+.. code-block:: text
 
       service-name|* +argument|* source destination action  [options]
 
@@ -83,7 +83,7 @@ Making an RPC call
 
 From outside of dom0, RPC calls take the following form:
 
-.. code:: console
+.. code-block:: console
 
       $ qrexec-client-vm target_vm_name RPC_ACTION_NAME rpc_client_path client arguments
 
@@ -91,7 +91,7 @@ From outside of dom0, RPC calls take the following form:
 
 For example:
 
-.. code:: console
+.. code-block:: console
 
       $ qrexec-client-vm work qubes.StartApp+firefox
 
@@ -101,7 +101,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:: console
+.. code-block:: console
 
       $ qrexec-client-vm target_vm_name RPC_ACTION_NAME
 
@@ -132,7 +132,7 @@ There are severals methods for specifying source/target VMs in RPC policies.
 
 Target VM can be also specified as ``@default``, which matches the case when calling VM didn’t specified any particular target (either by using ``@default`` target, or empty target). For DisposableVMs, ``@dispvm:DISP_VM`` is very similar to ``@dispvm`` but forces using a particular VM (``DISP_VM``) as a base VM to be started as DisposableVM. For example:
 
-.. code:: text
+.. code-block:: text
 
       * * anon-whonix @dispvm:anon-whonix-dvm allow
 
@@ -140,7 +140,7 @@ Target VM can be also specified as ``@default``, which matches the case when cal
 
 Adding such policy itself will not force usage of this particular ``DISP_VM`` - it will only allow it when specified by the caller. But ``@dispvm:DISP_VM`` can also be used as target in request redirection, so *it is possible* to force particular ``DISP_VM`` usage, when caller didn’t specify it:
 
-.. code:: text
+.. code-block:: text
 
       * * anon-whonix @dispvm allow target=@dispvm:anon-whonix-dvm
 
@@ -150,7 +150,7 @@ Note that without redirection, this rule would allow using default Disposable VM
 
 The policy confirmation dialog (``ask`` action) allows the user to specify target VM. User can choose from VMs that, according to policy, would lead to ``ask`` or ``allow`` actions. It is not possible to select VM that policy would deny. By default no VM is selected, even if the caller provided some, but policy can specify default value using ``default_target=`` parameter. For example:
 
-.. code:: text
+.. code-block:: text
 
       * * work-mail work-archive allow
       * * work-mail @tag:work ask default_target=work-files
@@ -168,7 +168,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:: console
+.. code-block:: console
 
       $ qvm-run --dispvm=work firefox
 
@@ -176,7 +176,7 @@ For example, this command will run the ``firefox`` command in a DisposableVM bas
 
 By contrast, consider this command:
 
-.. code:: console
+.. code-block:: console
 
       $ qvm-run --dispvm=work --service qubes.StartApp+firefox
 
@@ -194,7 +194,7 @@ For this reason it is possible to specify a service argument, which will be subj
 
 The argument is specified in the second column of the policy line, as +ARGUMENT. If the policy uses “*” as an argument, then it will match any argument (including no argument). As rules are processed in order, any lines with a specific argument below the line with the wildcard argument will be ignored. So for instance, we might have policies which are different depending on the argument:
 
-.. code:: text
+.. code-block:: text
 
       Device +device1 * * allow
       Device +device2 * * deny
@@ -204,7 +204,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:: console
+.. code-block:: console
 
       $ qrexec-client-vm target_vm_name RPC_ACTION_NAME+ARGUMENT
 
@@ -226,7 +226,7 @@ Simple RPC service (addition)
 
 We can create an RPC service that adds two integers in a target domain (the server, call it “anotherVM”) and returns back the result to the invoker (the client, “someVM”). In someVM, create a file with the following contents and save it with the path ``/usr/bin/our_test_add_client``:
 
-.. code:: bash
+.. code-block:: bash
 
       #!/bin/sh
       echo $1 $2             # pass data to RPC server
@@ -236,7 +236,7 @@ We can create an RPC service that adds two integers in a target domain (the serv
 
 Our server will be anotherVM at ``/usr/bin/our_test_add_server``. The code for this file is:
 
-.. code:: bash
+.. code-block:: bash
 
       #!/bin/sh
       read arg1 arg2        # read from stdin, which is received from the RPC client
@@ -246,7 +246,7 @@ Our server will be anotherVM at ``/usr/bin/our_test_add_server``. The code for t
 
 We’ll need to create a service called ``test.Add`` with its own definition and policy file in dom0. Now we need to define what the service does. In this case, it should call our addition script. We define the service with a symlink at ``/etc/qubes-rpc/test.Add`` pointing to our server script (the script can be also placed directly in ``/etc/qubes-rpc/test.Add`` - make sure the file has executable bit set!):
 
-.. code:: console
+.. code-block:: console
 
       $ ln -s /usr/bin/our_test_add_server /etc/qubes-rpc/test.Add
 
@@ -254,7 +254,7 @@ We’ll need to create a service called ``test.Add`` with its own definition and
 
 The administrative domain will direct traffic based on the current RPC policies. In dom0, create a file at ``/etc/qubes/policy.d/30-test.policy`` containing the following:
 
-.. code:: text
+.. code-block:: text
 
       test.Add * * * ask
 
@@ -264,7 +264,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:: console
+.. code-block:: console
 
       $ qrexec-client-vm anotherVM test.Add /usr/bin/our_test_add_client 1 2
 
@@ -284,7 +284,7 @@ First, on your target VM, create two files in the home directory: ``testfile1``
 
 Next, we define the RPC service. On the target VM, place the code below at ``/etc/qubes-rpc/test.File``:
 
-.. code:: bash
+.. code-block:: bash
 
       #!/bin/sh
       argument="$1" # service argument, also available as $QREXEC_SERVICE_ARGUMENT
@@ -300,7 +300,7 @@ Make sure the file is executable! (The service argument is already sanitized by
 
 Now we create the policy file in dom0, at ``/etc/qubes/policy.d/30-test.policy``. The contents of the file are below. Replace “source_vm1” and others with the names of your own chosen domains.
 
-.. code:: text
+.. code-block:: text
 
       test.File +testfile1 source_vm1 target_vm allow
       test.File +testfile2 source_vm2 target_vm allow
@@ -310,7 +310,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:: console
+.. code-block:: console
 
       [user@source_vm1] $ qrexec-client-vm target_vm test.File+testfile1
 
@@ -318,7 +318,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:: console
+.. code-block:: console
 
       [user@source_vm2] $ qrexec-client-vm target_vm test.File+testfile1
       Request refused
diff --git a/developer/services/qrexec2.rst b/developer/services/qrexec2.rst
index f49dfdda6e..86ab8497d5 100644
--- a/developer/services/qrexec2.rst
+++ b/developer/services/qrexec2.rst
@@ -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:: console
+.. code-block:: console
 
       [user@dom0 ~]$ /usr/lib/qubes/qrexec-client -d <vm name> user:bash
 
@@ -54,7 +54,7 @@ Besides each VM needing to provide explicit programs to serve each supported ser
 
 In dom0, there is a bunch of files in ``/etc/qubes-rpc/policy/`` directory, whose names describe the available RPC actions; their content is the RPC access policy database. Some example of the default services in Qubes are:
 
-.. code:: text
+.. code-block:: text
 
       qubes.Filecopy
       qubes.OpenInVM
@@ -70,7 +70,7 @@ In dom0, there is a bunch of files in ``/etc/qubes-rpc/policy/`` directory, whos
 
 These files contain lines with the following format:
 
-.. code:: text
+.. code-block:: text
 
       srcvm destvm (allow|deny|ask)[,user=user_to_run_as][,target=VM_to_redirect_to]
 
@@ -88,7 +88,7 @@ Requesting VM-VM (and VM-Dom0) services execution
 
 In a src VM, one should invoke the qrexec client via the following command:
 
-.. code:: console
+.. code-block:: console
 
       $ /usr/lib/qubes/qrexec-client-vm <target vm name> <service name> <local program path> [local program arguments]
 
@@ -112,7 +112,7 @@ Qubes RPC policy supports an “ask” action, that will prompt the user whether
 
 In order to remove such authorization, issue this command from a Dom0 terminal (example below for ``qubes.Filecopy`` service):
 
-.. code:: console
+.. code-block:: console
 
       $ sudo nano /etc/qubes-rpc/policy/qubes.Filecopy
 
@@ -129,7 +129,7 @@ We will show the necessary files to create a simple RPC call that adds two integ
 
 - Client code on source VM (``/usr/bin/our_test_add_client``)
 
-  .. code:: bash
+  .. code-block:: bash
 
         #!/bin/sh
         echo $1 $2    # pass data to rpc server
@@ -138,7 +138,7 @@ We will show the necessary files to create a simple RPC call that adds two integ
 
 - Server code on target VM (``/usr/bin/our_test_add_server``)
 
-  .. code:: bash
+  .. code-block:: bash
 
         #!/bin/sh
         read arg1 arg2 # read from stdin, which is received from the rpc client
@@ -147,14 +147,14 @@ 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:: text
+  .. code-block:: text
 
         $anyvm $anyvm ask
 
 
 - Server path definition on target VM (``/etc/qubes-rpc/test.Add``)
 
-  .. code:: text
+  .. code-block:: text
 
         /usr/bin/our_test_add_server
 
@@ -162,7 +162,7 @@ We will show the necessary files to create a simple RPC call that adds two integ
 
 - To test this service, run the following in the source VM:
 
-  .. code:: console
+  .. code-block:: console
 
         $ /usr/lib/qubes/qrexec-client-vm <target VM> test.Add /usr/bin/our_test_add_client 1 2
 
diff --git a/developer/system/gui.rst b/developer/system/gui.rst
index 9c3c76e331..b3989c2325 100644
--- a/developer/system/gui.rst
+++ b/developer/system/gui.rst
@@ -102,7 +102,7 @@ Window manager hints and flags are described in the `Extended Window Manager Hin
 
 Each message starts with the following header:
 
-.. code:: c
+.. code-block:: c
 
    struct msghdr {
        uint32_t type;
@@ -132,7 +132,7 @@ This header is followed by message-specific data:
           - Store the received clipboard content (not parsed in any way)
 
         * - MSG_CREATE
-          - .. code:: c
+          - .. code-block:: c
 
                    struct msg_create {
                      uint32_t x;
@@ -149,7 +149,7 @@ This header is followed by message-specific data:
           - Destroy a window
 
         * - MSG_MAP
-          - .. code:: c
+          - .. code-block:: c
 
                    struct msg_map_info {
                      uint32_t transient_for;
@@ -163,7 +163,7 @@ This header is followed by message-specific data:
           - Unmap a window
 
         * - MSG_CONFIGURE
-          - .. code:: c
+          - .. code-block:: c
 
                    struct msg_configure {
                      uint32_t x;
@@ -176,7 +176,7 @@ This header is followed by message-specific data:
           - Change window position/size/type
 
         * - MSG_MFNDUMP
-          - .. code:: c
+          - .. code-block:: c
 
                    struct shm_cmd {
                      uint32_t shmid;
@@ -194,7 +194,7 @@ This header is followed by message-specific data:
             The “num_mfn” 32bit integers follow the shm_cmd structure; “off” is the offset of the composite buffer start in the first frame; “shmid” and “domid” parameters are just placeholders (to be filled by ``qubes-guid``), so that we can use the same structure when talking to ``shmoverride.so``.
 
         * - MSG_SHMIMAGE
-          - .. code:: c
+          - .. code-block:: c
 
                    struct msg_shmimage {
                         uint32_t x;
@@ -206,7 +206,7 @@ This header is followed by message-specific data:
           - Repaint the given window fragment
 
         * - MSG_WMNAME
-          - .. code:: c
+          - .. code-block:: c
 
                    struct msg_wmname {
                      char data[128];
@@ -219,7 +219,7 @@ This header is followed by message-specific data:
           - Dock the window in the tray
 
         * - MSG_WINDOW_HINTS
-          - .. code:: c
+          - .. code-block:: c
 
                    struct msg_window_hints {
                         uint32_t flags;
@@ -236,7 +236,7 @@ This header is followed by message-specific data:
           - Size hints for window manager
 
         * - MSG_WINDOW_FLAGS
-          - .. code:: c
+          - .. code-block:: c
 
                    struct msg_window_flags {
                         uint32_t flags_set;
@@ -246,7 +246,7 @@ This header is followed by message-specific data:
           - Change window state request; fields contains bitmask which flags request to be set and which unset
 
         * - MSG_CURSOR
-          - .. code:: c
+          - .. code-block:: c
 
                    struct msg_cursor {
                         uint32_t cursor;
@@ -255,7 +255,7 @@ This header is followed by message-specific data:
           - Update cursor pointer for a window. Supported cursor IDs are default cursor (0) and `X Font cursors <https://tronche.com/gui/x/xlib/appendix/b/>`__ (with 0x100 bit set).
 
         * - MSG_WMCLASS
-          - .. code:: c
+          - .. code-block:: c
 
                    struct msg_wmclass {
                        char res_class[64];
@@ -265,7 +265,7 @@ This header is followed by message-specific data:
           - Set the WM_CLASS property of a window.
 
         * - MSG_WINDOW_DUMP
-          - .. code:: c
+          - .. code-block:: c
 
                    struct msg_window_dump_hdr {
                        uint32_t type;
@@ -276,7 +276,7 @@ This header is followed by message-specific data:
 
           - Header for shared memory dump command of type hdr.type. Currently only ``WINDOW_DUMP_TYPE_GRANT_REFS``  (0) is supported.
         * -     WINDOW_DUMP_TYPE_GRANT_REFS
-          -     .. code:: c
+          -     .. code-block:: c
 
                     struct msg_window_dump_grant_refs {
                         uint32_t refs[0];
@@ -295,7 +295,7 @@ Proper handling of the below messages is NOT security-critical.
 
 Each message starts with the following header
 
-.. code:: c
+.. code-block:: c
 
    struct msghdr {
            uint32_t type;
@@ -314,7 +314,7 @@ The header is followed by message-specific data:
           - Action
 
         * - MSG_KEYPRESS
-          - .. code:: c
+          - .. code-block:: c
 
                    struct msg_keypress {
                      uint32_t type;
@@ -327,7 +327,7 @@ The header is followed by message-specific data:
           - Tell ``qubes_drv`` driver to generate a keypress
 
         * - MSG_BUTTON
-          - .. code:: c
+          - .. code-block:: c
 
                    struct msg_button {
                      uint32_t type;
@@ -340,7 +340,7 @@ The header is followed by message-specific data:
           - Tell   ``qubes_drv``  driver to generate mouseclick
 
         * - MSG_MOTION
-          - .. code:: c
+          - .. code-block:: c
 
                    struct msg_motion {
                      uint32_t x;
@@ -351,7 +351,7 @@ The header is followed by message-specific data:
 
           - Tell  ``qubes_drv``  driver to generate motion event
         * - MSG_CONFIGURE
-          - .. code:: c
+          - .. code-block:: c
 
                    struct msg_configure {
                      uint32_t x;
@@ -364,7 +364,7 @@ The header is followed by message-specific data:
           - Change window position/size/type
 
         * - MSG_MAP
-          - .. code:: c
+          - .. code-block:: c
 
                    struct msg_map_info {
                      uint32_t transient_for;
@@ -378,7 +378,7 @@ The header is followed by message-specific data:
           - send wmDeleteMessage to the window
 
         * - MSG_CROSSING
-          - .. code:: c
+          - .. code-block:: c
 
                    struct msg_crossing {
                      uint32_t type;
@@ -394,7 +394,7 @@ The header is followed by message-specific data:
 
         * - MSG_FOCUS
 
-          - .. code:: c
+          - .. code-block:: c
 
               struct msg_focus {
                 uint32_t type;
@@ -421,7 +421,7 @@ The header is followed by message-specific data:
           - Synchronize the keyboard state (key pressed/released) with dom0
 
         * - MSG_WINDOW_FLAGS
-          - .. code:: c
+          - .. code-block:: c
 
               struct msg_window_flags {
                 uint32_t flags_set;
diff --git a/developer/system/networking.rst b/developer/system/networking.rst
index 8ea92ab7f5..b3f1fcebad 100644
--- a/developer/system/networking.rst
+++ b/developer/system/networking.rst
@@ -119,7 +119,7 @@ IPv6
 
 Starting with Qubes 4.0, there is opt-in support for IPv6 forwarding. Similar to the IPv4, traffic is routed and NAT is applied at each network gateway. This way we avoid reconfiguring every connected qube whenever uplink connection is changed, and even telling the qube what that uplink is - which may be complex when VPN or other tunneling services are employed. The feature can be enabled on any network-providing qube, and will be propagated down the network tree, so every qube connected to it will also have IPv6 enabled. To enable the ``ipv6`` feature use ``qvm-features`` tool and set the value to ``1``. For example to enable it on ``sys-net``, execute in dom0:
 
-.. code:: console
+.. code-block:: console
 
       $ qvm-features sys-net ipv6 1
 
@@ -129,7 +129,7 @@ Starting with Qubes 4.0, there is opt-in support for IPv6 forwarding. Similar to
 
 It is also possible to explicitly disable IPv6 support for some qubes, even if it is connected to IPv6-providing one. This can be done by setting ``ipv6`` feature to empty value:
 
-.. code:: console
+.. code-block:: console
 
       $ qvm-features ipv4-only-qube ipv6 ''
 
diff --git a/developer/system/template-manager.rst b/developer/system/template-manager.rst
index f43f8ee165..6e4dfee0a1 100644
--- a/developer/system/template-manager.rst
+++ b/developer/system/template-manager.rst
@@ -247,7 +247,7 @@ Input
 
 Both calls accept the following format from standard input:
 
-.. code:: text
+.. code-block:: text
 
       arg1
       arg2
diff --git a/developer/system/vm-sudo.rst b/developer/system/vm-sudo.rst
index 3189d8e0f9..6a0a5dc07c 100644
--- a/developer/system/vm-sudo.rst
+++ b/developer/system/vm-sudo.rst
@@ -9,7 +9,7 @@ This page sets out the configuration changes made, with (not necessary complete)
 
 1. sudo (``/etc/sudoers.d/qubes``):
 
-   .. code:: text
+   .. code-block:: text
 
          Defaults !requiretty
          %qubes ALL=(ALL) ROLE=unconfined_r TYPE=unconfined_t NOPASSWD: ALL
@@ -26,7 +26,7 @@ This page sets out the configuration changes made, with (not necessary complete)
 
 2. PolicyKit (``/etc/polkit-1/rules.d/00-qubes-allow-all.rules``):
 
-   .. code:: text
+   .. code-block:: text
 
          //allow any action, detailed reasoning in sudoers.d/qubes
          polkit.addRule(function(action,subject) { if (subject.isInGroup("qubes")) return polkit.Result.YES; });
diff --git a/introduction/faq.rst b/introduction/faq.rst
index b3f8d3b67f..fe1c504ff9 100644
--- a/introduction/faq.rst
+++ b/introduction/faq.rst
@@ -557,7 +557,7 @@ or
 
 - Go to the sysfs (``/sys/bus/pci``), find the right device, detach it from the pciback driver and attach back to the original driver. Replace ``<BDF>`` with your device, for example ``00:1c.2``:
 
-  .. code:: console
+  .. code-block:: console
 
         $ echo 0000:<BDF> > /sys/bus/pci/drivers/pciback/unbind
         $ MODALIAS=`cat /sys/bus/pci/devices/0000:<BDF>/modalias`
@@ -584,7 +584,7 @@ For Debian:
 
 
 
-   .. code:: console
+   .. code-block:: console
 
          $ sudo apt install vlc
 
@@ -603,7 +603,7 @@ For Fedora:
 
 
 
-   .. code:: console
+   .. code-block:: console
 
          $ sudo dnf install vlc
 
@@ -686,7 +686,7 @@ I see a screen popup with SeaBios and 4 lines, last one being ``Probing EDD (edd
 
 From a ``dom0`` prompt, enter:
 
-.. code:: console
+.. code-block:: console
 
       $ qvm-prefs <HVMname> kernel ""
 
@@ -710,7 +710,7 @@ I see a "Failed to start Load Kernel Modules" message on boot
 
 The full message looks like:
 
-.. code:: output
+.. code-block:: output
 
       [FAILED] Failed to start Load Kernel Modules.
       See 'systemctl status systemd-modules-load.service' for details.
diff --git a/introduction/issue-tracking.rst b/introduction/issue-tracking.rst
index 2a31bb9a1b..363b7922ef 100644
--- a/introduction/issue-tracking.rst
+++ b/introduction/issue-tracking.rst
@@ -216,7 +216,7 @@ Use collapsible sections for long, nonessential content
 
 On GitHub, create collapsible sections in Markdown like so:
 
-.. code:: html
+.. code-block:: html
 
       <details>
       <summary>Summary goes here. This line is optional.</summary>
diff --git a/introduction/privacy.rst b/introduction/privacy.rst
index 0c801584ab..8553dcd923 100644
--- a/introduction/privacy.rst
+++ b/introduction/privacy.rst
@@ -26,7 +26,7 @@ Please refer to RTD's `privacy policy <https://docs.readthedocs.com/platform/sta
 for more information.
 As per RTD site, the TL;DR version is as follows:
 
-.. code:: text
+.. code-block:: text
 
    RTD collects information only with consent; only the minimum amount of personal information that is necessary to fulfill the purpose of the interaction with RTD;
    doesn’t sell it to third parties; and only use it as the above Privacy Policy describes.
diff --git a/introduction/statistics.rst b/introduction/statistics.rst
index bafbe11dc9..8c1de9684f 100644
--- a/introduction/statistics.rst
+++ b/introduction/statistics.rst
@@ -36,7 +36,7 @@ How are Tor users counted?
 
 We estimate the number of Tor users as a proportion of the total number of *requests* from Tor exit nodes on the assumption that the proportion of users to requests is roughly the same for both clearnet and Tor users. To be precise, the formula is:
 
-.. code:: text
+.. code-block:: text
 
       tor_users = tor_requests * (plain_users / plain_requests)
 
diff --git a/project-security/security-pack.rst b/project-security/security-pack.rst
index f74fcbe33a..81875fc848 100644
--- a/project-security/security-pack.rst
+++ b/project-security/security-pack.rst
@@ -31,7 +31,7 @@ The following example demonstrates one method of obtaining the qubes-secpack and
 
 1. Use Git to clone the qubes-secpack repo.
 
-   .. code:: console
+   .. code-block:: console
 
          $ git clone https://github.com/QubesOS/qubes-secpack.git
          Cloning into 'qubes-secpack'...
@@ -44,7 +44,7 @@ The following example demonstrates one method of obtaining the qubes-secpack and
 
 2. Import the included PGP keys. See our :ref:`project-security/security-pack:pgp key policies` for important information about these keys.
 
-   .. code:: console
+   .. code-block:: console
 
          $ gpg --import qubes-secpack/keys/*/*
          gpg: directory `/home/user/.gnupg' created
@@ -79,7 +79,7 @@ The following example demonstrates one method of obtaining the qubes-secpack and
 
 4. Verify signed Git tags.
 
-   .. code:: console
+   .. code-block:: 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:: console
+   .. code-block:: console
 
          $ cd canaries/
          $ gpg --verify canary-001-2015.txt.sig.joanna canary-001-2015.txt
@@ -129,7 +129,7 @@ History and rationale
 
 On 2013-01-05, Joanna Rutkowska announced the qubes-secpack and explained its rationale in an `email <https://groups.google.com/d/msg/qubes-devel/twkOEaMLtNI/lZyGx6_jFCEJ>`__ to the Qubes mailing lists:
 
-.. code:: text
+.. code-block:: text
 
       Hello,
 
diff --git a/project-security/security.rst b/project-security/security.rst
index c746e903d0..fa5bdbc58b 100644
--- a/project-security/security.rst
+++ b/project-security/security.rst
@@ -31,7 +31,7 @@ Reporting security issues in Qubes OS
 
 If you’ve discovered a security issue affecting Qubes OS, either directly or indirectly (e.g., the issue affects Xen in a configuration that is used in Qubes OS), then we would be more than happy to hear from you! We promise to take all reported issues seriously. If our investigation confirms that an issue affects Qubes, we will patch it within a reasonable time and release a public `Qubes security bulletin (QSB) <https://www.qubes-os.org/security/qsb/>`__ that describes the issue, discusses the potential impact of the vulnerability, references applicable patches or workarounds, and credits the discoverer. Please use the `Qubes security team PGP key <https://keys.qubes-os.org/keys/qubes-os-security-team-key.asc>`__ to encrypt your email to this address:
 
-.. code:: text
+.. code-block:: text
 
       security at qubes-os dot org
 
diff --git a/project-security/verifying-signatures.rst b/project-security/verifying-signatures.rst
index 1829c79cdf..d164f4f089 100644
--- a/project-security/verifying-signatures.rst
+++ b/project-security/verifying-signatures.rst
@@ -55,14 +55,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:: console
+  .. code-block:: 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:: console
+  .. code-block:: console
 
         $ dnf install distribution-gpg-keys
         $ gpg2 --import /usr/share/distribution-gpg-keys/qubes/*
@@ -72,14 +72,14 @@ Once you have appropriate OpenPGP software installed, there are several ways to
 
 - You can also **fetch it with GPG**:
 
-  .. code:: console
+  .. code-block:: 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:: console
+  .. code-block:: console
 
         $ gpg2 --keyserver-options no-self-sigs-only,no-import-clean --keyserver hkp://keyserver.ubuntu.com --recv-keys 0x427F11FD0FAA4B080123F01CDDFA1A3E36879494
 
@@ -97,7 +97,7 @@ Once you have appropriate OpenPGP software installed, there are several ways to
 
   Once you have the key as a file, **import it**:
 
-  .. code:: console
+  .. code-block:: console
 
         $ gpg2 --import /<PATH_TO_FILE>/qubes-master-signing-key.asc
 
@@ -110,7 +110,7 @@ So, what *should* you do? One option is to use the PGP `Web of Trust <https://en
 
 Perhaps the most common route is to rely on the key’s fingerprint, which is a string of 40 alphanumeric characters, like this:
 
-.. code:: text
+.. code-block:: text
 
       427F 11FD 0FAA 4B08 0123  F01C DDFA 1A3E 3687 9494
 
@@ -122,7 +122,7 @@ But how do you know which fingerprint is the real one? After all, :ref:`this web
 
 For the purpose of convincing yourself that you know the authentic QMSK fingerprint, spaces and capitalization don’t matter. In other words, all of these fingerprints are considered the same:
 
-.. code:: text
+.. code-block:: text
 
       427F 11FD 0FAA 4B08 0123  F01C DDFA 1A3E 3687 9494
       427f 11fd 0faa 4b08 0123  f01c ddfa 1a3e 3687 9494
@@ -135,7 +135,7 @@ Instead, what matters is that *all* the characters are present in *exactly* the
 
 However, for the purpose of *searching for*, *looking up*, or *entering* keys, spaces and capitalization can matter, depending on the software or tool you’re using. You may need to try different variations (e.g., with and without spaces). You may also sometimes see (or need to enter) the entire fingerprint prefixed with ``0x``, as in:
 
-.. code:: text
+.. code-block:: text
 
       0x427F11FD0FAA4B080123F01CDDFA1A3E36879494
       0x427f11fd0faa4b080123f01cddfa1a3e36879494
@@ -170,7 +170,7 @@ Once you’ve observed enough matching fingerprints from enough independent sour
 
 Now that you’ve imported the authentic QMSK, set its trust level to “ultimate” so that it can be used to automatically verify all the keys signed by the QMSK (in particular, RSKs).
 
-.. code:: console
+.. code-block:: console
 
       $ gpg2 --edit-key 0x427F11FD0FAA4B080123F01CDDFA1A3E36879494
       gpg (GnuPG) 1.4.18; Copyright (C) 2014 Free Software Foundation, Inc.
@@ -254,21 +254,21 @@ After you have completed these two prerequisite steps, the next step is to obtai
 
   If you wish to use one of these keys, **make sure to import it into your keyring**, e.g.:
 
-  .. code:: console
+  .. code-block:: console
 
      [user@fedora-based-qube] $ gpg2 --import /etc/pki/rpm-gpg/RPM-GPG-KEY-qubes-*
 
 
 - **Fetch it with GPG**:
 
-  .. code:: console
+  .. code-block:: console
 
         [user@any-online-qube] $ 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:: console
+  .. code-block:: console
 
         [user@any-qube] $ gpg2 --keyserver-options no-self-sigs-only,no-import-clean --import ./qubes-release-X-signing-key.asc
 
@@ -373,7 +373,7 @@ In order to do this, **we have to know the exact size, in bytes, of the original
 * **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>`__.
 * **from the ISO itself**:
 
-.. code:: console
+.. code-block:: console
 
       $ stat -c %s Qubes-RX-x86_64.iso
       8176568320
@@ -425,14 +425,14 @@ How to verify a signature on a Git tag
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 
-.. code:: console
+.. code-block:: console
 
       $ git tag -v <tag name>
 
 
 or
 
-.. code:: console
+.. code-block:: console
 
       $ git verify-tag <tag name>
 
@@ -441,14 +441,14 @@ How to verify a signature on a Git commit
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 
-.. code:: console
+.. code-block:: console
 
       $ git log --show-signature <commit ID>
 
 
 or
 
-.. code:: console
+.. code-block:: console
 
       $ git verify-commit <commit ID>
 
diff --git a/user/advanced-topics/awesomewm.rst b/user/advanced-topics/awesomewm.rst
index a4a8f9885c..5bf776dfec 100644
--- a/user/advanced-topics/awesomewm.rst
+++ b/user/advanced-topics/awesomewm.rst
@@ -24,7 +24,7 @@ Installation
 
 AwesomeWM can be installed with the standard dom0 installation mechanisms.
 
-.. code:: console
+.. code-block:: 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:: console
+.. code-block:: console
 
       $ git clone https://github.com/QubesOS/qubes-desktop-linux-awesome
 
diff --git a/user/advanced-topics/bind-dirs.rst b/user/advanced-topics/bind-dirs.rst
index 5a97b62438..f8c60adff0 100644
--- a/user/advanced-topics/bind-dirs.rst
+++ b/user/advanced-topics/bind-dirs.rst
@@ -28,7 +28,7 @@ In this example, we want to make ``/var/lib/tor`` persistent. Enter all of the f
 
 1. Make sure the directory ``/rw/config/qubes-bind-dirs.d`` exists.
 
-   .. code:: console
+   .. code-block:: console
 
          $ sudo mkdir -p /rw/config/qubes-bind-dirs.d
 
@@ -36,7 +36,7 @@ In this example, we want to make ``/var/lib/tor`` persistent. Enter all of the f
 
 2. Create the file ``/rw/config/qubes-bind-dirs.d/50_user.conf`` with root permissions, if it doesn’t already exist.
 
-   .. code:: console
+   .. code-block:: console
 
          $ sudo touch /rw/config/qubes-bind-dirs.d/50_user.conf
 
@@ -44,7 +44,7 @@ In this example, we want to make ``/var/lib/tor`` persistent. Enter all of the f
 
 3. Add a line to ``/rw/config/qubes-bind-dirs.d/50_user.conf`` that appends a folder or file to the ``binds`` variable.
 
-   .. code:: bash
+   .. code-block:: bash
 
          binds+=( '/var/lib/tor' )
 
@@ -54,7 +54,7 @@ In this example, we want to make ``/var/lib/tor`` persistent. Enter all of the f
 
 5. If the directory you wish to make persistent doesn’t exist in the template on which the app qube is based, you’ll need to create the directory (with its full path) under ``/rw/bind-dirs`` in the app qube. For example, if ``/var/lib/tor`` didn’t exist in the template, then you would execute the following command in your app qube:
 
-   .. code:: console
+   .. code-block:: console
 
          $ sudo mkdir -p /rw/bind-dirs/var/lib/tor
 
@@ -72,7 +72,7 @@ From now on, all files in the ``/var/lib/tor`` directory will persist across reb
 
 You can make as many files or folders persist as you want simply by making multiple entries in the ``50_user.conf`` file, each on a separate line. For example, if you added the file ``/etc/tor/torrc`` to the ``binds`` variable, any modifications to *that* file would also persist across reboots.
 
-.. code:: bash
+.. code-block:: bash
 
       binds+=( '/var/lib/tor' )
       binds+=( '/etc/tor/torrc' )
@@ -125,7 +125,7 @@ How to remove binds from bind-dirs.sh?
 
 ``/rw/config/qubes-bind-dirs.d/50_user.conf``
 
-.. code:: bash
+.. code-block:: bash
 
       binds=( "${binds[@]/'/var/lib/tor'}" )
 
@@ -155,7 +155,7 @@ Bind dirs are obviously still supported but this must be configured either in th
 
 To use this feature, first, enable it:
 
-.. code:: console
+.. code-block:: console
 
       $ qvm-service -e my-app-vm custom-persist
 
@@ -163,7 +163,7 @@ To use this feature, first, enable it:
 
 Then, configure a persistent directory with ``qvm-features``:
 
-.. code:: console
+.. code-block:: console
 
       $ qvm-features my-app-vm custom-persist.my_persistent_dir /var/my_persistent_dir
 
@@ -171,7 +171,7 @@ Then, configure a persistent directory with ``qvm-features``:
 
 To re-enable ``/home`` and ``/usr/local`` persistence, just add them to the list:
 
-.. code:: console
+.. code-block:: console
 
       $ qvm-features my-app-vm custom-persist.home /home
       $ qvm-features my-app-vm custom-persist.usrlocal /usr/local
@@ -182,7 +182,7 @@ When starting the VM, declared custom-persist bind dirs are automatically added
 
 A user may want their bind-dirs to be automatically pre-created in ``/rw/bind-dirs``. Custom persist can do this for you by providing the type of the resource to create (file or dir), owner, group and mode. For example:
 
-.. code:: console
+.. code-block:: console
 
       $ qvm-features my-app-vm custom-persist.downloads dir:user:user:0755:/home/user/Downloads
       $ qvm-features my-app-vm custom-persist.my_ssh_known_hosts_file file:user:user:0600:/home/user/.ssh/known_hosts
diff --git a/user/advanced-topics/config-files.rst b/user/advanced-topics/config-files.rst
index 7f41ede649..c72767426f 100644
--- a/user/advanced-topics/config-files.rst
+++ b/user/advanced-topics/config-files.rst
@@ -14,7 +14,7 @@ These files are placed in ``/rw``, which survives a VM restart. That way, they c
 
 - ``/rw/config/rc.local`` - script runs at VM startup. Good place to change some service settings, replace config files with its copy stored in ``/rw/config``, etc. The script need to have the executable permission set to be executed. Example usage:
 
-  .. code:: bash
+  .. code-block:: bash
 
         # Store bluetooth keys in /rw to keep them across VM restarts
         rm -rf /var/lib/bluetooth
@@ -22,7 +22,7 @@ These files are placed in ``/rw``, which survives a VM restart. That way, they c
 
 
 
-  .. code:: bash
+  .. code-block:: bash
 
         # Add entry to /etc/hosts
         echo '127.0.0.1 example.com' >> /etc/hosts
@@ -37,7 +37,7 @@ These files are placed in ``/rw``, which survives a VM restart. That way, they c
 
 - In ProxyVMs (or app qubes with ``qubes-firewall`` service enabled), scripts placed in the following directories will be executed in the listed order followed by ``qubes-firewall-user-script`` at start up. Good place to write custom firewall rules.
 
-  .. code:: text
+  .. code-block:: text
 
         /etc/qubes/qubes-firewall.d
         /rw/config/qubes-firewall.d
@@ -49,7 +49,7 @@ These files are placed in ``/rw``, which survives a VM restart. That way, they c
 
 - In NetVMs/ProxyVMs, scripts placed in ``/rw/config/network-hooks.d`` will be ran when configuring Qubes interfaces. For each script, the ``command``, ``vif``, ``vif_type`` and ``ip`` is passed as arguments (see ``/etc/xen/scripts/vif-route-qubes``). For example, consider a PV app qube ``work`` with IP ``10.137.0.100`` and ``sys-firewall`` as NetVM. Assuming it’s Xen domain id is arbitrary ``12`` then, the following script located at ``/rw/config/network-hooks.d/hook-100.sh`` in ``sys-firewall``:
 
-  .. code:: bash
+  .. code-block:: bash
 
         #!/bin/bash
 
@@ -84,7 +84,7 @@ GUI and audio configuration in dom0
 
 The GUI configuration file ``/etc/qubes/guid.conf`` in one of a few not managed by ``qubes-prefs`` or the Qubes Manager tool. Sample config (included in default installation):
 
-.. code::
+.. code-block::
 
       # Sample configuration file for Qubes GUI daemon
       #  For syntax go https://www.hyperrealm.com/libconfig/libconfig_manual.html
diff --git a/user/advanced-topics/disposable-customization.rst b/user/advanced-topics/disposable-customization.rst
index fef09d154d..52f0904cbf 100644
--- a/user/advanced-topics/disposable-customization.rst
+++ b/user/advanced-topics/disposable-customization.rst
@@ -49,7 +49,7 @@ Open a program in a disposable via command line (from app qube)
 
 Sometimes it can be useful to start an arbitrary program in a disposable. This can be done from an app qube with :program:`qvm-run-vm`:
 
-.. code:: console
+.. code-block:: console
 
       [user@work ~]$ qvm-run-vm -- '@dispvm' qubes-run-terminal
 
@@ -65,7 +65,7 @@ Suppose that you have a qube named ``email`` and its default disposable template
 
 Open the :doc:`user policy </user/how-to-guides/how-to-edit-a-policy>` and insert the following rule:
 
-.. code:: text
+.. code-block:: text
 
       # SERVICE      ARGUMENT  FROM   TO               ACTION
       qubes.OpenURL  *         email  @dispvm:net-dvm  allow
@@ -86,7 +86,7 @@ In other words, the ``email`` qube will be allowed to create a new disposable ba
 
 To check if everything is working as expected, from the ``email`` qube with :program:`qvm-open-in-vm`:
 
-.. code:: console
+.. code-block:: console
 
       [user@email ~] $ qvm-open-in-vm -- '@dispvm:net-dvm' 'https://www.qubes-os.org'
 
@@ -100,7 +100,7 @@ You can enable a :ref:`qube service <user/how-to-guides/how-to-enable-a-service:
 
 For instance, to have Mozilla Thunderbird application open all attachments in a disposable, find its application name with |qubes-logo-icon|:menuselection:`Qubes App Menu (Q icon) --> TEMPLATES --> <DISPOSABLE_TEMPLATE> --> Settings --> Applications`, hover your mouse over the application to see the ``.desktop filename``. Or use the command line equivalent:
 
-.. code:: console
+.. code-block:: console
 
       qvm-appmenus --get-available --i-understand-format-is-unstable <QUBE> | grep -i thunderbird
 
@@ -134,7 +134,7 @@ The system's default disposable template can be configured in |qubes-logo-icon|:
 
 This can also be changed from the command line with with :program:`qubes-prefs`:
 
-.. code:: console
+.. code-block:: console
 
       user@dom0:~$ qubes-prefs default_dispvm <DISPOSABLE_TEMPLATE>
 
@@ -151,7 +151,7 @@ The per qube default disposable template can be configured in the app menu, for
 
 This can also be changed from the command line with :program:`qvm-prefs`:
 
-.. code:: console
+.. code-block:: console
 
       user@dom0:~$ qvm-prefs work default_dispvm <DISPOSABLE_TEMPLATE>
 
@@ -187,7 +187,7 @@ It is also possible to change application settings of a disposable by customizin
 
 1. Start a terminal (or your chosen application) in the :samp:`{<DISPOSABLE_TEMPLATE>}` qube with |qubes-logo-icon|:menuselection:`Qubes App Menu (Q icon) --> TEMPLATES --> <DISPOSABLE_TEMPLATE> --> Run Terminal` or by running the following command in a :term:`GUI domain`:
 
-   .. code:: console
+   .. code-block:: console
 
          user@dom0:~$ qvm-run --service -- <DISPOSABLE_TEMPLATE> qubes.StartApp+qubes-run-terminal
 
@@ -211,14 +211,14 @@ Let's take for example ``sys-net``, which could be a disposable if you enabled t
 
 From the :term:`GUI domain`:
 
-.. code:: console
+.. code-block:: console
 
       user@dom0:~$ qvm-features sys-net vm-config.wifi-ssid <SSID>
       user@dom0:~$ qvm-features sys-net vm-config.wifi-pass <PASSWORD>
 
 From the configured qube, ``sys-net``:
 
-.. code:: console
+.. code-block:: console
 
       [user@sys-net ~] $ qubesdb-read /vm-config/wifi-ssid
       [user@sys-net ~] $ qubesdb-read /vm-config/wifi-pass
@@ -233,7 +233,7 @@ Next, go to |qubes-logo-icon|:menuselection:`Qubes App Menu (Q icon) --> APPS --
 
 You can also use the command line equivalent:
 
-.. code:: console
+.. code-block:: console
 
       user@dom0:~$ qvm-create --template <TEMPLATE> --label red <DISPOSABLE_TEMPLATE>
       user@dom0:~$ qvm-prefs <DISPOSABLE_TEMPLATE> template_for_dispvms True
@@ -270,7 +270,7 @@ Click :guilabel:`&OK` to save changes and close the window.
 
 On the :term:`GUI domain` terminal, disable disposable's appmenus:
 
-.. code:: console
+.. code-block:: console
 
       user@dom0:~$ qvm-features <SERVICE_QUBE> appmenus-dispvm ''
 
@@ -282,7 +282,7 @@ Named disposable for service qubes without PCI devices via command line
 
 To create one that has no PCI devices attached, such as for ``sys-firewall``:
 
-.. code:: console
+.. code-block:: console
 
       user@dom0:~$ qvm-create -C DispVM -l green <SERVICE_QUBE>
       user@dom0:~$ qvm-prefs <SERVICE_QUBE> autostart true
@@ -294,7 +294,7 @@ Next, set the old service qube's ``autostart`` to false, and update any referenc
 
 Here is an example of a complete ``sys-firewall`` replacement:
 
-.. code:: console
+.. code-block:: console
 
       user@dom0:~$ qvm-create -C DispVM -l green sys-net2
       user@dom0:~$ qvm-prefs sys-net2 autostart true
@@ -335,13 +335,13 @@ Click :guilabel:`&OK` to save changes and close the window.
 
 On the :term:`GUI domain` terminal, disable disposable's appmenus:
 
-.. code:: console
+.. code-block:: console
 
       user@dom0:~$ qvm-features <SERVICE_QUBE> appmenus-dispvm ''
 
 Next, set the old service qube's autostart to false, and update any references to the old one, e.g.:
 
-.. code:: console
+.. code-block:: console
 
       user@dom0:~$ qvm-prefs sys-firewall netvm <SERVICE_QUBE>
 
@@ -355,7 +355,7 @@ To create one with a PCI device attached, such as for ``sys-net`` or ``sys-usb``
 
 .. important:: You can use ``qvm-pci`` to :ref:`determine <user/how-to-guides/how-to-use-pci-devices:\`\`qvm-pci\`\` usage>` the ``<BDF>``. Also, you will often need to include the ``-o no-strict-reset=True`` :ref:`option <user/how-to-guides/how-to-use-pci-devices:no-strict-reset>` with USB controllers.
 
-.. code:: console
+.. code-block:: console
 
       user@dom0:~$ qvm-create -C DispVM -l red <SERVICE_QUBE>
       user@dom0:~$ qvm-prefs <SERVICE_QUBE> virt_mode hvm
@@ -367,13 +367,13 @@ To create one with a PCI device attached, such as for ``sys-net`` or ``sys-usb``
 
 Optionally, if this disposable will also provide network access to other qubes:
 
-.. code:: console
+.. code-block:: console
 
       user@dom0:~$ qvm-prefs <SERVICE_QUBE> provides_network true
 
 Next, set the old service qube's autostart to false, and update any references to the old one, e.g.:
 
-.. code:: console
+.. code-block:: console
 
       user@dom0:~$ qvm-prefs sys-firewall netvm <SERVICE_QUBE>
 
@@ -381,7 +381,7 @@ Also make sure to update any :doc:`RPC policies </user/advanced-topics/rpc-polic
 
 Here is an example of a complete ``sys-net`` replacement:
 
-.. code:: console
+.. code-block:: console
 
       user@dom0:~$ qvm-create -C DispVM -l red sys-net2
       user@dom0:~$ qvm-prefs sys-net2 virt_mode hvm
@@ -408,7 +408,7 @@ Let's delete a disposable template with |qubes-logo-icon|:menuselection:`Qubes A
 
 Or with the command line equivalent:
 
-.. code:: console
+.. code-block:: console
 
       user@dom0:~$ qvm-remove <DISPOSABLE_TEMPLATE>
       This will completely remove the selected VM(s)
@@ -423,7 +423,7 @@ Retire the qube from being the system's default disposable template
 
 The system's default disposable template may reference the :samp:`{<DISPOSABLE_TEMPLATE>}`. Let's check if it is being used with |qubes-logo-icon|:menuselection:`Qubes App Menu (Q icon) --> Settings (icon) --> Qubes Tools --> Qubes Global Config --> General --> Default disposable template`. Or the command line equivalent.
 
-.. code:: console
+.. code-block:: console
 
       user@dom0:~$ qubes-prefs default_dispvm
       <DISPOSABLE_TEMPLATE>
@@ -436,7 +436,7 @@ Retire the qube from being a qube's default disposable template
 
 Now let's check the per qube ``default_dispvm`` property for any qube, in this case, the ``work`` qube, in |qubes-logo-icon|:menuselection:`Qubes App Menu (Q icon) --> APPS --> work --> Settings --> Advanced --> Default disposable template`. Or use the command line equivalent:
 
-.. code:: console
+.. code-block:: console
 
       user@dom0:~$ qvm-prefs <QUBE> | grep default_dispvm
       default_dispvm        -  <DISPOSABLE_TEMPLATE>
@@ -451,6 +451,6 @@ Disposable template deletion troubleshooting
 
 If you still encounter a problem, you may have forgotten to clean an entry. Looking at the system logs will help you:
 
-.. code:: console
+.. code-block:: console
 
       user@dom0:~$ journalctl -S 60s
diff --git a/user/advanced-topics/gui-configuration.rst b/user/advanced-topics/gui-configuration.rst
index a392a8fb5f..00f3939988 100644
--- a/user/advanced-topics/gui-configuration.rst
+++ b/user/advanced-topics/gui-configuration.rst
@@ -14,7 +14,7 @@ When a qube starts, a fixed amount of RAM is allocated to the graphics buffer ca
 
 To increase the minimum size of the video RAM buffer:
 
-.. code:: console
+.. code-block:: console
 
       $ qvm-features dom0 gui-videoram-min $(($WIDTH * $HEIGHT * 4 / 1024))
       $ qvm-features dom0 gui-videoram-overhead 0
@@ -24,7 +24,7 @@ Where ``$WIDTH`` × ``$HEIGHT`` is the maximum desktop size that you anticipate
 
 In the case of multiple display with different orientations or if you plug/unplug displays, the following code will set correct memory size using xrandr.
 
-.. code:: console
+.. code-block:: console
 
       $ qvm-features dom0 gui-videoram-min $(xrandr --verbose | grep "Screen 0" | sed -e 's/.*current //' -e 's/\,.*//' | awk '{print $1*$3*4/1024}')
 
@@ -45,7 +45,7 @@ Xorg configuration to mitigate tearing
 
 If video playback is choppy instead of smooth, this could be because the X server is not properly configured. If you have HD graphics, then you could try placing this configuration in ``/etc/X11/xorg.conf.d/90-intel.conf``, and restarting the X server.
 
-.. code:: xorg.conf
+.. code-block:: xorg.conf
 
       Section "Device"
               Identifier "Intel Graphics"
diff --git a/user/advanced-topics/gui-domain.rst b/user/advanced-topics/gui-domain.rst
index d00de23855..7ac0d3e161 100644
--- a/user/advanced-topics/gui-domain.rst
+++ b/user/advanced-topics/gui-domain.rst
@@ -20,7 +20,7 @@ Here, we describe how to setup ``sys-gui`` that we call *hybrid mode* or referen
 
 In ``dom0``, enable the formula for ``sys-gui`` with pillar data:
 
-.. code:: console
+.. code-block:: console
 
       $ sudo qubesctl top.enable qvm.sys-gui
       $ sudo qubesctl top.enable qvm.sys-gui pillar=True
@@ -28,21 +28,21 @@ In ``dom0``, enable the formula for ``sys-gui`` with pillar data:
 
 then, execute it:
 
-.. code:: console
+.. code-block:: console
 
       $ sudo qubesctl --all state.highstate
 
 
 You can now disable the ``sys-gui`` formula:
 
-.. code:: console
+.. code-block:: console
 
       $ sudo qubesctl top.disable qvm.sys-gui
 
 
 Note that the ``default_guivm`` qubes global property has not been changed. You can confirm this with:
 
-.. code:: console
+.. code-block:: console
 
       $ qubes-prefs default_guivm
 
@@ -65,7 +65,7 @@ Here, we describe how to setup ``sys-gui-gpu`` which is a GUI domain with *GPU p
 
 In ``dom0``, enable the formula for ``sys-gui-gpu`` with pillar data:
 
-.. code:: console
+.. code-block:: console
 
       $ sudo qubesctl top.enable qvm.sys-gui-gpu
       $ sudo qubesctl top.enable qvm.sys-gui-gpu pillar=True
@@ -73,21 +73,21 @@ In ``dom0``, enable the formula for ``sys-gui-gpu`` with pillar data:
 
 then, execute it:
 
-.. code:: console
+.. code-block:: console
 
       $ sudo qubesctl --all state.highstate
 
 
 You can now disable the ``sys-gui-gpu`` formula:
 
-.. code:: console
+.. code-block:: console
 
       $ sudo qubesctl top.disable qvm.sys-gui-gpu
 
 
 One more step is needed: attaching the actual GPU to ``sys-gui-gpu``. This can be done either manually via ``qvm-pci`` (remember to enable permissive option), or via:
 
-.. code:: console
+.. code-block:: console
 
       $ sudo qubesctl state.sls qvm.sys-gui-gpu-attach-gpu
 
@@ -112,7 +112,7 @@ Here, we describe how to setup ``sys-gui-vnc`` that we call a *remote* GUI domai
 
 In ``dom0``, enable the formula for ``sys-gui-vnc`` with pillar data:
 
-.. code:: console
+.. code-block:: console
 
       $ sudo qubesctl top.enable qvm.sys-gui-vnc
       $ sudo qubesctl top.enable qvm.sys-gui-vnc pillar=True
@@ -120,21 +120,21 @@ In ``dom0``, enable the formula for ``sys-gui-vnc`` with pillar data:
 
 then, execute it:
 
-.. code:: console
+.. code-block:: console
 
       $ sudo qubesctl --all state.highstate
 
 
 You can now disable the ``sys-gui-vnc`` formula:
 
-.. code:: console
+.. code-block:: console
 
       $ sudo qubesctl top.disable qvm.sys-gui-vnc
 
 
 At this point, you need to shutdown all your running qubes as the ``default_guivm`` qubes global property has been set to ``sys-gui-vnc``. Then, you can start ``sys-gui-vnc``:
 
-.. code:: console
+.. code-block:: console
 
       $ qvm-start sys-gui-vnc
 
@@ -185,21 +185,21 @@ The following commands have to be run in ``dom0``.
 
 Set ``default_guivm`` as ``dom0``:
 
-.. code:: console
+.. code-block:: console
 
       $ qubes-prefs default_guivm dom0
 
 
 and for every selected qubes not using default value for GUI domain property, for example with a qube ``personal``:
 
-.. code:: console
+.. code-block:: console
 
       $ qvm-prefs personal guivm dom0
 
 
 You are now able to delete the GUI domain, for example ``sys-gui-gpu``:
 
-.. code:: console
+.. code-block:: console
 
       $ qvm-remove -f sys-gui-gpu
 
diff --git a/user/advanced-topics/how-to-install-software-in-dom0.rst b/user/advanced-topics/how-to-install-software-in-dom0.rst
index 104cf7715b..9adf3cced8 100644
--- a/user/advanced-topics/how-to-install-software-in-dom0.rst
+++ b/user/advanced-topics/how-to-install-software-in-dom0.rst
@@ -32,7 +32,7 @@ How to install a specific package
 
 To install additional packages in dom0 (usually not recommended):
 
-.. code:: console
+.. code-block:: console
 
       $ sudo qubes-dom0-update anti-evil-maid
 
@@ -48,7 +48,7 @@ How to downgrade a specific package
 
 To downgrade a specific package in dom0:
 
-.. code:: console
+.. code-block:: console
 
       $ sudo qubes-dom0-update --action=downgrade package-version
 
@@ -60,7 +60,7 @@ How to re-install a package
 
 To re-install a package in dom0:
 
-.. code:: console
+.. code-block:: console
 
       $ sudo qubes-dom0-update --action=reinstall package
 
@@ -72,7 +72,7 @@ How to uninstall a package
 
 If you’ve installed a package such as anti-evil-maid, you can remove it with the following command:
 
-.. code:: console
+.. code-block:: console
 
       $ sudo dnf remove anti-evil-maid
 
@@ -97,7 +97,7 @@ If you wish to install updates that are still in :doc:`testing </user/downloadin
 
 To temporarily enable any of these repos, use the ``--enablerepo=<repo-name>`` option. Example commands:
 
-.. code:: console
+.. code-block:: console
 
       $ sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing
       $ sudo qubes-dom0-update --enablerepo=qubes-dom0-security-testing
@@ -155,7 +155,7 @@ Example
 
 (Note that the following example enables the unstable repo.)
 
-.. code:: console
+.. code-block:: console
 
       $ sudo qubes-dom0-update --enablerepo=qubes-dom0-unstable kernel kernel-qubes-vm
 
@@ -169,7 +169,7 @@ EFI
 
 Replace the example version numbers with the one you are upgrading to.
 
-.. code:: console
+.. code-block:: console
 
       $ sudo dracut -f /boot/efi/EFI/qubes/initramfs-4.14.35-1.pvops.qubes.x86_64.img 4.14.35-1.pvops.qubes.x86_64
 
@@ -179,7 +179,7 @@ Grub2
 ^^^^^
 
 
-.. code:: console
+.. code-block:: console
 
       $ sudo grub2-mkconfig -o /boot/grub2/grub.cfg
 
@@ -196,14 +196,14 @@ Changing default kernel
 This section describes changing the default kernel in dom0. It is sometimes needed if you have upgraded to a newer kernel and are having problems booting, for example. On the next kernel update, the default will revert to the newest.
 
 
-.. code:: console
+.. code-block:: console
 
       $ sudo nano /etc/default/grub
 
 
 Update the following two lines, add if needed:
 
-.. code:: bash
+.. code-block:: bash
 
       GRUB_DISABLE_SUBMENU=false
       GRUB_SAVEDEFAULT=true
@@ -211,7 +211,7 @@ Update the following two lines, add if needed:
 
 Save and exit nano. Regenerate the GRUB 2 configuration.
 
-.. code:: console
+.. code-block:: console
 
       $ sudo grub2-mkconfig -o /boot/grub2/grub.cfg
 
diff --git a/user/advanced-topics/i3.rst b/user/advanced-topics/i3.rst
index f622ce1096..709d67575d 100644
--- a/user/advanced-topics/i3.rst
+++ b/user/advanced-topics/i3.rst
@@ -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:: console
+.. code-block:: console
 
       $ sudo qubes-dom0-update i3 i3-settings-qubes
 
@@ -47,7 +47,7 @@ Getting the code
 
 Clone the i3-qubes repository here:
 
-.. code:: console
+.. code-block:: 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:: console
+.. code-block:: 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:: console
+.. code-block:: 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:: console
+.. code-block:: 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:: console
+.. code-block:: 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:: console
+.. code-block:: console
 
       $ sudo yum localinstall i3.rpm
 
diff --git a/user/advanced-topics/installing-contributed-packages.rst b/user/advanced-topics/installing-contributed-packages.rst
index 3897dbba96..8e33caa979 100644
--- a/user/advanced-topics/installing-contributed-packages.rst
+++ b/user/advanced-topics/installing-contributed-packages.rst
@@ -20,7 +20,7 @@ In dom0, use ``qubes-dom0-update``:
 
 
 
-.. code:: console
+.. code-block:: console
 
       $ sudo qubes-dom0-update qubes-repo-contrib
 
@@ -29,7 +29,7 @@ In a Fedora-based template, use ``dnf``:
 
 
 
-.. code:: console
+.. code-block:: console
 
       $ sudo dnf install qubes-repo-contrib
 
@@ -38,14 +38,14 @@ In a Debian-based template, use ``apt``:
 
 
 
-.. code:: console
+.. code-block:: console
 
       $ sudo apt update && sudo apt install qubes-repo-contrib
 
 
 The new repository definition will be in the usual location for your distro, and it will follow the naming pattern ``qubes-contrib-*``, depending on your Qubes release and whether it is in dom0 or a template. For example, in a Fedora template on Qubes 4.0, the new repository definition would be:
 
-.. code:: text
+.. code-block:: text
 
       /etc/yum.repos.d/qubes-contrib-vm-r4.0.repo
 
@@ -63,7 +63,7 @@ For example, to install ``qvm-screenshot-tool`` in dom0:
 
 
 
-.. code:: console
+.. code-block:: console
 
       $ sudo qubes-dom0-update --clean qvm-screenshot-tool
 
diff --git a/user/advanced-topics/kde.rst b/user/advanced-topics/kde.rst
index b9f48daa19..145493a78b 100644
--- a/user/advanced-topics/kde.rst
+++ b/user/advanced-topics/kde.rst
@@ -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:: console
+.. code-block:: console
 
       $ sudo qubes-dom0-update kde-settings-qubes
 
@@ -23,7 +23,7 @@ After the installation is complete log out. At the top of the log in screen is a
 
 KDE is very customisable, and there is a range of widgets to use. If you want to use the Menu widget, then you must edit ``/etc/X11/xinit/xinitrc.d/55xfce-qubes.sh`` as follows:
 
-.. code:: bash
+.. code-block:: bash
 
       #!/usr/bin/sh
 
@@ -47,7 +47,7 @@ You can also change your default login manager (lightdm) to the new KDE default:
 
 - first you need to edit the ``/etc/sddm.conf`` to make sure if the custom X parameter is set according to Qubes needs:
 
-  .. code:: kconfig
+  .. code-block:: kconfig
 
         [XDisplay]
         ServerArguments=-nolisten tcp -background none
@@ -56,7 +56,7 @@ You can also change your default login manager (lightdm) to the new KDE default:
 
 - disable the lightdm service:
 
-  .. code:: console
+  .. code-block:: 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:: console
+  .. code-block:: console
 
         $ sudo systemctl enable sddm
 
@@ -82,7 +82,7 @@ Window Management
 
 You can set each window’s position and size like this:
 
-.. code:: text
+.. code-block:: text
 
       Right click title bar --> More actions --> Special window settings...
 
@@ -97,7 +97,7 @@ You can set each window’s position and size like this:
 
 You can also use ``kstart`` to control virtual desktop placement like this:
 
-.. code:: console
+.. code-block:: console
 
       $ kstart --desktop 3 --windowclass <vm_name> -q --tray -a <vm_name> '<run_program_command>'
 
@@ -112,7 +112,7 @@ Wayland session
 
 Default installation includes KDE Plasma X11 session. KDE project primary focus is Wayland session, which in Qubes OS is currently experimental. To enable the experimental Wayland session support install the following package:
 
-.. code:: console
+.. code-block:: console
 
     $ sudo qubes-dom0-update qubes-desktop-linux-common-wayland
 
@@ -124,7 +124,7 @@ If you decide to remove KDE do **not** use ``dnf remove @kde-desktop-qubes``. Yo
 
 The safest way to remove (most of) KDE is:
 
-.. code:: console
+.. code-block:: console
 
       $ sudo dnf remove kdelibs plasma-workspace
 
diff --git a/user/advanced-topics/managing-vm-kernels.rst b/user/advanced-topics/managing-vm-kernels.rst
index d781c43fbf..2388c02f44 100644
--- a/user/advanced-topics/managing-vm-kernels.rst
+++ b/user/advanced-topics/managing-vm-kernels.rst
@@ -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:: console
+.. code-block:: console
 
       [user@dom0 ~]$ dnf list --installed kernel
       Installed Packages
@@ -37,7 +37,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:: console
+.. code-block:: console
 
       [user@dom0 ~]$ qubes-prefs default-kernel
       6.12.59-1.fc37
@@ -46,7 +46,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:: console
+.. code-block:: console
 
       [user@dom0 ~]$ qvm-prefs my-appvm kernelopts
       swiotlb=2048
@@ -59,7 +59,7 @@ Installing different kernel using Qubes kernel package
 
 VM kernels are packaged by the Qubes team in the ``kernel`` packages. Generally, the system will keep the three newest available versions. You can list them using ``rpm`` or ``dnf`` commands:
 
-.. code:: console
+.. code-block:: console
 
       [user@dom0 ~]$ rpm -qa 'kernel'
       kernel-6.12.47-1.qubes.fc37.x86_64
@@ -76,7 +76,7 @@ If you want a more recent version, you can check ``qubes-dom0-unstable`` and ``q
 
 To check available versions in the ``qubes-dom0-current-testing`` repository:
 
-.. code:: console
+.. code-block:: console
 
       [root@dom0 ~]# qubes-dom0-update --enablerepo=qubes-dom0-current-testing --action=list kernel-latest kernel
       Using sys-whonix as UpdateVM for Dom0
@@ -99,7 +99,7 @@ To check available versions in the ``qubes-dom0-current-testing`` repository:
 
 Installing a new version from ``qubes-dom0-current-testing`` repository:
 
-.. code:: console
+.. code-block:: console
 
       [root@dom0 ~]# qubes-dom0-update --enablerepo=qubes-dom0-current-testing kernel
       Using sys-whonix as UpdateVM for Dom0
@@ -210,7 +210,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:: console
+.. code-block:: 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...
@@ -254,7 +254,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:: console
+.. code-block:: 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
@@ -289,7 +289,7 @@ Using kernel installed in the VM
 
 Non-minimal debian and fedora templates already have grub and related tools preinstalled so if you want to use one of the distribution kernels, all you need to do is clone either template to a new one, then:
 
-.. code:: console
+.. code-block:: console
 
       [user@dom0 ~]$ qvm-prefs <clonetemplatename> virt_mode hvm
       [user@dom0 ~]$ qvm-prefs <clonetemplatename> kernel ''
@@ -297,7 +297,7 @@ Non-minimal debian and fedora templates already have grub and related tools prei
 
 Depending on vm and kernel you're running, you may also want to disable memory balancing and change the amount of memory vm has: 
 
-.. code:: console
+.. code-block:: console
 
       [user@dom0 ~]$ qvm-prefs <clonedtemplatename> maxmem 0
       [user@dom0 ~]$ qvm-prefs <clonedtemplatename> memory 2000
@@ -311,7 +311,7 @@ Fedora distribution kernel
 
 Install kernel and the packages required to run vm with its own kernel:
 
-.. code:: console
+.. code-block:: console
 
   [root@fedora-vm ~]# dnf install kernel qubes-kernel-vm-support grub2
 
@@ -319,7 +319,7 @@ Install kernel and the packages required to run vm with its own kernel:
 
 Once the kernel is installed, you need to setup ``grub2`` by running:
 
-.. code:: console
+.. code-block:: console
 
   [root@fedora-vm ~]# grub2-install /dev/xvda
 
@@ -327,7 +327,7 @@ Once the kernel is installed, you need to setup ``grub2`` by running:
 
 Finally, you need to create a GRUB configuration. You may want to adjust some settings in ``/etc/default/grub``; for example, lower ``GRUB_TIMEOUT`` to speed up VM startup. Then, you need to generate the actual configuration. In Fedora it can be done using the ``grub2-mkconfig`` tool:
 
-.. code:: console
+.. code-block:: console
 
   [root@fedora-vm ~]# grub2-mkconfig -o /boot/grub2/grub.cfg
 
@@ -338,7 +338,7 @@ Fedora custom kernel
 
 If you are using a manually built kernel, you need to handle the initramfs and kernel modules on your own. Take a look at the ``dkms`` documentation, especially the ``dkms autoinstall`` command may be useful. If you did not see the ``kernel`` install rebuild your initramfs, or are using a manually built kernel, you will need to rebuild it yourself. Replace the version numbers in the example below with the ones appropriate to the kernel you are installing:
 
-.. code:: console
+.. code-block:: console
 
   [root@fedora-vm ~]# dracut -f /boot/initramfs-4.15.14-200.fc26.x86_64.img 4.15.14-200.fc26.x86_64
 
@@ -346,7 +346,7 @@ If you are using a manually built kernel, you need to handle the initramfs and k
 
 Once the kernel is installed, you need to setup ``grub2`` by running:
 
-.. code:: console
+.. code-block:: console
 
   [root@fedora-vm ~]# grub2-install /dev/xvda
 
@@ -354,7 +354,7 @@ Once the kernel is installed, you need to setup ``grub2`` by running:
 
 Finally, you need to create a GRUB configuration. You may want to adjust some settings in ``/etc/default/grub``; for example, lower ``GRUB_TIMEOUT`` to speed up VM startup. Then, you need to generate the actual configuration. In Fedora it can be done using the ``grub2-mkconfig`` tool:
 
-.. code:: console
+.. code-block:: console
 
   [root@fedora-vm ~]# grub2-mkconfig -o /boot/grub2/grub.cfg
 
@@ -362,7 +362,7 @@ Finally, you need to create a GRUB configuration. You may want to adjust some se
 
 You can safely ignore this error message:
 
-.. code:: output
+.. code-block:: output
 
       grub2-probe: error: cannot find a GRUB drive for /dev/mapper/dmroot. Check your device.map
 
@@ -396,7 +396,7 @@ Using a distribution kernel package the initramfs and kernel modules should be h
 
 Install distribution kernel image, kernel headers and the grub.
 
-.. code:: console
+.. code-block:: console
 
   [root@debian-vm ~]# apt install linux-image-amd64 linux-headers-amd64 grub2 qubes-kernel-vm-support
 
@@ -404,7 +404,7 @@ Install distribution kernel image, kernel headers and the grub.
 
 If you are doing that on a qube based on “Debian Minimal” template, a grub gui will popup during the installation, asking you where you want to install the grub loader. You must select ``/dev/xvda`` (check the box using the space bar, and validate your choice with “Enter”.) If this popup does not appear during the installation, you must manually setup ``grub2`` by running:
 
-.. code:: console
+.. code-block:: console
 
   [root@debian-vm ~]# grub-install /dev/xvda
 
@@ -458,7 +458,7 @@ Run DKMS. Replace this with actual kernel version.
 
 
 
-.. code:: console
+.. code-block:: console
 
   [root@debian-vm ~]# dkms autoinstall -k <kernel-version>
 
@@ -467,7 +467,7 @@ For example.
 
 
 
-.. code:: console
+.. code-block:: console
 
   [root@debian-vm ~]# dkms autoinstall -k 4.19.0-6-amd64
 
@@ -476,14 +476,14 @@ Update initramfs.
 
 
 
-.. code:: console
+.. code-block:: console
 
   [root@debian-vm ~]# update-initramfs -u
 
 
 The output should look like this:
 
-.. code:: console
+.. code-block:: console
 
   [root@debian-vm ~]# dkms autoinstall -k 3.16.0-4-amd64
 
diff --git a/user/advanced-topics/mount-from-other-os.rst b/user/advanced-topics/mount-from-other-os.rst
index 02f195ce8f..9ec30b5418 100644
--- a/user/advanced-topics/mount-from-other-os.rst
+++ b/user/advanced-topics/mount-from-other-os.rst
@@ -26,7 +26,7 @@ Decrypting the Disk
 
    1. Open a Linux terminal in either dom0 or the app qube the disk was passed through to and enter ``lsblk``, which will result in an output similar to the following. In this example, the currently booted Qubes system is installed on ``sda`` and the qubes system to be accessed is on ``nvme0n1p2``.
 
-      .. code:: output
+      .. code-block:: output
 
             sda                                                                   8:0    0 111.8G  0 disk
             ├─sda1                                                                8:1    0   200M  0 part  /boot/efi
diff --git a/user/advanced-topics/qubes-service.rst b/user/advanced-topics/qubes-service.rst
index 1a5ba7e834..27ab3a49dd 100644
--- a/user/advanced-topics/qubes-service.rst
+++ b/user/advanced-topics/qubes-service.rst
@@ -12,7 +12,7 @@ Under the hood, an enabled service in a VM is signaled by a file in ``/var/run/q
 
 Adding support for systemd services is pretty simple. In the VM, create the following file (and directory, if needed): ``/etc/systemd/system/<service name>.service.d/30_qubes.conf``. It should contain the following:
 
-.. code:: systemd
+.. code-block:: systemd
 
       [Unit]
       ConditionPathExists=/var/run/qubes-service/<service name>
diff --git a/user/advanced-topics/resize-disk-image.rst b/user/advanced-topics/resize-disk-image.rst
index f6fee8724c..34cc80944b 100644
--- a/user/advanced-topics/resize-disk-image.rst
+++ b/user/advanced-topics/resize-disk-image.rst
@@ -36,7 +36,7 @@ Increasing the size of Disk Images with :program:`qvm-volume`
 
 Use either GUI tool Qube Settings (``qubes-vm-settings``) or the CLI tool ``qvm-volume``. Maximum size which can be assigned through Qube Settings is 1048576 MiB - if you need more, use ``qvm-volume``:
 
-.. code:: console
+.. code-block:: console
 
       $ qvm-volume extend <vm_name>:root <size>
 
@@ -44,7 +44,7 @@ Use either GUI tool Qube Settings (``qubes-vm-settings``) or the CLI tool ``qvm-
 
 OR
 
-.. code:: console
+.. code-block:: console
 
       $ qvm-volume extend <vm_name>:private <size>
 
@@ -86,7 +86,7 @@ FreeBSD
 ^^^^^^^
 
 
-.. code:: console
+.. code-block:: console
 
       $ gpart recover ada0
       $ sysctl kern.geom.debugflags=0x10
@@ -111,7 +111,7 @@ You can create a new qube, copy your files in to the new qube, and delete the ol
 
 Or you can take the risk of reducing the size of the disk. For example, to reduce the private storage of qube1 to 1GiB: Open a terminal in dom0:
 
-.. code:: console
+.. code-block:: console
 
       $ qvm-shutdown qube1
       $ sudo lvresize --size 1024M /dev/qubes_dom0/vm-qube1-private
diff --git a/user/advanced-topics/rpc-policy.rst b/user/advanced-topics/rpc-policy.rst
index 1906cda759..4e7daaa9bc 100644
--- a/user/advanced-topics/rpc-policy.rst
+++ b/user/advanced-topics/rpc-policy.rst
@@ -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:: console
+.. code-block:: console
 
       [user@dom0 user ~]$ cat /etc/qubes-rpc/policy/qubes.FileCopy
       (...)
diff --git a/user/advanced-topics/salt.rst b/user/advanced-topics/salt.rst
index 3ca36b3aa1..0a9ae7a527 100644
--- a/user/advanced-topics/salt.rst
+++ b/user/advanced-topics/salt.rst
@@ -50,7 +50,7 @@ States
 
 The smallest unit of configuration is a state. A state is written in YAML and looks like this:
 
-.. code:: yaml
+.. code-block:: yaml
 
       stateid:
         cmd.run:  #this is the execution module. in this case it will execute a command on the shell
@@ -74,7 +74,7 @@ With these three states you can define most of the configuration of a VM.
 
 You can also `order the execution <https://docs.saltproject.io/en/latest/ref/states/ordering.html>`__ of your states:
 
-.. code:: yaml
+.. code-block:: yaml
 
       D:
         cmd.run:
@@ -111,7 +111,7 @@ Top Files
 
 After you have several state files, you need something to assign them to a qube. This is done by ``*.top`` files (`official documentation <https://docs.saltproject.io/en/latest/ref/states/top.html>`__). Their structure looks like this:
 
-.. code:: yaml
+.. code-block:: yaml
 
       environment:
         target_matching_clause:
@@ -122,7 +122,7 @@ After you have several state files, you need something to assign them to a qube.
 
 In most cases, the environment will be called ``base``. The ``target_matching_clause`` will be used to select your minions (Templates or qubes). It can be either the name of a qube or a regular expression. If you are using a regular expressions, you need to give Salt a hint you are doing so:
 
-.. code:: yaml
+.. code-block:: yaml
 
       environment:
         ^app-(work|(?!mail).*)$:
@@ -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:: console
+.. code-block:: 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:: console
+.. code-block:: console
 
       $ qubesctl top.enabled
 
@@ -155,7 +155,7 @@ To list all enabled top files:
 
 And to disable one:
 
-.. code:: console
+.. code-block:: 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:: console
+.. code-block:: console
 
       $ qubesctl --all state.apply
 
@@ -193,7 +193,7 @@ Configuring a qube's System from Dom0
 
 Salt can be used to configure qubes from dom0. Simply set the qube name as the target minion name in the top file. You can also use the ``qubes`` pillar module to select qubes with a particular property (see below). If you do so, then you need to pass additional arguments to the ``qubesctl`` tool:
 
-.. code:: output
+.. code-block:: output
 
       usage: qubesctl [-h] [--show-output] [--force-color] [--skip-dom0]
                       [--targets TARGETS | --templates | --app | --all]
@@ -233,7 +233,7 @@ Writing Your Own Configurations
 
 Let’s start with a quick example:
 
-.. code:: yaml
+.. code-block:: yaml
 
       my new and shiny VM:
         qvm.present:
@@ -267,7 +267,7 @@ As you will notice, the options are the same (or very similar) to those used in
 
 This should be put in ``/srv/salt/my-new-vm.sls`` or another ``.sls`` file. A separate ``*.top`` file should be also written:
 
-.. code:: yaml
+.. code-block:: yaml
 
       base:
         dom0:
@@ -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:: console
+.. code-block:: 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:: console
+.. code-block:: console
 
       $ qubesctl state.apply
 
@@ -299,7 +299,7 @@ Example of Configuring Templates from Dom0
 
 Lets make sure that the ``mc`` package is installed in all templates. Similar to the previous example, you need to create a state file (``/srv/salt/mc-everywhere.sls``):
 
-.. code:: yaml
+.. code-block:: yaml
 
       mc:
         pkg.installed: []
@@ -308,7 +308,7 @@ Lets make sure that the ``mc`` package is installed in all templates. Similar to
 
 Then the appropriate top file (``/srv/salt/mc-everywhere.top``):
 
-.. code:: yaml
+.. code-block:: yaml
 
       base:
        qubes:type:template:
@@ -319,7 +319,7 @@ Then the appropriate top file (``/srv/salt/mc-everywhere.top``):
 
 Now you need to enable the top file:
 
-.. code:: console
+.. code-block:: console
 
       $ qubesctl top.enable mc-everywhere
 
@@ -327,7 +327,7 @@ Now you need to enable the top file:
 
 And apply the configuration:
 
-.. code:: console
+.. code-block:: console
 
       $ qubesctl --all state.apply
 
@@ -349,7 +349,7 @@ As in the example above, it creates a qube and sets its properties.
 
 You can set properties of an existing qube:
 
-.. code:: yaml
+.. code-block:: yaml
 
       my preferences:
         qvm.prefs:
@@ -364,7 +364,7 @@ You can set properties of an existing qube:
 ^^^^^^^^^^^^^^^
 
 
-.. code:: yaml
+.. code-block:: yaml
 
       services in my qube:
         qvm.service:
@@ -388,7 +388,7 @@ This enables, disables, or sets to default, services as in ``qvm-service``.
 
 Ensures the specified qube is running:
 
-.. code:: yaml
+.. code-block:: yaml
 
       qube is running:
         qvm.running:
@@ -402,7 +402,7 @@ Virtual Machine Formulae
 
 You can use these formulae to download, install, and configure qubes in Qubes. These formulae use pillar data to define default qube names and configuration details. The default settings can be overridden in the pillar data located in:
 
-.. code:: text
+.. code-block:: text
 
       /srv/pillar/base/qvm/init.sls
 
@@ -540,7 +540,7 @@ Whonix Workstation template
 
 Updates dom0. Example (executed in dom0):
 
-.. code:: console
+.. code-block:: 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:: console
+.. code-block:: 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:: console
+.. code-block:: 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:: console
+.. code-block:: console
 
       $ qvm-run -p -u root fedora-24-minimal-template 'dnf install -y sudo'
 
@@ -681,7 +681,7 @@ Disk Quota Exceeded (When Installing Templates)
 
 If you install multiple templates you may encounter this error. The solution is to shut down the updateVM between each install:
 
-.. code:: yaml
+.. code-block:: yaml
 
       install template and shutdown updateVM:
         cmd.run:
diff --git a/user/advanced-topics/secondary-storage.rst b/user/advanced-topics/secondary-storage.rst
index e69b660c34..8a6987ab32 100644
--- a/user/advanced-topics/secondary-storage.rst
+++ b/user/advanced-topics/secondary-storage.rst
@@ -20,14 +20,14 @@ Qubes 4.0 is more flexible than earlier versions about placing different VMs on
 
 You can query qvm-pool to list available storage drivers:
 
-.. code:: console
+.. code-block:: console
 
       $ qvm-pool --help-drivers
 
 
 qvm-pool driver explanation:
 
-.. code:: text
+.. code-block:: text
 
       <file> refers to using a simple file for image storage and lacks a few features.
       <file-reflink> refers to storing images on a filesystem supporting copy on write.
@@ -48,7 +48,7 @@ These steps assume you have already created a separate `volume group <https://ac
 
 First, collect some information in a dom0 terminal:
 
-.. code:: console
+.. code-block:: console
 
       $ sudo pvs
       $ sudo lvs
@@ -56,7 +56,7 @@ First, collect some information in a dom0 terminal:
 
 Take note of the VG and thin pool names for your second drive, then register it with Qubes, where ``<pool_name>`` is a freely chosen pool name, ``<vg_name>`` is LVM volume group name and ``<thin_pool_name>`` is LVM thin pool name:
 
-.. code:: console
+.. code-block:: console
 
       $ qvm-pool --add <pool_name> lvm_thin -o volume_group=<vg_name>,thin_pool=<thin_pool_name>,revisions_to_keep=2
 
@@ -70,7 +70,7 @@ Theses steps assume you have already created a separate Btrfs filesystem for you
 
 It is possible to use an existing Btrfs storage if it is configured. In dom0, available Btrfs storage can be displayed using:
 
-.. code:: console
+.. code-block:: console
 
       $ mount -t btrfs
       $ sudo btrfs filesystem show
@@ -78,7 +78,7 @@ It is possible to use an existing Btrfs storage if it is configured. In dom0, av
 
 To register the storage to qubes use the following command where ``<pool_name>`` is a freely chosen pool name adn ``<dir_path>`` is the mounted path to the second Btrfs storage:
 
-.. code:: console
+.. code-block:: console
 
       $ qvm-pool --add <pool_name> file-reflink -o dir_path=<dir_path>,revisions_to_keep=2
 
@@ -89,14 +89,14 @@ Using the new pool
 
 Now, you can create qubes in that pool:
 
-.. code:: console
+.. code-block:: console
 
       $ qvm-create -P <pool_name> --label red <vmname>
 
 
 It isn’t possible to directly migrate an existing qube to the new pool, but you can clone it there, then remove the old one:
 
-.. code:: console
+.. code-block:: console
 
       $ qvm-clone -P <pool_name> <sourceVMname> <cloneVMname>
       $ qvm-remove <sourceVMname>
@@ -104,7 +104,7 @@ It isn’t possible to directly migrate an existing qube to the new pool, but yo
 
 If that was a template, or other qube referenced elsewhere (netVM or such), you will need to adjust those references manually after moving. For example:
 
-.. code:: console
+.. code-block:: console
 
       $ qvm-prefs <appvmname_based_on_old_template> template <new_template_name>
 
@@ -115,7 +115,7 @@ Example setup of second drive.
 
 Assuming the secondary hard disk is at /dev/sdb , you can encrypt the drive as follows. Note that the drive contents will be completely erased, In a dom0 terminal run this command - use the same passphrase as the main Qubes disk to avoid a second password prompt at boot:
 
-.. code:: console
+.. code-block:: console
 
       $ sudo cryptsetup luksFormat --sector-size=512 /dev/sdb
       $ sudo blkid /dev/sdb
@@ -126,7 +126,7 @@ Assuming the secondary hard disk is at /dev/sdb , you can encrypt the drive as f
 
 Note the device’s UUID (in this example “b209…”), we will use it as its luks name for auto-mounting at boot, by editing ``/etc/crypttab``, and adding this line to crypttab (replacing both “b209…” entries with your device’s UUID taken from blkid) :
 
-.. code:: text
+.. code-block:: text
 
       luks-b20975aa-8318-433d-8508-6c23982c6cde UUID=b20975aa-8318-433d-8508-6c23982c6cde none
 
@@ -139,28 +139,28 @@ For LVM
 
 First create the physical volume:
 
-.. code:: console
+.. code-block:: console
 
       $ sudo pvcreate /dev/mapper/luks-b20975aa-8318-433d-8508-6c23982c6cde
 
 
 Then create the LVM volume group, we will use for example “qubes” as the :
 
-.. code:: console
+.. code-block:: console
 
       $ sudo vgcreate qubes /dev/mapper/luks-b20975aa-8318-433d-8508-6c23982c6cde
 
 
 And then use “poolhd0” as the (LVM thin pool name):
 
-.. code:: console
+.. code-block:: console
 
       $ sudo lvcreate -T -n poolhd0 -l +100%FREE qubes
 
 
 Finally we will tell Qubes to add a new pool on the just created thin pool:
 
-.. code:: console
+.. code-block:: console
 
       $ qvm-pool --add poolhd0_qubes lvm_thin -o volume_group=qubes,thin_pool=poolhd0,revisions_to_keep=2
 
@@ -171,7 +171,7 @@ For Btrfs
 
 First create the physical volume:
 
-.. code:: console
+.. code-block:: console
 
       # <label> Btrfs Label
       $ sudo mkfs.btrfs -L <label> /dev/mapper/luks-b20975aa-8318-433d-8508-6c23982c6cde
@@ -179,7 +179,7 @@ First create the physical volume:
 
 Then mount the new Btrfs filesystem with compression enabled if desired, where ``<compression>`` can take the values ``zlib|lzo|zstd``:
 
-.. code:: console
+.. code-block:: console
 
       $ sudo mkdir -p /mnt/new_qube_storage
       $ sudo mount /dev/mapper/luks-b20975aa-8318-433d-8508-6c23982c6cde /mnt/new_qube_storage -o compress=<compression>
@@ -187,21 +187,21 @@ Then mount the new Btrfs filesystem with compression enabled if desired, where `
 
 Create a subvolume to hold the data:
 
-.. code:: console
+.. code-block:: console
 
       $ sudo btrfs subvolume create /mnt/new_qube_storage/qubes
 
 
 Finally we will tell Qubes to add a new pool on the just created Btrfs subvolume:
 
-.. code:: console
+.. code-block:: console
 
       $ qvm-pool --add poolhd0_qubes file-reflink -o dir_path=/mnt/new_qube_storage/qubes,revisions_to_keep=2
 
 
 By default VMs will be created on the main Qubes disk (i.e. a small SSD), to create them on this secondary drive do the following on a dom0 terminal:
 
-.. code:: console
+.. code-block:: console
 
       $ qvm-create -P poolhd0_qubes --label red unstrusted-hdd
 
diff --git a/user/advanced-topics/standalones-and-hvms.rst b/user/advanced-topics/standalones-and-hvms.rst
index 515d02a523..b7041a3820 100644
--- a/user/advanced-topics/standalones-and-hvms.rst
+++ b/user/advanced-topics/standalones-and-hvms.rst
@@ -44,7 +44,7 @@ You can create a standalone in the Qube Manager by selecting the “Type” of 
 
 Alternatively, to create an empty standalone from the dom0 command line:
 
-.. code:: console
+.. code-block:: console
 
       $ qvm-create --class StandaloneVM --label <YOUR_COLOR> --property virt_mode=hvm <NEW_STANDALONE_NAME>
 
@@ -52,7 +52,7 @@ Alternatively, to create an empty standalone from the dom0 command line:
 
 Or to create a standalone copied from a template:
 
-.. code:: console
+.. code-block:: console
 
       $ qvm-create --class StandaloneVM --label <YOUR_COLOR> --property virt_mode=hvm --template <TEMPLATE_QUBE_NAME> <NEW_STANDALONE_NAME>
 
@@ -88,7 +88,7 @@ Command line
 
 Qubes are template-based (i.e., :term:`app qubes  <app qube>` by default, so you must set the ``--class StandaloneVM`` option to create a standalone. The name and label color used below are for illustration purposes.
 
-.. code:: console
+.. code-block:: console
 
       $ qvm-create my-new-vm --class StandaloneVM --property virt_mode=hvm --property kernel='' --label=green
 
@@ -96,7 +96,7 @@ Qubes are template-based (i.e., :term:`app qubes  <app qube>` by default, so you
 
 If you receive an error like this one, then you must first enable VT-x in your BIOS:
 
-.. code:: output
+.. code-block:: output
 
       libvirt.libvirtError: invalid argument: could not find capabilities for arch=x86_64
 
@@ -112,7 +112,7 @@ You will have to boot the qube with the installation media “attached” to it.
 
 1. If you have the physical CD-ROM media and an optical disc drive:
 
-   .. code:: console
+   .. code-block:: console
 
          $ qvm-start <YOUR_HVM> --cdrom=/dev/cdrom
 
@@ -120,7 +120,7 @@ You will have to boot the qube with the installation media “attached” to it.
 
 2. If you have an ISO image of the installation media located in dom0:
 
-   .. code:: console
+   .. code-block:: console
 
          $ qvm-start <YOUR_HVM> --cdrom=dom0:/usr/local/iso/<YOUR_INSTALLER.ISO>
 
@@ -128,7 +128,7 @@ You will have to boot the qube with the installation media “attached” to it.
 
 3. If you have an ISO image of the installation media located in a qube (the qube where the media is located must be running):
 
-   .. code:: console
+   .. code-block:: console
 
          $ qvm-start <YOUR_HVM> --cdrom=<YOUR_OTHER_QUBE>:/home/user/<YOUR_INSTALLER.ISO>
 
@@ -199,7 +199,7 @@ Qubes allows HVMs to share a common root filesystem from a select template. This
 
 In order to create an HVM template, you use the following command, suitably adapted:
 
-.. code:: console
+.. code-block:: console
 
       $ qvm-create --class TemplateVM <YOUR_HVM_TEMPLATE_NAME> --property virt_mode=HVM --property kernel=''  -l <YOUR_COLOR>
 
@@ -219,7 +219,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:: console
+.. code-block:: console
 
       [joanna@dom0 ~]$ qvm-prefs my-new-vm
       autostart           D  False
@@ -309,7 +309,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:: console
+.. code-block:: console
 
       [joanna@dom0 ~]$ qvm-ls -n
 
@@ -321,7 +321,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:: console
+.. code-block:: 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
@@ -375,7 +375,7 @@ About 60 GB of disk space is required for conversion. Use an external hard drive
 
 In a Debian app qube, install ``qemu-utils`` and ``unzip``:
 
-.. code:: console
+.. code-block:: console
 
       $ sudo apt install qemu-utils unzip
 
@@ -383,7 +383,7 @@ In a Debian app qube, install ``qemu-utils`` and ``unzip``:
 
 In a Fedora app qube:
 
-.. code:: console
+.. code-block:: console
 
       $ sudo dnf install qemu-img
 
@@ -391,7 +391,7 @@ In a Fedora app qube:
 
 Unzip VirtualBox zip file:
 
-.. code:: console
+.. code-block:: console
 
       $ unzip *.zip
 
@@ -399,7 +399,7 @@ Unzip VirtualBox zip file:
 
 Extract OVA tar archive:
 
-.. code:: console
+.. code-block:: console
 
       $ tar -xvf *.ova
 
@@ -407,7 +407,7 @@ Extract OVA tar archive:
 
 Convert vmdk to raw:
 
-.. code:: console
+.. code-block:: console
 
       $ qemu-img convert -O raw *.vmdk win10.raw
 
@@ -415,7 +415,7 @@ Convert vmdk to raw:
 
 Copy the root image file from the originating qube (here called ``untrusted``) to a temporary location in dom0, typing this in a dom0 terminal:
 
-.. code:: console
+.. code-block:: console
 
       $ qvm-run --pass-io untrusted 'cat "/media/user/externalhd/win10.raw"' > /home/user/win10-root.img
 
@@ -423,7 +423,7 @@ Copy the root image file from the originating qube (here called ``untrusted``) t
 
 From within dom0, create a new HVM (here called ``win10``) with the root image we just copied to dom0 (change the amount of RAM in GB as you wish):
 
-.. code:: console
+.. code-block:: console
 
       $ qvm-create --property=virt_mode=hvm --property=memory=4096 --property=kernel='' --label red --standalone --root-move-from /home/user/win10-root.img win10
 
@@ -431,7 +431,7 @@ From within dom0, create a new HVM (here called ``win10``) with the root image w
 
 Start ``win10``:
 
-.. code:: console
+.. code-block:: console
 
       $ qvm-start win10
 
@@ -443,7 +443,7 @@ Optional ways to get more information
 
 Filetype of OVA file:
 
-.. code:: console
+.. code-block:: console
 
       $ file *.ova
 
@@ -451,7 +451,7 @@ Filetype of OVA file:
 
 List files of OVA tar archive:
 
-.. code:: console
+.. code-block:: console
 
       $ tar -tf *.ova
 
@@ -459,7 +459,7 @@ List files of OVA tar archive:
 
 List filetypes supported by qemu-img:
 
-.. code:: console
+.. code-block:: console
 
       $ qemu-img -h | tail -n1
 
diff --git a/user/advanced-topics/usb-qubes.rst b/user/advanced-topics/usb-qubes.rst
index 77265bd0b9..8abceb3c20 100644
--- a/user/advanced-topics/usb-qubes.rst
+++ b/user/advanced-topics/usb-qubes.rst
@@ -28,7 +28,7 @@ If you’re reading this section, it’s likely because the installer did not al
 
 First, make sure you have the latest ``qubes-mgmt-salt-dom0-virtual-machines`` package by :ref:`updating dom0 <user/advanced-topics/how-to-install-software-in-dom0:how to update dom0>`. Then, enter the following command in dom0:
 
-.. code:: console
+.. code-block:: console
 
       $ sudo qubesctl state.sls qvm.usb-keyboard
 
@@ -46,7 +46,7 @@ Manual setup for USB keyboards
 
 In order to use a USB keyboard, you must first attach it to a USB qube, then give that qube permission to pass keyboard input to dom0. Edit the ``qubes.InputKeyboard`` policy file in dom0, which is located here:
 
-.. code:: text
+.. code-block:: text
 
       /etc/qubes-rpc/policy/qubes.InputKeyboard
 
@@ -54,7 +54,7 @@ In order to use a USB keyboard, you must first attach it to a USB qube, then giv
 
 Add a line like this one to the top of the file:
 
-.. code:: text
+.. code-block:: text
 
       sys-usb dom0 allow
 
@@ -66,7 +66,7 @@ You can now use your USB keyboard to log in to your dom0 user account (after LUK
 
 You can set up your system so that there’s a confirmation prompt each time the USB keyboard is connected. However, this will effectively disable your USB keyboard for dom0 user account login and the screen locker, so **don’t do this if you want to log into and unlock your device with a USB keyboard!** If you’re sure you wish to proceed, change the previous line to:
 
-.. code:: text
+.. code-block:: text
 
       sys-usb dom0 ask,default_target=dom0
 
@@ -110,7 +110,7 @@ Handling a USB mouse isn’t as critical as handling a keyboard, since you can l
 
 If you want to attach the USB mouse automatically anyway, you have to edit the ``qubes.InputMouse`` policy file in dom0, located at:
 
-.. code:: text
+.. code-block:: text
 
       /etc/qubes-rpc/policy/qubes.InputMouse
 
@@ -118,7 +118,7 @@ If you want to attach the USB mouse automatically anyway, you have to edit the `
 
 The first line should read similar to:
 
-.. code:: text
+.. code-block:: text
 
       sys-usb dom0 ask,default_target=dom0
 
@@ -130,7 +130,7 @@ If the file is empty or does not exist, something might have gone wrong during s
 
 In case you are absolutely sure you do not want to confirm mouse access from ``sys-usb`` to ``dom0``, you may add the following line to the top of the file:
 
-.. code:: text
+.. code-block:: text
 
       sys-usb dom0 allow
 
@@ -146,7 +146,7 @@ If :ref:`automatically creating a USB qube for use with a USB keyboard <user/adv
 
 You can create a USB qube using the management stack by executing the following command as root in dom0:
 
-.. code:: console
+.. code-block:: console
 
       $ sudo qubesctl state.sls qvm.sys-usb
 
diff --git a/user/advanced-topics/volume-backup-revert.rst b/user/advanced-topics/volume-backup-revert.rst
index 8cafefc60f..b5663a51e1 100644
--- a/user/advanced-topics/volume-backup-revert.rst
+++ b/user/advanced-topics/volume-backup-revert.rst
@@ -12,7 +12,7 @@ In Qubes, when you create a new VM, it’s volumes are stored in one of the syst
 
 For the private volume associated with a VM named *vmname*, you may inspect the value of ``revisions_to_keep`` from the dom0 CLI as follows:
 
-.. code:: console
+.. code-block:: console
 
       $ qvm-volume info vmname:private
 
@@ -20,7 +20,7 @@ For the private volume associated with a VM named *vmname*, you may inspect the
 
 The output of the above command will also display the “Available revisions (for revert)” at the bottom. For a very large volume in a small pool, ``revisions_to_keep`` should probably be set to the maximum value of 1 to minimize the possibility of the pool being accidentally filled up by snapshots. For a smaller volume for which you would like to have the future option of reverting, ``revisions_to_keep`` should probably be set to at least 2. To set ``revisions_to_keep`` for this same VM / volume example:
 
-.. code:: console
+.. code-block:: console
 
       $ qvm-volume config vmname:private revisions_to_keep 2
 
@@ -28,7 +28,7 @@ The output of the above command will also display the “Available revisions (fo
 
 With the VM stopped, you may revert to an older snapshot of the private volume from the above list of “Available revisions (for revert)”, where the last item on the list with the largest integer is the most recent snapshot:
 
-.. code:: console
+.. code-block:: console
 
       $ qvm-volume revert vmname:private <revision>
 
diff --git a/user/downloading-installing-upgrading/installation-guide.rst b/user/downloading-installing-upgrading/installation-guide.rst
index 222607df60..c85ba08ecb 100644
--- a/user/downloading-installing-upgrading/installation-guide.rst
+++ b/user/downloading-installing-upgrading/installation-guide.rst
@@ -57,7 +57,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:: console
+.. code-block:: console
 
       $ sudo dd if=Qubes-RX-x86_64.iso of=/dev/sdY status=progress bs=1M conv=fsync
 
diff --git a/user/downloading-installing-upgrading/testing.rst b/user/downloading-installing-upgrading/testing.rst
index 6be34cd111..be20e9713d 100644
--- a/user/downloading-installing-upgrading/testing.rst
+++ b/user/downloading-installing-upgrading/testing.rst
@@ -62,7 +62,7 @@ How to test :doc:`templates </user/templates/templates>`:
 
 To temporarily enable any of these repos, use the ``--enablerepo=<repo-name>`` option. Example commands:
 
-.. code:: console
+.. code-block:: console
 
       $ qvm-template --enablerepo=qubes-templates-itl-testing list --available
       $ qvm-template --enablerepo=qubes-templates-itl-testing install <template_name>
diff --git a/user/downloading-installing-upgrading/upgrade/2.rst b/user/downloading-installing-upgrading/upgrade/2.rst
index 3471e42ce8..b432ea3ab0 100644
--- a/user/downloading-installing-upgrading/upgrade/2.rst
+++ b/user/downloading-installing-upgrading/upgrade/2.rst
@@ -31,7 +31,7 @@ Note that dom0 in R2 is based on Fedora 20, in contrast to Fedora 18 in previous
 
 2. Install all the updates for Dom0:
 
-   .. code:: console
+   .. code-block:: console
 
          $ sudo qubes-dom0-update
 
@@ -49,7 +49,7 @@ After this step you should have ``qubes-release-2-5`` in your Dom0. Important: i
 
 **Note:** be sure that the VM used as a update-downloading-vm (by default its the firewallvm based on the default template) has been updated to the latest Qubes packages, specifically ``qubes-core-vm-2.1.33`` or later. This doesn’t imply that the VM must already be upgraded to fc20 – for Dom0 upgrade we could still use an fc18-based VM (updatevm) it is only important to install the latest Qubes packages there.
 
-.. code:: console
+.. code-block:: console
 
       $ sudo qubes-dom0-update qubes-dom0-dist-upgrade
       $ sudo qubes-dom0-update
@@ -64,7 +64,7 @@ After this step you should have ``qubes-release-2-5`` in your Dom0. Important: i
 
 4a. If you chose not to upgrade your fc18 templates, but instead to download our new fc20-based template you should now be able to do that by simply typing:
 
-.. code:: console
+.. code-block:: console
 
       $ sudo qubes-dom0-update qubes-template-fedora-20-x64
 
diff --git a/user/downloading-installing-upgrading/upgrade/2b1.rst b/user/downloading-installing-upgrading/upgrade/2b1.rst
index ead3f7ffec..1c10a30aa9 100644
--- a/user/downloading-installing-upgrading/upgrade/2b1.rst
+++ b/user/downloading-installing-upgrading/upgrade/2b1.rst
@@ -19,7 +19,7 @@ By default, in Qubes R1, there is only one template, however users are free to c
 
 2. Install ``qubes-upgrade-vm`` package (this package brings in R2 repo definitions and R2 keys)
 
-   .. code:: console
+   .. code-block:: console
 
          $ sudo yum install qubes-upgrade-vm
 
@@ -27,14 +27,14 @@ By default, in Qubes R1, there is only one template, however users are free to c
 
 3. Proceed with normal update in the template (this should bring in also the R2 packages for the VMs):
 
-   .. code:: console
+   .. code-block:: console
 
          $ sudo yum update
 
 
    The installer (yum) will prompt to accept the new Qubes R2 signing key:
 
-   .. code:: output
+   .. code-block:: output
 
          Importing GPG key 0x0A40E458:
           Userid     : "Qubes OS Release 2 Signing Key"
@@ -70,7 +70,7 @@ Be sure to do steps described in this section after *all* your template and stan
 
 2. Upgrade the ``qubes-release`` package to the latest version which brings in new repo definitions and R2 signing keys:
 
-   .. code:: console
+   .. code-block:: console
 
          $ sudo qubes-dom0-update qubes-release
 
@@ -79,7 +79,7 @@ Be sure to do steps described in this section after *all* your template and stan
 
 3. Install R2 packages:
 
-   .. code:: console
+   .. code-block:: console
 
          $ sudo qubes-dom0-update --releasever=2
 
diff --git a/user/downloading-installing-upgrading/upgrade/2b2.rst b/user/downloading-installing-upgrading/upgrade/2b2.rst
index da2b9fc808..c644f0ab74 100644
--- a/user/downloading-installing-upgrading/upgrade/2b2.rst
+++ b/user/downloading-installing-upgrading/upgrade/2b2.rst
@@ -17,7 +17,7 @@ By default, in Qubes R1, there is only one template, however users are free to c
 
 2. Install ``qubes-upgrade-vm`` package (this package brings in R2 repo definitions and R2 keys)
 
-   .. code:: console
+   .. code-block:: console
 
          $ sudo yum install qubes-upgrade-vm
 
@@ -25,14 +25,14 @@ By default, in Qubes R1, there is only one template, however users are free to c
 
 3. Proceed with normal update in the template (this should bring in also the R2 packages for the VMs):
 
-   .. code:: console
+   .. code-block:: console
 
          $ sudo yum update
 
 
    The installer (yum) will prompt to accept the new Qubes R2 signing key:
 
-   .. code:: output
+   .. code-block:: output
 
          Importing GPG key 0x0A40E458:
           Userid     : "Qubes OS Release 2 Signing Key"
@@ -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:: console
+.. code-block:: console
 
       $ sudo -s
       # mkdir -p /mnt/cdrom
@@ -86,7 +86,7 @@ Be sure to do steps described in this section after *all* your template and stan
 
 2. Upgrade the ``qubes-release`` package to the latest version which brings in new repo definitions and R2 signing keys:
 
-   .. code:: console
+   .. code-block:: console
 
          $ sudo qubes-dom0-update qubes-release
 
@@ -95,7 +95,7 @@ Be sure to do steps described in this section after *all* your template and stan
 
 3. Install R2 upgrade package:
 
-   .. code:: console
+   .. code-block:: console
 
          $ sudo qubes-dom0-update --releasever=1 qubes-dist-upgrade
 
@@ -103,7 +103,7 @@ Be sure to do steps described in this section after *all* your template and stan
 
 4. Start upgrade process:
 
-   .. code:: console
+   .. code-block:: console
 
          $ sudo qubes-dist-upgrade
 
@@ -115,7 +115,7 @@ Be sure to do steps described in this section after *all* your template and stan
 
 7. When system starts up, login and start start
 
-   .. code:: console
+   .. code-block:: console
 
          $ sudo qubes-dist-upgrade
 
diff --git a/user/downloading-installing-upgrading/upgrade/2b3.rst b/user/downloading-installing-upgrading/upgrade/2b3.rst
index 81c3dd32b4..d17fbbfd44 100644
--- a/user/downloading-installing-upgrading/upgrade/2b3.rst
+++ b/user/downloading-installing-upgrading/upgrade/2b3.rst
@@ -21,7 +21,7 @@ It is critical to complete this step **before** proceeding to dom0 upgrade. Othe
 
 2. Proceed with normal update in the template:
 
-   .. code:: console
+   .. code-block:: console
 
          $ sudo yum update
 
@@ -29,7 +29,7 @@ It is critical to complete this step **before** proceeding to dom0 upgrade. Othe
 
 3. Ensure that you’ve got qubes-core-vm package version 2.1.13-3.fc18:
 
-   .. code:: console
+   .. code-block:: console
 
          $ rpm -q qubes-core-vm
 
@@ -37,7 +37,7 @@ It is critical to complete this step **before** proceeding to dom0 upgrade. Othe
 
 4. Update the system to R2 beta3 packages:
 
-   .. code:: console
+   .. code-block:: console
 
          $ sudo yum --enablerepo=qubes-vm-r2b3-current update
 
@@ -57,7 +57,7 @@ Be sure to do steps described in this section after *all* your template and stan
 
 2. Upgrade the ``qubes-release`` package to the latest version which brings in new repo definitions and R2 signing keys:
 
-   .. code:: console
+   .. code-block:: console
 
          $ sudo qubes-dom0-update qubes-release
 
@@ -66,7 +66,7 @@ Be sure to do steps described in this section after *all* your template and stan
 
 3. Upgrade dom0 to R2 beta3:
 
-   .. code:: console
+   .. code-block:: console
 
          $ sudo qubes-dom0-update --enablerepo=qubes-dom0-r2b3-current
 
@@ -76,7 +76,7 @@ Be sure to do steps described in this section after *all* your template and stan
 
 5. Now is the time to shutdown all the VMs:
 
-   .. code:: console
+   .. code-block:: console
 
          $ qvm-shutdown --all --wait
 
diff --git a/user/downloading-installing-upgrading/upgrade/3_0.rst b/user/downloading-installing-upgrading/upgrade/3_0.rst
index db6ee1cf23..db4a094b4e 100644
--- a/user/downloading-installing-upgrading/upgrade/3_0.rst
+++ b/user/downloading-installing-upgrading/upgrade/3_0.rst
@@ -27,7 +27,7 @@ Upgrade Fedora template:
 
 2. Install ``qubes-upgrade-vm`` package:
 
-   .. code:: console
+   .. code-block:: console
 
          $ sudo yum install qubes-upgrade-vm
 
@@ -35,7 +35,7 @@ Upgrade Fedora template:
 
 3. Proceed with normal update in the template:
 
-   .. code:: console
+   .. code-block:: console
 
          $ sudo yum update
 
@@ -54,7 +54,7 @@ Upgrade Debian template:
 
 2. Update repository definition:
 
-   .. code:: console
+   .. code-block:: console
 
          $ sudo cp /etc/apt/sources.list.d/qubes-r2.list /etc/apt/sources.list.d/qubes-r3-upgrade.list
          $ sudo sed -i 's/r2/r3.0/' /etc/apt/sources.list.d/qubes-r3-upgrade.list
@@ -63,7 +63,7 @@ Upgrade Debian template:
 
 3. Proceed with normal update in the template:
 
-   .. code:: console
+   .. code-block:: console
 
          $ sudo apt-get update
          $ sudo apt-get dist-upgrade
@@ -85,7 +85,7 @@ Be sure to do steps described in this section after *all* your template and stan
 
 2. Upgrade the ``qubes-release`` package to the latest version which brings in new repo definitions and R2 signing keys:
 
-   .. code:: console
+   .. code-block:: console
 
          $ sudo qubes-dom0-update qubes-release
 
@@ -94,7 +94,7 @@ Be sure to do steps described in this section after *all* your template and stan
 
 3. Upgrade dom0 to R3.0:
 
-   .. code:: console
+   .. code-block:: console
 
          $ sudo qubes-dom0-update --releasever=3.0
 
@@ -105,7 +105,7 @@ Be sure to do steps described in this section after *all* your template and stan
 
 5. Enable Xen services:
 
-   .. code:: console
+   .. code-block:: console
 
          $ sudo systemctl enable xenconsoled.service xenstored.service
 
@@ -123,7 +123,7 @@ Please note that if you use Anti Evil Maid, then it won’t be able to unseal th
 
 Now, when you have dom0 upgraded, you can install new templates from Qubes R3.0 repositories. Especially Fedora 21 - default Qubes R3.0 template:
 
-.. code:: console
+.. code-block:: console
 
       $ sudo qubes-dom0-update qubes-template-fedora-21
 
@@ -149,7 +149,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:: console
+   .. code-block:: console
 
          [user@dom0 ~]$ qvm-ls -n custom-template
          -------------------+----+--------+-------+------+-------------+-------+-------------+---------+-------------+
@@ -160,7 +160,7 @@ Because of above limitations, you will need to configure some of those manually.
 
 2. Start the VM from command line:
 
-   .. code:: console
+   .. code-block:: console
 
          [user@dom0 ~]$ qvm-start custom-template
          --> Loading the VM (type = template)...
@@ -176,14 +176,14 @@ Because of above limitations, you will need to configure some of those manually.
 
 3. Access VM console:
 
-   .. code:: console
+   .. code-block:: console
 
          [user@dom0 ~]$ virsh -c xen:/// console custom-template
 
 
 4. Configure network according to parameters retrieved in first step:
 
-   .. code:: console
+   .. code-block:: console
 
          $ ip addr add 10.137.1.53/32 dev eth0
          $ ip route add 10.137.1.1/32 dev eth0
diff --git a/user/downloading-installing-upgrading/upgrade/3_1.rst b/user/downloading-installing-upgrading/upgrade/3_1.rst
index 06640f19ea..a67a479293 100644
--- a/user/downloading-installing-upgrading/upgrade/3_1.rst
+++ b/user/downloading-installing-upgrading/upgrade/3_1.rst
@@ -21,7 +21,7 @@ Upgrade Fedora templates:
 
 2. Install the ``qubes-upgrade-vm`` package:
 
-   .. code:: console
+   .. code-block:: console
 
          $ sudo yum install qubes-upgrade-vm
 
@@ -29,7 +29,7 @@ Upgrade Fedora templates:
 
 3. Proceed with a normal upgrade in the template:
 
-   .. code:: console
+   .. code-block:: console
 
          $ sudo yum upgrade
 
@@ -47,7 +47,7 @@ Upgrade Debian (and Whonix) templates:
 
 2. Update repository definition:
 
-   .. code:: console
+   .. code-block:: console
 
          $ sudo cp /etc/apt/sources.list.d/qubes-r3.list /etc/apt/sources.list.d/qubes-r3-upgrade.list
          $ sudo sed -i 's/r3.0/r3.1/' /etc/apt/sources.list.d/qubes-r3-upgrade.list
@@ -56,7 +56,7 @@ Upgrade Debian (and Whonix) templates:
 
 3. Proceed with a normal update in the template:
 
-   .. code:: console
+   .. code-block:: console
 
          $ sudo apt-get update
          $ sudo apt-get dist-upgrade
@@ -65,7 +65,7 @@ Upgrade Debian (and Whonix) templates:
 
 4. Remove unnecessary now file:
 
-   .. code:: console
+   .. code-block:: console
 
          $ sudo rm -f /etc/apt/sources.list.d/qubes-r3-upgrade.list
 
@@ -85,7 +85,7 @@ Upgrading dom0
 
 2. Upgrade dom0 to R3.1:
 
-   .. code:: console
+   .. code-block:: console
 
          $ sudo qubes-dom0-update --releasever=3.1
 
@@ -108,7 +108,7 @@ If you use USB VM, you may encounter problem with starting it on updated Xen ver
 
 Once you have upgraded dom0, you can install new templates from Qubes R3.1 repositories, in particular the new default Fedora 23 template:
 
-.. code:: console
+.. code-block:: console
 
       $ sudo qubes-dom0-update qubes-template-fedora-23
 
diff --git a/user/downloading-installing-upgrading/upgrade/3_2.rst b/user/downloading-installing-upgrading/upgrade/3_2.rst
index a35a99254f..4c893d7b16 100644
--- a/user/downloading-installing-upgrading/upgrade/3_2.rst
+++ b/user/downloading-installing-upgrading/upgrade/3_2.rst
@@ -17,7 +17,7 @@ Upgrading dom0
 
 3. Install ``qubes-release`` package carrying R3.2 repository information.
 
-   .. code:: console
+   .. code-block:: console
 
          $ sudo qubes-dom0-update --releasever=3.2 qubes-release
 
@@ -29,7 +29,7 @@ Upgrading dom0
 
 
 
-   .. code:: console
+   .. code-block:: console
 
          $ sudo qubes-dom0-update systemd-compat-libs perl-libwww-perl perl-Term-ANSIColor perl-Term-Cap gdk-pixbuf2-xlib speexdsp qubes-mgmt-salt-admin-tools lvm2
          (...)
@@ -48,7 +48,7 @@ Upgrading dom0
 
 4. Upgrade dom0 to R3.2:
 
-   .. code:: console
+   .. code-block:: console
 
          $ sudo qubes-dom0-update
 
@@ -66,7 +66,7 @@ Upgrading dom0
 
 
 
-   .. code:: output
+   .. code-block:: output
 
          warning: /etc/salt/minion.d/f_defaults.conf created as /etc/salt/minion.d/f_defaults.conf.rpmnew
 
@@ -76,7 +76,7 @@ Upgrading dom0
 
 
 
-   .. code:: console
+   .. code-block:: console
 
          $ rm -f /etc/group.rpmnew
          $ rm -f /etc/shadow.rpmnew
@@ -116,7 +116,7 @@ Upgrade Fedora templates:
 
 2. Install the ``qubes-upgrade-vm`` package:
 
-   .. code:: console
+   .. code-block:: console
 
          $ sudo dnf install --refresh qubes-upgrade-vm
 
@@ -124,7 +124,7 @@ Upgrade Fedora templates:
 
 3. Proceed with a normal upgrade in the template:
 
-   .. code:: console
+   .. code-block:: console
 
          $ sudo dnf upgrade --refresh
 
@@ -132,7 +132,7 @@ Upgrade Fedora templates:
 
 4. Add new packages (only needed in default template):
 
-   .. code:: console
+   .. code-block:: console
 
          $ sudo dnf install qubes-mgmt-salt-vm-connector
 
@@ -150,7 +150,7 @@ Upgrade Debian (and Whonix) templates:
 
 2. Update repository definition:
 
-   .. code:: console
+   .. code-block:: console
 
          $ sudo cp /etc/apt/sources.list.d/qubes-r3.list /etc/apt/sources.list.d/qubes-r3-upgrade.list
          $ sudo sed -i 's/r3.1/r3.2/' /etc/apt/sources.list.d/qubes-r3-upgrade.list
@@ -159,7 +159,7 @@ Upgrade Debian (and Whonix) templates:
 
 3. Proceed with a normal update in the template:
 
-   .. code:: console
+   .. code-block:: console
 
          $ sudo apt-get update
          $ sudo apt-get dist-upgrade
@@ -168,7 +168,7 @@ Upgrade Debian (and Whonix) templates:
 
 4. Add new packages (only needed in default template):
 
-   .. code:: console
+   .. code-block:: console
 
          $ sudo apt-get install qubes-mgmt-salt-vm-connector
 
@@ -176,7 +176,7 @@ Upgrade Debian (and Whonix) templates:
 
 5. Remove unnecessary now file:
 
-   .. code:: console
+   .. code-block:: console
 
          $ sudo rm -f /etc/apt/sources.list.d/qubes-r3-upgrade.list
 
diff --git a/user/downloading-installing-upgrading/upgrade/4_0.rst b/user/downloading-installing-upgrading/upgrade/4_0.rst
index a094e3396d..c25839d955 100644
--- a/user/downloading-installing-upgrading/upgrade/4_0.rst
+++ b/user/downloading-installing-upgrading/upgrade/4_0.rst
@@ -63,7 +63,7 @@ Restore from your backup
 
 2. Since patches may have been released since your installation image was created, update Qubes R4.0 by going to the dom0 command line (**Qubes menu -> Terminal Emulator**) then running:
 
-   .. code:: console
+   .. code-block:: console
 
          $ sudo qubes-dom0-update
 
diff --git a/user/downloading-installing-upgrading/upgrade/4_1.rst b/user/downloading-installing-upgrading/upgrade/4_1.rst
index 7f0ec23832..ddb5aa73ed 100644
--- a/user/downloading-installing-upgrading/upgrade/4_1.rst
+++ b/user/downloading-installing-upgrading/upgrade/4_1.rst
@@ -37,7 +37,7 @@ The upgrade may take several hours, and will download several gigabytes of data.
 
 In place upgrade is a complex operation. For this reason, we provide a ``qubes-dist-upgrade`` tool to handle all the necessary steps automatically. You can install it with the following command in the dom0 terminal:
 
-.. code:: console
+.. code-block:: console
 
       $ sudo qubes-dom0-update -y qubes-dist-upgrade
 
@@ -47,7 +47,7 @@ The upgrade consists of seven stages — six before restarting the system — la
 
 Full list of options can be obtained with ``qubes-dist-upgrade --help``:
 
-.. code:: output
+.. code-block:: output
 
       Usage: qubes-dist-upgrade [OPTIONS]...
 
@@ -82,7 +82,7 @@ Full list of options can be obtained with ``qubes-dist-upgrade --help``:
 
 After installing the tool, upgrade can be performed all at once with:
 
-.. code:: console
+.. code-block:: console
 
       $ sudo qubes-dist-upgrade --all
 
@@ -94,7 +94,7 @@ Alternatively, each upgrade stage can be started separately (see the list of opt
 
 After completing “STAGE 0” through “STAGE 5”, restart the system. Then perform the final step:
 
-.. code:: console
+.. code-block:: console
 
       $ sudo qubes-dist-upgrade --resync-appmenus-features
 
diff --git a/user/downloading-installing-upgrading/upgrade/4_2.rst b/user/downloading-installing-upgrading/upgrade/4_2.rst
index a579f810ac..75fc408cba 100644
--- a/user/downloading-installing-upgrading/upgrade/4_2.rst
+++ b/user/downloading-installing-upgrading/upgrade/4_2.rst
@@ -21,7 +21,7 @@ If you would prefer to perform a clean installation rather than upgrading in-pla
 
 2. Install the ``qubes-dist-upgrade`` tool. This is the inplace upgrade tool, which is not what we’re doing. However it will be needed in order to prepare the templates for the 4.2 version. You install it with the following command in the dom0 terminal:
 
-   .. code:: console
+   .. code-block:: console
 
          $ sudo qubes-dom0-update -y qubes-dist-upgrade
 
@@ -29,7 +29,7 @@ If you would prefer to perform a clean installation rather than upgrading in-pla
 
 3. Change your templates to use the 4.2 repositories instead of the 4.1 ones. You do this with the following command in the dom0 terminal:
 
-   .. code:: console
+   .. code-block:: console
 
          qubes-dist-upgrade --template-standalone-upgrade
 
@@ -56,7 +56,7 @@ The upgrade may take several hours, and will download several gigabytes of data.
 
 In place upgrade is a complex operation. For this reason, we provide a ``qubes-dist-upgrade`` tool to handle all the necessary steps automatically. You can install it with the following command in the dom0 terminal:
 
-.. code:: console
+.. code-block:: console
 
       $ sudo qubes-dom0-update -y qubes-dist-upgrade
 
@@ -66,7 +66,7 @@ The upgrade consists of six stages — three before restarting the system — la
 
 Full list of options can be obtained with ``qubes-dist-upgrade --help``:
 
-.. code:: output
+.. code-block:: output
 
       Usage: qubes-dist-upgrade [OPTIONS]...
 
@@ -102,7 +102,7 @@ Full list of options can be obtained with ``qubes-dist-upgrade --help``:
 
 After installing the tool, before-reboot stages can be performed at once with:
 
-.. code:: console
+.. code-block:: console
 
       $ sudo qubes-dist-upgrade --all-pre-reboot
 
@@ -114,7 +114,7 @@ Alternatively, each upgrade stage can be started separately (see the list of opt
 
 After completing “STAGE 1” through “STAGE 3”, restart the system. Then perform the final steps:
 
-.. code:: console
+.. code-block:: console
 
       $ sudo qubes-dist-upgrade --all-post-reboot
 
diff --git a/user/downloading-installing-upgrading/upgrade/4_3.rst b/user/downloading-installing-upgrading/upgrade/4_3.rst
index 00285a4c1e..526d817294 100644
--- a/user/downloading-installing-upgrading/upgrade/4_3.rst
+++ b/user/downloading-installing-upgrading/upgrade/4_3.rst
@@ -37,13 +37,13 @@ If you would prefer to perform a clean installation rather than upgrading in-pla
 
    1. :ref:`Install in dom0 <install-package-in-dom0>` the :program:`qubes-dist-upgrade` tool, in order to be able to upgrade the templates to the Qubes 4.3 version:
 
-      .. code:: console
+      .. code-block:: console
 
          [user@dom0] $ sudo qubes-dom0-update qubes-dist-upgrade
 
    2. Change your templates to use the 4.3 repositories instead of the 4.2 ones. You do this with the following command in the dom0 terminal:
 
-      .. code:: console
+      .. code-block:: console
 
           [user@dom0] $ sudo qubes-dist-upgrade --releasever=4.3 --template-standalone-upgrade
 
@@ -65,13 +65,13 @@ How-to upgrade from Qubes 4.2 to Qubes 4.3 in-place
 
 1. You have to :ref:`install qubes-dist-upgrade in dom0 <install-package-in-dom0>`:
 
-   .. code:: console
+   .. code-block:: console
 
       [user@dom0] $ sudo qubes-dom0-update qubes-dist-upgrade
 
 2. After installing the tool, pre-reboot stages can be performed at once with:
 
-   .. code:: console
+   .. code-block:: console
 
       [user@dom0] $ sudo qubes-dist-upgrade --releasever 4.3 --all-pre-reboot
 
@@ -83,7 +83,7 @@ How-to upgrade from Qubes 4.2 to Qubes 4.3 in-place
 
 4. Then perform the final steps:
 
-   .. code:: console
+   .. code-block:: console
 
       [user@dom0] $ sudo qubes-dist-upgrade --releasever 4.3 --all-post-reboot
 
diff --git a/user/how-to-guides/backup-emergency-restore-v2.rst b/user/how-to-guides/backup-emergency-restore-v2.rst
index 8e6e0d2ddc..93e9e1fdb4 100644
--- a/user/how-to-guides/backup-emergency-restore-v2.rst
+++ b/user/how-to-guides/backup-emergency-restore-v2.rst
@@ -11,7 +11,7 @@ The Qubes backup system has been designed with emergency disaster recovery in mi
 
 1. Untar the main backup file.
 
-   .. code:: console
+   .. code-block:: 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:: console
+   .. code-block:: 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:: console
+   .. code-block:: 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:: console
+   .. code-block:: 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
 
@@ -71,7 +71,7 @@ The Qubes backup system has been designed with emergency disaster recovery in mi
 
 **Note:** For multi-part files, a loop can be used:
 
-.. code:: bash
+.. code-block:: bash
 
       #!/bin/sh
       find -name 'private.img.*' | sort -V | while read f; do
@@ -85,7 +85,7 @@ The Qubes backup system has been designed with emergency disaster recovery in mi
 
 5. Decompress the decrypted ``private.img`` file.
 
-   .. code:: console
+   .. code-block:: console
 
          [user@restore vm1]$ zforce private.img.dec.*
          [user@restore vm1]$ gunzip private.img.dec.000.gz
@@ -100,7 +100,7 @@ The Qubes backup system has been designed with emergency disaster recovery in mi
 
 6. Untar the decrypted and decompressed ``private.img`` file.
 
-   .. code:: console
+   .. code-block:: console
 
          [user@restore vm1]$ tar -M -xvf private.img.dec.000
          vm1/private.img
@@ -110,7 +110,7 @@ The Qubes backup system has been designed with emergency disaster recovery in mi
 
    1. Create a ``new-volume-script``:
 
-      .. code:: bash
+      .. code-block:: bash
 
             #!/bin/sh
             name=`expr $TAR_ARCHIVE : '\(.*\)\..*'`
@@ -127,7 +127,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:: console
+   .. code-block:: console
 
          [user@restore vm1]$ sudo mkdir /mnt/img
          [user@restore vm1]$ sudo mount -o loop vm1/private.img /mnt/img/
diff --git a/user/how-to-guides/backup-emergency-restore-v3.rst b/user/how-to-guides/backup-emergency-restore-v3.rst
index 079721588f..8f44eb39bd 100644
--- a/user/how-to-guides/backup-emergency-restore-v3.rst
+++ b/user/how-to-guides/backup-emergency-restore-v3.rst
@@ -11,7 +11,7 @@ The Qubes backup system has been designed with emergency disaster recovery in mi
 
 1. Untar the main backup file.
 
-   .. code:: console
+   .. code-block:: 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:: console
+   .. code-block:: 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:: console
+   .. code-block:: 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:: console
+   .. code-block:: 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:: console
+   .. code-block:: 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:: console
+   .. code-block:: 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:: console
+   .. code-block:: 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:: console
+   .. code-block:: 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:: console
+   .. code-block:: 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:: console
+   .. code-block:: console
 
          [user@restore vm1]$ sudo mkdir /mnt/img
          [user@restore vm1]$ sudo mount -o loop vm1/private.img /mnt/img/
diff --git a/user/how-to-guides/backup-emergency-restore-v4.rst b/user/how-to-guides/backup-emergency-restore-v4.rst
index f8f1763e9c..ce32a6f66b 100644
--- a/user/how-to-guides/backup-emergency-restore-v4.rst
+++ b/user/how-to-guides/backup-emergency-restore-v4.rst
@@ -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:: console
+   .. code-block:: 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:: console
+   .. code-block:: console
 
          [user@restore ~]$ dnf download scrypt
 
 
    Or, if that doesn’t work:
 
-   .. code:: console
+   .. code-block:: 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:: console
+   .. code-block:: 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:: console
+   .. code-block:: 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:: console
+   .. code-block:: 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:: console
+   .. code-block:: 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:: console
+   .. code-block:: 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:: console
+   .. code-block:: console
 
          [user@restore ~]$ set +H
          [user@restore ~]$ echo "backup-header!$backup_pass" |\
@@ -117,7 +117,7 @@ Emergency recovery instructions
 
 4. Read ``backup-header``.
 
-   .. code:: console
+   .. code-block:: 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:: console
+   .. code-block:: 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:: console
+   .. code-block:: 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:: console
+   .. code-block:: 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:: console
+   .. code-block:: 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:: console
+   .. code-block:: console
 
          [user@restore ~]$ find vm123/ -name 'private.img.*.enc' | sort -V | while read f_enc; do \
              f_dec=${f_enc%.enc}; \
@@ -207,7 +207,7 @@ Emergency recovery instructions
   .. warning::   Beside the security risk of accessing compromised *files*,  there can be security consequences of simply mounting *file systems* if an attacker had been able to compromise the file system in some way. For better security, handle these files within an isolated environment like a dedicated VM, a Live USB, or by using `libguestfs <https://libguestfs.org/>`__
 
 
-  .. code:: console
+  .. code-block:: console
 
          [user@restore ~]$ sudo mkdir /mnt/img
          [user@restore ~]$ sudo mount -o loop vm123/private.img /mnt/img/
diff --git a/user/how-to-guides/how-to-back-up-restore-and-migrate.rst b/user/how-to-guides/how-to-back-up-restore-and-migrate.rst
index 2fed9d0c85..6aa620da57 100644
--- a/user/how-to-guides/how-to-back-up-restore-and-migrate.rst
+++ b/user/how-to-guides/how-to-back-up-restore-and-migrate.rst
@@ -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:: console
+.. code-block:: console
 
       $ mkdir -p ~/backup/etc/qubes/
       $ cp -a /etc/qubes/* ~/backup/etc/qubes/
diff --git a/user/how-to-guides/how-to-copy-and-move-files.rst b/user/how-to-guides/how-to-copy-and-move-files.rst
index b194084ff7..9010b44d03 100644
--- a/user/how-to-guides/how-to-copy-and-move-files.rst
+++ b/user/how-to-guides/how-to-copy-and-move-files.rst
@@ -15,7 +15,7 @@ For simplicity, these instructions will refer to copying/moving a single file, b
 
 3. If the target qube is not already running, it will be started automatically, and the file will be copied there. It will show up in this directory (which will automatically be created if it does not already exist):
 
-   .. code:: text
+   .. code-block:: text
 
          /home/user/QubesIncoming/<source_qube>/<filename>
 
@@ -28,13 +28,13 @@ For simplicity, these instructions will refer to copying/moving a single file, b
 
 The same operations are also available via these command-line tools:
 
-.. code:: console
+.. code-block:: console
 
       $ qvm-copy [--without-progress] file [file]+
 
 
 
-.. code:: console
+.. code-block:: console
 
       $ qvm-move [--without-progress] file [file]+
 
diff --git a/user/how-to-guides/how-to-copy-and-paste-text.rst b/user/how-to-guides/how-to-copy-and-paste-text.rst
index 0a24a5f3b4..5f3c95d01f 100644
--- a/user/how-to-guides/how-to-copy-and-paste-text.rst
+++ b/user/how-to-guides/how-to-copy-and-paste-text.rst
@@ -62,7 +62,7 @@ The copy/paste shortcuts are configurable via :program:`Qubes OS Global Config`,
 You can also change them using :doc:`qvm-features <core-admin-client:manpages/qvm-features>`.
 The following commands would change the *copy/paste to global clipboard* shortcuts to :kbd:`Win` + :kbd:`c` for copy, and :kbd:`Win` + :kbd:`v` for paste:
 
-.. code:: console
+.. code-block:: console
 
       [user@dom0] $ qvm-features dom0 gui-default-secure-copy-sequence 'Mod4-c'
       [user@dom0] $ qvm-features dom0 gui-default-secure-paste-sequence 'Mod4-v'
diff --git a/user/how-to-guides/how-to-copy-from-dom0.rst b/user/how-to-guides/how-to-copy-from-dom0.rst
index 02e91c92d2..0ae2f8654c 100644
--- a/user/how-to-guides/how-to-copy-from-dom0.rst
+++ b/user/how-to-guides/how-to-copy-from-dom0.rst
@@ -15,7 +15,7 @@ Copying files from dom0
 
 To copy a file from dom0 to a VM, simply use ``qvm-copy-to-vm``:
 
-.. code:: console
+.. code-block:: console
 
       $ qvm-copy-to-vm <target_vm> <file>
 
@@ -71,7 +71,7 @@ There should normally be few reasons for the user to want to copy anything from
 
 If you are determined to copy some files to dom0 anyway, you can use the following method. (If you want to copy text, first save it into a text file.) Run this command in a dom0 terminal:
 
-.. code:: console
+.. code-block:: console
 
       $ qvm-run --pass-io <src-vm> 'cat /path/to/file_in_src_domain' > /path/to/file_name_in_dom0
 
@@ -79,7 +79,7 @@ If you are determined to copy some files to dom0 anyway, you can use the followi
 
 Note that you can use the same method to copy files from dom0 to domUs (if, for some reason, you don’t want to use ``qvm-copy-to-vm``):
 
-.. code:: console
+.. code-block:: console
 
       $ cat /path/to/file_in_dom0 | qvm-run --pass-io <dest-vm> 'cat > /path/to/file_name_in_appvm'
 
diff --git a/user/how-to-guides/how-to-edit-a-policy.rst b/user/how-to-guides/how-to-edit-a-policy.rst
index 473ef9a0d7..fd2d61c2ac 100644
--- a/user/how-to-guides/how-to-edit-a-policy.rst
+++ b/user/how-to-guides/how-to-edit-a-policy.rst
@@ -53,7 +53,7 @@ Edit a policy with :program:`Qubes Policy Editor`
 
 3. Add a line to the file. In order to prevent the *untrusted* qube from pasting to the *vault* qube, the line should be:
 
-   .. code:: text
+   .. code-block:: text
 
       qubes.ClipboardPaste *       untrusted       vault   deny
 
@@ -64,7 +64,7 @@ Edit a policy with :program:`qubes-policy-editor`
 
 :program:`qubes-policy-editor` is a command-line tool that ensures that the syntax of the policy is valid. You have to run it as root:
 
-.. code:: console
+.. code-block:: console
 
    [root@dom0] # qubes-policy-editor
 
@@ -72,7 +72,7 @@ An editor will open; it will be your default editor if you have set the environm
 
 It will open :file:`30-user.policy` by default but you can invoke the program with any valid filename (only alphanumeric characters, underscores and hyphens), without the ``.policy`` extension:
 
-.. code:: console
+.. code-block:: console
 
    [root@dom0] # qubes-policy-editor 30-clipboard
 
diff --git a/user/how-to-guides/how-to-enable-a-service.rst b/user/how-to-guides/how-to-enable-a-service.rst
index e409132aab..4f96eb5e7c 100644
--- a/user/how-to-guides/how-to-enable-a-service.rst
+++ b/user/how-to-guides/how-to-enable-a-service.rst
@@ -51,24 +51,24 @@ How to enable a service with :program:`qvm-service`
 
 In a dom0 terminal, enter the following command, replacing :samp:`{<QUBE_NAME>}` by the name of the qube and :samp:`{<SERVICE_NAME>}` by the name of the service:
 
-.. code:: console
+.. code-block:: console
 
    [user@dom0] $ qvm-service -e <QUBE_NAME> <SERVICE_NAME>
 
 This is equivalent to:
 
-.. code:: console
+.. code-block:: console
 
    [user@dom0] $ qvm-service <QUBE_NAME> <SERVICE_NAME> on
 
 You can check the current status of the services of one qube with the following command:
 
-.. code:: console
+.. code-block:: console
 
    [user@dom0] $ qvm-service <QUBE_NAME>
 
 Or you can check only the current status of one service with the following command:
 
-.. code:: console
+.. code-block:: console
 
    [user@dom0] $ qvm-service <QUBE_NAME> <SERVICE_NAME>
diff --git a/user/how-to-guides/how-to-enter-fullscreen-mode.rst b/user/how-to-guides/how-to-enter-fullscreen-mode.rst
index 0c2e0cf018..02ab97243f 100644
--- a/user/how-to-guides/how-to-enter-fullscreen-mode.rst
+++ b/user/how-to-guides/how-to-enter-fullscreen-mode.rst
@@ -68,7 +68,7 @@ With the command-line, targeting the qube
 
 In dom0, run the following command, replacing :samp:`{<QUBE_NAME>}` with the actual name of the qube:
 
-.. code:: console
+.. code-block:: console
 
    [user@dom0] $ qvm-features <QUBE_NAME> gui-allow-fullscreen 1
 
@@ -90,7 +90,7 @@ With the command-line, in dom0
 
 In dom0, run the following command:
 
-.. code:: console
+.. code-block:: console
 
    [user@dom0] $ qvm-features dom0 gui-default-allow-fullscreen 1
 
diff --git a/user/how-to-guides/how-to-install-software.rst b/user/how-to-guides/how-to-install-software.rst
index 98367ee26e..c33a4a6b6a 100644
--- a/user/how-to-guides/how-to-install-software.rst
+++ b/user/how-to-guides/how-to-install-software.rst
@@ -61,7 +61,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:: console
+.. code-block:: console
 
       $ export HTTP_PROXY=http://127.0.0.1:8082 http_proxy=$HTTP_PROXY \
                HTTPS_PROXY=$HTTP_PROXY https_proxy=$HTTPS_PROXY \
@@ -155,7 +155,7 @@ There are three Qubes VM testing repositories (where ``*`` denotes the Release):
 
 To temporarily enable any of these repos, use the ``--enablerepo=<repo-name>`` option. Example commands:
 
-.. code:: console
+.. code-block:: console
 
       $ sudo dnf upgrade --enablerepo=qubes-vm-*-current-testing
       $ sudo dnf upgrade --enablerepo=qubes-vm-*-security-testing
@@ -196,7 +196,7 @@ RPMFusion for Fedora templates
 
 If you would like to enable the `RPM Fusion <https://rpmfusion.org>`__ repositories, open a Terminal of the template and type the following commands, depending on which RPM Fusion repositories you wish to enable (see `RPM Fusion <https://rpmfusion.org>`__ for details):
 
-.. code:: console
+.. code-block:: console
 
       $ sudo dnf config-manager setopt rpmfusion-free.enabled=1
       $ sudo dnf config-manager setopt rpmfusion-free-updates.enabled=1
@@ -228,7 +228,7 @@ Root revert
 
 2. In a dom0 terminal:
 
-   .. code:: console
+   .. code-block:: console
 
          [user@dom0]$ qvm-volume revert <template>:root
 
@@ -270,7 +270,7 @@ The updates proxy uses RPC/qrexec. The proxy is configured in qrexec policy in d
 
 Example policy file in R4.2 (with Whonix installed, but not set as default UpdateVM for all templates):
 
-.. code:: text
+.. code-block:: text
 
       # HTTP proxy for downloading updates
       # Upgrade all TemplateVMs through sys-whonix.
@@ -291,7 +291,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:: console
+   .. code-block:: 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.
@@ -328,7 +328,7 @@ Snap packages do not use the normal update channels for Debian and Fedora (apt a
 
    You may see the following message:
 
-   .. code:: console
+   .. code-block:: console
 
          Failed to resolve booleanif statement at /var/lib/selinux/targeted/tmp/modules/200/snappy/cil:1174
          /usr/sbin/semodule:  Failed!
@@ -336,13 +336,13 @@ 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:: console
+   .. code-block:: 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:: console
+   .. code-block:: console
 
          [user@snap-demo-app qube ~]$ snap install <package>
 
@@ -361,7 +361,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:: console
+   .. code-block:: console
 
          [user@example-app qube ~]$ ls /usr/share/applications/
          bluetooth-sendto.desktop
@@ -373,13 +373,13 @@ If you want a desktop app to start automatically every time a qube starts you ca
 
 3. Create the autostart directory:
 
-   .. code:: console
+   .. code-block:: console
 
          [user@example-app qube ~]$ mkdir -p ~/.config/autostart
 
 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:: console
+   .. code-block:: console
 
          [user@example-app qube ~]$ ln -s /usr/share/applications/mozilla-thunderbird.desktop ~/.config/autostart/mozilla-thunderbird.desktop
 
diff --git a/user/how-to-guides/how-to-organize-your-qubes.rst b/user/how-to-guides/how-to-organize-your-qubes.rst
index a227a37a6e..810fd9964f 100644
--- a/user/how-to-guides/how-to-organize-your-qubes.rst
+++ b/user/how-to-guides/how-to-organize-your-qubes.rst
@@ -15,7 +15,7 @@ Alice, the software developer
 
 Alice is a freelance dev who works on several projects for different clients simultaneously. The projects have varying requirements and often different build environments. She has a separate set of qubes for each project. She keeps them organized by coming up with a naming scheme, such as:
 
-.. code:: text
+.. code-block:: text
 
       clientA-code
       clientA-build
diff --git a/user/how-to-guides/how-to-reinstall-a-template.rst b/user/how-to-guides/how-to-reinstall-a-template.rst
index 1922f3aebf..46edc2cd3b 100644
--- a/user/how-to-guides/how-to-reinstall-a-template.rst
+++ b/user/how-to-guides/how-to-reinstall-a-template.rst
@@ -11,7 +11,7 @@ Automatic Method
 
 First, copy any files that you wish to keep from the template’s ``/home`` and ``/rw`` folders to a safe storage location. Then, in a dom0 terminal, run:
 
-.. code:: console
+.. code-block:: console
 
       $ sudo qubes-dom0-update --action=reinstall qubes-template-package-name
 
@@ -23,7 +23,7 @@ Note that Qubes may initially refuse to perform the reinstall if the exact revis
 
 **Reminder:** If you’re trying to reinstall a template that is not in an enabled repo, you must enable that repo. For example:
 
-.. code:: console
+.. code-block:: console
 
       $ sudo qubes-dom0-update --enablerepo=qubes-templates-community --action=reinstall qubes-template-whonix-ws
 
@@ -51,14 +51,14 @@ In what follows, the term “target template” refers to whichever template you
 
 3. Uninstall the target template from dom0:
 
-   .. code:: console
+   .. code-block:: console
 
          $ sudo dnf remove <template-package-name>
 
 
    For example, to uninstall the ``whonix-gw`` template:
 
-   .. code:: console
+   .. code-block:: console
 
          $ sudo dnf remove qubes-template-whonix-gw
 
@@ -66,14 +66,14 @@ In what follows, the term “target template” refers to whichever template you
 
 4. Reinstall the target template in dom0:
 
-   .. code:: console
+   .. code-block:: console
 
          $ sudo qubes-dom0-update --enablerepo=<optional-additional-repo> \
             <template-package-name>
 
    For example, to install the ``whonix-gw`` template:
 
-   .. code:: console
+   .. code-block:: console
 
          $ sudo qubes-dom0-update --enablerepo=qubes-templates-community \
             qubes-template-whonix-gw
diff --git a/user/how-to-guides/how-to-set-a-wallpaper.rst b/user/how-to-guides/how-to-set-a-wallpaper.rst
index 91406951e8..3ae0b91510 100644
--- a/user/how-to-guides/how-to-set-a-wallpaper.rst
+++ b/user/how-to-guides/how-to-set-a-wallpaper.rst
@@ -24,7 +24,7 @@ In default Qubes OS installation, you can use the default XFCE screenshot tool (
 
 The file will be saved in :term:`dom0`, so you need to copy it out of :term:`dom0` if you want to use it in any other qube. The easiest way to do it is with the ``qvm-copy-to-vm`` tool in :term:`dom0` terminal:
 
-.. code:: console
+.. code-block:: console
 
     $ qvm-copy-to-vm qube-name Pictures/screenshot_name.jpg
 
diff --git a/user/how-to-guides/how-to-update.rst b/user/how-to-guides/how-to-update.rst
index 022ef80bb9..d116664348 100644
--- a/user/how-to-guides/how-to-update.rst
+++ b/user/how-to-guides/how-to-update.rst
@@ -100,7 +100,7 @@ Advanced users may wish to perform updates via the command-line interface. There
 
   - To check for dom0 updates and apply them, in a dom0 terminal:
 
-    .. code:: console
+    .. code-block:: console
 
        # qubes-dom0-update
 
@@ -108,7 +108,7 @@ Advanced users may wish to perform updates via the command-line interface. There
 
   - To update all updatable templates, in a dom0 terminal:
 
-    .. code:: console
+    .. code-block:: console
 
        $ qubes-vm-update -T
 
@@ -176,7 +176,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:: console
+.. code-block:: console
 
       $ sudo qubes-dom0-update fwupd-qubes-dom0
 
@@ -184,7 +184,7 @@ In a dom0 terminal, install the ``fwupd-qubes-dom0`` package:
 
 Once the package is installed:
 
-.. code:: console
+.. code-block:: console
 
       $ sudo qubes-fwupdmgr get-devices
 
@@ -192,7 +192,7 @@ Once the package is installed:
 
 Examine the terminal output for warnings or errors. You may see the following warning:
 
-.. code:: output
+.. code-block:: output
 
       WARNING: UEFI capsule updates not available or enabled
 
@@ -202,7 +202,7 @@ If so, `adjust your BIOS settings <https://github.com/fwupd/fwupd/wiki/PluginFla
 
 Once resolved, in a dom0 terminal:
 
-.. code:: console
+.. code-block:: console
 
       $ sudo qubes-fwupdmgr get-devices
       $ sudo qubes-fwupdmgr refresh
diff --git a/user/how-to-guides/how-to-use-block-storage-devices.rst b/user/how-to-guides/how-to-use-block-storage-devices.rst
index 913fb92407..85d04f674f 100644
--- a/user/how-to-guides/how-to-use-block-storage-devices.rst
+++ b/user/how-to-guides/how-to-use-block-storage-devices.rst
@@ -31,7 +31,7 @@ Block Devices in VMs
 
 If not specified otherwise, block devices will show up as ``/dev/xvdi*`` in a linux VM, where ``*`` may be the partition-number. If a block device isn’t automatically mounted after attaching, open a terminal in the VM and execute:
 
-.. code:: console
+.. code-block:: console
 
       $ cd ~
       $ mkdir mnt
@@ -56,20 +56,20 @@ In case of a USB-drive, make sure it’s attached to your computer. If you don
 
 1. In a dom0 console (running as a normal user), list all available block devices:
 
-   .. code:: console
+   .. code-block:: console
 
          $ qvm-block
 
    This will list all available block devices in your system across all VMs. The name of the qube hosting the block device is displayed before the colon in the device ID. The string after the colon is the ID of the device used within the qube, like so:
 
-   .. code:: output
+   .. code-block:: output
 
          sourceVM:sdb     Cruzer () 4GiB
          sourceVM:sdb1    Disk () 2GiB
 
 2. Assuming your block device is attached to ``sys-usb`` and its device node is ``sdb``, we attach the device to a qube with the name ``work`` like so:
 
-   .. code:: console
+   .. code-block:: console
 
          $ qvm-block attach work sys-usb:sdb
 
@@ -79,7 +79,7 @@ In case of a USB-drive, make sure it’s attached to your computer. If you don
 
 3. The block device is now attached to the qube. If using a default qube, you may open the Nautilus file manager in the qube, and your drive should be visible in the **Devices** panel on the left. If you’ve attached a single partition (e.g. ``sdb2`` instead of ``sdb`` in our example), you may need to manually mount before it becomes visible:
 
-   .. code:: console
+   .. code-block:: console
 
          $ cd ~
          $ mkdir mnt
@@ -89,13 +89,13 @@ In case of a USB-drive, make sure it’s attached to your computer. If you don
 
    - If you’ve manually mounted a single partition in the above step, use:
 
-   .. code:: console
+   .. code-block:: console
 
          $ sudo umount mnt
 
 5. In a dom0 console, detach the device
 
-   .. code:: console
+   .. code-block:: console
 
          $ qvm-block detach work sys-usb:sdb
 
@@ -108,7 +108,7 @@ If you fail to detach the device before it’s destroyed in the sourceVM (e.g. 
 
 To recover from this error state, in dom0 run
 
-.. code:: console
+.. code-block:: console
 
       $ virsh detach-disk targetVM xvdi
 
@@ -125,7 +125,7 @@ Currently (until issue `1082 <https://github.com/QubesOS/qubes-issues/issues/108
 
 2. Attach the device manually to the same VM using the ``xl block-attach`` command. It is important to use the same “frontend” device name (by default, ``xvdi``). You can get it from the ``qvm-block`` listing:
 
-   .. code:: console
+   .. code-block:: console
 
          [user@dom0 ~]$ qvm-block
          sys-usb:sda DataTraveler_2.0 () 246 MiB (attached to 'testvm' as 'xvdi')
@@ -150,7 +150,7 @@ To attach a file as block device to another qube, first turn it into a loopback
 
 1. In the linux sourceVM run
 
-   .. code:: console
+   .. code-block:: console
 
          $ sudo losetup -f --show /path/to/file
 
@@ -162,7 +162,7 @@ To attach a file as block device to another qube, first turn it into a loopback
 
    - In dom0, run ``qvm-block`` to display known block devices. The newly created loop device should show up:
 
-   .. code:: console
+   .. code-block:: console
 
          ~]$ qvm-block
          BACKEND:DEVID  DESCRIPTION  USED BY
@@ -170,13 +170,13 @@ To attach a file as block device to another qube, first turn it into a loopback
 
 3. Attach the ``loop0``-device using qvm-block as usual:
 
-   .. code:: console
+   .. code-block:: console
 
          $ qvm-block a targetVM sourceVM:loop0
 
 4. After detaching, destroy the loop-device inside the sourceVM as follows:
 
-   .. code:: console
+   .. code-block:: console
 
          $ sudo losetup -d /dev/loop0
 
@@ -192,7 +192,7 @@ This option allows you to specify the name of the device node made available in
 
 usage example:
 
-.. code:: console
+.. code-block:: console
 
       $ qvm-block a work sys-usb:sda1 -o frontend-dev=xvdz
 
@@ -207,13 +207,13 @@ If the device is a read-only device, this option is forced true.
 
 usage example:
 
-.. code:: console
+.. code-block:: console
 
       $ qvm-block a work sys-usb:sda1 -o read-only=true
 
 There exists a shortcut to set read-only ``true``, ``--ro``:
 
-.. code:: console
+.. code-block:: console
 
       $ qvm-block a work sys-usb:sda1 --ro
 
@@ -226,7 +226,7 @@ Usually, a block device is attached as disk. In case you need to attach a block
 
 usage example:
 
-.. code:: console
+.. code-block:: console
 
       $ qvm-block a work sys-usb:sda1 -o devtype=cdrom
 
diff --git a/user/how-to-guides/how-to-use-disposables.rst b/user/how-to-guides/how-to-use-disposables.rst
index 2085545833..3be318d036 100644
--- a/user/how-to-guides/how-to-use-disposables.rst
+++ b/user/how-to-guides/how-to-use-disposables.rst
@@ -96,7 +96,7 @@ Sometimes it is desirable to open an instance of Firefox in a new fresh disposab
 
 It is possible to do the same as above using the command line:
 
-.. code:: console
+.. code-block:: console
 
       user@dom0:~$ qvm-run --dispvm=default-dvm --service -- qubes.StartApp+firefox
 
@@ -117,7 +117,7 @@ In an app qube's file manager, right click on the file you wish to open in a dis
 
 It is also possible to do the same from the command line using :program:`qvm-open-in-dvm`:
 
-.. code:: console
+.. code-block:: console
 
       [user@work ~]$ qvm-open-in-dvm -- 'apple-sandbox.pdf'
       [user@work ~]$ qvm-open-in-dvm --view-only -- 'apple-sandbox.pdf'
@@ -151,7 +151,7 @@ The same can be done from the command line, although more difficult:
    Python Admin API was preferred because each shell has a different way to read null bytes (qubesd-query).
    The escaped backslash is used to have indented blocks for readability.
 
-.. code:: console
+.. code-block:: console
 
       user@dom0:~$ disp_template="default-dvm"
       user@dom0:~$ disp="$(python3 -c "import qubesadmin; \
@@ -191,7 +191,7 @@ Preloading from the system's default disposable is possible with the |qubes-logo
 
 This can also be changed from the command line from the :term:`GUI domain`, with :program:`qvm-features` targeting ``dom0``:
 
-.. code:: console
+.. code-block:: console
 
       user@dom0:~$ qvm-features dom0 preload-dispvm-max 2
 
@@ -212,7 +212,7 @@ To configure, for example, the ``default-mgmt-dvm`` qube using the app menu and
 
 This can also be changed from the command line from the :term:`GUI domain`, with :program:`qvm-features` targeting ``default-mgmt-dvm``:
 
-.. code:: console
+.. code-block:: console
 
       [user@dom0 ~]$ qvm-features default-mgmt-dvm preload-dispvm-max 2
 
diff --git a/user/how-to-guides/how-to-use-pci-devices.rst b/user/how-to-guides/how-to-use-pci-devices.rst
index 02182f6a56..6bdac00a32 100644
--- a/user/how-to-guides/how-to-use-pci-devices.rst
+++ b/user/how-to-guides/how-to-use-pci-devices.rst
@@ -53,7 +53,7 @@ The ``qvm-pci`` tool allows PCI attachment and detachment. It’s a shortcut for
 
 To figure out what device to attach, first list the available PCI devices by running (as user) in dom0:
 
-.. code:: console
+.. code-block:: console
 
       $ qvm-pci
 
@@ -61,7 +61,7 @@ To figure out what device to attach, first list the available PCI devices by run
 
 This will show you the ``backend:BDF`` (Bus_Device.Function) address of each PCI device. It will look something like ``dom0:00_1a.0``. Once you’ve found the address of the device you want to attach, then attach it like this:
 
-.. code:: console
+.. code-block:: console
 
       $ qvm-pci attach targetVM sourceVM:[BDF] --persistent
 
@@ -71,7 +71,7 @@ Since PCI devices have to be attached on bootup, attaching has to happen with th
 
 For example, if ``00_1a.0`` is the BDF of the device you want to attach to the “work” domain, you would do this:
 
-.. code:: console
+.. code-block:: console
 
       $ qvm-pci attach work dom0:00_1a.0 --persistent
 
@@ -99,7 +99,7 @@ Do not require PCI device to be reset before attaching it to another VM. This ma
 
 usage example:
 
-.. code:: console
+.. code-block:: console
 
       $ qvm-pci a work dom0:00_1a.0 --persistent -o no-strict-reset=true
 
@@ -113,7 +113,7 @@ Allow write access to full PCI config space instead of whitelisted registers. Th
 
 usage example:
 
-.. code:: console
+.. code-block:: console
 
       $ qvm-pci a work dom0:00_1a.0 --persistent -o permissive=true
 
@@ -139,7 +139,7 @@ or
 
 - Go to the sysfs (``/sys/bus/pci``), find the right device, detach it from the pciback driver, and attach it back to the original driver. Replace ``<BDF>`` with your full device, for example ``0000:00:1c.2``:
 
-  .. code:: console
+  .. code-block:: console
 
         $ echo <BDF> > /sys/bus/pci/drivers/pciback/unbind
         $ MODALIAS=`cat /sys/bus/pci/devices/<BDF>/modalias`
diff --git a/user/how-to-guides/how-to-use-usb-devices.rst b/user/how-to-guides/how-to-use-usb-devices.rst
index 8ed9b8f510..97cdcc6a4a 100644
--- a/user/how-to-guides/how-to-use-usb-devices.rst
+++ b/user/how-to-guides/how-to-use-usb-devices.rst
@@ -48,7 +48,7 @@ In dom0, you can use ``qvm-usb`` from the commandline to attach and detach devic
 
 Listing available USB devices:
 
-.. code:: console
+.. code-block:: console
 
       [user@dom0 ~]$ qvm-usb
       BACKEND:DEVID   DESCRIPTION                    USED BY
@@ -58,7 +58,7 @@ Listing available USB devices:
 
 Attaching selected USB device:
 
-.. code:: console
+.. code-block:: console
 
       [user@dom0 ~]$ qvm-usb attach work sys-usb:2-5
       [user@dom0 ~]$ qvm-usb
@@ -71,7 +71,7 @@ Now, you can use your USB device (camera in this case) in the ``work`` qube. If
 
 When you finish, detach the device.
 
-.. code:: console
+.. code-block:: console
 
       [user@dom0 ~]$ qvm-usb detach work sys-usb:2-5
       [user@dom0 ~]$ qvm-usb
@@ -99,13 +99,13 @@ If you receive this error: ``ERROR: qubes-usb-proxy not installed in the qube``,
 
 - Fedora:
 
-  .. code:: console
+  .. code-block:: console
 
         $ sudo dnf install qubes-usb-proxy
 
 - Debian/Ubuntu:
 
-  .. code:: console
+  .. code-block:: console
 
         $ sudo apt-get install qubes-usb-proxy
 
@@ -125,13 +125,13 @@ You can find your controller and its BDF address using the method described belo
 
 First, find out which USB bus the device is connected to (note that these steps need to be run from a terminal inside your USB qube):
 
-.. code:: console
+.. code-block:: console
 
       $ lsusb
 
 For example, I want to attach a broadband modem to the NetVM. In the output of ``lsusb`` it may be listed as something like:
 
-.. code:: output
+.. code-block:: output
 
       Bus 003 Device 003: ID 413c:818d Dell Computer Corp.
 
@@ -141,25 +141,25 @@ The device is connected to USB bus #3. Check which other devices are connected t
 
 To find the right controller, follow the usb bus:
 
-.. code:: console
+.. code-block:: console
 
       $ readlink /sys/bus/usb/devices/usb3
 
 This should output something like:
 
-.. code:: output
+.. code-block:: output
 
       ../../../devices/pci-0/pci0000:00/0000:00:1a.0/usb3
 
 Now you see the path: the text between ``/pci0000:00/0000:`` and ``/usb3`` i.e. ``00:1a.0`` is the BDF address. Strip the address and pass it to the :doc:`qvm-pci tool </user/how-to-guides/how-to-use-pci-devices>` to attach the controller to the target qube, like this:
 
-.. code:: console
+.. code-block:: console
 
       $ qvm-pci attach --persistent personal dom0:00_1a.0
 
 It is possible that on some system configurations the readlink method produces output which is different from the example above, For example, you might see output like this:
 
-.. code:: output
+.. code-block:: output
 
       ../../../devices/pci0000:00/0000:00:1c.0/0000:01:00.0/usb1
 
diff --git a/user/security-in-qubes/anti-evil-maid.rst b/user/security-in-qubes/anti-evil-maid.rst
index 213e05d0f4..0e5d21c0cd 100644
--- a/user/security-in-qubes/anti-evil-maid.rst
+++ b/user/security-in-qubes/anti-evil-maid.rst
@@ -23,7 +23,7 @@ Installing
 
 In Dom0 install ``anti-evil-maid``:
 
-.. code:: console
+.. code-block:: console
 
       $ sudo qubes-dom0-update anti-evil-maid
 
diff --git a/user/security-in-qubes/ctap-proxy.rst b/user/security-in-qubes/ctap-proxy.rst
index 65d279e795..7f34e1d909 100644
--- a/user/security-in-qubes/ctap-proxy.rst
+++ b/user/security-in-qubes/ctap-proxy.rst
@@ -53,7 +53,7 @@ These instructions assume that there is a ``sys-usb`` qube that holds the USB st
 
 In dom0:
 
-.. code:: console
+.. code-block:: 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:: console
+.. code-block:: console
 
       $ sudo dnf install qubes-ctap
 
@@ -72,7 +72,7 @@ In Fedora templates:
 
 In Debian templates:
 
-.. code:: console
+.. code-block:: console
 
       $ sudo apt install qubes-ctap
 
@@ -90,7 +90,7 @@ If you are using Qubes 4.0, you can further compartmentalise your CTAP keys by r
 
 To enable this, create a file in dom0 named ``/etc/qubes/policy.d/30-user-ctapproxy.policy`` with the following content:
 
-.. code:: text
+.. code-block:: text
 
       policy.RegisterArgument +u2f.Authenticate sys-usb @anyvm allow target=dom0
 
@@ -107,7 +107,7 @@ If your USB qube has a different name (not ``sys-usb``), you need to update in t
 
 1. In the **template**, run these commands (replace ``YOUR_USB_QUBE`` with your actual USB qube name):
 
-   .. code:: console
+   .. code-block:: console
 
          [user@template] $ systemctl enable qubes-ctapproxy@YOUR_USB_QUBE.service
          [user@template] $ systemctl disable qubes-ctapproxy@sys-usb.service
diff --git a/user/security-in-qubes/firewall.rst b/user/security-in-qubes/firewall.rst
index 7db65f791d..3bad030b58 100644
--- a/user/security-in-qubes/firewall.rst
+++ b/user/security-in-qubes/firewall.rst
@@ -48,7 +48,7 @@ If you previously used the :program:`qvm-firewall` program with a qube, the sett
 
 In that case, you can remove every firewall rules by using the following command:
 
-.. code:: console
+.. code-block:: console
 
    [user@dom0] $ qvm-firewall <QUBE> reset
 
@@ -74,13 +74,13 @@ Where are the rules?
 
 The firewall rules for each qube are saved in an XML file in that qube’s directory in dom0:
 
-.. code:: text
+.. code-block:: text
 
       /var/lib/qubes/appvms/<vm-name>/firewall.xml
 
 Rules are implemented on the :term:`net qube`: If a rule is set for a qube that uses *sys-firewall* as its net qube, *sys-firewall* will implement the rules. This is done by the `qubes-firewall <https://dev.qubes-os.org/projects/core-admin-client/en/latest/manpages/qvm-service.html#supported-services>`_ service. You can verify that the service is running by executing the following command in the net qube:
 
-.. code:: console
+.. code-block:: console
 
    [user@net-qube] $ sudo systemctl status qubes-firewall.service
 
@@ -98,7 +98,7 @@ Reconnecting qubes after a net qube reboot
 
 Qubes OS tries to prevent stopping a net qube if there are other qubes running which use it as their own net qube. But in case the net qube stops for whatever reason (e.g. it crashes, or the user forces its shutdown via qvm-kill via terminal in Dom0), Qubes OS will often automatically repair the connection. If it does not, then there is an easy way to restore the connection to the net qube by issuing the following command in dom0:
 
-.. code:: console
+.. code-block:: console
 
       [user@dom0] $ qvm-prefs <QUBE> netvm <NET_QUBE>
 
@@ -106,7 +106,7 @@ Where :samp:`{<QUBE>}` is the qube connected to the stopped net qube and :samp:`
 
 A qube should normally not connect directly to the actual net qube which has networking devices (*sys-net* by default), but rather to another net qube first (*sys-firewall* by default). In most cases it would be the net qube with networking devices that will crash, e.g. in response to S3 sleep/restore or other issues with WiFi drivers. In that case it is only necessary to issue the above command once, for the *sys-firewall* qube (following named conventions used by the default Qubes installation):
 
-.. code:: console
+.. code-block:: console
 
       [user@dom0] $ qvm-prefs sys-firewall netvm sys-net
 
@@ -120,7 +120,7 @@ Qubes does not support running any networking services (e.g. VPN, local DNS ser
 
 Instead, you should deploy a network infrastructure such as
 
-.. code:: text
+.. code-block:: text
 
       sys-net <--> sys-firewall-1 <--> network service qube <--> sys-firewall-2 <--> [client qubes]
 
@@ -160,7 +160,7 @@ In order to allow networking from qube A (client) to qube B (server) follow thes
 
 
 
-.. code:: console
+.. code-block:: console
 
       $ sudo nft add rule ip qubes custom-forward ip saddr <IP address of A> ip daddr <IP address of B> ct state new,established,related counter accept
 
@@ -170,7 +170,7 @@ In order to allow networking from qube A (client) to qube B (server) follow thes
 
 
 
-.. code:: console
+.. code-block:: console
 
       $ sudo nft add rule qubes custom-input ip saddr <IP address of A> ct state new,established,related counter accept
 
@@ -182,7 +182,7 @@ In order to allow networking from qube A (client) to qube B (server) follow thes
 
 
 
-.. code:: console
+.. code-block:: 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
@@ -193,7 +193,7 @@ In order to allow networking from qube A (client) to qube B (server) follow thes
 
 
 
-.. code:: console
+.. code-block:: 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
@@ -212,7 +212,7 @@ Consider the following example. ``mytcp-service`` qube has a TCP service running
 
 - In dom0, add the following to ``/etc/qubes/policy.d/30-user-networking.policy``: (it could be ``another-other-name.policy`` – just remember to keep it consistent)
 
-  .. code:: text
+  .. code-block:: text
 
         qubes.ConnectTCP * untrusted @default allow target=mytcp-service
 
@@ -220,7 +220,7 @@ Consider the following example. ``mytcp-service`` qube has a TCP service running
 
 - In untrusted, use the Qubes tool ``qvm-connect-tcp``:
 
-  .. code:: console
+  .. code-block:: console
 
         [user@untrusted #]$ qvm-connect-tcp 444:@default:444
 
@@ -234,7 +234,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:: console
+.. code-block:: console
 
       [user@untrusted #]$ qvm-connect-tcp ::444
 
@@ -246,7 +246,7 @@ which means to use default local port of ``unstrusted`` as the same of the remot
 
 Consider now the case where someone prefers to specify the destination qube and use another port in untrusted, for example ``10044``. Instead of previous case, add
 
-.. code:: text
+.. code-block:: text
 
       qubes.ConnectTCP * untrusted mytcp-service allow
 
@@ -254,7 +254,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:: console
+.. code-block:: console
 
       [user@untrusted #]$ qvm-connect-tcp 10444:mytcp-service:444
 
@@ -266,7 +266,7 @@ The service of ``mytcp-service`` running on port ``444`` is now accessible in ``
 
 One can go further than the previous examples by redirecting different ports to different qubes. For example, let assume that another qube ``mytcp-service-bis`` with a TCP service is running on port ``445``. If someone wants ``untrusted`` to be able to reach this service but port ``445`` is reserved to ``mytcp-service-bis`` then, in dom0, add the following to ``/etc/qubes/policy.d/30-user-networking.policy``:
 
-.. code:: text
+.. code-block:: text
 
       qubes.ConnectTCP +445 untrusted @default allow target=mytcp-service-bis
 
@@ -274,7 +274,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:: console
+.. code-block:: console
 
       [user@untrusted #]$ qvm-connect-tcp ::445
 
@@ -286,7 +286,7 @@ will restrict the binding to only the corresponding TCP port of ``mytcp-service-
 
 For creating a permanent port bind between two qubes, ``systemd`` can be used. We use the case of the first example. In ``/rw/config`` (or any place you find suitable) of qube ``untrusted``, create ``my-tcp-service.socket`` with content:
 
-.. code:: systemd
+.. code-block:: systemd
 
       [Unit]
       Description=my-tcp-service
@@ -302,7 +302,7 @@ For creating a permanent port bind between two qubes, ``systemd`` can be used. W
 
 and ``my-tcp-service@.service`` with content:
 
-.. code:: systemd
+.. code-block:: systemd
 
       [Unit]
       Description=my-tcp-service
@@ -316,7 +316,7 @@ and ``my-tcp-service@.service`` with content:
 
 In ``/rw/config/rc.local``, append the lines:
 
-.. code:: bash
+.. code-block:: bash
 
       cp -r /rw/config/my-tcp-service.socket /rw/config/my-tcp-service@.service /lib/systemd/system/
       systemctl daemon-reload
@@ -392,7 +392,7 @@ When writing rules in sys-net, you can use ``iif`` or ``iifname``. ``iif`` is fa
 
 In the sys-net VM’s Terminal, the first step is to define an nftables chain that will receive DNAT rules to relay the network traffic on a given port to the qube NetVM, we recommend to define a new chain for each destination qube to ease rules management:
 
-.. code:: console
+.. code-block:: console
 
       $ nft add chain qubes custom-dnat-qubeDEST '{ type nat hook prerouting priority filter +1 ; policy accept; }'
 
@@ -406,7 +406,7 @@ In the sys-net VM’s Terminal, the first step is to define an nftables chain th
 
 Second step, code a natting firewall rule to route traffic on the outside interface for the service to the sys-firewall VM
 
-.. code:: console
+.. code-block:: console
 
       $ nft add rule qubes custom-dnat-qubeDEST iifname ens6 ip saddr 192.168.x.y/24 tcp dport 443 ct state new,established,related counter dnat 10.137.1.z
 
@@ -414,7 +414,7 @@ Second step, code a natting firewall rule to route traffic on the outside interf
 
 Third step, code the appropriate new filtering firewall rule to allow new connections for the service
 
-.. code:: console
+.. code-block:: console
 
       $ nft add rule qubes custom-forward iifname ens6 ip saddr 192.168.x.y/24 ip daddr 10.137.1.z tcp dport 443 ct state new,established,related counter accept
 
@@ -428,7 +428,7 @@ Third step, code the appropriate new filtering firewall rule to allow new connec
 
 Verify the rules on the sys-net firewall correctly match the packets you want by looking at the counters: check for the counter lines in the chains ``custom-forward`` and ``custom-dnat-qubeDEST``:
 
-.. code:: console
+.. code-block:: console
 
       $ nft list table ip qubes
 
@@ -436,7 +436,7 @@ Verify the rules on the sys-net firewall correctly match the packets you want by
 
 In this example, we can see 7 packets in the forward rule, and 3 packets in the dnat rule:
 
-.. code:: output
+.. code-block:: output
 
       chain custom-forward {
         iifname ens6 ip saddr 192.168.x.y/24 ip daddr 10.137.1.z tcp dport 443 ct state new,established,related counter packets 7 bytes 448 accept
@@ -451,7 +451,7 @@ In this example, we can see 7 packets in the forward rule, and 3 packets in the
 
 (Optional) You can send a test packet by trying to connect to the service from an external device using the following command:
 
-.. code:: console
+.. code-block:: console
 
       $ telnet 192.168.x.n 443
 
@@ -459,7 +459,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 (see section :ref:`Where to put firewall rules <user/security-in-qubes/firewall:where to put firewall rules>`):
 
-.. code:: console
+.. code-block:: console
 
       [user@sys-net user]$ sudo -i
       [root@sys-net user]# nano /rw/config/qubes-firewall-user-script
@@ -468,7 +468,7 @@ Once you have confirmed that the counters increase, store the commands used in t
 
 Content of ``/rw/config/qubes-firewall-user-script`` in ``sys-net``:
 
-.. code:: bash
+.. code-block:: bash
 
       #!/bin/sh
 
@@ -490,7 +490,7 @@ For the following example, we use the fact that the interface of sys-firewall fa
 
 In the sys-firewall Terminal, add a DNAT chain that will contain routing rules:
 
-.. code:: console
+.. code-block:: console
 
       $ nft add chain qubes custom-dnat-qubeDEST '{ type nat hook prerouting priority filter +1 ; policy accept; }'
 
@@ -498,7 +498,7 @@ In the sys-firewall Terminal, add a DNAT chain that will contain routing rules:
 
 Second step, code a natting firewall rule to route traffic on the outside interface for the service to the destination qube
 
-.. code:: console
+.. code-block:: console
 
       $ nft add rule qubes custom-dnat-qubeDEST iifgroup 1 ip saddr 192.168.x.y/24 tcp dport 443 ct state new,established,related counter dnat 10.137.0.xx
 
@@ -506,7 +506,7 @@ Second step, code a natting firewall rule to route traffic on the outside interf
 
 Third step, code the appropriate new filtering firewall rule to allow new connections for the service
 
-.. code:: console
+.. code-block:: console
 
       $ nft add rule qubes custom-forward iifgroup 1 ip saddr 192.168.x.y/24 ip daddr 10.137.0.xx tcp dport 443 ct state new,established,related counter accept
 
@@ -518,7 +518,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`` (see section :ref:`Where to put firewall rules <user/security-in-qubes/firewall:where to put firewall rules>`):
 
-.. code:: console
+.. code-block:: console
 
       [user@sys-net user]$ sudo -i
       [root@sys-net user]# nano /rw/config/qubes-firewall-user-script
@@ -527,7 +527,7 @@ Once you have confirmed that the counters increase, store these commands in the
 
 Content of ``/rw/config/qubes-firewall-user-script`` in ``sys-firewall``:
 
-.. code:: bash
+.. code-block:: bash
 
       #!/bin/sh
 
@@ -553,7 +553,7 @@ For the following example, we assume that the target VM running the web server h
 
 The according rule to allow the traffic is:
 
-.. code:: console
+.. code-block:: console
 
       $ nft add rule qubes custom-input tcp dport 443 ip daddr 10.137.0.xx ct state new,established,related counter accept
 
@@ -561,7 +561,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:: console
+.. code-block:: 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
@@ -588,7 +588,7 @@ An effective console utility to troubleshoot network is `tcpdump <https://www.tc
 
 For instance, if you want to check if your network interface ``eth0`` is receiving packets on port TCP 443 from the network 192.168.x.y, you can run this command:
 
-.. code:: console
+.. code-block:: console
 
       $ tcpdump -i eth0 -nn dst port 443 and src net 192.168.x.y/24
 
@@ -606,7 +606,7 @@ By adding ``flush ruleset`` at the top of the file, you can achieve atomic updat
 
 You can dump the ruleset in two files using the following command:
 
-.. code:: console
+.. code-block:: console
 
       $ nft list ruleset | tee nft_backup | tee nft_new_ruleset
 
@@ -616,7 +616,7 @@ Then, edit ``nft_new_ruleset``, add ``flush ruleset`` on top and make changes, l
 
 You can revert to the original ruleset with the following commands:
 
-.. code:: console
+.. code-block:: console
 
       $ nft flush ruleset && nft -f nft_backup
 
diff --git a/user/security-in-qubes/mfa.rst b/user/security-in-qubes/mfa.rst
index 1788562b78..093b49c76a 100644
--- a/user/security-in-qubes/mfa.rst
+++ b/user/security-in-qubes/mfa.rst
@@ -25,7 +25,7 @@ As the name implies, this generates authentication code that is time-dependent.
 
 1. Download ``google-authenticator`` in dom0:
 
-   .. code:: console
+   .. code-block:: console
 
          $ sudo qubes-dom0-update google-authenticator
 
@@ -33,7 +33,7 @@ As the name implies, this generates authentication code that is time-dependent.
 
 2. Run google authenticator:
 
-   .. code:: console
+   .. code-block:: console
 
          $ google-authenticator
 
@@ -41,7 +41,7 @@ As the name implies, this generates authentication code that is time-dependent.
 
 3. Walk through the setup instructions which will also generate your QR code for your auth app of choice:
 
-   .. code:: output
+   .. code-block:: output
 
          Do you want me to update your “/home/user/.google_authenticator” file (y/n) y
 
@@ -66,14 +66,14 @@ Now we are going to add the authenticator as a login requirement:
 2. Edit the custom system authentication template in ``/etc/authselect/custom/mfa/system-auth``.
    Add the following line right after ``auth required pam_faildelay.so delay=2000000``:
 
-   .. code:: text
+   .. code-block:: text
 
          auth required pam_google_authenticator.so
 
 
    After the change, the top of the file should look like this:
 
-   .. code:: text
+   .. code-block:: text
 
          {imply "with-smartcard" if "with-smartcard-required"}
          auth required pam_env.so
@@ -84,7 +84,7 @@ Now we are going to add the authenticator as a login requirement:
 
 3. Lastly, activate this authentication method with:
 
-   .. code:: console
+   .. code-block:: console
 
          $ sudo authselect select custom/mfa
 
@@ -108,7 +108,7 @@ The following assumes you haven’t restarted your computer since setting up TOT
 
 2. Revert to the original policy with:
 
-   .. code:: console
+   .. code-block:: console
 
          $ sudo authselect select sssd
 
@@ -168,7 +168,7 @@ All these requirements are described below, step by step, for the YubiKey and Ni
 
 
 
-     .. code:: console
+     .. code-block:: console
 
            $ sudo dnf install ykpers
 
@@ -178,7 +178,7 @@ All these requirements are described below, step by step, for the YubiKey and Ni
 
 
 
-     .. code:: console
+     .. code-block:: console
 
            $ sudo apt-get install yubikey-personalization
 
@@ -202,7 +202,7 @@ All these requirements are described below, step by step, for the YubiKey and Ni
 
 2. Install `qubes-app-yubikey <https://github.com/QubesOS/qubes-app-yubikey>`__ in dom0. This provides the program to authenticate with password and YubiKey / NitroKey3.
 
-   .. code:: console
+   .. code-block:: console
 
          $ sudo qubes-dom0-update qubes-yubikey-dom0
 
@@ -236,7 +236,7 @@ All these requirements are described below, step by step, for the YubiKey and Ni
 
      - Set up a new NK3 Secrets App HOTP secret by attaching the NitroKey to your USB qube and running the following commands in it:
 
-       .. code:: console
+       .. code-block:: console
 
              $ AESKEY=$(echo -n "your-20-digit-secret" | base32)
              $ nitropy nk3 secrets register --kind hotp --hash sha256 --digits-str 8 --counter-start 1 --touch-button loginxs $AESKEY
@@ -281,7 +281,7 @@ All these requirements are described below, step by step, for the YubiKey and Ni
 
    - You can calculate your hashed password using the following two commands. First run the following command to store your password in a temporary variable ``password``. (This way your password will not leak to the terminal command history file.)
 
-     .. code:: console
+     .. code-block:: console
 
            $ read -r password
 
@@ -289,7 +289,7 @@ All these requirements are described below, step by step, for the YubiKey and Ni
 
    - Now run the following command to calculate your hashed password.
 
-     .. code:: console
+     .. code-block:: console
 
            $ echo -n "$password" | openssl dgst -sha1 | cut -f2 -d ' '
 
@@ -299,7 +299,7 @@ All these requirements are described below, step by step, for the YubiKey and Ni
 
 6. To enable multi-factor authentication for a service, you need to add
 
-   .. code:: text
+   .. code-block:: text
 
          auth include yubikey
 
@@ -337,7 +337,7 @@ Optional: Enforce YubiKey / NitroKey3 Login
 
 Edit ``/etc/pam.d/yubikey`` (or appropriate file if you are using other screen locker program) and remove ``default=ignore`` so the line looks like this.
 
-.. code:: text
+.. code-block:: text
 
       auth [success=done] pam_exec.so expose_authtok quiet /usr/bin/yk-auth
 
@@ -353,7 +353,7 @@ In dom0:
 
 1. First configure the qrexec service. Create ``/etc/qubes-rpc/custom.LockScreen`` with a simple command to lock the screen. In the case of xfce4-screensaver (used in Xfce) it would be:
 
-   .. code:: text
+   .. code-block:: text
 
          DISPLAY=:0 xfce4-screensaver-command -lock
 
@@ -361,7 +361,7 @@ In dom0:
 
 2. Then make ``/etc/qubes-rpc/custom.LockScreen`` executable.
 
-   .. code:: console
+   .. code-block:: console
 
          $ sudo chmod +x /etc/qubes-rpc/custom.LockScreen
 
@@ -369,7 +369,7 @@ In dom0:
 
 3. Allow your USB VM to call that service. Assuming that it’s named ``sys-usb`` it would require creating ``/etc/qubes-rpc/policy/custom.LockScreen`` with:
 
-   .. code:: text
+   .. code-block:: text
 
          sys-usb dom0 allow
 
@@ -381,7 +381,7 @@ In your USB VM:
 
 1. Create udev hook. Store it in ``/rw/config`` to have it persist across VM restarts. For example name the file ``/rw/config/yubikey.rules``. Add the following line:
 
-   .. code:: text
+   .. code-block:: text
 
          ACTION=="remove", SUBSYSTEM=="usb", ENV{ID_SECURITY_TOKEN}=="1", RUN+="/usr/bin/qrexec-client-vm dom0 custom.LockScreen"
 
@@ -389,7 +389,7 @@ In your USB VM:
 
 2. Ensure that the udev hook is placed in the right place after VM restart. Append to ``/rw/config/rc.local``:
 
-   .. code:: bash
+   .. code-block:: bash
 
          ln -s /rw/config/yubikey.rules /etc/udev/rules.d/
          udevadm control --reload
@@ -398,7 +398,7 @@ In your USB VM:
 
 3. Then make ``/rw/config/rc.local`` executable.
 
-   .. code:: console
+   .. code-block:: console
 
          $ sudo chmod +x /rw/config/rc.local
 
@@ -406,7 +406,7 @@ In your USB VM:
 
 4. For changes to take effect, you need to call this script manually for the first time.
 
-   .. code:: console
+   .. code-block:: console
 
          $ sudo /rw/config/rc.local
 
@@ -416,7 +416,7 @@ In your USB VM:
 
 If you use KDE, the command(s) in first step would be different:
 
-.. code:: console
+.. code-block:: console
 
       # In the case of USB VM being autostarted, it will not have direct access to D-Bus
       # session bus, so find its address manually:
diff --git a/user/security-in-qubes/split-gpg-2.rst b/user/security-in-qubes/split-gpg-2.rst
index c17f7e8ca4..62b4fadc3b 100644
--- a/user/security-in-qubes/split-gpg-2.rst
+++ b/user/security-in-qubes/split-gpg-2.rst
@@ -28,7 +28,7 @@ Create a policy for Split GPG-2
 
 **In dom0**, :doc:`create or edit an RPC policy </user/how-to-guides/how-to-edit-a-policy>`. Add a line like the following and make sure to replace :samp:`{client-qube}` and :samp:`{server-qube}` by the appropriate values.
 
-.. code:: text
+.. code-block:: text
 
       qubes.Gpg2 + client-qube @default allow target=server-qube
 
@@ -39,13 +39,13 @@ Generate or import the secret keys in the *server qube*
 
 * either generate your secret keys, like this:
 
-   .. code:: console
+   .. code-block:: console
 
          [user@server-qube] $ gpg --gen-key
 
 * or, if you want to use some old keys, previously generated in another qube, import them and the ownertrust. Make sure to replace :file:`/home/user/QubesIncoming/{<SOME_OTHER_QUBE>}/{[...]}` by the path of the expected file:
 
-   .. code:: console
+   .. code-block:: console
 
          [user@server-qube] $ gpg --import /home/user/QubesIncoming/<SOME_OTHER_QUBE>/secret-keys-export
          [user@server-qube] $ gpg --import-ownertrust /home/user/QubesIncoming/<SOME_OTHER_QUBE>/ownertrust-export
@@ -54,7 +54,7 @@ Generate or import the secret keys in the *server qube*
 
 In both situations, you have to export the public part of your keys and the "ownertrust" values in the *client qube*:
 
-.. code:: console
+.. code-block:: console
 
  [user@server-qube] $ gpg --export > public-keys-export
  [user@server-qube] $ gpg --export-ownertrust > ownertrust-export
@@ -75,7 +75,7 @@ Import the public keys and ownertrust
 
 If you have previously exported the public keys and the "ownertrust" values from the *server qube*. Now, you have to import them in the *client qube*. Replace the following paths by the correct values.
 
-.. code:: console
+.. code-block:: console
 
       [user@client-qube] $ gpg --import /home/user/QubesIncoming/server-qube/public-keys-export
       [user@client-qube] $ gpg --import-ownertrust /home/user/QubesIncoming/server-qube/ownertrust-export
@@ -85,7 +85,7 @@ Check that Split GPG-2 works
 
 You should be able to run ``gpg -K`` in the *client qube*:
 
-.. code:: console
+.. code-block:: console
 
       [user@client-qube] $ gpg -K
       /home/user/.gnupg/pubring.kbx
@@ -117,7 +117,7 @@ If you want to change some server option, copy :file:`/usr/share/doc/split-gpg2/
 
 By setting up some values in the configuration file, you can change some parameters. The configurations files are INI files, you can set global options in the ``DEFAULT`` section, or provide some client specific options in their own :samp:`client:{QUBE_NAME}` section (where ``QUBE_NAME`` is the name of the client). The following configuration is an example where no qube is automatically accepted besides *personal* qube:
 
-.. code:: ini
+.. code-block:: ini
 
    [DEFAULT]
    autoaccept = no
diff --git a/user/security-in-qubes/split-gpg.rst b/user/security-in-qubes/split-gpg.rst
index 6f3eaff8b8..827db218c7 100644
--- a/user/security-in-qubes/split-gpg.rst
+++ b/user/security-in-qubes/split-gpg.rst
@@ -28,7 +28,7 @@ Configuring Split GPG
 
 In dom0, make sure the ``qubes-gpg-split-dom0`` package is installed.
 
-.. code:: console
+.. code-block:: console
 
       [user@dom0 ~]$ sudo qubes-dom0-update qubes-gpg-split-dom0
 
@@ -37,7 +37,7 @@ Make sure you have the ``qubes-gpg-split`` package installed in the template you
 
 For Debian or Whonix:
 
-.. code:: console
+.. code-block:: console
 
       [user@debian-10 ~]$ sudo apt install qubes-gpg-split
 
@@ -45,7 +45,7 @@ For Debian or Whonix:
 
 For Fedora:
 
-.. code:: console
+.. code-block:: console
 
       [user@fedora-32 ~]$ sudo dnf install qubes-gpg-split
 
@@ -59,7 +59,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:: console
+.. code-block:: console
 
       [user@work-gpg ~]$ gpg -K
       /home/user/.gnupg/secring.gpg
@@ -72,7 +72,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:: console
+.. code-block:: console
 
       [user@work-gpg ~]$ echo "export QUBES_GPG_AUTOACCEPT=86400" >> ~/.profile
 
@@ -87,7 +87,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:: console
+.. code-block:: console
 
       [user@work-email ~]$ export QUBES_GPG_DOMAIN=work-gpg
       [user@work-email ~]$ gpg -K
@@ -115,7 +115,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:: console
+.. code-block:: console
 
       [user@work-email ~]$ sudo bash
       [root@work-email ~]$ echo "work-gpg" > /rw/config/gpg-split-domain
@@ -123,7 +123,7 @@ The ``qubes-gpg-client-wrapper`` script sets the ``QUBES_GPG_DOMAIN`` variable a
 
 Split GPG’s default qrexec policy requires the user to enter the name of the app qube containing GPG keys on each invocation. To improve usability for applications like Thunderbird with Enigmail, in ``dom0`` place the following line at the top of the file ``/etc/qubes-rpc/policy/qubes.Gpg``:
 
-.. code:: text
+.. code-block:: text
 
       work-email  work-gpg  allow
 
@@ -133,7 +133,7 @@ where ``work-email`` is the Thunderbird + Enigmail app qube and ``work-gpg`` con
 
 You may also edit the qrexec policy file for Split GPG in order to tell Qubes your default gpg vm (qrexec prompts will appear with the gpg vm preselected as the target, instead of the user needing to type a name in manually). To do this, append ``default_target=<vmname>`` to ``ask`` in ``/etc/qubes-rpc/policy/qubes.Gpg``. For the examples given on this page:
 
-.. code:: text
+.. code-block:: text
 
       @anyvm  @anyvm  ask default_target=work-gpg
 
@@ -157,7 +157,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:: console
+.. code-block:: console
 
       [user@work-email ~]$ qubes-gpg-client-wrapper -K --keyid-format long
       /home/user/.gnupg/pubring.kbx
@@ -169,7 +169,7 @@ You need to obtain your key ID which should be **exactly 16 characters**. Enter
 
 
 
-.. code:: console
+.. code-block:: console
 
       [user@work-email ~]$ qubes-gpg-client-wrapper --armor --export 777402E6D301615C > 777402E6D301615C.asc
 
@@ -217,7 +217,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:: console
+.. code-block:: console
 
       $ keybase config set gpg.command /usr/bin/qubes-gpg-client-wrapper
 
@@ -231,7 +231,7 @@ Using Git with Split GPG
 
 Git can be configured to utilize Split GPG, something useful if you would like to contribute to the Qubes OS Project as every commit is required to be signed. The most basic ``~/.gitconfig`` file enabling Split GPG looks something like this.
 
-.. code:: ini
+.. code-block:: ini
 
       [user]
           name = <YOUR_NAME>
@@ -245,7 +245,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:: console
+.. code-block:: console
 
       [user@work-email ~]$ qubes-gpg-client --list-keys
       /home/user/.gnupg/pubring.kbx
@@ -260,7 +260,7 @@ Your key id is the public id of your signing key, which can be found by running
 
 To sign commits, you now add the “-S” flag to your commit command, which should prompt for Split GPG usage. If you would like to automatically sign all commits, you can add the following snippet to ``~/.gitconfig``.
 
-.. code:: ini
+.. code-block:: ini
 
       [commit]
           gpgSign = true
@@ -275,7 +275,7 @@ Importing public keys
 
 Use ``qubes-gpg-import-key`` in the client app qube to import the key into the GPG backend VM.
 
-.. code:: console
+.. code-block:: console
 
       [user@work-email ~]$ export QUBES_GPG_DOMAIN=work-gpg
       [user@work-email ~]$ qubes-gpg-import-key ~/Downloads/marmarek.asc
diff --git a/user/security-in-qubes/vm-sudo.rst b/user/security-in-qubes/vm-sudo.rst
index 9e841bebc6..daf7d011ad 100644
--- a/user/security-in-qubes/vm-sudo.rst
+++ b/user/security-in-qubes/vm-sudo.rst
@@ -5,7 +5,7 @@ Passwordless root access in qubes
 
 The background to passswordless root access is summarised in this statement, that used to be found at ``/etc/sudoers.d/qubes`` in each qube:
 
-.. code:: text
+.. code-block:: text
 
       user ALL=(ALL) NOPASSWD: ALL
 
diff --git a/user/templates/debian/debian-upgrade.rst b/user/templates/debian/debian-upgrade.rst
index 77f6ed60f4..dd46761ba5 100644
--- a/user/templates/debian/debian-upgrade.rst
+++ b/user/templates/debian/debian-upgrade.rst
@@ -21,7 +21,7 @@ This page provides instructions for performing an in-place upgrade of an install
 Summary instructions for Debian templates
 -----------------------------------------
 
-.. code:: console
+.. code-block:: console
 
       [user@dom0 ~]$ qvm-clone debian-<old> debian-<new>
       [user@dom0 ~]$ qvm-run debian-<new> qubes-run-terminal &
@@ -44,28 +44,28 @@ These instructions will show you how to upgrade Debian templates. The same gener
 
 1. Ensure the existing template is not running.
 
-   .. code:: console
+   .. code-block:: console
 
          [user@dom0 ~]$ qvm-shutdown debian-<old>
 
 
 2. Clone the existing template and start a terminal in the new template.
 
-   .. code:: console
+   .. code-block:: console
 
          [user@dom0 ~]$ qvm-clone debian-<old> debian-<new>
          [user@dom0 ~]$ qvm-run debian-<new> qubes-run-terminal
 
 3. Update the new cloned template.
 
-   .. code:: console
+   .. code-block:: console
 
          [user@debian-<new> ~]$ sudo apt update
          [user@debian-<new> ~]$ sudo apt upgrade
 
 4. 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:: console
+   .. code-block:: 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
@@ -74,7 +74,7 @@ These instructions will show you how to upgrade Debian templates. The same gener
 
 5. 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:: console
+   .. code-block:: console
 
          [user@debian-<new> ~]$ sudo apt update
          [user@debian-<new> ~]$ sudo apt upgrade
@@ -84,7 +84,7 @@ These instructions will show you how to upgrade Debian templates. The same gener
 
 6. (Optional) Remove unnecessary packages that were previously installed.
 
-   .. code:: console
+   .. code-block:: console
 
          [user@debian-<new> ~]$ sudo apt-get autoremove
 
@@ -92,7 +92,7 @@ These instructions will show you how to upgrade Debian templates. The same gener
 
 7. (Optional) Clean cached packages from ``/var/cache/apt``.
 
-   .. code:: console
+   .. code-block:: console
 
          [user@debian-<new> ~]$ sudo apt-get clean
 
@@ -100,7 +100,7 @@ These instructions will show you how to upgrade Debian templates. The same gener
 
 8. (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:: console
+   .. code-block:: console
 
          [user@debian-<new> ~]$ sudo fstrim -av
          [user@dom0 ~]$ qvm-shutdown debian-<new>
@@ -110,14 +110,14 @@ These instructions will show you how to upgrade Debian templates. The same gener
 
 9. Shut down the new template.
 
-   .. code:: console
+   .. code-block:: console
 
          [user@dom0 ~]$ qvm-shutdown debian-<new>
 
 
 10. Set the template-name, which is used by the Qubes updater.
 
-   .. code:: console
+   .. code-block:: console
 
          [user@dom0 ~]$ qvm-features debian-<new> template-name debian-<new>
 
@@ -128,7 +128,7 @@ These instructions will show you how to upgrade Debian templates. The same gener
 
 12. (Optional) Make the new template the global default.
 
-    .. code:: console
+    .. code-block:: console
 
           [user@dom0 ~]$ qubes-prefs --set default_template debian-<new>
 
diff --git a/user/templates/debian/debian.rst b/user/templates/debian/debian.rst
index 6ba89d269b..4b33590606 100644
--- a/user/templates/debian/debian.rst
+++ b/user/templates/debian/debian.rst
@@ -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:: console
+.. code-block:: console
 
       $ qvm-template install XX
 
@@ -74,7 +74,7 @@ The Debian-12 templates that ship with release 4.2.4 cannot be used for salting
 
 If you have a Debian template from an earlier release that you want to use for salting Qubes, you **must** stop the salt-common and salt-ssh packages from being upgraded. Do this by marking these packages on hold *before* updating the template.
 
-.. code:: console
+.. code-block:: console
 
       $ sudo apt-mark hold salt-common salt-ssh
       $ sudo apt update
@@ -110,7 +110,7 @@ Now the ssh service will **NOT** start in qubes based on this template.
 
 Where you **DO** want the service to run, put this in ``/rw/config/rc.local``:
 
-.. code:: bash
+.. code-block:: bash
 
       systemctl unmask ssh
       systemctl start ssh
diff --git a/user/templates/fedora/fedora-upgrade.rst b/user/templates/fedora/fedora-upgrade.rst
index c3080b335b..8c02e03482 100644
--- a/user/templates/fedora/fedora-upgrade.rst
+++ b/user/templates/fedora/fedora-upgrade.rst
@@ -16,7 +16,7 @@ This page provides instructions for performing an in-place upgrade of an install
 Summary instructions for standard Fedora templates
 --------------------------------------------------
 
-.. code:: console
+.. code-block:: console
 
       [user@dom0 ~]$ qvm-clone fedora-<old> fedora-<new>
       [user@dom0 ~]$ truncate -s 5GB /var/tmp/template-upgrade-cache.img
@@ -43,14 +43,14 @@ These instructions will show you how to upgrade the standard Fedora template. Th
 
 1. Ensure the existing template is not running.
 
-   .. code:: console
+   .. code-block:: console
 
          [user@dom0 ~]$ qvm-shutdown fedora-<old>
 
 
 2. Clone the existing template and start a terminal in the new template.
 
-   .. code:: console
+   .. code-block:: console
 
          [user@dom0 ~]$ qvm-clone fedora-<old> fedora-<new>
          [user@dom0 ~]$ qvm-run fedora-<new> qubes-run-terminal
@@ -58,7 +58,7 @@ These instructions will show you how to upgrade the standard Fedora template. Th
 
 3. Attempt the upgrade process in the new template.
 
-   .. code:: console
+   .. code-block:: console
 
          [user@fedora-<new> ~]$ sudo dnf update
          [user@fedora-<new> ~]$ sudo dnf clean all
@@ -67,7 +67,7 @@ These instructions will show you how to upgrade the standard Fedora template. Th
 
    **Note:** ``dnf`` might ask you to approve importing a new package signing key. For example, you might see a prompt like this one:
 
-   .. code:: output
+   .. code-block:: output
 
          warning: /mnt/removable/updates-0b4cc238d1aa4ffe/packages/example-package.fc<new>.x86_64.rpm: Header V3 RSA/SHA256 Signature, key ID XXXXXXXX: NOKEY
          Importing GPG key 0xXXXXXXXX:
@@ -83,7 +83,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:: console
+     .. code-block:: 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)
@@ -91,7 +91,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:: console
+     .. code-block:: console
 
            [user@fedora-<new> ~]$ sudo mkfs.ext4 /dev/xvdi
            [user@fedora-<new> ~]$ sudo mount /dev/xvdi /mnt/removable
@@ -108,7 +108,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:: console
+   .. code-block:: console
 
          [user@fedora-<new> ~]$ cat /etc/fedora-release
 
@@ -116,7 +116,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:: console
+   .. code-block:: console
 
          [user@fedora-<new> ~]$ sudo fstrim -av
          [user@dom0 ~]$ qvm-shutdown fedora-<new>
@@ -126,14 +126,14 @@ These instructions will show you how to upgrade the standard Fedora template. Th
 
 6. Shut down the new template.
 
-   .. code:: console
+   .. code-block:: console
 
          [user@dom0 ~]$ qvm-shutdown fedora-<new>
 
 
 7. Remove the cache file, if you created one.
 
-   .. code:: console
+   .. code-block:: console
 
          [user@dom0 ~]$ sudo losetup -d $dev
          [user@dom0 ~]$ rm /var/tmp/template-upgrade-cache.img
@@ -141,7 +141,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:: console
+   .. code-block:: console
 
          [user@dom0 ~]$ qvm-features fedora-<new> template-name fedora-<new>
 
@@ -150,7 +150,7 @@ These instructions will show you how to upgrade the standard Fedora template. Th
 
 10. (Optional) Make the new template the global default.
 
-    .. code:: console
+    .. code-block:: console
 
           [user@dom0 ~]$ qubes-prefs --set default_template fedora-<new>
 
@@ -165,7 +165,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:: console
+.. code-block:: console
 
       [user@dom0 ~]$ qvm-clone fedora-<old>-minimal fedora-<new>-minimal
       [user@dom0 ~]$ qvm-run -u root -a fedora-<new>-minimal xterm
@@ -203,7 +203,7 @@ Additional information
 
 As mentioned above, you may encounter the following ``dnf`` error:
 
-.. code:: output
+.. code-block:: output
 
       At least X MB more space needed on the / filesystem.
 
diff --git a/user/templates/fedora/fedora.rst b/user/templates/fedora/fedora.rst
index 559c930046..a9d060a7da 100644
--- a/user/templates/fedora/fedora.rst
+++ b/user/templates/fedora/fedora.rst
@@ -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:: console
+.. code-block:: console
 
       $ qvm-template install XX
 
diff --git a/user/templates/minimal-templates.rst b/user/templates/minimal-templates.rst
index 7af74eedeb..7226b30c9e 100644
--- a/user/templates/minimal-templates.rst
+++ b/user/templates/minimal-templates.rst
@@ -42,21 +42,21 @@ Installation
 
 The minimal templates can be installed with the following type of command:
 
-.. code:: console
+.. code-block:: 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:: console
+.. code-block:: 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:: console
+.. code-block:: console
 
       [user@dom0 ~]$ sudo qubes-dom0-update --enablerepo=qubes-templates-community qubes-template-<DISTRO_NAME>-<RELEASE_NUMBER>-minimal
 
@@ -69,7 +69,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:: console
+.. code-block:: console
 
       [user@dom0 ~]$ qvm-run -u root <DISTRO_NAME>-<RELEASE_NUMBER>-minimal xterm
 
@@ -100,7 +100,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:: console
+.. code-block:: console
 
       [user@your-new-clone ~]$ sudo dnf install packages
 
@@ -186,7 +186,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:: console
+.. code-block:: console
 
       [user@your-new-clone ~]$ sudo apt install packages
 
diff --git a/user/templates/templates.rst b/user/templates/templates.rst
index 0347a0fbee..a0d7617ec9 100644
--- a/user/templates/templates.rst
+++ b/user/templates/templates.rst
@@ -89,7 +89,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:: console
+.. code-block:: console
 
       $ qvm-template install  <template_name>
 
@@ -97,7 +97,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:: console
+.. code-block:: console
 
       $ qvm-template  --enablerepo qubes-templates-community install <template_name>
 
@@ -139,13 +139,13 @@ To remove a template, the graphical ``Qube Manager`` (Qubes Menu > Qubes Tools >
 
 Alternatively, to remove a template via the command line in dom0:
 
-.. code:: console
+.. code-block:: console
 
       $ qvm-template remove <TEMPLATE_NAME>
 
 <TEMPLATE_NAME> is the first column from the output of:
 
-.. code:: console
+.. code-block:: console
 
       $ qvm-template list --installed
 
@@ -173,13 +173,13 @@ When you install a new template or :ref:`upgrade <user/how-to-guides/how-to-upda
 
      In the App Menu, click on Terminal Emulator. Type the command below, substituting ``<SYS_USB_DISPOSABLE_TEMPLATE>`` with the name of the disposable template on which ``sys-usb`` is based, ``<NEW_TEMPLATE>`` with the name of the new template, and ``<USB_QUBE>`` with the name of your USB qube. Other than these substitutions, make sure to enter the command exactly as written.
 
-     .. code:: console
+     .. code-block:: console
 
            $ qvm-shutdown --wait --all; qvm-prefs <SYS_USB_DISPOSABLE_TEMPLATE> template <NEW_TEMPLATE>; qvm-start <USB_QUBE>
 
      With substitutions, your command should look similar to this example. (**Warning:** This is just an example. Do not attempt to use it.)
 
-     .. code:: console
+     .. code-block:: console
 
            $ qvm-shutdown --wait --all; qvm-prefs fedora-01-dvm template fedora-02; qvm-start sys-usb
 
diff --git a/user/templates/windows/qubes-windows-tools.rst b/user/templates/windows/qubes-windows-tools.rst
index 5d3b0f1eb0..ac59c21fe7 100644
--- a/user/templates/windows/qubes-windows-tools.rst
+++ b/user/templates/windows/qubes-windows-tools.rst
@@ -150,13 +150,13 @@ Maybe in the future, this step will not be necessary anymore, because we will si
 
 QWT relies on PowerShell scripts. If the execution policy defined for PowerShell is set to `Restricted`, execution of these scripts is blocked. Before QWT installation, this should be checked using the PowerShell command
 
-.. code:: powershell
+.. code-block:: powershell
 
  	PS C:\> Get-ExecutionPolicy
  
 If script execution is blocked, it must be allowed using the following PowerShell command with administrator privileges:
 
-.. code:: powershell
+.. code-block:: powershell
 
 	PS C:\> Set-ExecutionPolicy Unrestricted
 
@@ -165,14 +165,14 @@ If script execution is blocked, it must be allowed using the following PowerShel
 
 **Warning:** It is recommended to increase the default value of the 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 a 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:: console
+.. code-block:: console
 
       [user@dom0 ~]$ qvm-prefs <VMNAME> qrexec_timeout 7200
 
 
 To enable file copy operations to a Windows VM, the ``default_user`` property of this VM should be set to the ``<USERNAME>`` that you use to log in to the Windows VM. This can be done via the following command on a ``dom0`` terminal  (where ``<VMNAME>`` is the name of your Windows VM):
 
-   .. code:: console
+   .. code-block:: console
 
 	    [user@dom0 ~]$ qvm-prefs <VMNAME> default_user <USERNAME>
   
@@ -190,13 +190,13 @@ To enable file copy operations to a Windows VM, the ``default_user`` property of
 
 Additionally, these versions of Windows will not display the CD-ROM drive after starting the qube with
 
-.. code:: console
+.. code-block:: console
 
       [user@dom0 ~]$ qvm-start <VMNAME> --cdrom ...
 
 or
 
-.. code:: console
+.. code-block:: console
 
       [user@dom0 ~]$ qvm-start <VMNAME> --install-windows-tools
 
@@ -225,7 +225,7 @@ Installing the Qubes Windows Tools on Windows 7, 10, and 11, both as a Standalon
 
    - For use with **Windows 10 and 11**, you have to install the new version 4.2.2 of Qubes Windows Tools. In Qubes R4.3, the QWT package is already part of the repositories. So, QWT can be installed directy, without downloading anything, via
 
-     .. code:: console
+     .. code-block:: console
 
      	[user@dom0 ~]$ sudo qubes-dom0-update qubes-windows-tools
      	
@@ -238,7 +238,7 @@ Installing the Qubes Windows Tools on Windows 7, 10, and 11, both as a Standalon
 
 2. To install the Qubes Windows Tools in a Windows VM, one should start the VM passing the additional option ``--install-windows-tools``:
 
-   .. code:: console
+   .. code-block:: console
 
       [user@dom0 ~]$ qvm-start <VMNAME> --install-windows-tools
 
@@ -290,7 +290,7 @@ Installing the Qubes Windows Tools on Windows 7, 10, and 11, both as a Standalon
 
 5. 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:: console
+   .. code-block:: console
 
          [user@dom0 ~]$ qvm-features <VMNAME> audio-model ich9
          [user@dom0 ~]$ qvm-features <VMNAME> stubdom-qrexec 1
@@ -299,7 +299,7 @@ Installing the Qubes Windows Tools on Windows 7, 10, and 11, both as a Standalon
 
    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:: console
+   .. code-block:: console
 
          [user@dom0 ~]$ qvm-features <VMNAME> timer-period 1000
          [user@dom0 ~]$ qvm-features <VMNAME> out.latency 10000
@@ -360,7 +360,7 @@ Windows Apps can be started using the Qubes menu. Alternatively, you can open th
 
 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:: console
+.. code-block:: console
 
       [user@dom0 ~]$ qvm-run -a my-win-appvm explorer.exe
 
@@ -370,7 +370,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:: console
+.. code-block:: console
 
       [user@dom0 ~]$ qvm-open-in-vm my-win-appvm roadmap.pptx
       
@@ -452,7 +452,7 @@ Windows qubes can be used as disposables, like any other Linux-based qubes. On c
 
 - In the Qube Manager, refresh the applications of the newly created AppVM and select those applications that you want to make available from the disposable. Alternatively, in dom0 execute the command 
 
-.. code:: console
+.. code-block:: console
 
 		[user@dom0 ~]$ qvm-sync-appmenus <VMNAME>
 
@@ -460,7 +460,7 @@ where ``<VMNAME>`` is the name of your windows qube.
 
 - In the Qube Manager, go to the “Advanced” tab and enable the option ``Disposable template`` for your Windows qube. Alternatively, in dom0 execute the commands 
 
-.. code:: console
+.. code-block:: console
 
 		[user@dom0 ~]$ qvm-prefs <VMNAME> template_for_dispvms True
 		[user@dom0 ~]$ qvm-features <VMNAME> appmenus-dispvm 1``.
@@ -573,7 +573,7 @@ Troubleshooting
 If the VM is inaccessible (doesn’t respond to qrexec commands, gui is not functioning), try to boot it in safe mode:
 
 - 
-   .. code:: console
+   .. code-block:: console
 
 		[user@dom0 ~]$ qvm-start --debug <VMNAME>
 
@@ -627,7 +627,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:: console
+.. code-block:: console
 
       [user@dom0 ~]$ sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing qubes-windows-tools
 
diff --git a/user/templates/windows/qubes-windows.rst b/user/templates/windows/qubes-windows.rst
index 6ba5dfa698..80400d3d23 100644
--- a/user/templates/windows/qubes-windows.rst
+++ b/user/templates/windows/qubes-windows.rst
@@ -126,14 +126,14 @@ Create a VM named WindowsNew in :doc:`HVM </user/advanced-topics/standalones-and
   - This can also be done via the following CLI commands in dom0, for a standalone qube:
 
 
-  .. code:: console
+  .. code-block:: console
 
         [user@dom0 ~]$ qvm-create --class StandaloneVM --label orange --property virt_mode=hvm WindowsNew
 
 
   and for a template:
 
-  .. code:: console
+  .. code-block:: console
 
         [user@dom0 ~]$ qvm-create --class TemplateVM --label black --property virt_mode=hvm WindowsNew
 
@@ -141,7 +141,7 @@ Create a VM named WindowsNew in :doc:`HVM </user/advanced-topics/standalones-and
 - After creation, set the following parameters via CLI in a dom0 terminal:
 
 
-  .. code:: console
+  .. code-block:: console
 
         [user@dom0 ~]$ qvm-volume extend WindowsNew:root 60g
         [user@dom0 ~]$ qvm-prefs WindowsNew memory 4096
@@ -158,7 +158,7 @@ These parameters are set for the following reasons:
 
 - The Windows installer requires a significant amount of memory, or else the VM will crash with such errors:
 
-  .. code:: bash
+  .. code-block:: bash
 
         /var/log/xen/console/hypervisor.log:
         
@@ -173,7 +173,7 @@ These parameters are set for the following reasons:
 
 - After creating the new qube, increase the VM’s ``qrexec_timeout``: in case you happen to get a BSOD or a similar crash in the VM, utilities like ``chkdsk`` won’t complete on restart before ``qrexec_timeout`` automatically halts the VM. That can really put the VM in a totally unrecoverable state, whereas with higher ``qrexec_timeout``, ``chkdsk`` or the appropriate utility has plenty of time to fix the VM. Note that Qubes Windows Tools also require a larger timeout to move the user profiles to the private volume the first time the VM reboots after the tools’ installation. So set the parameter via the following CLI command from a dom0 terminal, because the Qube manager does not support this setting:
 
-  .. code:: console
+  .. code-block:: console
 
         [user@dom0 ~]$ qvm-prefs WindowsNew qrexec_timeout 7200
 
@@ -202,7 +202,7 @@ Start Windows VM
 
   This can also be done via the following CLI command in dom0 (assuming that the Windows installer ISO is stored in the directory ``/home/user/`` in the AppVM ``untrusted``):
 
-  .. code:: console
+  .. code-block:: console
 
         [user@dom0 ~]$ qvm-start --cdrom=untrusted:/home/user/windows_install.iso WindowsNew
 
@@ -293,7 +293,7 @@ After Windows installation
 
 - From the Windows command line, disable hibernation in order to avoid an incomplete Windows shutdown, which could lead to corruption of the VM’s disk.
 
-  .. code:: console
+  .. code-block:: console
 
         C:\> powercfg -H off
 
@@ -321,7 +321,7 @@ After Windows installation
 - Given the higher-than-usual memory requirements of Windows, you may get a ``Not enough memory to start domain 'WindowsNew'`` error. In that case, try to shut down unneeded VMs to free memory before starting the Windows VM.
   At this point, you may open a tab in dom0 for debugging, in case something goes amiss:
 
-  .. code:: bash
+  .. code-block:: bash
 
         tailf /var/log/qubes/vm-WindowsNew.log \
            /var/log/xen/console/hypervisor.log \
@@ -374,7 +374,7 @@ Moving the user data is not directly possible under Windows, because the directo
 
 AppVMs based on these templates can be created in the normal way by using the Qube Manager or by specifying
 
-.. code:: console
+.. code-block:: console
 
       [user@dom0 ~]$ qvm-create --class=AppVM --template=<VMname> WindowsAppVM
 
@@ -386,7 +386,7 @@ On starting the AppVM, sometimes a message is displayed that the Xen PV Network
 
 Furthermore, if manual IP setup was used for the template, the IP address selected for the template will also be used for the AppVM, as it inherits this address from the template. Qubes, however, will have assigned a different address to the AppVM, which will have to be changed to that of the template (e.g., 10.137.0.x) so that the AppVM can access the network, via the CLI command in a dom0 terminal:
 
-.. code:: console
+.. code-block:: console
 
       [user@dom0 ~]$ qvm-prefs WindowsNew ip 10.137.0.x
 
diff --git a/user/templates/xfce-templates.rst b/user/templates/xfce-templates.rst
index 8618ce68e0..7671af964b 100644
--- a/user/templates/xfce-templates.rst
+++ b/user/templates/xfce-templates.rst
@@ -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:: console
+.. code-block:: 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:: console
+.. code-block:: 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:: console
+.. code-block:: 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:: console
+.. code-block:: console
 
       [user@dom0 ~]$ sudo qubes-dom0-update --enablerepo=qubes-templates-community-testing qubes-template-X-xfce
 
diff --git a/user/troubleshooting/app-menu-shortcut-troubleshooting.rst b/user/troubleshooting/app-menu-shortcut-troubleshooting.rst
index 2cd10dab8b..017fe3f2b9 100644
--- a/user/troubleshooting/app-menu-shortcut-troubleshooting.rst
+++ b/user/troubleshooting/app-menu-shortcut-troubleshooting.rst
@@ -36,7 +36,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:: console
+.. code-block:: console
 
       [user@dom0] $ qvm-sync-appmenus <QUBE_NAME>
 
@@ -44,7 +44,7 @@ To update the list of available applications, use the ``qvm-sync-appmenus`` comm
 
 When using the :guilabel:`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 :guilabel:`Refresh Applications` button is the following (always in dom0):
 
-.. code:: console
+.. code-block:: console
 
       [user@dom0] $ qvm-sync-appmenus <APPVM_NAME>
       [user@dom0] $ qvm-sync-appmenus <TEMPLATE_NAME>
@@ -53,7 +53,7 @@ When using the :guilabel:`Refresh Applications` button in a qube’s settings, t
 
 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:: console
+.. code-block:: console
 
       [user@dom0] $ qvm-appmenus --set-whitelist <FILE_PATH> <QUBE_NAME>
 
@@ -61,7 +61,7 @@ In dom0, the ``qvm-appmenus`` tool allows the user to see the list of available
 
 To change the whitelist shown in app menu, you need to provide a list of the desktop entries. Each line contains a desktop entry name, with its ``.desktop`` extension, like this:
 
-.. code:: text
+.. code-block:: text
 
       qubes-open-file-manager.desktop
       qubes-run-terminal.desktop
@@ -87,7 +87,7 @@ You can manually create new entries in the “available applications” list of
 
 2. Create a custom ``.desktop`` file in :file:`/usr/share/applications` (you may need to first create the subdirectory). Look in :file:`/usr/share/applications` for existing examples, or see the full `.desktop file format <https://standards.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html>`__ specification. It will be something like:
 
-   .. code:: desktop
+   .. code-block:: desktop
 
          [Desktop Entry]
          Type=Application
@@ -120,7 +120,7 @@ To add a custom menu entry instead:
 
 4. Add a custom menu entry referring to your newly created ``.desktop`` file.
 
-   .. code:: xml
+   .. code-block:: xml
 
          <Menu>
               <Name>Webmail</Name>
@@ -161,7 +161,7 @@ What if a removed application is still in the app menu?
 
 First, try this in dom0:
 
-.. code:: console
+.. code-block:: console
 
       [user@dom0] $ qvm-appmenus --update --force <QUBE_NAME>
 
@@ -169,7 +169,7 @@ First, try this in dom0:
 
 You can also try:
 
-.. code:: console
+.. code-block:: console
 
       [user@dom0] $ qvm-appmenus --remove <QUBE_NAME>
 
@@ -187,7 +187,7 @@ First, check in the corresponding ``.desktop`` file in :file:`~/.local/share/qub
 
 The line starting with ``Exec=`` points out the exact command run by dom0 to start the application. It should be something like:
 
-.. code:: desktop
+.. code-block:: desktop
 
       Exec=qvm-run -q -a --service -- <QUBE_NAME> qubes.StartApp+<APPLICATION_NAME>
 
@@ -195,7 +195,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:: console
+.. code-block:: console
 
       [user@any-qube] $ /etc/qubes-rpc/qubes.StartApp <APPLICATION_NAME>
 
@@ -215,7 +215,7 @@ The whitelist given to ``qvm-appmenu --set-whitelist`` is stored as a feature ca
 
 Actual command lines for the menu shortcuts involve the ``qvm-run`` command which starts a process in another domain. Examples:
 
-.. code:: console
+.. code-block:: console
 
       $ qvm-run -q -a --service -- %VMNAME% qubes.StartApp+firefox
       $ qvm-run -q -a --service -- %VMNAME% qubes.StartApp+7-Zip-7-Zip_File_Manager
@@ -224,7 +224,7 @@ Actual command lines for the menu shortcuts involve the ``qvm-run`` command whic
 
 Note that you can create a shortcut that points to a ``.desktop`` file in your app qube with e.g.:
 
-.. code:: console
+.. code-block:: console
 
       $ qvm-run -q -a --service -- personal qubes.StartApp+firefox
 
diff --git a/user/troubleshooting/debian-and-whonix-update-troubleshooting.rst b/user/troubleshooting/debian-and-whonix-update-troubleshooting.rst
index 7f4e9d79db..d5a00c90f7 100644
--- a/user/troubleshooting/debian-and-whonix-update-troubleshooting.rst
+++ b/user/troubleshooting/debian-and-whonix-update-troubleshooting.rst
@@ -15,7 +15,7 @@ Updating Error Messages
 
 After running the commands to update Debian or Whonix, hopefully everything will complete perfectly.
 
-.. code:: console
+.. code-block:: console
 
       $ sudo apt-get update && sudo apt-get dist-upgrade
 
@@ -23,7 +23,7 @@ After running the commands to update Debian or Whonix, hopefully everything will
 
 However, if you see something like the following, then something went wrong.
 
-.. code:: output
+.. code-block:: output
 
       W: Failed to fetch http://ftp.us.debian.org/debian/dist/jessie/contrib/binary-i386/Packages 404 Not Found
 
@@ -60,7 +60,7 @@ This could be a temporary Tor exit relay or server failure that should fix itsel
 
 Sometimes if you see a message such as:
 
-.. code:: output
+.. code-block:: output
 
       Could not resolve 'security.debian.org'
 
@@ -68,7 +68,7 @@ Sometimes if you see a message such as:
 
 It helps to run the following command:
 
-.. code:: console
+.. code-block:: console
 
       $ nslookup security.debian.org
 
@@ -76,7 +76,7 @@ It helps to run the following command:
 
 And then trying running the ``update`` and ``upgrade`` commands again.
 
-.. code:: console
+.. code-block:: console
 
       $ sudo apt-get update && sudo apt-get dist-upgrade
 
@@ -90,7 +90,7 @@ Never Install Unsigned Packages
 
 If you see something like this:
 
-.. code:: output
+.. code-block:: output
 
       WARNING: The following packages cannot be authenticated!
         icedove
@@ -106,7 +106,7 @@ Signature Verification Warnings
 
 There should be none at the moment. If there was such a warning, it would look like this:
 
-.. code:: output
+.. code-block:: output
 
       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
 
@@ -120,7 +120,7 @@ In past various apt repositories were signed with expired key: `The Tor Project
 
 You saw the following warning:
 
-.. code:: output
+.. code-block:: output
 
       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
 
@@ -139,7 +139,7 @@ Changed Configuration Files
 
 If you see something like the following.
 
-.. code:: output
+.. code-block:: output
 
       Setting up ifupdown ...
       Configuration file /etc/network/interfaces
diff --git a/user/troubleshooting/disk-troubleshooting.rst b/user/troubleshooting/disk-troubleshooting.rst
index 31799d3fde..d1d0dd1f36 100644
--- a/user/troubleshooting/disk-troubleshooting.rst
+++ b/user/troubleshooting/disk-troubleshooting.rst
@@ -9,7 +9,7 @@ Disk troubleshooting
 
 If the disk is completely full, you will get an ``Out of disk space`` error that may crash your system because Dom0 does not have enough disk space to work. So it’s good practice to regularly check disk space usage. Running the ``df -h`` command in dom0 terminal will show some information, but not include all the relevant details. The Qubes user interface provides a disk space widget. If you are unable to access the interface, the command line version is running ``sudo lvs | head`` and looking at top entry for LVM pool. For example:
 
-.. code:: output
+.. code-block:: output
 
       LV                                            VG         Attr       LSize   Pool   Origin                                        Data%  Meta%  Move Log Cpy%Sync Convert
        pool00                                        qubes_dom0 twi-aotz-- 453.17g                                                      89.95  69.78
@@ -28,7 +28,7 @@ In any case you’ll need some disk space to start the VM. Check ``df -h`` outpu
 
 1. Clean yum cache.
 
-   .. code:: console
+   .. code-block:: console
 
          $ sudo dnf clean all
 
@@ -36,7 +36,7 @@ In any case you’ll need some disk space to start the VM. Check ``df -h`` outpu
 
 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.
 
-   .. code:: console
+   .. code-block:: console
 
          $ qvm-remove <VMname>
 
@@ -45,7 +45,7 @@ In any case you’ll need some disk space to start the VM. Check ``df -h`` outpu
 
 3. Decrease the filesystem safety margin (5% by default).
 
-   .. code:: console
+   .. code-block:: console
 
          $ sudo tune2fs -m 4 /dev/mapper/vg_dom0-lv_root
 
@@ -67,7 +67,7 @@ The above steps applies to old VM disks format. These steps may work on Qubes 4.
 
 For example:
 
-.. code:: console
+.. code-block:: console
 
       $ sudo lvs
         LV                                            VG         Attr       LSize   Pool   Origin                                        Data%  Meta%  Move Log Cpy%Sync Convert
@@ -96,7 +96,7 @@ For example:
 
 After freeing some initial space, it may be possible to recover more space by deleting files in a userVM after connecting to the userVM terminal:
 
-.. code:: console
+.. code-block:: console
 
       $ qvm-start <VMname>
       $ qvm-console-dispvm <VMname>
@@ -115,7 +115,7 @@ To fix this issue:
 
 1. In the dom0 terminal get a root console on the vm (eg. sys-usb) with:
 
-   .. code:: console
+   .. code-block:: console
 
          $ qvm-console-dispvm sys-usb
 
@@ -125,7 +125,7 @@ To fix this issue:
 
 3. When you attempt to unmount the ``/home`` directory using the ``umount /home`` command, you will encounter an error because there are processes using the ``/home`` directory. You can view a list of these processes with the ``fuser`` command:
 
-   .. code:: console
+   .. code-block:: console
 
          $ fuser -m /home
 
@@ -137,7 +137,7 @@ Kill these process until they are all gone using ``kill <process ID>``.
 
 4. Finally, run:
 
-   .. code:: console
+   .. code-block:: console
 
          $ umount /home
          $ fsck /dev/xvdb
diff --git a/user/troubleshooting/gui-troubleshooting.rst b/user/troubleshooting/gui-troubleshooting.rst
index 1ff6b50020..3236e23fc1 100644
--- a/user/troubleshooting/gui-troubleshooting.rst
+++ b/user/troubleshooting/gui-troubleshooting.rst
@@ -13,7 +13,7 @@ When a qube starts, a fixed amount of RAM is allocated to the graphics buffer ca
 
 To determine if this is the problem affecting you, look at the Xorg log inside the Qube at ``/home/user/.local/share/xorg/Xorg.0.log`` for lines like the following:
 
-.. code:: text
+.. code-block:: text
 
       [  1623.988] (EE) DUMMYQBS(0): Unable to set up a virtual screen size of 3440x1440 with 17101 Kb of video memory available.  Please increase the video memory size.
 
@@ -39,7 +39,7 @@ Post installation, screen goes black and freezes following LUKS decryption
 
 After installing Qubes, you may experience a black screen after entering your LUKS decryption password. To fix the problem, use your preferred text editor (``nano`` works) to edit ``/mnt/sysimage/boot/efi/EFI/qubes/xen.cfg``, adding the ``efi=no-rs`` option to the end of the ``options= line``. For example:
 
-.. code:: text
+.. code-block:: text
 
       [4.14.18-1.pvops.qubes.x86_64]
       options=loglvl=all dom0_mem=min:1024M dom0_mem=max:4096M iommu=no-igfx ucode=scan efi=no-rs
@@ -54,7 +54,7 @@ Can start VM, but can't launch any applications
 
 If you can start your VM, but can’t launch any applications, then you need to fix the issues from the ``VM console``, accessible from xen through:
 
-.. code:: console
+.. code-block:: console
 
       $ qvm-start <VMname> # Make sure the VM is started
       $ qvm-console-dispvm <VMname>
@@ -62,7 +62,7 @@ If you can start your VM, but can’t launch any applications, then you need to
 
 After launching a VM console using ``qvm-console-dispvm``, you may look at the ``qubes-gui-agent`` service state with:
 
-.. code:: console
+.. code-block:: console
 
       $ systemctl status -l qubes-gui-agent
 
@@ -78,7 +78,7 @@ Disable audited messages
 
 During troubleshooting, you may be getting a lot of ‘audit’ messages which make the log very noisy. To disable audited messages, you need to edit your VM kernel parameters:
 
-.. code:: console
+.. code-block:: console
 
       $ previous_kernel_parameters=$(qvm-prefs --get <VMname> kernelopts) # Get current kernel parameters
       $ qvm-prefs --set <VMname> kernelopts "<previous_kernel_parameters> audit=0"
diff --git a/user/troubleshooting/hardware-troubleshooting.rst b/user/troubleshooting/hardware-troubleshooting.rst
index b38d88642f..0b6d312fc9 100644
--- a/user/troubleshooting/hardware-troubleshooting.rst
+++ b/user/troubleshooting/hardware-troubleshooting.rst
@@ -9,7 +9,7 @@ Audio doesn't work / Troubleshooting newer hardware
 
 By default, the kernel that is installed in dom0 comes from the ``kernel`` package, which is an older Linux LTS kernel. For most cases this works fine since the Linux kernel developers backport fixes to this kernel, but for some newer hardware, you may run into issues. For example, the audio might not work if the sound card is too new for the LTS kernel. To fix this, you can try the ``kernel-latest`` package – though be aware that it’s less tested! (See :ref:`here <user/advanced-topics/how-to-install-software-in-dom0:kernel upgrade>` for more information about upgrading kernels in dom0). In dom0:
 
-.. code:: console
+.. code-block:: console
 
       $ sudo qubes-dom0-update kernel-latest
 
diff --git a/user/troubleshooting/hvm-troubleshooting.rst b/user/troubleshooting/hvm-troubleshooting.rst
index b8e5c3448c..021859e6ef 100644
--- a/user/troubleshooting/hvm-troubleshooting.rst
+++ b/user/troubleshooting/hvm-troubleshooting.rst
@@ -9,7 +9,7 @@ HVM pauses on boot, followed by kernel error
 
 The HVM may pause on boot, showing a fixed cursor. After a while a series of warnings may be shown similar to this:
 
-.. code:: output
+.. code-block:: output
 
       BUG: soft lockup - CPU#0 stuck for 23s! [systemd-udevd:244]
 
@@ -35,7 +35,7 @@ If this solves the problem then you will want to make the change permanent:
 
 2. Find the line which starts:
 
-   .. code:: bash
+   .. code-block:: bash
 
          GRUB_CMDLINE_LINUX=
 
@@ -43,7 +43,7 @@ If this solves the problem then you will want to make the change permanent:
 
 3. Remove this text from that line:
 
-   .. code:: text
+   .. code-block:: text
 
          rhgb
 
@@ -51,7 +51,7 @@ If this solves the problem then you will want to make the change permanent:
 
 4. Add this text to that line:
 
-   .. code:: text
+   .. code-block:: text
 
          modprobe.blacklist=bochs_drm
 
@@ -59,7 +59,7 @@ If this solves the problem then you will want to make the change permanent:
 
 5. Run this command:
 
-   .. code:: console
+   .. code-block:: console
 
          $ grub2-mkconfig --output=/boot/grub2/grub.cfg
 
@@ -75,7 +75,7 @@ Can't start an OS in an HVM / "Probing EDD (edd=off to disable!… ok" message
 
 If you see a screen popup with SeaBios and 4 lines, last one being ``Probing EDD (edd=off to disable!... ok``, then enter the following command from a ``dom0`` prompt:
 
-.. code:: console
+.. code-block:: console
 
       $ qvm-prefs <HVMname> kernel ""
 
@@ -90,7 +90,7 @@ You can disable memory-balancing in the settings, under the “Advanced” tab.
 
 To give the VM a RAM of 2GB, open a terminal in ``dom0`` and enter:
 
-.. code:: console
+.. code-block:: console
 
       $ qvm-prefs <HVMname> memory 2000
 
diff --git a/user/troubleshooting/installation-troubleshooting.rst b/user/troubleshooting/installation-troubleshooting.rst
index a405c6af03..32e09bf401 100644
--- a/user/troubleshooting/installation-troubleshooting.rst
+++ b/user/troubleshooting/installation-troubleshooting.rst
@@ -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:: console
+.. code-block:: console
 
       $ sudo dd if=Qubes-RX-x86_64.iso of=/dev/sdY status=progress bs=1048576 && sync
 
@@ -65,14 +65,14 @@ These errors may also occur due to an incompatible Nvidia graphics card. If you
 
 
 
-.. code:: text
+.. code-block:: text
 
       nouveau.modeset=0 rd.driver.blacklist=nouveau video=vesa:off
 
 
 If the above code doesn’t fix the problem, replace it with:
 
-.. code:: text
+.. code-block:: text
 
       noexitboot=1 modprobe.blacklist=nouveau rd.driver.blacklist=nouveau --- intitrd.img
 
@@ -105,7 +105,7 @@ In Qubes 4.0, the default installation won’t function properly without IOMMU,
 
 In Qubes 4.1, the default sys-net and sys-usb qubes need additional configuration to be usable without an IOMMU. Otherwise they will fail to start with this error message:
 
-.. code:: text
+.. code-block:: text
 
       Start failed: internal error: libxenlight failed to create new domain 'sys-net', see /var/log/libvirt/libxl/libxl-driver.log for details
 
@@ -113,7 +113,7 @@ In Qubes 4.1, the default sys-net and sys-usb qubes need additional configuratio
 
 To confirm that a missing IOMMU is causing this problem, check for the following error message in ``/var/log/libvirt/libxl/libxl-driver.log``:
 
-.. code:: text
+.. code-block:: text
 
       2022-03-01 13:27:17.117+0000: libxl: libxl_create.c:1146:libxl__domain_config_setdefault: passthrough not supported on this platform
 
diff --git a/user/troubleshooting/pci-troubleshooting.rst b/user/troubleshooting/pci-troubleshooting.rst
index 684cb26026..6d8684968b 100644
--- a/user/troubleshooting/pci-troubleshooting.rst
+++ b/user/troubleshooting/pci-troubleshooting.rst
@@ -11,7 +11,7 @@ VMs with attached PCI devices in Qubes have allocated a small buffer for DMA ope
 
 To change this allocation, edit VM’s kernel parameters (this is expressed in 512B chunks) by running the following in a dom0 terminal:
 
-.. code:: console
+.. code-block:: console
 
       $ qvm-prefs netvm |grep kernelopts
       kernelopts       : iommu=soft swiotlb=2048 (default)
@@ -55,7 +55,7 @@ Using the command line
 
 1. To see all the PCI available devices, enter the ``lspci`` command into the dom0 terminal. Each device will be listed on a line, for example:
 
-   .. code:: output
+   .. code-block:: output
 
          0000:03:00.0 Audio device: Intel Corporation Haswell-ULT HD Audio Controller (rev 0b)
 
@@ -64,14 +64,14 @@ Using the command line
 
 2. Now that you can see all the PCI devices and their BDFs, you can decide which to remove and which to keep. Imagine we faced the following error message:
 
-   .. code:: output
+   .. code-block:: output
 
          libvirt.libvirtError: internal error: Unable to reset PCI device 0000:03:00.1: internal error: Active 0000:03:00.0 devices on bus with 0000:03:00.1, not doing bus reset
 
 
    In the above case, the device ``0000:03:00.1`` is the device which we want to use. But we are facing the ``Unable to reset PCI device`` error because another device, ``0000:03:00.0``, is active. To fix this error and get device ``0000:03:00.1`` to work, we must first remove the offending device ``0000:03:00.0``.
 
-   .. code:: console
+   .. code-block:: console
 
          $ sudo su
          $ echo -n "1" > /sys/bus/pci/devices/0000:03:00.0/remove
@@ -80,7 +80,7 @@ Using the command line
 
 3. In order to make this change persistent, create a file ``/etc/systemd/system/qubes-pre-netvm.service`` and add the following:
 
-   .. code:: systemd
+   .. code-block:: systemd
 
          [Unit]
          Description=Netvm fixup
@@ -107,7 +107,7 @@ This is a :ref:`PCI passthrough issue <user/troubleshooting/pci-troubleshooting:
 
 NOTE: The ``permissive`` flag increases attack surface and possibility of `side channel attacks <https://en.wikipedia.org/wiki/Side-channel_attack>`__. While using the ``no-strict-reset`` flag, do not require PCI device to be reset before attaching it to another VM. This may leak usage data even without malicious intent. Both ``permissive`` and ``no-strict-reset`` options may not be necessary and you should try one first, then the other, before using both.
 
-.. code:: console
+.. code-block:: console
 
       $ qvm-pci attach --persistent --option permissive=true --option no-strict-reset=true sys-usb dom0:<BDF_OF_DEVICE>
 
diff --git a/user/troubleshooting/resume-suspend-troubleshooting.rst b/user/troubleshooting/resume-suspend-troubleshooting.rst
index 3687a02c6c..fe458b226e 100644
--- a/user/troubleshooting/resume-suspend-troubleshooting.rst
+++ b/user/troubleshooting/resume-suspend-troubleshooting.rst
@@ -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:: console
+.. code-block:: console
 
       [user@sys-net ~]$ lspci -k
       00:00.0 Network controller: Intel Corporation Wireless 8260 (rev 3a)
@@ -39,7 +39,7 @@ 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):
 
-.. code:: output
+.. code-block:: output
 
       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
@@ -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:: console
+.. code-block:: 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:: console
+.. code-block:: 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:: console
+.. code-block:: 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:: console
+.. code-block:: 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:: console
+.. code-block:: 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:: console
+.. code-block:: 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
diff --git a/user/troubleshooting/uefi-troubleshooting.rst b/user/troubleshooting/uefi-troubleshooting.rst
index fb780f1c0f..db0316244f 100644
--- a/user/troubleshooting/uefi-troubleshooting.rst
+++ b/user/troubleshooting/uefi-troubleshooting.rst
@@ -13,7 +13,7 @@ Successfully installed in legacy mode, but had to change some xen parameters
 
 2. Open a terminal and enter the command ``sudo su -``. Use your preferred text editor (e.g ``vi``) to edit your xen config (``EFI/BOOT/grub.cfg``):
 
-   .. code:: console
+   .. code-block:: console
 
          $ vi EFI/BOOT/grub.cfg
 
@@ -52,7 +52,7 @@ Some Dell systems and probably others have `another bug in UEFI firmware <https:
 
 3. Execute:
 
-   .. code:: console
+   .. code-block:: console
 
          $ sed -i -e 's/ucode=scan/\0 efi=attr=uc/' /mnt/sysimage/boot/efi/EFI/qubes/grub.cfg
 
@@ -68,26 +68,26 @@ Or if you have already rebooted after the first stage install and have encounter
 
 3. Find and mount the EFI system partition. (replace ``/dev/sda`` with your disk name. If unsure, use the ``lsblk`` command to display a list of disks):
 
-   .. code:: console
+   .. code-block:: console
 
          $ fdisk -l /dev/sda | grep EFI
 
    The output should look like this:
 
-   .. code:: output
+   .. code-block:: output
 
          /dev/sda1   2048    1230847 1228800 600M EFI System
 
    Then mount it:
 
-   .. code:: console
+   .. code-block:: console
 
          $ mkdir -p /mnt/sysimage/boot/efi
          $ mount /dev/sda1 /mnt/sysimage/boot/efi
 
 4. Execute:
 
-   .. code:: console
+   .. code-block:: console
 
          $ sed -i -e 's/ucode=scan/\0 efi=attr=uc/' /mnt/sysimage/boot/efi/EFI/qubes/grub.cfg
 
@@ -106,26 +106,26 @@ Some firmware will not recognize the default Qubes EFI configuration. As such, i
 
 3. Find and mount the EFI system partition. (replace ``/dev/sda`` with your disk name. If unsure, use the ``lsblk`` command to display a list of disks):
 
-   .. code:: console
+   .. code-block:: console
 
          $ fdisk -l /dev/sda | grep EFI
 
    The output should look like this:
 
-   .. code:: output
+   .. code-block:: output
 
          /dev/sda1   2048    1230847 1228800 600M EFI System
 
    Then mount it:
 
-   .. code:: console
+   .. code-block:: console
 
          $ mkdir -p /mnt/sysimage/boot/efi
          $ mount /dev/sda1 /mnt/sysimage/boot/efi
 
 4. Copy ``grubx64.efi`` to the fallback path:
 
-   .. code:: console
+   .. code-block:: console
 
          $ cp /mnt/sysimage/boot/efi/EFI/qubes/grubx64.efi /mnt/sysimage/boot/efi/EFI/BOOT/bootx64.efi
 
@@ -140,7 +140,7 @@ Some firmware will not recognize the default Qubes EFI configuration. As such, i
 
 3. Create boot entry in EFI firmware (replace ``/dev/sda`` with your disk name and ``-p 1`` with ``/boot/efi`` partition number):
 
-   .. code:: console
+   .. code-block:: console
 
          $ efibootmgr -v -c -u -L Qubes -l /EFI/qubes/grubx64.efi -d /dev/sda -p 1
 
@@ -156,7 +156,7 @@ If you upgraded from Qubes OS R4.0 or followed outdated instructions, you might
 
 The content of :file:`/boot/efi/EFI/qubes/grub.cfg` should be something like:
 
-.. code:: bash
+.. code-block:: bash
 
    search --no-floppy --fs-uuid --set=dev xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
    set prefix=($dev)/grub2
@@ -165,7 +165,7 @@ The content of :file:`/boot/efi/EFI/qubes/grub.cfg` should be something like:
 
 Where the end of the first line is replaced by a UUID. If not, you can reinstall this file:
 
-.. code:: console
+.. code-block:: console
 
    sudo qubes-dom0-update --action=reinstall grub2-common
 
diff --git a/user/troubleshooting/usb-troubleshooting.rst b/user/troubleshooting/usb-troubleshooting.rst
index 1ffe7968ee..0d18495025 100644
--- a/user/troubleshooting/usb-troubleshooting.rst
+++ b/user/troubleshooting/usb-troubleshooting.rst
@@ -41,7 +41,7 @@ A device that does not support reset is not ideal and generally should not be as
 
 Most likely the offending controller is a USB 3.0 device. You can remove this controller from the USB VM, and see if this allows the VM to boot. Alternatively you may be able to disable USB 3.0 in the BIOS. If the BIOS does not have the option to disable USB 3.0, try running the following command in dom0 to force USB 2.0 modes for the USB ports:
 
-.. code:: console
+.. code-block:: console
 
       $ lspci -nn | grep USB | cut -d '[' -f3 | cut -d ']' -f1 | xargs -I@ setpci -H1 -d @ d0.l=0
 
@@ -51,7 +51,7 @@ Errors suggesting this issue:
 
 - in ``xl dmesg`` output:
 
-  .. code:: output
+  .. code-block:: output
 
         (XEN) [VT-D] It's disallowed to assign 0000:00:1a.0 with shared RMRR at dbe9a000 for Dom19.
         (XEN) XEN_DOMCTL_assign_device: assign 0000:00:1a.0 to dom19 failed (-1)
@@ -60,7 +60,7 @@ Errors suggesting this issue:
 
 - during ``qvm-start sys-usb``:
 
-  .. code:: output
+  .. code-block:: output
 
         internal error: Unable to reset PCI device [...]  no FLR, PM reset or bus reset available.
 
@@ -72,7 +72,7 @@ Another solution would be to set the pci_strictreset option in dom0:
 
 - In Qubes R4.x, when attaching the PCI device to the VM (where ``<BDF>`` can be obtained from running ``qvm-pci``):
 
-  .. code:: console
+  .. code-block:: console
 
         $ qvm-pci attach --persistent --option no-strict-reset=true usbVM dom0:<BDF>
 
@@ -80,7 +80,7 @@ Another solution would be to set the pci_strictreset option in dom0:
 
 - In Qubes R3.x, by modifying the VM’s properties:
 
-  .. code:: console
+  .. code-block:: console
 
         $ qvm-prefs usbVM -s pci_strictreset false
 
diff --git a/user/troubleshooting/vm-troubleshooting.rst b/user/troubleshooting/vm-troubleshooting.rst
index f15beef735..dd4d516064 100644
--- a/user/troubleshooting/vm-troubleshooting.rst
+++ b/user/troubleshooting/vm-troubleshooting.rst
@@ -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:: console
+   .. code-block:: 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:: console
+   .. code-block:: 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:: console
+  .. code-block:: console
 
         $ qvm-remove template-vm-name
 
@@ -73,7 +73,7 @@ Some packages will throw an error on installation in this situation. For example
 
 One solution is to add a dummy interface to allow the package to install correctly:
 
-.. code:: console
+.. code-block:: console
 
       $ ip link add d0 type dummy
       $ ip addr add 192.168.0.1/24 dev d0
@@ -95,7 +95,7 @@ If the error occurs as a result of too little initial memory, increase the initi
 
 For example:
 
-.. code:: console
+.. code-block:: 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...