Qubes-Whonix 14.0.0.7.9 TemplateVMs for R3.2 and R4 -- Testers Wanted!

Step 2.1:

sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing qubes-core-admin-addon-whonix

Complains that there is no match. Is this Qubes 4.0 only?

1 Like

I ignored the problem in Step 2.1 and went on:

Step 2.2

sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing qubes-release

Says Skip one package as it is already installed. However, there is no [qubes-templates-itl-testing] section, and no /etc/yum.repos.d/qubes-templates.repo.rpmnew.


Note: I was testing on Qubes 3.2

1 Like

Fixed by running sudo qubes-dom0-update

1 Like

Step 4:

sudo qubesctl state.sls qvm.anon-whonix

I executed it once without deleting the existing sys-whonix, and the existing sys-whonix remained unchanged. Then I deleted sys-whonix and executed the command again. I got a brand new sys-whonix.

1 Like

Note: I need to manually configure the templates whonix-gw-14 and whonix-ws-14 to use sys-whonix as NetVM. Since it’s been documented, Update Qubes-Whonix ™, I think it’s fair. :slight_smile:

1 Like

iry:

Step 2.1:

sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing qubes-core-admin-addon-whonix

Complains that there is no match. Is this Qubes 4.0 only?

Yes. Documentation updated.

1 Like

I didn’t set sys-whonix as my UpdateVM/ClockVM/netVM, however, sys-whonix is auto-started at every boot of Qubes now.

Is this the expected default behavior? People argues that Issues · QubesOS/qubes-issues · GitHub

This can weaken the anonymity, if one connects automatically to different Networks with the same sys-whonix VM because of the same entry guards.

To disable the auto-start:

  1. In Qubes Manager, open the VM settings for sys-net.
  2. Deselect “Start VM automatically on boot”.
  3. Click “OK”.
  4. Reboot the whole system.
1 Like

iry:

I ignored the problem in Step 2.1 and went on:

Step 2.2

sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing qubes-release

Says Skip one package as it is already installed. However, there is no [qubes-templates-itl-testing] section, and no /etc/yum.repos.d/qubes-templates.repo.rpmnew.


Note: I was testing on Qubes 3.2

[quote=“iry, post:3, topic:5529”]
Says Skip one package as it is already installed. However, there is
no [qubes-templates-itl-testing] section, and no
/etc/yum.repos.d/qubes-templates.repo.rpmnew .
[/quote]

Fixed by running sudo qubes-dom0-update

Alright, can’t explain this but I added to the very top:

Update Qubes dom0. sudo qubes-dom0-update

Can’t be wrong to update Qubes before anything else.

1 Like

iry:

Note: I need to manually configure the templates whonix-gw-14 and whonix-ws-14 to use sys-whonix as NetVM. Since it’s been documented, Update Qubes-Whonix, I think it’s fair. :slight_smile:

Yes. Anyhow I guess it will generate a ton of confusion. Usability issue
on Qubes R3.2. The proper way to fix this would be the following but not
sure if realistic to happen:

1 Like

iry:

I didn’t set sys-whonix as my UpdateVM/ClockVM/netVM, however, sys-whonix is auto-started at every boot of Qubes now.

Is this the expected default behavior?

Expected.

People argues that Cannot deactivate automatically start default netvm on boot. · Issue #3554 · QubesOS/qubes-issues · GitHub

This can weaken the anonymity, if one connects automatically to different Networks with the same sys-whonix VM because of the same entry guards.

Reference: Tor Documentation for Whonix Users

1 Like

I tried to follow the steps at HowTo: Install the Testers-Only Version of Qubes-Whonix ™

However, in section ‘Qubes R4 Only’, this fails:

sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing mgmt-salt-dom0-virtual-machines

Error is:

No match for argument: mgmt-salt-dom0-virtual-machines
Error: Unable to find a match

The subsequent command sudo qubesctl top.enable qvm.whonix-testing pillar=true also then fails with salt.exceptions.SaltRenderError: Could not find relpath for qvm.whonix-testing.top

2 Likes

It looks as though the package name is actually

qubes-mgmt-salt-dom0-virtual-machines

I also had to add --best --allowerasing to force the upgrade to 4.0.0.13-1.fc25 from 40.0.11-1.fc25 due to apparent ‘conflicts’ (though it wasn’t clear what conflicts they were)

2 Likes

Section “Add Qubes’ Community Templates Testing Repository” :

Ensure the file contains [qubes-templates-itl-testing]

minor note, this should be “Ensure the file contains [qubes-templates-community-testing]” because the text pasted beneath it is for templates-community-testing. (or, the text pasted beneath is incorrect, and should be that of qubes-templates-itl-testing. Whichever is true).

I have both qubes-templates-itl-testing and qubes-templates-community-testing in my qubes-templates.repo.

2 Likes

mig5:

Section “Add Qubes’ Community Templates Testing Repository” :

Ensure the file contains [qubes-templates-itl-testing]

minor note, this should be “Ensure the file contains [qubes-templates-community-testing]” because the text pasted beneath it is for templates-community-testing. (or, the text pasted beneath is incorrect, and should be that of qubes-templates-itl-testing. Whichever is true).

I have both qubes-templates-itl-testing and qubes-templates-community-testing in my qubes-templates.repo.

Fixed.

2 Likes

mig5:

It looks as though the package name is actually

qubes-mgmt-salt-dom0-virtual-machines

Fixed.

iry:

Step 4:

sudo qubesctl state.sls qvm.anon-whonix

I executed it once without deleting the existing sys-whonix, and the existing sys-whonix remained unchanged. Then I deleted sys-whonix and executed the command again. I got a brand new sys-whonix.

This is addressed for now through:
How-to: Install Qubes-Whonix

But I don’t like that solution. Could you report a bug to Qubes please?

1 Like

Sure thing, done:

1 Like