Bug 1406130 - Upgrade does not show progress between Cleanup and Verify
Upgrade does not show progress between Cleanup and Verify
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: dnf (Show other bugs)
rawhide
Unspecified Unspecified
medium Severity low
: ---
: ---
Assigned To: rpm-software-management
Fedora Extras Quality Assurance
: FutureFeature, Reopened, Triaged
: 1412086 (view as bug list)
Depends On: 1246600 1411423
Blocks:
  Show dependency treegraph
 
Reported: 2016-12-19 14:42 EST by Viliam Križan
Modified: 2017-04-01 13:22 EDT (History)
8 users (show)

See Also:
Fixed In Version: dnf-2.2.0-1.fc26
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-04-01 13:22:20 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Viliam Križan 2016-12-19 14:42:29 EST
Description of problem:

No progress is being printed after Cleanup is done, right before Verification. I've found out that mandb was indexing all man pages (on one CPU core). Is it possible to show more progress messages when doing mandb indexing (or post scripts?)? Maybe to use more verbose from dnf core to show for `PlymouthOutput`. 

When I was upgrading a one message "[5813/5813] Clean libgcc-5.3.1-6" hung there for 20-30 minutes. To me (or to other users) it looked like the update has hanged.


I am not sure if this should be improved in system-upgrade plugin or dnf core.


How reproducible:

When upgrading system, e.g. from F23->F24 or F24->F25.


Steps to Reproduce:
1. dnf system-upgrade --releasever 25 download
2. dnf system-upgrade reboot


Actual results:

No progress messages after Cleanup transaction, right before Verify. One message hangs there for several minutes.

Expected results:

Display message(s) between Cleanup and Verify.
It could be something like: "Regenrating man index... This may take several minutes."


Additional info:
You need to have a root password set to check login to system while upgrading. (Other user logins are disabled/locked.)
Comment 1 Will Woods 2016-12-23 15:44:27 EST
This is a DNF/RPM problem - DNF doesn't display the output from scriptlets, and scriptlets don't have any other way to report progress.
Comment 2 Igor Gnatenko 2017-01-02 03:15:33 EST
well, it's RPM working there (I guess filetriggers)...
Comment 3 Will Woods 2017-01-03 15:07:49 EST
yeah - %transfile*, %posttrans*, etc.

There *are* RPM callbacks for these events but AFAIK they're not documented as public and therefore DNF doesn't handle them. See e.g. bug 1246600.
Comment 4 Panu Matilainen 2017-01-04 02:08:00 EST
Eh? Not to excuse for bad/missing documentation, but the script start/stop callback events aren't any less documented than the rest of the callback events, which dnf is merrily using.
Comment 5 Will Woods 2017-01-04 11:29:43 EST
Yeah, but (at least the last time I looked) the DNF team doesn't want to add stuff that yum didn't use without it being documented as part of RPM's public API, but nobody on either team has had the time or inclination to do that, so it's not been done.

See the DNF side of the discussion here:
  https://github.com/rpm-software-management/dnf/pull/281#issuecomment-124263743

DNF-2.0 actually dropped support for RPMCALLBACK_SCRIPT_START, since it was still unused by the rest of DNF:
  https://github.com/rpm-software-management/dnf/commit/25e626d

So. This situation could certainly be improved, but it's unfortunately not possible for dnf-plugin-system-upgrade to fix it.
Comment 6 Panu Matilainen 2017-01-04 11:46:22 EST
Dnf itself may have special rules about documentation required for something to be considered public but they shouldn't expect every other project to follow the same rules.

Whether something is rpm public API doesn't depend on documentation, it depends on what *is* public: If it's in the public headers then it's a public API, and that's all there is to it. On python side the standard underscore-prefixing is used to mark something private, IIRC there isn't a whole lot that is private though.

Just FWIW.
Comment 7 Igor Gnatenko 2017-01-11 04:19:05 EST
*** Bug 1412086 has been marked as a duplicate of this bug. ***
Comment 8 Jaroslav Mracek 2017-03-17 09:32:00 EDT
I tried to fulfill your request. Here is pull request: https://github.com/rpm-software-management/dnf/pull/763.
Comment 9 Viliam Križan 2017-03-17 10:04:04 EDT
Appreciated. Thank you Jaroslav!

Will the messages be visible by default or does the verbose have to be on. If the later, then consider turning on the verbose on `system-upgrade`.
Comment 10 Jaroslav Mracek 2017-03-17 10:17:13 EDT
Well so far it will be visible by defaults. But to be exact PR shows starting scriplets for each package but there is no progress bar because it is not supported by rpm. They don't know how long each scriplets will take. But the PR should really help, because usually scriplets are short.
Comment 11 Viliam Križan 2017-03-17 10:53:09 EDT
Showing messages when running scriplets is enough for me (almost as showin progress). 

There are some scriplets that run `mandb`. I am not sure if its run per each package, or dnf has some trigger and runs it itelf. On system upgrade, when (almost) all packages are being upgraded, that mandb takes too long. (see comment #0)
Comment 12 Fedora Update System 2017-03-27 15:21:04 EDT
dnf-2.2.0-1.fc26, libdnf-0.8.0-1.fc26 has been pushed to the Fedora 26 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-65586fa42b
Comment 13 Fedora Update System 2017-04-01 13:22:20 EDT
dnf-2.2.0-1.fc26, libdnf-0.8.0-1.fc26 has been pushed to the Fedora 26 stable repository. If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.