Short summery:
we just talk about a small improvement.
It works like it is now, but risks can me minimized with small adaptions to the package sort order in dnf while upgrading.
Am 23.05.24 um 06:14 schrieb Peter Boy:
we just talk about a small improvement.
It works like it is now, but risks can me minimized with small adaptions to the package sort order in dnf while upgrading.
Am 23.05.24 um 06:14 schrieb Peter Boy:
I'm under the impression, there is a small misunderstanding here: The upgrade worked as it should for the 23th time in a row :DSo, your server is running with F39 now?
Yes.
It's just, that > while < the upgrade process was running, there was the risk, that it or the connection fails, and in that case, there would not have been a way to fix it remotely because of the mismatch of openssl and openssh versions. (yes of course, an IPMI would be a way ).Unfortunately, I don’t understand, what exactly the problem is. If you follow the procedure as described in the Quick Docs document mentioned above, there is no network connection while the actual update process is running. And even if there was one, you have no way of intervening in the process.
I guess you think of "
dnf system-upgrade reboot" when you upgrade, but
honestly, it's not something I wanne do on a server.
The idea behind it may be ok, if the server can go offline for a
while, i wanne see what it does, when it does it, and if it
failes, which happens to post-scripts a lot lately.(yes i report
them, but most of the time nothing happens, sniff..)
I use the dnf distro-sync as mentioned in the fedora dnf upgrade guides for the upgrade process since at least FC15 and it works..and works
It has different issues, like hanging processes that need manually restarts, for which you need a working secondary ssh connection ;) .
i.e. rpc services have shown this on several occations in the past.
A desktop pc in berlin did a reset in the middle of an upgrade started in the softwarecenter and ended up with DBUS server and client mismatch, so it did not even boot into multiusermode. Had a hard time to get the person infront of it to boot into a root shell and start sshd manually .. at 0:30 in the morning ;)
In the end, it does not matter if you do a remote or a locally started upgrade.. it can fail. If it fails with a vital part like DBUS or ssh having version mismatches, you are in big trouble.
i would define "vital" very specific as : "all you need for bash" "all you need for ssh" "all you need for dbus". This would make a "dirty" little patch possible that would upgrade those ten packages at best as first/last ones, one after the other.
On the positive side, I remember pressing CTRL+C in the wrong terminal window after 1000 upgrade steps and just restarting the upgrade without any issues.
Like i said, it's in any situation a good idea if depending vital-packages get upgraded in close proximation in the chain to minimize the risk.
If DNF Devs can take this into consideration while they are on implementing new stuff, maybe someone has a brilliant idea how to archive this. All it takes is the right idea in the right moment.
Probably I overlook something in your mail. But I would really like to understand your issue. We are always looking to improve Fedora Server.
It just minimizing risks, that can be minimized. I assume it's just a small change on the sort order algorithm of dnf.
Of course we do snapshots to minimize upgrade issues.
The thing with snapshots is, that while such a distro-sync takes up to 15 minutes, in case of SATA hds 45 minutes, that can mean X Minutes of email losses once reverted.
It would be easy to stop the services, but as most of you know, customers do not like when services are not available, because that 1 soooo important visitor just shows up in this exact moment ;) And of course they do not pay for that hot-stand-by that would solve this easily :D And silverblue isn't an option either here.
In the past 13 years of distro-syncing our serverfarm I had to revert 2 times. Means: "GOOD JOB Everyone! Thanks."
And I’m running a bunch of servers in a remote data center, too, w/o access to the console (but a temporary KVM in case of emergency). So I have the update adventure every 6 months as well.
...one who knows... :)
best regards,
Marius Schwarz
-- _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
