Bug 1769831

Summary: microdnf fails when passing --setopt=tsflags=nodocs
Product: Red Hat Enterprise Linux 8 Reporter: Jonathan Dowland <jdowland>
Component: microdnfAssignee: Lukáš Hrázký <lhrazky>
Status: CLOSED ERRATA QA Contact: Luca Berton <lberton>
Severity: unspecified Docs Contact:
Priority: medium    
Version: 8.4CC: dornelas, fsayyed, jlieskov, lberton, lhrazky, lmorse, mgoldman, rolweber, tgolembi
Target Milestone: rcKeywords: Triaged
Target Release: 8.0Flags: lberton: needinfo+
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: librepo-1.11.0-2.el8 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
: 1798029 (view as bug list) Environment:
Last Closed: 2020-04-28 16:55:23 UTC Type: Bug
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: 1186913, 1798029    

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 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