[HOME] [DOWNLOAD] [DOCS] [NEWS] [SUPPORT] [TIPS] [ISSUES] [Priority Support]

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


#1

Whonix 14 release blockers - status of Whonix 14 development
Qubes-Whonix 14.0.0.6.9 TemplateVMs for R3.2 and R4--Testers Wanted!
Qubes-Whonix 14 SaltStack state files - Testers Wanted!
#2

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?


#3

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


#4

Fixed by running sudo qubes-dom0-update


#5

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.


#6

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, https://www.whonix.org/wiki/Qubes/Update, I think it’s fair. :slight_smile:


#7

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.


#8

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 https://github.com/QubesOS/qubes-issues/issues/3554:

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.

#9

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.


#10

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, https://www.whonix.org/wiki/Qubes/Update, 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:


#11

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 https://github.com/QubesOS/qubes-issues/issues/3554

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: https://www.whonix.org/wiki/Tor#Entry_Guards


#12

I tried to follow the steps at https://www.whonix.org/wiki/Qubes/Install/Testing

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


#13

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)


#14

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.


#15

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.


#16

mig5:

It looks as though the package name is actually

qubes-mgmt-salt-dom0-virtual-machines

Fixed.


#17

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:
https://www.whonix.org/wiki/Qubes/Install/Testing#Remove_Old_Versions

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


#18

Sure thing, done:


#19

#20