Offline update verbosity

Hrm, I’ll have to test that out. I got the complete dnf update info when I went verbose when I’d used it last.
I’m not aware of that having changed recently. I’ll test that out with the next update and report back.

I did not “mislead”, and it is not spam. I understand that you are annoyed, but please watch your tone and your phrasing. Please read the code of conduct again. The link is in the top bar of this forum.

6 Likes

Please do not baselessly accuse people of ill intent. We’re all here to be helpful. @FranciscoD stated that they got the full update log when last they tried and even promised to try to reproduce your issue on their system next time an update occurs on their system.

And yet, you are and you do.

5 Likes

If the offline update is giving you that much trouble then just run the update live in a terminal or TTY, at least for this particular update. TTY is safer so I’ll walk you through that. Login to your desktop normally, so WiFi service starts. Then press CTRL+ALT+F2 (you may also need to use the FN key to use the F2 key if you’re on a laptop) and login, run sudo dnf update and then manually reboot when finished by typing reboot. See if DNF hangs on a particular package, which sounds like what is happening.

If you want to check your logs, you can use journalctl -r to list the most recent logs and save yourself some reading time.

3 Likes

i already wrote i can run dnf update from terminal or TTY, but i’m asking about the offline update verbosity level .

but why ?! why should the offline update be limited to percentage progress .
my problem is not with the UI but even after pressing F1 you are still limited only to textual percentage progress as i have shown in the video .
the verbosity textual output does not show more information, but a text line which means absolutely nothing : “a stope job is running” and there is no limit to when it finishes .

this is a serious design flaw, what is the point of writing there is a job that doesn’t have a limit on when it finishes !?
and why choose the term “job” the user already pressed F1 for verbosity, so do write meaningful sentences .

in my estimation whoever wrote this offline update have a problem in communicating with the underlying dnf architecture, this is not a feature but a bug .
it doesn’t look like someone wanted to withhold information from the user, but more like the programmer does not know how to output that information from dnf .

i should study systemd to figure out which script in boot process responsible for the offline update and find why they couldn’t output information from dnf .

Ah I see.You want to view the exact output of everything going on with the update. Instead it just switches you back to systemd and tells you the update is running. Hence the start/stop job. I dislike the offline updater so I normally bypass it and deal with the risks. Thus I don’t have much experience with it and just thought I’d offer you a quick workaround in case you were still stuck.

I think you may have stumbled upon a bug or there is something wrong with the offline updater on your system. I researched the offline updater just now and I am surprised by how little documentation there is on it.

When @FranciscoD tests it on his system, we will know for certain.

2 Likes

this really really really sounds highly implausible .
there is no way you pressed F1 during boot offline update and was able to see complete dnf info .
seems the only explanation is that you saw systemd boot process and mistaken that for dnf information .
they certainly are not the same thing .

Please be less confrontational.

Looking at the systemd target that triggers the offline upgrade, it seems the update is performed via packagekit (/usr/libexec/pk-offline-update to be precise) and not dnf. I have no idea what packagekit logs to console while doing that, or if that changed recently, but regardless, that would explain differences in the output. It also makes a difference if you’re looking at an update from one Fedora version to another (which uses dnf) or a “normal” offline update, which uses packagekit.

The start-job stuff is logged not by the update process but by systemd managing the update process, it can’t and isn’t supposed to log output from the job being started. The ‘no limit’ is also correct - systemd can’t know how long the upgrade will take, is it supposed to just terminate it after a set timeout, potentially leaving you with a broken system? The repeated messages you’re seeing are basically a quirk of how console output works - the update job & the start job are both trying to update the last written line simultaneously & getting into a fight over it.

2 Likes

packagekit is just abstraction layer, it does run dnf under the hood .
anyway the point is : i want more information than percentage progress when i press F1 .
my problem again : my parents computer got stuck at 97% and there was nothing to do other than rebooting the computer using the power button .
and i have to wait for next time to visit them so i can figure out the reason it got stuck, while if packagekit offline update did show more information maybe i could have advised them on solving the issue before my next visit .

It doesn’t, it uses libdnf, which is why it doesn’t have dnf’s console output but rather its own.

That is a crappy situation, agreed. FWIW, the offline update program currently doesn’t log anything useful to console beyond what you’re seeing. This is definitely something worth asking the packagekit devs about changing - presumably packagekit logs what it is doing to syslog, it would probably be fairly easy to send that output to console as well.

