Hi,
as the title says, my upgrade does not even start after
sudo qubes-dist-upgrade --all-pre-reboot -y
I get the above message. Manually shutdown of sys-firewall (only possible after manually shutdown of sys-whonix) will not help, because once I run the command, both start up again and the error is the same.
Can’t believe its only me, because I use a pretty normal setup. Please help.
Thanks
Mol
Me three.
If I remember correctly stage 1 is updating dom0 and all templates and HVMs. For this you probably want sys-firewall to download those updates.
sudo qubes-dist-upgrade --help
shows you how you can exclude sys-firewall from shutting down, if I understand that error correctly.
Ran into the same problem. Manually shutting down sys-whonix and sys-firewall prior to running the command made no difference, as the sys-firewall VM appears to re-launch the instant the qubes-dist-upgrade command is executed.
I’m re-running with this command to see if it resolves
sudo qubes-dist-upgrade --all-pre-reboot -y --keep-running sys-firewall
Adding the --keep-running sys-firewall option allowed the command to complete executing, but ultimately the upgrade process failed after running both pre and post stages and performing the required reboots.
I rebooted and started again doing one stage at a time. On stage 1, I’m getting errors on a few VMs still, one Win7, one OpenBSD and the other a Debian StandAloneVM with some PGP key errors where it’s incorrectly sending qubes-os as the apt pkg distro vernsion instead of a debian one. Going to nuke the problem VMs and at least see if I can get through stage 1 without errors.
If it hasn’t been already, I think it is worth reporting this issue on GitHub (GitHub - QubesOS/qubes-issues: The Qubes OS Project issue tracker).
Update: I powered through the update process one stage at a time, and finally got through it. So it is possible, but might not work if you batch everything into the pre-reboot and post-reboot command options. Be prepared to re-download what seem to be the same redhat packages at each of the earlier stages in the process. It might be better to just backup your VMs and do a clean install, but I at least wanted to prove to myself that the upgrade process was viable.
That actually worked for me through all stages.
For me, the first y/N prompt will start sys-whonix. After the first prompt, then shutdown sys-whonix and then yes at the second prompt. If you’ve just shutdown sys-whonix, it should work. Worked for me multiple times.
In stage 3, I did run into an issue where “Shutdown all unnecessary VMs” would also shutdown the sys-usb, which causes the loss of kb/mouse, and the inability to respond to subsequent prompts.
For me, I looked through the grub config and saw no reference to blocking dom0 So I simply removed sys-usb.
This threat has a lot of good info.
Once your upgrade was completed, did get the following warning in the Qubes menu?
“Some qubes are no longer supported!
The following qubes are based on distributions that are no longer supported:
fedora-36
Install new templates with the Template Manager”
No. I prefer to maintain the latest supported OSes if possible.
The hardest thing is to in-place upgrade a stand alone, but I’ve done it many times and the instructions are foolproof. It’s also healthy to start over now and then, and installing a new template is pretty easy. Usually the most work comes from re-configuring the new template, removing the installed apps and services that aren’t needed and installing/configuring the ones that are.