I tried to do the in-place upgrade but I got stopped at stage 1. I have several non-networked standalone VMs that obviously failed to update. Some are even EOL, but they never touch a network, so I don’t really care. When it finished, it said the upgrade had failed and to not continue to the next stage. Should I ignore that error? If so, how do I continue to stage 2 if 1 won’t finish?
I see how to continue with stage 2, thanks to the docks. I’d still like to be sure I should/shouldn’t move forward. It gave no errors when updating dom0, it just said that there wasn’t anything to install.
I recently completed in inplace upgrade to Qubes 4.3. I was stopped at step 1 about 5 times. Each time I restored the backup in the logical volume Qubes42UpgradeBackup, rebooted and tried again with mitigations to try to fix the problems. The log, /var/log/qubes-dist-upgrade.log, contained instructions for recovery of errors and some indication of what qubes were causing errors. I was able to search the logs to determine which qubes were causing the errors by simply searching on the term ‘error’.
sudo lvconvert --merge qubes_dom0/Qubes42UpgradeBackup
I ran the above command and rebooted about 4 times and did not proceed until stage 1 ran with out errors. I have at last count 46 templates and most of them did not require and update because I had tried to update everything earlier.
Since I had full verified backups I removed the 2 standalone hvm and the regular template standalone (not hvm) since these seemed to cause errors with no other explanation. After that I ran with the --max-concurrency parameter with values 2 and then 1 because I continued to get errors even after removing the problematic standalones. This wasn’t suprising to me because updating often caused me to get timeout errors and I noticed that I did get a timeout error notifications even after removing the standalones once when stage 1 failed. Once I reduced the --max-concurrency to 1, stage 1 completed with no errors and the update continued automatically with stage 2 and then stage 3.
sudo qubes-dist-upgrade --releasever 4.3 --all-pre-reboot --max-concurrency 1
I don’t know if it is possible to continue manually with each stage if errors occur in a previous stage. That is why I restored and reworked the upgrade until it was working with no errors. I was sure that I could restore and build the 3 hvm/standalone ones after the upgrade was complete and all necessary qubes dom0 hooks would be defined correctly for each of the standalones. After the pre-reboot stages completed I rebooted as the instructions said and ran the post-reboot steps but I included the --max-concurrency 1 parameter.
sudo qubes-dist-upgrade --releasever 4.3 --all-post-reboot --max-concurrency 1
1 Like
I would not treat stage 1 as safe to ignore unless the log makes it clear that only disposable/non-important qubes failed and you have a rollback path. The important check is /var/log/qubes-dist-upgrade.log: look for the first real error, not only the final summary, because later failures can be just consequences. For offline standalone VMs, one safer pattern is to export/backup them, temporarily remove or exclude the broken ones, get the upgrade to finish cleanly with low concurrency, then recreate/import them after 4.3 is stable. That is slower, but it avoids carrying a half-upgraded state into stage 2.
I’d also not continue into stage 2 until stage 1 is either clean or you know exactly which VM caused the stop. The useful bit to paste is the first real error block from /var/log/qubes-dist-upgrade.log, not just the final summary. For the offline standalone VMs, I’d back them up/export them first, temporarily remove or exclude the ones that break stage 1, rerun with low concurrency, and only import/recreate them after 4.3 is stable.
I ended up disabling it for the standalones with --skip-standalone-upgrade and it went through just fine. Well, I didn’t get any errors for the rest of the process. I’ve got some weirdness going on and hopefully someone can help.
I don’t see fedora-43-xfce in the installed templates section of the new template manager. It also says the templates I do have are still on 4.2, though when I try qubes-dist-upgrade --template-standalone-upgrade, it says all those templates are already upgraded, including fedora-43.
Not sure what that’s about. Is there any other way for me to see what qubes version these templates are associated with?
Also, I can’t tell if it’s letting me upgrade the few standalones I need to upgrade now that I’m here. I ran the script and didn’t get any errors, but only saw a script done at the end, with no progress bar or anything.
A separate but related problem is with the screensaver. I can log into the boot screen and the change user screen without issue. But when I try to log into the screensaver, it doesn’t read my yubikey for the 2fa.
I’d appreciate any advice you’ve got on either issue.
I’m glad that --skip-standalone-upgrade worked for you. It would be helpful to see more information. When you examined the /var/log/qubes-dist-upgrade.log did you see evidence that all 6 stages were executed and each template was handled appropriately. Search “STAGE” to move to each section.
Have you rebooted and updated everything after completing the scripts for the in-place upgrade?
Did you refresh the repos in the template manager gui?
Does Qube Manager → About and → Version Information show 4.3 version?
Does Qubes OS Global Config → This Device > Qubes OS version indicate 4.3?
Is fedora-43-xfce installed as well as fedora-43? What is the output of
qvm-ls --class TemplateVM | grep fedora
What does does qvm-template list produce?
qvm-template list
I’ve checked for updates and restarted the system since I did the upgrade. I’ve refreshed template manager several times with no changes.
As far as I can see in the log, everything got updated. I’m not seeing any errors and all 6 went through without any visible problems once I had stage 1 ignore the standalones.
When I ran stage 4 again to try to update the standalones, it skipped all my templates saying they’d already been upgraded to 4.3. However, qvm-template list shows the same thing as the template manager. It says debian-13-xfce is still on 4.2 and doesn’t think I have fedora-43-xfce installed.
Obviously neither the manager or qvm-template shows me the standalones or other templates that I’ve customized and renamed either.
Template manager and my navigation gui both show that I have fedora-43-xfce and I’ve already started several qubes that use that template with no problems that I can tell. Aside from 2fa not working in the screen saver, my net and usb qubes seem to be working, both based off a disposable that uses that template.
output for qvm-ls --class TemplateVM | grep fedora is
fedora-43-xfce Halted TemplateVM black - -
Qubes global config says I’m on qubes R4.3.1
Edit: I managed to get the screensaver login working. Apparently they changed screensavers from xscreensaver to xfce, so the add yubikey line wasn’t in there. I added it and that part is working now. Very strange that I can do that successfully with a vm that uses a template the template manager doesn’t think exists.
You should be able to fix the problems with fedora-43-xfce and debian-13-xfce by simply removing them and installing them from template manager. Since this is a normal procedure everything about those templates and their installation should be reset to standard for 4.3.
qvm-clone fedora-43-xfce temp-fed-43-xfce
qvm-clone debian-13-xfce temp-deb-13-xfce
qvm-prefs appvm-for-fedora-43-xfce template temp-fed-43-xfce
qvm-prefs appvm-for-debian-13-xfce template temp-deb-13-xfce
qvm-remove fedora-43-xfce debian-13-xfce
qvm-template install fedora-43-xfce debian-13-xfce
qvm-prefs appvm-for-fedora-43-xfce template fedora-43-xfce
qvm-prefs appvm-for-debian-13-xfce template debian-13-xfce
You will have to decide what to do with all the appVMs or dispVM templates which are currently using those templates. You must temporarily reassign them to another compatible template or a copy of the templates before you delete the templates as shown above.
All these instructions can also be performed with a gui through qubes-manager and template-manager.