Edit: Sorry, I made a mistake. Looking at the code, the update program does in fact have a more verbose output mode where it logs the specific package it is currently updating but what you’re seeing does not seem to be that mode. Maybe that is what changed from when @FranciscoD checked on their system. No idea if there is a simple way to select the mode, but maybe somebody else here does.

5 Likes

it looks like dracut crashed, that is why the update was halted at 97% .
https://gist.github.com/yakoub/bd539b535ea8b490206cf15d0ac0bc8b

1 Like

i don’t care about hiding/flagging my post … whatever .
but i think it is worthwhile to document somewhere that offline update will get halted at 97% if dracut crashes .
– well actually after examining more carefully the log i’m not sure dracut really did fail .

This is a bit off topic, I admit, but I have to ask… what’s the basis for that claim?

The supposed dangers of updating a live system (greatly exaggerated, IMHO) have to do with replacing files while they’re in use by the system. If you’re still LOGGED IN and your session is still running, then all the same files are in use regardless and there’s no difference between running dnf from a console TTY vs. a graphical shell. Just do it from gnome-terminal.

(If you’d said “log out first, then switch to a console TTY”, then maybe I could see the point.)

2 Likes

All good points. I was mainly thinking of Wayland or Xorg crashing during an update, then the update is not interrupted and no one runs into a partial update issue. Your argument is certainly valid outside of that. I told him not to log out of session1 before switching to session 2 as I personally have issues with getting NetworkManager.service to start from TTY on my system. Apparently systemctl start NetworkManager.service doesn’t do the trick for me unless I also have myself logged in on session 1. Logging out of my DE on session 1 and then logging in on session 2 is the ideal method.

(Come to think of it I probably should have opened a thread on that issue.)

I fully agree, though apparently it was enough concern for the GNOME devs to implement this Windows-style offline update. I made a thread last year where I sorta questioned it and got the “safety” argument. I would have told OP just to use terminal but I was worried about getting the “you’re giving dangerous instructions” talk again. And here, too

Of course now I know you need to restart regardless of method used. I was quite inexperienced back then.

2 Likes

Sometimes I wonder if the package-update paranoiacs are aware that Linux filehandles are independent of disk paths?

If a process has some shared library open or whatever, and that library gets replaced with an updated version on disk, the process is still linked to the previous version of the library, and will keep that handle until termination.

For an update to cause problems with running processes, you’d have to be unlucky enough to have one dynamically-load files from a package as it was being updated, so it ended up with an incompatible mix of old/new libs or something like that. (Or happen to load an updated library that depends on a new version of a different library that hasn’t been updated yet… but DNF’s dependency-ordering should really make even that an unlikely occurrence.)

There’s only one issue I’ve ever experienced with ‘live’ package updates: When the Nvidia proprietary display drivers get updated, suddenly the library version doesn’t match the loaded kernel module, so they refuse to communicate. Which means anything that tries to do accelerated video output will fail until I reboot. But even that is… it’s just as I said, video fails to play. It’s not like anything crashes or eats all of my files. And even my X session stays running with no problems, because like I said: Still has the old driver loaded.

what if that process decides on its own to reload the library manually ?

Then it will get the new library. Which, realistically, 95% of the time is OK anyway, since ABI compatibility typically means a newer version of a lib is OK if it keeps the same SONAME. (If it doesn’t, then the old file is gone and there’s nothing there to reload.)

In any of the cases where that’s a bad thing, the program will presumably crash. But years and years of live updates have reassured me that (at least) the standard desktop environment stack of GNOME services, mutter, X.org server, etc. clearly doesn’t do that, because they’ve never experienced a single problem.

Heck, if you install python3-dnf-plugin-tracer, DNF will run a scan at the end of the upgrade run and offer you a report if it finds any processes with files open that were part of the transaction. That way you know which ones might theoretically hit problems, and should at least be restarted after the upgrade.

But, really, it already feels like this is all in the realm of upgrade-security theater.

2 Likes

Personally, I don’t use offline updates, and I had - very occasionally - some issue where Program A + B were updated, but A was running and so was still the old version, which then failed when trying to interact with the new version of Program B. I also - very occasionally - had some issues with a kernel update, because some stupid program got confused with ‘running’ and ‘newest’ kernel, but I’d consider that a bug in the program.

I’d say the offline update stuff is a case of “out of an abundance of caution” - there might sometimes be some issues with some updates, so in order not to confuse users, we do them offline even if not strictly necessary. Nobody is bothered by ‘update will be applied after next reboot’, but people will be bothered by weird transient errors after updating.

I second that - tracer is very useful, especially on machines that only get rebooted rarely.

1 Like

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