Red Hat Bugzilla – Bug 1478051
Fedora 25 - RPM installation/update with progress display makes it impossible to install ep11 host package
Last modified: 2018-02-20 10:31:29 EST
Fedora version: zlinuxdriver 25 (Twenty Five)
RPM version: 184.108.40.206
The ep11 host package (see attachment) has to be downloaded by our customers from a IBM website and the customer has to install it with rpm -i or with rpm -U. This works correctly.
However with our new version 1.3.0-1 (not yet released) and if the rpm option '-h' is used (e.g with rpm -Uvh), rpm prints thousands of hash characters to the screen and the installation procedure does not complete. If the rpm process is killed, the next rpm command shows that many read locks need to be freed and the new package is NOT installed.
Using '--percent' shows this:
Updating / installing...
1:ep11-host-1.3.0-1 %% 0.000000
Interesting is that with IO-redirection to a file RPM installs the package correctly. However the progress display is nevertheless broken:
Updating / installing...
ep11-host-1.3.0-1 #(<-character nr 143) ... (character nr 820989->)#
Cleaning up / removing...
Workaround: Do not use the '-h' option or use it with IO-redirection to a file (e.g.: rpm -Uvh 'package' > 'filename')
(In reply to IBM Bug Proxy from comment #1)
> The ep11 host package (see attachment)
The attachment seems to be missing...
------- Comment From email@example.com 2017-08-03 10:24 EDT-------
Yes the attachment is missing because it is a package of an internal test release. I will try to reproduce the problem with another RPM package tomorrow.
Is the RPM package needed to understand the problem or can this bug also be resolved without the package?
Can't the RH<->IBM partner channel be used for transferring the ep11 rpm? I guess it will be difficult to reproduce the rpm behaviour with another rpm.
Any reproducer will certainly do, it doesn't have to be that specific package. Attachments can be made private (a fairly common practise in cases like this) if that helps.
But chasing bugs without a reproducer ... the package must be doing something fairly strange because the progress bar code hasn't seen much change in many years and nobody else has reported such behavior.
Doh, forgot to mention: short of an actual reproducer, output of "rpm -qp --xml <package>" might provide clues where to look.
------- Comment From firstname.lastname@example.org 2017-08-04 06:08 EDT-------
Thanks for the pointer with the xml output option. I will attach the output from rpm -qp --xml ep11-host-1.3.0-1.s390x.rpm > ep11_1.3.0-1_rpm.xml
It seems I found something in the xml output that is clearly wrong:
Since extracting files from this rpm package does work without problems, it seems this information is only used for the progress indicator.
The rpm2archive command seems to read this info too, because it does not produce any output:
# rpm2archive ep11-host-1.3.0-1.s390x.rpm
# echo $?
However rpm2cpio works without a flaw:
# rpm2cpio ep11-host-1.3.0-1.s390x.rpm | LANG=C cpio -dium
Can you give me a pointer how to create a package that contains this info?
I did forget to mention that the build machine uses a rpm in version 220.127.116.11
Created attachment 1308976 [details]
xml file from rpm -qp --xml for file ep11-host-1.3.0-1.s390x.rpm
Right, the xml output is enough to explain it, thanks.
The rpm version used to *build* that package is buggy on big-endian systems:
Fixed in rpm 18.104.22.168 (http://rpm.org/wiki/Releases/22.214.171.124), upstream commit from the 4.12.x branch being here: https://github.com/rpm-software-management/rpm/commit/767140049c1eac57c105fdfc874c2628a9089145
But sure enough, in the face of buggy packages, rpm should either work around it or just reject it and not go crazy.
------- Comment From email@example.com 2017-08-04 08:01 EDT-------
Ok I will try to rebuild the package with a rpm that has this patch applied.
Some more consistency checking in rpm would be great.
------- Comment From firstname.lastname@example.org 2017-08-04 08:26 EDT-------
ok with the patch applied I can build a rpm package that can be installed and updated with the rpm option '-h' enabled.
With this my problem is fixed. Feel free to close this bug. However the bug can also be let open if some more consistency checks in RPM should be implemented.
This message is a reminder that Fedora 25 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 25. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora 'version'
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.
Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 25 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
Moving to rawhide to avoid timeouting, while the actual issue here is a bug in older rpm version, rpm should be more robust in the face of invalid archivesize data and that hasn't been addressed.
Upstream now has a guard against progress meters going crazy in such a case:
This bug appears to have been reported against 'rawhide' during the Fedora 28 development cycle.
Changing version to '28'.