Now I know what I’m doing for the holidays!!!
3 Likes
Want to add to the pile: update in place did not work, required a clean install.
On clean install, disposable sys-net does not have NetworkManager, so cannot connect to internet.
I would recommend people to wait to upgrade.
1 Like
@cubit you see the post install menue on first boot? Might be running in to the same issue I did (not getting a full install). For my personal situation the upgraded is definitely worth it from performance to many other creature comforts.
4.3: No templates installed; “Templates Configuration” screen never appeared
Could you also share how you did the upgrade and what errors you saw in the following discussion.
1 Like
I performed the upgrade from R4.2.4, and it was successful, but only if I excluded the rather exotic templates and standalones, such as Windows, during the steps to upgrade templates. If they were not excluded, the upgrade tried to upgrade them, too, which finally resulted in a broken system. Restricting the upgrade to only Debian and Fedora VMs corrected this problem and allowed the upgrade to run to a successful completion.
8 Likes
Thanks. Though I meant there are any specific features/upgrades that don’t get applied on upgrade. I though this was the case with a grub or luks related change in an earlier release, though I can’t find exactly what it was.
1 Like
How to exclude Windows templates/standalones?
I used sudo qubes-dist-upgrade --releasever=4.3 --all-pre-reboot and it already aborted at Stage 1 because it cannot update the Windows VM’s during template updates.
1 Like
Maybe part of the process should be Qubes looking for Qubes-installed templates and their derivatives only. It’s far from impossible to do, since IIRC it’s already tracked in qvm-features $qube.
3 Likes
Does this mean one should upgrade any Whonix-based VMs first, in particular Standalone VMs?
This isn’t addressed here: How to upgrade to Qubes 4.3 — Qubes OS Documentation
But I would hate to upgrade to 4.3 and end up with Whonix VMs that can’t boot or something. And have to revert to 4.2 to fix them.
1 Like
Upgrading without the Windows etc. templates was rather tedious. As far as I remember, I had to perform the upgrade stages 1 to 3 using --skip-template-upgrade and --skip-standalone-upgrade (not sure if this was necessary), and select the qubes to be upgraded explicitly in stage 4, using --only-update to select only the supported VMs.
Upgrading from R4.3 to some future version should be easier, because now, you can deselect the VMs that should not be upgraded via qvm-features --skip-update.
3 Likes
Like @GWeck, I had a similar issue. My Whonix gateway and workstation templates had been having update issues in the last few weeks. So, when I started the 4.3 update from 4.2 (in-place), I knew I might need to troubleshoot. I didn’t use the --skip-template-upgrade flag (an oversight on my part). The initial attempt using --all-pre-reboot (stage 1-3) failed. Then, I did them by individual stage 1-3. After that, I did --all-post-reboot (stages 4-6) together. In my case, when those two templates failed in stage 1, I got an error message asking me if I wanted to proceed. I said “yes” for each of them, and stage 1 completed. I had no other errors in the remaining stages. After I finished the upgrade to 4.3, I simply installed (and updated) the new whonix-18 templates, switched the 3-4 VMs that used version-17 to use the newer templates, and deleted the old/no longer supported ones. Everything is working fine.
Separately, a big thank you to the Qubes development team and Community testers!!! Every release gets better and better. Happy New Year!
5 Likes
Thanks! Love the changes!
I did an in-place update, found twice that the pgp key for fedora primary on both devices were missing when doing in-place(easy fix tho). Also found that the drop down app menu occasionally opens on the right side of the screen and whonix never upgraded to 18. Attempted upgrade Release Upgrade Whonix 17 to Whonix 18 no luck. Do not see whonix 18 in template manager. Cmd skips the whonix templates and can confirm checking version file that they are v17
Update: refreshed template manager with additional repo activated via gobal configs and attempted How-to: Install Qubes-Whonix doesnt work & repo still not present.
Edit: After manual config, got the repo present.
1 Like
is it possible to run debian 11 restored from 4.2.4
1 Like
Debian TemplateVMs and StandaloneVMs with version lower than 12 are not supported
2 Likes
What is the download size of Qubes 4.3? I get one more that 7.6GB is that correct, the other releases like Q-R-4.2.3 are around 4.4 GB
1 Like
It is 8176568320 bytes. Or 7.6GiB as you mentioned.
For the record, r4.2.3 was 6910355456 bytes or 6.4GiB.
Link to individual ISOs: Index of /iso/
4 Likes
Had some problems most likely related the firmware version of my Nitropad. However, the in-place installation method succeeded with only minor issues. I can report that for the last few days Q4.3 runs stable and as performant as Q4.2 on my laptop.
1 Like
not sure if it is affecting ‘everyone’, but worth checking:
2 Likes
Thanks @Zrubi , I can confirm that the bug is present on a Lenovo T480 (fresh/clean 4.3.0 install). Also, the workaround presented works too.
2 Likes
now for 4.3
if you REALLY want me to backport bugfixes to 4.2 just let me know, but I’d prefer to skip 
3 Likes
The snippet about upgrading templates that are restored from a previous version needs a slight edit.
sudo qubes-dom0-update -y qubes-dist-upgrade
qubes-dist-upgrade --releasever=4.3 --template-standalone-upgrade -y
… should be
sudo qubes-dom0-update -y qubes-dist-upgrade
sudo qubes-dist-upgrade --releasever=4.3 --template-standalone-upgrade -y
You also may want to put a call out that any running templates that need to be upgraded will be shutdown during this process. 
2 Likes