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:
I'm under the impression, there is a small misunderstanding here: The upgrade
worked as it should for the 23th time in a row :D
So, 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@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue