Bug 1478051
Summary: | Fedora 25 - RPM installation/update with progress display makes it impossible to install ep11 host package | ||||||
---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | IBM Bug Proxy <bugproxy> | ||||
Component: | rpm | Assignee: | Packaging Maintenance Team <packaging-team-maint> | ||||
Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
Severity: | low | Docs Contact: | |||||
Priority: | unspecified | ||||||
Version: | 28 | CC: | dan, hannsj_uhl, ignatenko, jkachuck, kardos.lubos, mjw, packaging-team-maint, pmatilai, vmukhame | ||||
Target Milestone: | --- | ||||||
Target Release: | --- | ||||||
Hardware: | s390x | ||||||
OS: | Linux | ||||||
Whiteboard: | |||||||
Fixed In Version: | Doc Type: | If docs needed, set a value | |||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2018-06-29 13:27:25 UTC | Type: | --- | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Bug Depends On: | |||||||
Bug Blocks: | 467765 | ||||||
Attachments: |
|
Description
IBM Bug Proxy
2017-08-03 13:40:23 UTC
Fedora version: zlinuxdriver 25 (Twenty Five) RPM version: 4.13.0.1 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 %% 378.000000 %% 1372.000000 %% 3305.000000 %% 58286.000000 %% 64403.996094 %% 70520.000000 %% 70663.000000 %% 70811.000000 %% 136484.000000 %% 202020.000000 %% 252076.000000 %% 252220.000000 %% 252372.000000 %% 318048.000000 %% 377024.000000 %% 377167.000000 %% 377319.000000 %% 442996.000000 %% 508531.968750 %% 574068.000000 %% 606924.000000 %% 607072.000000 %% 607224.000000 %% 672900.000000 %% 738436.000000 %% 760396.000000 %% 826063.937500 %% 891600.000000 %% 957136.062500 %% 1022672.000000 %% 1088208.000000 %% 1153744.000000 %% 1219280.000000 %% 1284816.000000 %% 1350352.000000 %% 1415888.000000 %% 1481424.000000 %% 1546960.000000 %% 1612496.000000 %% 1678032.000000 %% 1743568.000000 %% 1809103.875000 %% 1874640.000000 %% 1940176.000000 %% 2005711.875000 %% 2050368.000000 Interesting is that with IO-redirection to a file RPM installs the package correctly. However the progress display is nevertheless broken: Preparing... ######################################## Updating / installing... ep11-host-1.3.0-1 #(<-character nr 143) ... (character nr 820989->)# Cleaning up / removing... ep11-host-1.2.2-2 ######################################## 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 benedikt.klotz.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 benedikt.klotz.com 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: <rpmTag name="Archivesize"> <integer>0</integer> </rpmTag> 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 $? 0 However rpm2cpio works without a flaw: # rpm2cpio ep11-host-1.3.0-1.s390x.rpm | LANG=C cpio -dium 4005 blocks 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 4.12.0.1 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: <rpmTag name="Rpmversion"> <string>4.12.0.1</string> </rpmTag> Fixed in rpm 4.12.0.2 (http://rpm.org/wiki/Releases/4.12.0.2), 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 benedikt.klotz.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 benedikt.klotz.com 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' of '25'. 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: https://github.com/rpm-software-management/rpm/commit/70b56c5022ad639042145eb94181fa6dfbaffad1 This bug appears to have been reported against 'rawhide' during the Fedora 28 development cycle. Changing version to '28'. Fixed now in rawhide as of rpm >= 4.14.2-rc1 |