i have several fedora computers, one of them is hanging while rebooting for what you call “offline” updates it reaches 97% and get stuck for ever .
i read you could reboot and then run journalctl with some special filter to check the logs and see what is the reason for it to get stuck .
so my question is, why not allow showing more verbosity already when the updates are being performed ?
i am really baffled as to why you limit the displayed information for percentage progress bar .
and then you show strange message about “a stop job is running … with time limit until it would stop”, but sometimes there is no time limit and that “stop job” runs forever .
if you run “dnf update” then you sure see lots of usefull information, then again why the “offline /reboot update” is only limited to percentage progress bar .
this is really very frustrating, the computer with the problem belong to my parents and i need to remember when visiting them again to check journalctl for reasons that update gets stuck .
You just press a key during the update and it’ll switch to verbose mode as you would do during a normal boot. Try the right-arrow key.
From a design perspective, we can’t have both: we can’t have a simple UI without detailed information that most people prefer, and at the same time show lots of debugging information. So, by default, it’s a simple progress bar, and you (and other advanced users) can press a key to see debug information if you wish.
If you wish the boot to always be verbose, remove the rhgb quiet line from your boot parameters.
you answer is misleading, it is obvious that i wrote regarding the update process specifically and not the general boot process .
when you press F1 you get verbose boot process but specifically the update will remain only percentage progress but just in textual format .
i don’t understand why you choose to mislead the discussion in such a manner, your answer is almost spam .
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.
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.
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.
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.
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 .
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.
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.
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.)
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.
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.
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.
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.