Debian bullseye port

torjunkie · August 2, 2021, 12:00pm

1. Note from Qubes R4.1 testers:

Package qubes-template-whonix-gw-15 available, but not installed.
No match for argument: qubes-template-whonix-gw-15
Error: No packages marked for reinstall
Fetching updates failed with code1; press Enter to exit

&

Yes I was able to install the template by enabling the templates-community-testing repo and then issuing this command: sudo qubes-dom0-update --enablerepo=qubes-templates-community qubes-template-whonix-gw-15 & sudo qubes-dom0-update --enablerepo=qubes-templates-community-testing qubes-template-whonix-ws-15

Note that the whonix wiki states to use the --action=upgrade or --action=reinstall argument which clearly failed to work in my case.

A bit confusing that R4.1 testers can’t install the template from the community repo which the whonix wiki insists on using.

I don’t know if we want to change anything i.e. since Qubes R4.1 will be stable soon enough?

Also, that reporter’s action to resolve it looks confusing i.e. enabling whonix-gw-15 from qubes-template-community, while whonix-ws-15 installed from qubes-templates-community-testing?

Why would ws and gw be available from different repos in that case? Weird.

2. Also, with Debian 11 released in two weeks (August 14), should there be some News announcement about upcoming Whonix 16? I know that you previously released Whonix 15 slightly before Debian 10 stable was released (from memory).

Patrick · August 2, 2021, 12:00pm

I don’t know anything other than the general public. No inside information. No news on that as far as I know.

Qubes-Whonix R4.1 plans generally:

github.com/QubesOS/qubes-issues

4.1: Whonix WS failing

opened 11:33AM - 11 May 21 UTC

jpds

C: Whonix P: default T: bug needs diagnosis

**Qubes OS version** 4.1, all updates applied. **Affected component(s) or …functionality** Whonix Workstation. **Brief summary** I applied updates to my 4.1 system a couple of weeks ago, and ever since then, I've not been able to use my Whonix Workstation DVMs, running `systemcheck` in the DVM gives: ``` $ systemcheck [INFO] [systemcheck] disp891 | Whonix-Workstation | whonix-ws-15-dvm DispVM AppVM | Tue 11 May 2021 11:30:05 AM UTC [INFO] [systemcheck] Tor Connection Result: Tor's Control Port could not be reached. Attempt 1 of 5. Could be temporary due to a Tor restart. Trying again... [ERROR] [systemcheck] Tor Connection Result: Tor's Control Port could not be reached! ... ``` The gateway itself is fine: ``` $ systemcheck [INFO] [systemcheck] sys-whonix | Whonix-Gateway | whonix-gw-15 TemplateBased ProxyVM | Tue 11 May 2021 11:31:20 AM UTC [INFO] [systemcheck] Connected to Tor. ... ``` I've also tried reinstalling both templates, same result. **How Reproducible** Always

That’s a Qubes issue. I don’t manage Qubes dom0 repositories.

Fedora upgrades (which Qubes dom0 is based on) and then on top of that the qubes-dom0-update is confusing. It might show “not available” while it actually means “installed and no other version found but let’s say not available”.

User didn’t follow instructions.
Instructions HowTo: Install the Stable Version of Qubes-Whonix ™ 15 do not mention sudo qubes-dom0-update --enablerepo [...].

Many Qubes specific quirks related to template installation. Related:

github.com/QubesOS/qubes-issues

phase out manual use of qubes-dom0-update by user / replace it by salt

opened 02:29PM - 06 Jan 18 UTC

adrelanos

C: mgmt T: enhancement

Talked to Marek at 34c3. We concluded the following. * Installing Whonix manu…ally using `qubes-dom0-update` got too difficult since too many manual modifications of dom0 would be required. * Most users shall no longer install Whonix using `qubes-dom0-update`. * Most users shall install Whonix using Qubes `salt`. * Most users shall no longer update using `qubes-dom0-update`. * Should use `sudo qubesctl --templates pkg.upgrade` instead. * We need `salt` commands for installation of arch linux and others * Modify `qubes-dom0-update` to tell the user it is recommended to use `salt` instead. Basically, let's phase out manual use of `qubes-dom0-update` by users. Technical background: * Marek said we cannot make `qubes-dom0-update` run `salt`, because `salt` is running `qubes-dom0-update` and it must not be circular. Would be tricky because not clear which salt `salt` formula to enable. * This is a description what Qubes `salt` does (confirmed by Marek): https://www.whonix.org/wiki/Dev/Qubes#salt

github.com/QubesOS/qubes-issues

qubes-dom0-update combined --action=upgrade --action=reinstall command

