Qubes-Whonix Development / Qubes Integration

Patrick · November 30, 2022, 6:24pm

qubes-template-whonix-gw-16 4.0.6-202211291224 (r4.1)

opened 12:25PM - 29 Nov 22 UTC

closed 11:45AM - 18 Dec 22 UTC

r4.1-stable

Template whonix-gw-16 4.0.6-202211291224 for Qubes r4.1, see comments below for …details. If you're release manager, you can issue GPG-inline signed command (depending on template): * `Upload linux-template-builder 4.0.6-202211291224 r4.1 templates-itl vm-whonix-gateway-16 repo` (available 7 days from now) * `Upload linux-template-builder 4.0.6-202211291224 r4.1 templates-community vm-whonix-gateway-16 repo` (available 7 days from now) Above commands will work only if package in testing repository isn't superseded by newer version.

github.com/QubesOS/updates-status

qubes-template-whonix-ws-16 4.0.6-202211291224 (r4.1)

opened 01:06PM - 29 Nov 22 UTC

closed 11:45AM - 18 Dec 22 UTC

qubesos-bot

r4.1-stable

Template whonix-ws-16 4.0.6-202211291224 for Qubes r4.1, see comments below for …details. If you're release manager, you can issue GPG-inline signed command (depending on template): * `Upload linux-template-builder 4.0.6-202211291224 r4.1 templates-itl vm-whonix-workstation-16 repo` (available 7 days from now) * `Upload linux-template-builder 4.0.6-202211291224 r4.1 templates-community vm-whonix-workstation-16 repo` (available 7 days from now) Above commands will work only if package in testing repository isn't superseded by newer version.

Patrick · December 3, 2022, 4:52pm

Patrick · December 18, 2022, 11:45am

qubes-template-whonix-gw-16 4.0.6-202211291224 (r4.1) · Issue #3212 · QubesOS/updates-status · GitHub
qubes-template-whonix-ws-16 4.0.6-202211291224 (r4.1) · Issue #3213 · QubesOS/updates-status · GitHub

Patrick · December 21, 2022, 2:16pm

github.com/adrelanos/qubes-template-whonix

Refactor for supporting both legacy and next generation of Qubes OS builder

adrelanos:master ← fepitre:builderv2

opened 08:26AM - 20 Dec 22 UTC

fepitre

+109 -54

While writing the new Qubes OS builder, we integrated the content of the templat…e-whonix repository into qubes-builderv2 repository directly to simplify the development. We are putting back refactored content for templates supporting both legacy and new Qubes builder into original repositories. Once this is merged into Whonix/qubes-template-whonix, we will adapt configuration file examples in qubes-builderv2 to use your key as maintainer for Whonix. See: - https://github.com/QubesOS/qubes-builderv2/pull/24 - https://github.com/QubesOS/qubes-builder-rpm/pull/120 - https://github.com/QubesOS/qubes-builder-debian/pull/63 - https://github.com/QubesOS/qubes-linux-template-builder/pull/25

Patrick · February 2, 2023, 7:25pm

qubes-template-whonix-gw-16 4.0.6-202302011525 (r4.1) · Issue #3479 · QubesOS/updates-status · GitHub
qubes-template-whonix-ws-16 4.0.6-202302011525 (r4.1) · Issue #3480 · QubesOS/updates-status · GitHub

Patrick · February 6, 2023, 11:17am

Above templates are working fine for me.

Patrick · February 8, 2023, 10:43am

https://github.com/QubesOS/qubes-issues/issues/5009#issuecomment-1422389814

Patrick · February 13, 2023, 12:07pm

Patrick · May 5, 2023, 1:40pm

github.com/QubesOS/qubes-issues

Qubes dom0 clock fix difficult, ClockVM does not fix its own clock

opened 01:39PM - 05 May 23 UTC

adrelanos

T: bug P: default

