Thanks for all the useful information. I have taken to using the virtual console to finishing my upgrades, so I think we are using the same workflow, now.
I’m surprised to hear this about TMUX. I switched to TMUX from Screen a long time ago, but didn’t know this. I don’t understand this because I start my upgrades with dnf --downloadonly in a tmux session, then I logout of X, then switch to VC, then reattach to tmux and run dnf upgrade to “resume” the upgrade before rebooting. I don’t understand the relationship between the X session and TMUX to interpret why what you say can happen would happen. Clearly, TMUX is a descendant of X and GDM, but so is screen. Does it have to do with cgroups? Does screen ignore HUP and TMUX doesn’t? Strange.
In any case, I had a new experience that makes me even more disappointed. My system booted into emergency mode/single, recently and I think the only problem was that it wanted me to do a manual fsck. So, I did that, it wasn’t anything too serious. But, afterward, I decided to do a DNF upgrade since I was already in single mode, and that was one workflow I was considering. Well, even that is not safe. During the DNF upgrade, something tripped systemd, or possibly anaconda, directly, to start GDM. I don’t know what or why because as soon as it started, which I didn’t realize immediately, I lost all access to the console (VC1), and the output from DNF. I waited a bit, as it seemed like dnf was still performing the update, and I think that was right, because, after I rebooted, I checked and it seemed like DNF had installed the rest of the updates; it was about half way through when I lost track of it.
So, WTF? I get the feeling that the process is even more fragile than we can anticipate. The system cannot get any more quiescent than single mode, so, it’s not that the update caused a crash or something failed during the update. But, the update actually tripped some trigger that caused systemd to start more services. So, then someone needs to sit down, figure out what the dependencies are, and make a systemd target with those services so we don’t have to flounder around trying to guess the safest workflow.
I’m looking for the DNF, command-line equivalent of GNOME software off-line updates. package-kit knows how to orchestrate this, obviously. So, why isn’t something like this documented and recommended by RedHat and Fedora maintainers? Just seems like something that is really valuable to have and I don’t understand why, after 20 years, it isn’t a standard thing.