RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1769831 - microdnf fails when passing --setopt=tsflags=nodocs
Summary: microdnf fails when passing --setopt=tsflags=nodocs
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: microdnf
Version: 8.4
Hardware: Unspecified
OS: Unspecified
medium
unspecified
Target Milestone: rc
: 8.0
Assignee: Lukáš Hrázký
QA Contact: Luca Berton
URL:
Whiteboard:
: 1771647 (view as bug list)
Depends On:
Blocks: 1186913 1798029
TreeView+ depends on / blocked
 
Reported: 2019-11-07 15:03 UTC by Jonathan Dowland
Modified: 2023-10-06 18:45 UTC (History)
9 users (show)

Fixed In Version: librepo-1.11.0-2.el8
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1798029 (view as bug list)
Environment:
Last Closed: 2020-04-28 16:55:23 UTC
Type: Bug
Target Upstream Version:
Embargoed:
lberton: needinfo+

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker RHELPLAN-31200 0 None None None 2023-02-12 22:24:51 UTC
Red Hat Product Errata RHEA-2020:1855 0 None None None 2020-04-28 16:55:43 UTC

Description Jonathan Dowland 2019-11-07 15:03:45 UTC 
Description of problem:

When supplying the command-line argument --setopt=tsflags=nodocs (which is even suggested as valid by the output of microdnf --help), microdnf fails to install the selected package and instead returns error code 141.

Version-Release number of selected component (if applicable):

3.0.1-3.el8

How reproducible:

Always

Steps to Reproduce:
1. microdnf --setopt=tsflags=nodocs install -y unzip

Actual results:

Return code 141 (and no unzip)

Expected results:

unzip installed. return code 0

Additional info:

This is a newly discovered issue that prevents us from using the minimal-flavour UBI images as base images for Middleware product container images (e.g. OpenJDK, EAP, etc.)
Comment 1 Roland Weber 2019-11-12 10:05:19 UTC 
Upstream issue report: https://github.com/rpm-software-management/microdnf/issues/50
Comment 3 Roland Weber 2019-11-12 12:34:54 UTC 
Afaict, the problem is not in microdnf itself, but introduced by one of the supporting libraries.
I narrowed it down to three packages updated from ubi8-minimal:8.0

- libdnf-0.35.1-9.el8_1.x86_64
- librepo-1.10.3-3.el8.x86_64
- libsolv-0.7.4-3.el8.x86_64

See https://github.com/rpm-software-management/microdnf/issues/50#issuecomment-552873517 for a small Dockerfile that reproduces the problem.
Comment 4 Roland Weber 2019-11-12 12:40:12 UTC 
It's librepo, see https://github.com/rpm-software-management/microdnf/issues/50#issuecomment-552876380
Comment 5 Roland Weber 2019-11-12 12:52:03 UTC 
I opened an issue against librepo: https://github.com/rpm-software-management/librepo/issues/177
Comment 6 Laurie Morse 2019-11-12 18:07:51 UTC 
We also hit this problem last week and opened Red Hat Case #02513689.  I will be monitoring this bug report.
Comment 7 Lukáš Hrázký 2019-11-13 15:05:28 UTC 
So far I've got this backtrace, seems like an issue with gpgme:

#0  0x00007ffff7999647 in write () from /lib64/libc.so.6
#1  0x00007ffff70ab9ba in ?? () from /lib64/libgpgme.so.11
#2  0x00007ffff7099ec5 in ?? () from /lib64/libgpgme.so.11
#3  0x00007ffff66c8129 in ?? () from /lib64/libassuan.so.0
#4  0x00007ffff66c87b7 in ?? () from /lib64/libassuan.so.0
#5  0x00007ffff66c7934 in ?? () from /lib64/libassuan.so.0
#6  0x00007ffff66c61d6 in ?? () from /lib64/libassuan.so.0
#7  0x00007ffff66c6229 in assuan_release () from /lib64/libassuan.so.0
#8  0x00007ffff70a3c1b in ?? () from /lib64/libgpgme.so.11
#9  0x00007ffff70a4d92 in ?? () from /lib64/libgpgme.so.11
#10 0x00007ffff709acff in ?? () from /lib64/libgpgme.so.11
#11 0x00007ffff70b0e28 in gpgme_release () from /lib64/libgpgme.so.11
#12 0x00007ffff76e0dc3 in lr_gpg_import_key () from /lib64/librepo.so.0
#13 0x00007ffff7b7467b in dnf_repo_update () from /lib64/libdnf.so.2
#14 0x00007ffff7b627ab in dnf_sack_add_repo () from /lib64/libdnf.so.2
#15 0x00007ffff7b62a7b in dnf_sack_add_repos () from /lib64/libdnf.so.2
#16 0x00007ffff7b69817 in dnf_context_setup_sack_with_flags () from /lib64/libdnf.so.2
#17 0x00007ffff7b69bc3 in dnf_context_install () from /lib64/libdnf.so.2
#18 0x000055555555a70b in ?? ()
#19 0x0000555555559829 in main ()
Comment 8 Lukáš Hrázký 2019-11-18 12:21:50 UTC 
*** Bug 1771647 has been marked as a duplicate of this bug. ***
Comment 9 Lukáš Hrázký 2019-11-27 15:36:47 UTC 
PR: https://github.com/rpm-software-management/librepo/pull/178

Which attempts to fix the issue by creating the /run/user/$UID directory, which, if present, will be used by gpgagent for its sockets. That way they'll be out of the way of container images and we don't have to attempt to make gpgagent clean them up, which doesn't seem to be possible to do reliably.
Comment 14 Lukáš Hrázký 2020-01-30 14:21:17 UTC 
Hey Luca, what's the needinfo for? :)
Comment 17 errata-xmlrpc 2020-04-28 16:55:23 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2020:1855
Note You need to log in before you can comment on or make changes to this bug.