### Qubes OS release `4.1.2` ### Brief summary Qubes is difficult to re…cover from wrong system time. `sudo qvm-sync-clock` is confusing and doesn't fix dom0 or VM clocks. ### Impact Why does it matter? If system time is too far off it breaks TLS (https websites), Tor, system upgrades and more. ### Steps to reproduce 1. set a wrong time in dom0 `sudo date --utc --set "Fri 04 May 2023 01:16:10 PM UTC"` 2. reboot (or at least restart sys-net (actually ClockVM)) 3. Try to fix in dom0 `sudo qvm-sync-clock`. 4. Alternatively try to fix dom0 clock by using GNU date (or any other mechanism). ### Expected behavior * `qvm-sync-clock` fixes the dom0 clock. * Newly started VMs have the correct time. * ClockVM should have a mechanism to fix its own time even if it is far off. ### Actual behavior * `qvm-sync-clock` sets the dom0 to the incorrect (outdated, slow) time, which it gets from ClockVM. Technically speaking, dom0 `/usr/bin/qvm-sync-clock` simply calls the ClockVMs `/etc/qubes-rpc/qubes.GetDate`, which still has the wrong time which then dom0 uses. * Newly started VMs the an incorrect time. * If just manually fixed using GNU date, then newly started VMs will get the correct time of a while. Except, until... * After `qvm-sync-clock` was automatically run (it seems to be periodically run), it will set again the wrong time from ClockVM. * dom0 clock will be periodically (whenever `qvm-sync-clock` automatically runs in dom0) be reverted to the wrong clock coming from ClockVM. * Highly confusing and took me a while to debug. ### Workaround 1. Shutdown all VMs. (Or at least ClockVM, most likely the default sys-net.) 2. Correct the time in dom0. 3. Restart VMs. 4. Done.

Patrick · May 6, 2023, 7:17am

Switch to nftables by DemiMarie · Pull Request #407 · QubesOS/qubes-core-agent-linux · GitHub

Patrick · June 17, 2023, 11:00am

github.com/QubesOS/qubes-issues

Qubes R4.2 build failing - qubes-builder/qubes-src/builder-debian/keys/qubes-debian-r4.2.asc: No such file or directory

opened 11:00AM - 17 Jun 23 UTC

adrelanos

T: bug P: default

``` /home/user/qubes-builder/qubes-src/builder-debian//prepare-chroot-debian: l…ine 193: /home/user/qubes-builder/qubes-src/builder-debian/keys/qubes-debian-r4.2.asc: No such file or directory make[1]: *** [/home/user/qubes-builder/qubes-src/builder-debian//Makefile-legacy.debian:28: /home/user/qubes-builder/chroot-vm-bookworm/home/user/.prepared_base] Error 1 make: *** [Makefile:265: core-vchan-xen-vm] Error 1 ```

Patrick · June 20, 2023, 8:26am

github.com/QubesOS/qubes-issues

Debian 12 (bookworm) Template has broken DNS resolution when using http_proxy=http://127.0.0.1:8082/ (Qubes UpdatesProxy) (tinyproxy)

opened 08:21AM - 20 Jun 23 UTC

adrelanos

T: bug P: default

### Qubes OS release 4.1 ### Brief summary Setting `http_proxy=http://1…27.0.0.1:8082/` is broken in `debian-12` (bookworm) Template. ### Steps to reproduce Use `debian-12` (bookworm) Template. http_proxy=http://127.0.0.1:8082/ curl https://check.torproject.org ### Expected behavior Functional DNS. ### Actual behavior Broken DNS. > curl: (6) Could not resolve host: check.torproject.org ### Additional information This is reproducible if `sys-net` (UpdateVM) is using as Template: * `debian-11` * `debian-12` * `fedora-38` Template: * This did not happen with `debian-11` (bullseye) Template. * Only `debian-12` (bookworm) Template is affected by this bug. dom0 journalctl qubes qrexec-policy-daemon does not see the request when using DNS. (It does see the request when using IP.) It could be that curl (and other applications) are using `http_proxy=http://127.0.0.1:8082/` for IP but ignore it for DNS resolution. ### Impact Breaks various things, including: * curl repository signing key download * extrepo: `http_proxy=http://127.0.0.1:8082/ sudo extrepo enable kicksecure` * flatpak: `http_proxy=http://127.0.0.1:8082 flatpak remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo` * Qubes-Whonix: Tor Browser updates by `update-torbrowser` running inside Template

Patrick · June 28, 2023, 12:25pm

github.com/QubesOS/qubes-issues

PS/2 touchpad broken in 4.2.0-rc1

opened 12:25PM - 28 Jun 23 UTC

adrelanos

T: bug P: default

### Qubes OS release `4.2.0-rc1` ### Brief summary PS/2 touchpad broke…n. ### Steps to reproduce Install Qubes `4.2.0-rc1` and try using the touchpad. ### Expected behavior Functional touchpad. ### Actual behavior Broken touchpad. ### Additional information Was functional in Qubes `R4.1`. Using USBVM. (This was OK in `R4.1` too.) But the touchpad is not an internal USB touchpad. It much be PS/2. This is because it was functional in Qubes `R4.1` previously too, because it was functional along with the internal keyboard while USBVM was shutdown (while USB connected mice was dysfunctional as expected when USBVM is shutdown). ### Debugging How to debug this? journalctl doesn't show any error related to `touchpad`, `pad`, `touch`, `mouse`, `mice`. Neither xorg log showing any errors. `xinput` doesn't show the device. Have any changes been made in Qubes `R4.2` which might result in the disabling of the internal PS/2 touchpad?

