But Whonix 17 isn’t available on Qubes 4.1, so how can a user on Qubes 4.1 upgrade to Whonix 17 before upgrading to Qubes 4.2? @adrelanos?
If I`m not mistaken - after looking at the issues on github - 4.2 rc2 will not boot with Seabios (without CSM/Legacy boot). Not sure if installing 4.1.2 and upgrading would work as a workaround.
I am not aware of this. That might be a Qubes bug if Qubes-Whonix has this amount of undue power which it shouldn’t have in the threat model. If so, a bug would need to reported to Qubes upstream on Issues · QubesOS/qubes-issues · GitHub.
I tend to think this is most likely user error and not a Qubes bug.
Are templates build for Qubes R4.1 compatible with Qubes R4.2? @marmarek
- If yes, and I presume so, I don’t see how that could cause any issues.
- If no, then after upgrading Qubes R4.1 to Qubes R4.2, users who wish to upgrade dom0 or Templates over Whonix would have a problem.
Probably not needed as per above.
- Release Upgrade Whonix ™ 16 to Whonix ™ 17
- apply the same procedure that one would use to upgrade a Debian 12 (bookworm) Template from Qubes 4.1 to 4.2 to the Qubes-Whonix Templates
Might have a pretty good chance.
When attempting the in-place-update, I was blocked on Stage 2.
I got a
qubes.ReceiveUpdates error with
returned non-zero exit status 1
which result to the
No security or unstable repo enabled.
dom0 qubes.ReceiveUpdates+-sys-firewall-dvm: Error canonicalizing file: No key available! dom0 qubes.ReceiveUpdates+-sys-firewall-dvm: Error canonicalizing /var/tmp/qubes-updates-tmp2ejy9fkh.UNTRUSTED/qubes-release-4.2-0.3.fc32.noarch.rpm
I had to manually add the 4.2 key (in
sudo rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-qubes-4.2-primary
and then, I was able to perform Stage 2 update.
No (blocking) errors from all other stages.
I’m trying to update in-place my desktop to 4.2 but I got this problem…
Before dom0 install new packages, it asks to shutdown all VMs, if you say No it aborts, if you say yes it continues but stop sys-usb, and you are left with a system on which you can’t do anything except using the power button…
Would it be ok to keep sys-usb running during the update using
--keep? Could it be the default? (or at least add a warning), a step before it was asking to shutdown VMs but not the system VMs. The last message wasn’t clear enough IMO
Perhaps your sys-usb qube name is not ‘sys-usb’ ? If so, it should be run with
See help for details:
Ok, after the pre-boot upgrade, after I restarted, I got a prompt fur the LUKS passphrase, and then I’m stuck indefinitely on the plymouth screen.
Not sure how to debug that, I removed the plymouth from the command line, I see a lot of stuff displayed on the tty but nothing significant. I saw a message about lightdm starting correctly, but that’s all.
I bricked my Qubes OS and I have no idea how to fix it now I did the dom0 snapshot, but I can’t access a Qubes OS root console to recover.
qubes-tunnel is not available yet for r4.2.0-rc2 - not a huge surprise I guess. Look forward to its inclusion later.
I guess this is a good reminder to turn autostart on sys-usb OFF before doing anything like this. That way your system may freeze up but at least on reboot sys-usb won’t start.
Just a quick question for those who are testing Q4.2:
Since dom0 got upgraded to Fedora 37 and uses Xfce, can you confirm that it’s Xfce 4.16 and that in the PowerManager there is some kind of option for night mode (blue light filter) based on color profiles?
If not, then I guess I’ll have to use redshift…
xfce is 4.16, so far i have not discovered a dedicated night mode, still using good old Blue Light Filter in XFCE (Redshift)
Qube Manager Dark Mode (built-in method) and so on.
Thank you. According to Xfce release manager Simon Steinbeiss on his blog this was part of the development goals:
It should be either in Power Manager or “settings daemon”, unless they ended up dropping that feature after all.