I finally migrated the HP Elitebook 820 G1 laptop to Qubes OS R4.3-alpha (Development branch). It did not take that much time. The backup took much more time indeed.
Procedure
I made two backups. One regular full backup with Qubes Backup tool and another with BTRFS send/receive for relevant subvolumes snapshots (since I use OpenSUSE style BTRFS filesystem & subvolumes) and rsync for /boot.
Then I followed the qubes-dist-upgrade as a blueprint. It consists of two main bash scripts. One for dom0 upgrade tasks which then sends another bash payload to each TemplateVM for their upgrade.
Compared to R4.1 → R4.2, the new R4.3 upgrade should be easier and painless. Because of few reasons. 1st of all, unlike R4.2, Fedora version for dom0 has not changed yet (but upgrade to Fedora 41/42 is on the TODO list according to the post below). 2nd of all, policy format conversion is not needed. But you should have upgraded the templates to a reasonable release.
I did not use the upgrade scripts directly and did all of the changes manually (mostly to repositories). There were few cases that I needed to copy and import signing keys.
The bash payload for TemplateVMs could not upgrade Archlinux and Gentoo templates. But the users of those Distros do not need it
Screenshots
Do not pay attention to MemTest86+. I had installed it manually. But you can see the Qubes version in GRUB menu.
The 1st evident change. The new Qubes Devices systray widget using The New Devices API. Finally the ugly () at the end of block devices is gone. And we have 'sub-device of ...' for block devices.
No. definitely not. That is one of the rss-glx screensavers ported to Linux (from Fedora 37 main repositories).
Nothing major so far. The patch for xscreensaver requires update for 4.3 branch to show the correct label. But it is minor. I saw some errors with The New Devices API front-ends (qvm-block, qvm-device, qvm-usb). Nothing major. This machine will stay on 4.3 and I should see what bugs I might encounter.
There is room for work. One of them would be updating the qubes-dist-upgrade repository for the 4.2 to 4.3 upgrade (Github Issue #9317). But I guess that we would better leave this to Marek and fepitre as it demands access to multiple machines and proper testing environment. We should only observe and suggest changes if they make sense. There are very minor ones that I did not bother wasting their precious time. e.g. this one:
echo "ERROR: UpdateVM ($updatevm) should on a template that have 'dnf' installed - at least Fedora 37, Debian 11, or Whonix 16."
should be ...should be a template that ...
One major contribution could be this one:
It should be possible to extend the qubes-dist-upgrade.sh bash script to check for existence of unsupported pre-EOL templates. e.g. it could check if the template os-distribution is fedora and then of the os-version feature is below 40. Then it should show a warning to user and prevent user from preoceeding forward (unless they run it again with something like --skip-unsupported). It will be trickier for Debian & Whonix but still doable.
I don’t really understand what kind of preview you were expecting but dom0 has not changed yet simply because R4.3 does not really exist and it’s just a switch between stable branches and main branches. So the upgrade is something very close to R4.2. Very few new features exist already but basically on the TODO list there is dom0 upgrade to probably Fedora 41/42.
This is something I do not know. I am a regular user like most of other forum members and not a member of the core team. I mostly monitor the PRs to Qubes OS repositories and the related comments. When I see something exciting, I reflect it in the weekly newsletters.
From what I see in the commit messages and related discussions, improvements of the Devices API and related changes to front-end tools and widgets will come only to R4.3
The 4.18 features for x86 aren‘t that boring either:
x86: On all Intel systems, MSR_ARCH_CAPS is now visible in guests, and controllable from the VM’s config file. For CPUs from ~2019 onwards, this allows guest kernels to see details about hardware fixes for speculative mitigations.
x86: Support for features new in AMD Genoa CPUs:
x86: CPUID_USER_DIS (CPUID Faulting) used by Xen to control PV guest’s view of CPUID data.
x86: Support for features new in Intel Sapphire Rapids CPUs:
PKS (Protection Key Supervisor) available to HVM/PVH guests
VM-Notify used by Xen to mitigate certain micro-architectural pipeline livelocks, instead of crashing the entire server
Bus-lock detection, used by Xen to mitigate (by rate-limiting) the systemwide impact of a guest misusing atomic instructions
x86: Support for features new in Intel Granite Rapids CPUs: AVX512-FP16