Patrick · June 28, 2023, 12:26pm

Patrick · June 30, 2023, 9:36am

github.com/QubesOS/qubes-issues

`sudo qubes-dom0-update` results in broken updates with `script: cannot open typescript: Permission denied`

opened 09:36AM - 30 Jun 23 UTC

adrelanos

T: bug P: default

### Qubes OS release R4.2 ### Brief summary Running `sudo qubes-dom0-up…date` results in: > script: cannot open typescript: Permission denied And no update. Nothing beyond that point. ### Steps to reproduce 1. Qubes R4.2 installation 2. testers updates 3. `sudo qubes-dom0-update` ### Expected behavior No such error. ### Actual behavior > script: cannot open typescript: Permission denied

Patrick · July 3, 2023, 12:14pm

github.com/QubesOS/qubes-issues

/usr/sbin/policy-rc.d file exists which prevents daemons from (re-)starting during package upgrades

opened 12:14PM - 03 Jul 23 UTC

adrelanos

T: bug P: default

### Qubes OS release R4.2 ### Brief summary File `/usr/sbin/policy-rc.d…` file exists and prevents daemons from (re-)starting during package upgrades. ### Steps to reproduce 1. install Qubes R4.2 2. Install whonix-gw-16 template from qubes-templates-community-testing repository 3. `ls -la /usr/sbin/policy-rc.d` ### Expected behavior No such message and service restarted. ### Actual behavior During upgrades: > /usr/sbin/policy-rc.d returned 101, not running 'restart qubes-whonix-network.service qubes-whonix-postinit.service qubes-whonix-qubes-updates-proxy-enable-maybe.service qubes-whonix-redirect-9050.service qubes-whonix-redirect-9050.socket qubes-whonix-remote-support.service qubes-whonix-sysinit.service qubes-whonix-torified-updates-proxy-check.service' ### Additional information cat /usr/sbin/policy-rc.d > exit 101 Does Qubes builder or a Qubes package create file `/usr/sbin/policy-rc.d`? Whonix doesn't create file `/usr/sbin/policy-rc.d` as this isn't needed and I highly discourage it. A Qubes user reported message `/usr/sbin/policy-rc.d returned 101, not running 'start qubes-qrexec-agent.service' ` here: https://forum.qubes-os.org/t/4-1beta-upgrade-stage1-errors/5227/4 Therefore this is most likely a general Qubes issue. Not caused by Whonix. Affects Qubes-Whonix: yes ### Related tickets * https://github.com/QubesOS/qubes-issues/issues/2238

Patrick · July 5, 2023, 8:14pm

github.com/QubesOS/qubes-issues

Qubes official Template build failed without success or error issue being created

opened 08:12PM - 05 Jul 23 UTC

adrelanos

T: bug P: default

Build commands to build Qubes-Whonix from 5 hours ago: https://github.com/Qubes…OS/updates-status/issues/566#issuecomment-1621896190 Build does not show up either in: * https://github.com/QubesOS/updates-status/issues nor * https://github.com/QubesOS/build-issues/issues The build command I used: make 'DISTS_VM=whonix-gateway-17 whonix-workstation-17' template-github

Patrick · July 14, 2023, 12:32pm

github.com/QubesOS/updates-status

qubes-template-whonix-gateway-17 4.2.0-202307131323 (r4.2)

opened 01:23PM - 13 Jul 23 UTC

fepitre-bot

r4.2-testing

Template whonix-gateway-17 4.2.0-202307131323 for Qubes OS r4.2, see comments be…low for details and build status. If you're release manager, you can issue GPG-inline signed command (depending on template): * `Upload-template r4.2 whonix-gateway-17 4.2.0-202307131323 templates-itl` (available 5 days from now) * `Upload-template r4.2 whonix-gateway-17 4.2.0-202307131323 templates-community` (available 5 days from now) Above commands will work only if package in testing repository isn't superseded by newer version. For more information on how to test this update, please take a look at https://www.qubes-os.org/doc/testing/#updates.

github.com/QubesOS/updates-status

