Rico
April 30, 2024, 4:05am
1
Hi there,
I recently updated my QubesOS from 4.1 to 4.2. I then upgraded from Whonix 16 to 17. I think it worked once when the Connection Wizard started automatically. After that, no such luck. When I run the System, it says my eth0 interface isn’t up and that I should restart the networking service. I did that, but it didn’t work. I’ve tried a few guides on the forums but nothing has worked.
Any guidance please?
Post exact error message.
Rico
May 1, 2024, 2:58am
3
The GUI interface says:
ERROR: check network interfaces Result: network interface eth0 not up!
Recommendation:
Try to manually start Whonix networking.
sudo systemctl restart networking
Or reboot.
Debugging information:
Command
sudo --non-interactive cat /sys/class/net/eth0/carrier
failed.
If this error happens only during upgrading or is transient this error can be safely ignored.
If you know what you are doing. feel free to disable this check. Create a file /etc/systemcheck.d/50_user.conf and add:
systemcheck_skip_functions+=" check_network_interfaces "
Rico
May 2, 2024, 3:16am
4
Just to add, rebooting and restarting the service didn’t fix the problem. I am also unable to view the content of the carrier file. It says cat: carrier: Invalid argument
Probably some dom0 settings are messed up.
Qubes salt (qubesctl
) might be able to fix this. Documented here:
Download and Configure Whonix Templates
Otherwise I recommend to uninstall.
And install.
Anon Connection Wizard (ACW) is unrelated. It is listed as Unsuitable Connectivity Troubleshooting Tools .
Rico
May 3, 2024, 11:37am
6
I tried the uninstall re-install process two times and the problem remains the same.
Any error during Qubes salt?
Any custom VMs other than sys-whonix and anon-whonix?
At least sys-whonix and anon-whonix should be functional?
Rico
May 3, 2024, 11:53am
8
When you say Qubes salt, you mean this command?
sudo qubesctl state.sls qvm.anon-whonix
If yes, no errors presented in the entire uninstall and reinstall processes.
No custom VMs using Whonix.
sys-whonix still presents the same errors.
So we need to compare the dom0 settings of sys-whonix in Qubes installation with release upgrade bug versus a Qubes installation without release upgrade bug.
In dom0:
qvm-prefs sys-whonix
In my opinion, release upgrade isn’t worth the trouble anyhow.
What is better? Upgrade or Image Re-Installation? See Update vs Image Re-Installation .
So a clean re-installation might be easier than debugging this to avoid running into lots of corner cases which only very few users are experiencing.
related Qubes upstream issue:
opened 09:41AM - 08 Oct 21 UTC
T: enhancement
ux
C: Whonix
P: default
***Usability Issue***
The more lengthy the instructions, the more commands us… ers needs to manually type into a terminal emulator, the more can go wrong usability wise.
For example in [Qubes-Whonix installation instructions](https://www.whonix.org/wiki/Qubes/Install), users need to be told:
> Upgrade Qubes dom0.
> sudo qubes-dom0-update
This is required to make sure
- version file
`/srv/formulas/base/virtual-machines-formula/qvm/whonix.jinja`
contains the current version number of is up to date,
- a recent version of Qubes repository definition files,
- Qubes salt,
- [qubes-core-admin-addon-whonix][],
- as well as [qubes-mgmt-salt-dom0-virtual-machines][] are installed
and up to date.
[qubes-core-admin-addon-whonix]: https://github.com/QubesOS/qubes-core-admin-addon-whonix
[qubes-mgmt-salt-dom0-virtual-machines]: https://github.com/QubesOS/qubes-mgmt-salt-dom0-virtual-machines
Many users skipped that step. That might be because Qubes dom0 updates have a chance, in past broke connectivity or Qubes dom0 boot.
Then documentation was updated to say:
> Upgrade Qubes dom0. This step is mandatory.
That helped but still some users skipping that step. Therefore it was required to make sure the user really did update Qubes dom0. More documentation was added:
>Verify `whonix_version` is `16`.
>
>If the previous `sudo qubes-dom0-update` was completed, it should not be necessary to verify the version number. However, this is mentioned because many users fail to update `dom0` packages beforehand.
>
>In `dom0`. View contents of file `/srv/formulas/base/virtual-machines-formula/qvm/whonix.jinja`.
>
> sudo cat /srv/formulas/base/virtual-machines-formula/qvm/whonix.jinja
>
>Example output:
>
> 16
>
>If it shows something else, then Qubes `dom0` is outdated. In that case, it is not possible to continue.
At this point, usability of these instructions is already really bad.
Next step in documentation is telling users:
> Download both Whonix-Gateway ™ and Whonix-Workstation ™ Templates.
> In dom0, run.
sudo qubes-dom0-update --enablerepo=qubes-templates-community qubes-template-whonix-gw-16 qubes-template-whonix-ws-16
That is a lengthy command to type. Users by Qubes default cannot copy from a VM to dom0 for security reasons. But then typing such a command for users who are not using a (kinda) 10 finger typing system is a challenge. One typo, and it won't work.
That command could be replaced by a shorter command `sudo qubesctl state.sls qvm.anon-whonix` but then that can take ages (especially when downloaded over Tor) so users reported this to be confusing as it's not known by the user if the download is still taking a long time or the entire process hanging forever. #4215
Also the parameter `--enablerepo=qubes-templates-community` [was reported to be needed quite some times](https://forums.whonix.org/t/had-to-enable-community-templates-to-get-new-template/12489) in Qubes-Whonix and Qubes forums.
After that users are told:
> Configure sys-whonix and anon-whonix safely.
> In dom0, run.
sudo qubesctl state.sls qvm.anon-whonix
Yet another command. Rationale for that is explained in #3447.
On top of that: #6904
It's a lot rough edges that really add up to bad usability.
***Technical Issue***
The template upgrade is currently scattered into many different pieces. At least:
* Qubes-Whonix template,
* [qubes-core-admin-addon-whonix](https://github.com/QubesOS/qubes-core-admin-addon-whonix),
* [qubes-mgmt-salt-dom0-virtual-machines](https://github.com/QubesOS/qubes-mgmt-salt-dom0-virtual-machines)
I.e. the template + meta scripts.
***Suggested Solution***
A Qubes template should be self-contained with everything (template + meta scripts).
For example, Whonix for VirtualBox doesn't have this issue because VirtualBox `.ova` files are self-contained. These contain both, the virtual machine image file as well as the metadata (virtual machine configuration).
If we had that + #4215 + #6904 then perhaps command line installation instructions could be really shrunk to `sudo qubesctl state.sls qvm.anon-whonix`.