Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.

Bug 1946024

Summary: libdnf crashes when trying to load CD/DVD repositories when the CD/DVD media is mounted
Product: [Fedora] Fedora Reporter: Neal Gompa <ngompa13>
Component: libdnfAssignee: amatej
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: high    
Version: rawhideCC: amatej, dmach, hellcp, jmracek, jrohel, mblaha, pkratoch, raistlin, rbrown, rpm-software-management, stasiek
Target Milestone: ---Keywords: Triaged
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: libdnf-0.63.1-1.fc35 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2021-06-15 07:21:27 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: 1665453    
Attachments:
Description Flags
microdnf coredump from gdb
none
Screenshot of the backtrace
none
openSUSE MicroOS 20210330 DVD repo config file none

Description Neal Gompa 2021-04-03 16:36:22 UTC
Created attachment 1768847 [details]
microdnf coredump from gdb

Description of problem:
openSUSE MicroOS Desktop (20210330 snapshot) switched to using MicroDNF and DNF through PackageKit for software management. However, if the install DVD is automounted by GNOME, libdnf consumers (such as microdnf and packagekit) will crash while attempting to access the repo on the DVD.

Version-Release number of selected component (if applicable):
0.60.0-1.3 (equivalent to 0.60.0-1.fc35)

How reproducible:
Always

Steps to Reproduce:
1. Install openSUSE MicroOS with GNOME Desktop (add Micro DNF to software selection in YaST)
2. In the installed system, run "sudo microdnf install emacs-nox"

Actual results:
ngompa@linux:~> sudo microdnf install emacs-nox

(microdnf:2911): librepo-WARNING **: 16:33:07.525: Error resolving real path of cd:/?devices=/dev/disk/by-id/ata-VMware_Virtual_IDE_CDROM_Drive_10000000000000000001: No such file or directory
Segmentation fault


Expected results:
Behaves as expected and offers to install emacs-nox

Additional info:
This issue seems to only happen if the DVD is mounted. If it is not, then it gracefully fails to load the repo and keeps working as intended.

I've also provided a coredump from my system for further examination.

Comment 1 Neal Gompa 2021-04-03 16:41:01 UTC
Created attachment 1768848 [details]
Screenshot of the backtrace

Here's also a screenshot of the backtrace from GDB.

Comment 2 Neal Gompa 2021-04-03 16:43:56 UTC
Created attachment 1768849 [details]
openSUSE MicroOS 20210330 DVD repo config file

I've also attached the repo config file that causes libdnf to attempt this and break.

Comment 3 Neal Gompa 2021-04-05 08:59:35 UTC
The install media that you can use to reproduce this on: https://download.opensuse.org/tumbleweed/iso/openSUSE-MicroOS-DVD-x86_64-Snapshot20210330-Media.iso

Comment 4 amatej 2021-04-14 07:54:28 UTC
I managed to reproduce this also on fedora simply by mounting one of the openSUSE microOS media images and running microdnf, that is all that's needed.

The problem was a missing return value check in libdnf together with a missing [media] section in the .treeinfo of the iso (which libdnf is hardcoded to expect for bootable media).
This PR should fix it: https://github.com/rpm-software-management/libdnf/pull/1193

(I haven't actually tested it in installed openSUSE MicroOS because I didn't manage to install microdnf for the current snapshot)

Comment 5 Fedora Update System 2021-06-15 07:21:27 UTC
FEDORA-2021-78c5f8c03d has been pushed to the Fedora 35 stable repository.
If problem still persists, please make note of it in this bug report.