ruza on Nostr: Over the weekend I have upgraded Qubes OS 4.1 to 4.2. Here are a gew little notes: - ...
Over the weekend I have upgraded Qubes OS 4.1 to 4.2.
Here are a gew little notes:
- be sure to have backups. I made a clone of the SATA SSD and did upgrade on the new disk. I had to restore a few volumes from backup, but I don't attribute it to a problem with the upgrade, but more likely with reading the original disk.
- be sure to have backups on more time. Seriously, try to restore at least on volume from your backup using "Qubes backup restore" utility before performing an upgrade.
- be sure all templates have latest updates applied and update procedure working without errors or warnings. Upgrade process would stop on such errors. You can instruct the upgrade script to ignore these errors using "qubes-dist-upgrade -j -k", but it means manual work to fix templates after the upgrade.
- in case of doing manual fix of the templates after the upgrade make sure repos are properly configured. That means:
Fedora:
- sed -i 's/r4.1/r4.2/g' /etc/yum.repos.d/qubes-r4.repo
- sed -i 's/4-primary/4.2-primary/g' /etc/yum.repos.d/qubes-r4.repo
Debian:
- add signed-by=/usr/share/keyrings/qubes-archive-keyring-4.2.gpg to /etc/apt/sources.list.d/qubes-r4.list
Ubuntu Jammy: do not mix template with qubes agent additions 4.2 for debian. it would not work anyways. Better wait for the next possible LTS after the end of April/2024.
Having a discrepancy between Qubes agent and other Qubes internal components may result in a situation a ProxyVM change will not be functional on a particular AppVM and Qubes Manager would crash on such event.
- qrexec-legacy-convert is meant to convert old style Qubes RPC policy to new format. It didnt worked for me with error message "default_target is None or default_target in targets_for_ask". You can perform an upgrade anyways and do conversion later.
There are still a few things I'll have to fix, that are not critical this time.
- audio using Pipewire is not working for all AppVMs. Have to study and do proper setup later
- there should be possibility to do firmware updates in Q4.2 using LVFS. I'm still a bit confused whether to use fwupdmgr or qubes-fwupdmgr. I haven't investigated the topic too much yet.
- there is some new implementation on GPG spilt. Luckily It didnt broke my existing setup that is working fine even after upgrade.
So far I haven't found any other problems and so I cautiously declare the upgrade to Q4.2 a success.
Here are a gew little notes:
- be sure to have backups. I made a clone of the SATA SSD and did upgrade on the new disk. I had to restore a few volumes from backup, but I don't attribute it to a problem with the upgrade, but more likely with reading the original disk.
- be sure to have backups on more time. Seriously, try to restore at least on volume from your backup using "Qubes backup restore" utility before performing an upgrade.
- be sure all templates have latest updates applied and update procedure working without errors or warnings. Upgrade process would stop on such errors. You can instruct the upgrade script to ignore these errors using "qubes-dist-upgrade -j -k", but it means manual work to fix templates after the upgrade.
- in case of doing manual fix of the templates after the upgrade make sure repos are properly configured. That means:
Fedora:
- sed -i 's/r4.1/r4.2/g' /etc/yum.repos.d/qubes-r4.repo
- sed -i 's/4-primary/4.2-primary/g' /etc/yum.repos.d/qubes-r4.repo
Debian:
- add signed-by=/usr/share/keyrings/qubes-archive-keyring-4.2.gpg to /etc/apt/sources.list.d/qubes-r4.list
Ubuntu Jammy: do not mix template with qubes agent additions 4.2 for debian. it would not work anyways. Better wait for the next possible LTS after the end of April/2024.
Having a discrepancy between Qubes agent and other Qubes internal components may result in a situation a ProxyVM change will not be functional on a particular AppVM and Qubes Manager would crash on such event.
- qrexec-legacy-convert is meant to convert old style Qubes RPC policy to new format. It didnt worked for me with error message "default_target is None or default_target in targets_for_ask". You can perform an upgrade anyways and do conversion later.
There are still a few things I'll have to fix, that are not critical this time.
- audio using Pipewire is not working for all AppVMs. Have to study and do proper setup later
- there should be possibility to do firmware updates in Q4.2 using LVFS. I'm still a bit confused whether to use fwupdmgr or qubes-fwupdmgr. I haven't investigated the topic too much yet.
- there is some new implementation on GPG spilt. Luckily It didnt broke my existing setup that is working fine even after upgrade.
So far I haven't found any other problems and so I cautiously declare the upgrade to Q4.2 a success.