qubes-template-whonix-workstation-17 4.2.0-202307131323 (r4.2)

opened 02:02PM - 13 Jul 23 UTC

fepitre-bot

r4.2-testing

Template whonix-workstation-17 4.2.0-202307131323 for Qubes OS r4.2, see comment…s below for details and build status. If you're release manager, you can issue GPG-inline signed command (depending on template): * `Upload-template r4.2 whonix-workstation-17 4.2.0-202307131323 templates-itl` (available 5 days from now) * `Upload-template r4.2 whonix-workstation-17 4.2.0-202307131323 templates-community` (available 5 days from now) Above commands will work only if package in testing repository isn't superseded by newer version. For more information on how to test this update, please take a look at https://www.qubes-os.org/doc/testing/#updates.

Patrick · July 14, 2023, 12:33pm

Coordinate release of Whonix for R4.2 · Issue #7931 · QubesOS/qubes-issues · GitHub

Patrick · July 15, 2023, 2:54pm

github.com/QubesOS/qubes-issues

raw disk backup of Qubes EFI is unbootable

opened 02:53PM - 15 Jul 23 UTC

adrelanos

T: bug P: default

### Qubes OS release R4.1 and R4.2 ### Brief summary When making a raw …disk backup from a Qubes installed to an internal hard drive to an external hard drive, the external hard drive is unbootable. raw disk backup means a backup using `dd` or 1 to 1 exact copy. ### Steps to reproduce 1. install Qubes normally on a computer that only support EFI booting on the internal harddrive 2. reboot 3. brief test that Qubes is working normally (yes) 4. shutdown Qubes 5. boot from an external drive, boot a live DVD or live USB such as Debian Live 6. perform a raw disk backup from the internal disk to the external disk 7. unplug that disk and try to boot from it in a different computer (or the same Qubes computer) ([example instructions for raw disk backups](https://www.kicksecure.com/wiki/Raw_Disk_Backup)) ### Expected behavior The raw disk backup of Qubes is bootable. ### Actual behavior The raw disk backup of Qubes is unbootable. ### Additional information According to my research that might be because of missing entries in the EFI firmware's NVRAM which is stored on the motherboard. Unfortunately, the EFI boot process doesn't seem by default to be self-contained on 1 harddrive but require extra settings stored outside harddrives on the motherboard (EFI NVRAM). Using `grub2-install` with options `--removable` / `--force-extra-removable` during Qubes installation might help? > [--removable](https://manpages.debian.org/bookworm/grub2-common/grub-install.8.en.html#removable) > the installation device is removable. This option is only available on EFI. > [--force-extra-removable](https://manpages.debian.org/bookworm/grub2-common/grub-install.8.en.html#force~2) > force installation to the removable media path also. This option is only available on EFI. Qubes does not have good support for multiboot support anyhow: * https://github.com/QubesOS/qubes-issues/issues/8351 * https://www.qubes-os.org/faq/#can-i-install-qubes-os-together-with-other-operating-system-dual-bootmulti-boot * It's "patches welcome". (And that's okay.) This ticket is not a feature request to improve multiboot support. Why do I mention this? Because otherwise, when considering options `--removable` / `--force-extra-removable` one *might* argue "but that breaks mutliboot support". I would argue that being able to boot a raw disk backup of Qubes is more important than mutliboot support. [Why do I like full raw disk backups? See this link.](https://forum.qubes-os.org/t/how-do-you-organize-your-backups/3986/16?u=adrelanos) Manually updating the NVRAM can be challenging: * It's vendor dependent because of many different EFI BIOS versions. * Some BIOS don't even have such an option. * Might require booting into an operating system installed on USB and running console commands to fix it. * Difficult, impossible for far most users to do or even to find instructions for it. Qubes with legacy BIOS booting as far as I remember didn't have this issue. However, never notebooks sometimes (or often, dunno) don't even support legacy BIOS booting anymore. Therefore "use legacy BIOS booting" is a non-solution. Also not a good long term solution in either case because of Qubes planned Secure Boot support. This bug might also make Qubes "non-portable". Meaning, Qubes installed to an external drive such as a USB SSD might be bootable on the computer where it was installed but unbootable when attempting to boot the same Qubes USB SSD on another computer. I didn't test this very part mentioned in this very chapter. Anaconda by Fedora might be using `grub2-install` with options `--removable` / `--force-extra-removable` already when installing to external devices (USB) instead of internal harddrive. Where is the Qubes code which defines bootloader / grub2 / EFI installation? Or is this currently all done by upstream's Anaconda?