opened 09:49AM - 18 Nov 18 UTC

adrelanos

C: core C: doc T: enhancement

### Qubes OS version: R4 ### Affected component(s): dom0 ### Steps to r…eproduce the behavior: Follow * https://www.whonix.org/wiki/Qubes/Reinstall OR * https://www.qubes-os.org/doc/reinstall-template/ ### Expected behavior: Easy combined upgrade and reinstall command without explanation required. ### Actual behavior: Commands for upgrade and reinstall have to be tried separately. Usability issue. * `--action=upgrade` * `--action=reinstall` I say "tried" since it is hard for users to find out the exact version of their currently installed TemplateVM package and then to also find out the latest TemplateVM package version, and to compare them. ### General notes: When users say "I want to reinstall my TemplateVM" what most normal users probably actually want is "fix my TemplateVM". Only a very small and very technical amount of users will insist on "I want to reinstall the exact same version which is currently installed". I think this is a source of confusion. When layman users run `--action=reinstall` regular users would expect the latest and greatest recommended (stable) TemplateVM. (Point release in technical terms.) Keeping the original meaning of `--action=upgrade` and `--action=reinstall` is probably ok. ### Related issues: https://github.com/QubesOS/qubes-issues/issues/4517

This time, no. I planned to wait until Debian 11 is released to avoid issues such as last time: apt-get error - E: Repository 'tor+https://cdn-aws.deb.debian.org/debian-security buster/updates InRelease' changed its 'Suite' value from 'testing' to 'stable'

Patrick · August 2, 2021, 12:00pm

Repository

deb tor+https://deb.debian.org/debian-security bullseye/updates main contrib non-free

does not exist yet.

Err:5 tor+https://deb.debian.org/debian-security bullseye/updates Release
404 Not Found [IP: 127.0.0.1 9050]
Reading package lists… Done
E: The repository ‘tor+https://deb.debian.org/debian-security bullseye/updates Release’ does not have a Release file.
N: Updating from such a repository can’t be done securely, and is therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user configuration details.

tempest · August 2, 2021, 12:00pm

@patrick replace “bullseye/updates” with “bullseye-security”. the debian team changed the name.

https://www.debian.org/releases/bullseye/amd64/release-notes/ch-information.en.html#security-archive

Patrick · September 10, 2021, 5:31pm

Release upgrades support:

Whonix 16 KVM status:

Whonix 15 KVM to Whonix 16 KVM release upgrades will likely be unsupported as per KVM maintainer decision. Similar to KVM Upgrade Instructions.
Wait for Whonix KVM release based on version 16.0.2.7.

Downloadable Whonix 16 for VirtualBox images:

Whonix 16 has been Released! (Debian 11 bullseye based) - for VirtualBox - Major Release

Downloadable Qubes-Whonix 16 images status:

torjunkie · August 14, 2021, 10:11pm

Also interesting:

Linux user namespaces - Chapter 5. Issues to be aware of for bullseye

Linux unprivileged bpf - Chapter 5. Issues to be aware of for bullseye

Patrick · August 23, 2021, 6:12pm

Above post updated.

Discussion:

And locales-all package not installed by default in all Debian templates · Issue #4889 · QubesOS/qubes-issues · GitHub (maybe should be re-titled) - fixed (workaround) already in Whonix repository.

not · August 24, 2021, 5:37pm

I successfully installed the kicksecure-cli on debian 11 from the bullseye-repo together with sdwdate, bootclockrandomization, security-misc etc.
However when I try to install kloak or tirdad, I get:

Note, selecting 'dummy-dependency' instead of 'kloak'
Note, selecting 'dummy-dependency' instead of 'tirdad'
The following NEW packages will be installed:
  dummy-dependency
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 54.2 kB of archives.
After this operation, 61.4 kB of additional disk space will be used.

I’m not in a hurry, so if these are not ready to be rolled out yet, I have every bit of patience, though when you said all packages are ported to Debian 11 and uploaded to the whonix-repo, it could also mean that there is some issue.

Patrick · August 25, 2021, 9:10am

Which hardware architecture? In other words, what’s the output of:

dpkg --print-architecture

?

Expected:

amd64

(means Intel64 and AMD64)

Otherwise, see:

not · August 25, 2021, 10:03am

dpkg --print-architecture

amd64

and

cat /etc/apt/sources.list.d/derivative.list

deb tor+https://deb.whonix.org bullseye main contrib non-free

Patrick · August 28, 2021, 6:07pm

Fixed.

not · August 29, 2021, 3:08pm

Thank you for fixing it.

Patrick · August 30, 2021, 7:36pm

build process issue:

Patrick · September 8, 2021, 9:18pm