Bug 1321484

Summary: Container bootstrapping with dnf is broken.
Product: [Fedora] Fedora Reporter: Patrick Meyer <patrick.meyer>
Component: rpmAssignee: Packaging Maintenance Team <packaging-team-maint>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: unspecified    
Version: 23CC: ffesti, jmracek, jsilhan, jzeleny, lkardos, mluscon, mmraka, novyjindrich, packaging-team-maint, patrick.meyer, pknirsch, pnemade, vmukhame
Target Milestone: ---Flags: lkardos: needinfo? (patrick.meyer)
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-04-15 07:27:33 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:
Attachments:
Description Flags
dnf output
none
enforcing
none
permissive
none
disabled
none
selinux log - permissive none

Description Patrick Meyer 2016-03-27 23:41:10 UTC
Created attachment 1140745 [details]
dnf output

Description of problem:

Using Cent7 I can use "yum --installroot=/path/to/container/root --releasever=7 -y install @core" to bootstrap a cent rootfs.
Doing a "dnf --installroot=/path/to/container/root --releasever=23 -y install @core" on Fedora23 results in the attached dnf output. The bootstraped system is broken.
The output looks similiarly broken when I install and try it with yum on fedora23.

Note that the systemd-nspawn man page suggests this kind of bootstrapping:
Example 2. Build and boot a minimal Fedora distribution in a container
# dnf -y --releasever=21 --nogpg --installroot=/srv/mycontainer --disablerepo='*' --enablerepo=fedora install systemd passwd dnf fedora-release vim-minimal
# systemd-nspawn -bD /srv/mycontainer


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


How reproducible:


Steps to Reproduce:
1. dnf --installroot=/path/to/container/root --releasever=23 -y install @core

Actual results:
See attached file.

Expected results:
A bootstraped fedora rootfs.

Additional info:

Comment 1 Jaroslav Mracek 2016-03-31 13:19:28 UTC
Probably rpm team will have a clue.

Comment 2 Florian Festi 2016-04-01 11:23:48 UTC
Works for me on my local F23 installation. But it sounds familiar. We had similar results with an issue of not setting the SELinux context properly when running with SELinux as permissive.

Can you please try with SELinux in enforcing, permissive and disabled and check the SELinux logs.

Comment 3 Patrick Meyer 2016-04-01 18:33:23 UTC
Created attachment 1142666 [details]
enforcing

Comment 4 Patrick Meyer 2016-04-01 18:34:10 UTC
Created attachment 1142667 [details]
permissive

Comment 5 Patrick Meyer 2016-04-01 18:34:58 UTC
Created attachment 1142668 [details]
disabled

Comment 6 Patrick Meyer 2016-04-01 18:42:17 UTC
The file names are self explaining, I guess.
There are only a couple of non fatal errors when I try it with selinux disabled. It does not work with selinux in permissive mode though.

Comment 7 Patrick Meyer 2016-04-01 19:00:34 UTC
Created attachment 1142685 [details]
selinux log - permissive

Comment 8 Patrick Meyer 2016-04-01 19:02:54 UTC
I hope that's sufficient, ask if you need anything else :3

Comment 9 Michael Mráka 2016-04-05 08:19:56 UTC
These two SIGABRTs from log seem to be interesting:

type=ANOM_ABEND msg=audit(1458383364.495:3849): auid=1000 uid=0 gid=0 ses=40 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 pid=33649 comm="dnf" exe="/usr/bin/python3.4" sig=6
type=ANOM_ABEND msg=audit(1458383410.956:3851): auid=1000 uid=0 gid=0 ses=40 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 pid=33686 comm="dnf" exe="/usr/bin/python3.4" sig=6

Do you have an idea what / when happened?

Comment 10 Ľuboš Kardoš 2016-04-06 09:23:34 UTC
Which version of rpm do you use? This problem should be fixed since version 4.13.0-0.rc1.4.

Comment 11 Ľuboš Kardoš 2016-04-15 07:27:33 UTC
I able to reproduce this only with rpm-4.13.0-0.rc1.3 and with that version of rpm I get almost exactly the same output from dnf as the one attached to this bug. But there are no problems with higher version of rpm so I will close this bug as currentrelease. If you have still this problem with the current rpm version then please reopen this bug and specify the version of rpm with which you encountered the problem.