Today I was doing a in place upgrade of Fedora from fedora 43 to fedora 44 in a standalone VM and I couldn’t get it to work at all with the “sudo dnf system-upgrade download --releasever=44 --allowerasing” command, that reboots to apply the changes, and I noticed this discrepancy where all the fedora docs said to use this command and all the qubes docs said to use “sudo dnf --releasever=44 distro-sync --best --allowerasing” as far as I’m aware the main difference between these commands is one reboots to apply the changes and one doesn’t and applies them right away, so I tested the first command and it doesn’t work as soon as it reboots it fails to start and then on the next boot boots up fine but the upgrade failed and with the second command it completes fine I tried to figure out why this was but didn’t really find anything.
Welcome to the forum 
Can you the error message you are getting?
So I had a look and there isn’t really a error message in the VM it’s self, so I start the command it downloads the packages and then I run the reboot and when it tries to boot up I get a generic cannot connect to gui-agent error and qube failed to start followed by shutdown and then when restarting the VM and checking the upgrade it says it didn’t finish and is back on fedora 43. The other method works though the other no reboot command for the fourm so It’s not like I need to solve it I’m mostly interested in why the other method is having issues and why the qubes docs recommend the no reboot option.
Did you manually modify the template? If not maybe just install the new 44 one and switch the prefs template to that one?
This topic is pretty off-topic, although it might not be since it is advised by the team how to upgrade in-place:
So, I don’t see why you would waste your time on looking for differences why some command doesn’t work, when everybody else use the other. Me too, on a regular basis.
If my memory is correct, fedora system upgrades switched to offline updates around version 41 or 42 to prevent dependency conflicts and other problems during the upgrade process.
The reason offline updates doesn’t work on a fedora-based qube is that the qrexec_timeout is set to 60 seconds and memory balancing is enabled.
Thus, adjustments are needed:
[user@dom0 ~]$ qvm-prefs VMNAME qrexec_timeout 3600
[user@dom0 ~]$ qvm-prefs VMNAME maxmem 0
[user@dom0 ~]$ qvm-prefs VMNAME memory 4000
You can monitor the upgrade process using qvm-console-dispvm
[user@dom0 ~]$ qvm-console-dispvm -- VMNAME
Personally, I use offline updates to upgrade my fedora-based template qubes.
why the qubes docs recommend the no reboot option.
This is because the documentation was written before the switch to offline updates. And since it still works as is for now, no one is fixing it.
If you’re interested in helping improve the documentation, please consider contributing:
https://www.qubes-os.org/doc/how-to-edit-the-documentation/
This looks good, I’ll give it a try in a minute.
Great, this works well
[user@dom0 ~]$ qvm-prefs VMNAME qrexec_timeout 3600
[user@dom0 ~]$ qvm-prefs VMNAME memory 4000
and it worked well and the monitoring command works well as well
qvm-console-dispvm -- VMNAME
i’d want to add something to the docs about this but I’m not sure I’m the right person for that job, I tried to look up what fedora version the offline upgrade mode became the default but I didn’t find anything, also I had to increase the time for the qrexec_timeout to stop it shutting the vm down halfway through the update, i initially only did it with the qrexec_timeout command
[user@dom0 ~]$ qvm-prefs VMNAME qrexec_timeout 3600
but that causes some issues where it doesn’t load enough ram and it hangs after upgrading and removing the packages.
What makes you think that? There is no “right person” for that “job”
The docs are a community effort, so the maintainers are here to carefully review anyone’s contributions. If you have trouble with basic things about contributing, I can help with building, formatting, etc. Just by trying to contribute, you will learn a lot. Feel free to ask!