diff --git a/about/faq.md b/about/faq.md index c666f9ca..375237bc 100644 --- a/about/faq.md +++ b/about/faq.md @@ -579,3 +579,8 @@ Arguably secure boot reliance on UEFI integrity is not the best design. The relevant binaries (shim.efi, xen.efi, kernel / initramfs) are not signed by the Qubes Team and secure boot has not been tested. Intel TXT (used in [Anti Evil Maid](/doc/anti-evil-maid/)) at least tries to avoid or limit trust in BIOS. See the Heads project [[1]](https://trmm.net/Heads) [[2]](http://osresearch.net/) for a better-designed non-UEFI-based secure boot scheme with very good support for Qubes. + +### What is the canonical way to detect Qubes VM? + +Check `/usr/share/qubes/marker-vm` file existence. Additionally, its last line contains Qubes release version (`3.2`, `4.0` etc). +The file was introduced after initial Qubes 3.2 and 4.0 release. If you need to support not-fully-updated systems, check `/usr/bin/qrexec-client-vm` existence. diff --git a/building/qubes-builder.md b/building/qubes-builder.md index 7cabbc29..0aefb037 100644 --- a/building/qubes-builder.md +++ b/building/qubes-builder.md @@ -135,6 +135,27 @@ If you want to somehow modify sources, you can also do it, here are some basic s make iso +### Use pre-built Qubes packages + +For building just few selected packages, it's very useful to download pre-built qubes-specific dependencies from `{yum,deb}.qubes-os.org`. +This is especially true for `gcc`, which takes several hours to build. + +Before creating the `chroot`, add this to your `builder.conf`: + + USE_QUBES_REPO_VERSION = $(RELEASE) + +It will add the 'current' Qubes repository to your `chroot` environment. +This way, you can build only the packages you are interested in. +If you also want to use the 'current-testing' repository, add this to your configuration: + + USE_QUBES_REPO_TESTING = 1 + +In the case of an existing `chroot`, for mock-enabled builds, it works immediately because `chroot` is constructed each time separately. +For legacy builds, it will not add the necessary configuration into the build environment unless a specific builder change or configuration would force rebuilding chroot. + +Also, once enabled, disabling this setting will not disable repositories in relevant chroots. +And even if it did, there could be leftover packages installed from those repos (which may or may not be desirable). + Code verification keys management --------------------------------- diff --git a/customization/bind-dirs.md b/customization/bind-dirs.md index 1b84f152..97a338b1 100644 --- a/customization/bind-dirs.md +++ b/customization/bind-dirs.md @@ -65,14 +65,13 @@ Creation of the file and folders in /rw/bind-dirs should be automatic the first If you want to circumvent this process, you can create the relevant filestructure under /rw/bind-dirs and make any changes at the same time that you perform the configuration, before reboot. - ## Limitations ## * Files that exist in the TemplateVM root image cannot be deleted in the TemplateBasedVMs root image using bind-dirs.sh. * Re-running `sudo /usr/lib/qubes/bind-dirs.sh` without a previous `sudo /usr/lib/qubes/bind-dirs.sh umount` does not work. * Running `sudo /usr/lib/qubes/bind-dirs.sh umount` after boot (before shutdown) is probably not sane and nothing can be done about that. * Many editors create a temporary file and copy it over the original file. If you have bind mounted an individual file this will break the mount. -Any changes you make will not survive a reboot. If you think it likely you will want to edit a file, then either include the parent directory in bind-dirs.rather than the file, or perform the file operation on the file in /rw/bind-dirs. +Any changes you make will not survive a reboot. If you think it likely you will want to edit a file, then either include the parent directory in bind-dirs rather than the file, or perform the file operation on the file in /rw/bind-dirs. * Some files are altered when a qube boots - e.g. `/etc/hosts`. If you try to use bind-dirs on such files you may break your qube in unpredictable ways. You can add persistent rules to `/etc/hosts` file using script `/rw/config/rc.local` that is designed to override configuration in /etc, starting services and etc. For example, to make software inside some TemplateBasedVM resolving the domain `example.com` as `127.0.0.1` open `/rw/config/rc.local` inside this TemplateBasedVM and add: @@ -83,8 +82,6 @@ echo '127.0.0.1 example.com' >> /etc/hosts After every boot of the TemplateBasedVM `rc.local` script will add line `127.0.0.1 example.com` to `/etc/hosts` file and the software inside the TemplateBasedVM will resolve domain `example.com` accordingly. You cam add several rules to `/etc/hosts` the same way. - - ## How to remove binds from bind-dirs.sh? ## `binds` is actually just a bash variable (an array) and the bind-dirs.sh configuration folders are `source`d as bash snippets in lexical order. diff --git a/managing-os/templates/fedora-minimal.md b/managing-os/templates/fedora-minimal.md index 13b8afac..4bafa214 100644 --- a/managing-os/templates/fedora-minimal.md +++ b/managing-os/templates/fedora-minimal.md @@ -67,7 +67,7 @@ Use case | Description | Required steps Use case | Description | Required steps --- | --- | --- **Standard utilities** | If you need the commonly used utilities | Install the following packages: `pciutils` `vim-minimal` `less` `psmisc` `gnome-keyring` -**Audio** | If you want sound from your VM... | Install `pulseaudio-qubes` +**Audio** | If you want sound from your VM | Install `pulseaudio-qubes` **FirewallVM** | You can use the minimal template as a [FirewallVM](/doc/firewall/), such as the basis template for `sys-firewall` | Install at least `qubes-core-agent-networking` and `iproute`, and also `qubes-core-agent-dom0-updates` if you want to use it as the updatevm (which is normally sys-firewall). **NetVM** | You can use this template as the basis for a NetVM such as `sys-net` | Install the following packages: `qubes-core-agent-networking` `qubes-core-agent-network-manager` `NetworkManager-wifi` `network-manager-applet` `wireless-tools` `dejavu-sans-fonts` `notification-daemon` `gnome-keyring` `polkit` `@hardware-support`. **NetVM (extra firmware)** | If your network devices need extra packages for the template to work as a network VM | Use the `lspci` command to identify the devices, then run `dnf search firmware` (replace `firmware` with the appropriate device identifier) to find the needed packages and then install them.