Although this is not an offline upgrade, you can still minimize the risks and also preserve the logs using systemd-run:
sudo dnf --refresh changelog --upgrades
sudo systemd-run -u dnf dnf -y upgrade
sudo journalctl -f -u dnf
5 Likes
I’d actually disagree with that a bit, only because I so rarely find myself in a situation where it’s a “good time” to restart my system. (Especially if it’s not going to come up again immediately, because it first has to perform an update run.)
I know myself, at least, and offline updates would mean that new packages sit for days or even weeks before getting installed. Which means security patches don’t get installed in as timely a fashion, which is a bad thing. If the choice is between installing now and rolling the dice on impact to current processes, or downloading and assuring myself that I’ll get around to restarting “real soon now”… well, here’s one of my two machines, right now:
$ uptime
05:30:21 up 20 days, 19:17, 1 user, load average: 1.03, 0.38, 0.23
# But it last upgraded packages...
$ sudo grep -i upgrade /var/log/dnf.rpm.log|tail -n 2
2020-08-01T02:12:21Z SUBDEBUG Upgraded: glibc-common-2.31-2.fc32.x86_64
2020-08-01T02:12:22Z SUBDEBUG Upgraded: libgcc-10.1.1-1.fc32.x86_64
(Heh! Heck, and that was glibc. Nothing crashed.)
1 Like
Ooh, that’s a neat tip, nice! I didn’t know about systemd-run. I have been known to start a screen session and run my dnf transactions there, on my remote hosts, so that if I get disconnected (or just need to disconnect) the update won’t be affected, but systemd-run sounds way handier.
The only thing I’d be wary of, personally, is that --refresh.
I’m a control freak and genuinely do read through the list of updated packages before confirming the transaction, so if I was gonna run dnf -y in a background process, it’d only be after first looking over a dnf check-update --refresh run. But if the transaction does another --refresh beforehand, who knows what could potentially sneak in there?
2 Likes