Bug 1351352

Summary: SELinux relabel fails (due to read-only / ?) on simple Fedora 24 virt-builder image
Product: [Fedora] Fedora Reporter: Adam Williamson <awilliam>
Component: libguestfsAssignee: Richard W.M. Jones <rjones>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: unspecified    
Version: 25CC: awilliam, cheimes, mbooth, ptoscano, rjones, virt-maint
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-11-01 10:55:08 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:

Description Adam Williamson 2016-06-29 20:25:25 UTC
If I build a simple fedora-24 image currently:

virt-builder fedora-24 -o test.img --arch x86_64 --root-password password:weakpassword --update --selinux-relabel

then try and boot it:

qemu-kvm -m 2G -nographic test.img

it sticks in a boot loop. This worked a week or so ago, so one of the package updates since then has changed things and made it stop working.

I think what's happening is that / winds up, for some reason, read-only, so the relabel script can neither relabel it nor remove /.autorelabel - so it sticks in a loop of trying over and over again and never getting anywhere.

Comment 1 Adam Williamson 2016-06-29 20:31:20 UTC
This can be worked around thus:

virt-builder fedora-24 -o test.img --arch x86_64 --root-password password:weakpassword --update --selinux-relabel --edit '/etc/selinux/config:s/SELINUX=.*/SELINUX=permissive/' --firstboot-command "sed -i -e 's/SELINUX=permissive/SELINUX=enforcing/' /etc/selinux/config"

so on the very first boot - when the relabel is done - SELinux will be set to permissive. When the system automatically reboots from the relabelling it will be in permissive mode, then subsequent boots will be enforcing. To switch the second boot to enforcing mode you could add one more arg, I guess:

virt-builder fedora-24 -o test.img --arch x86_64 --root-password password:weakpassword --update --selinux-relabel --edit '/etc/selinux/config:s/SELINUX=.*/SELINUX=permissive/' --firstboot-command "sed -i -e 's/SELINUX=permissive/SELINUX=enforcing/' /etc/selinux/config" --firstboot-command "setenforce Enforcing"

Comment 2 Christian Heimes 2016-06-30 09:56:58 UTC
Yesterday I ran into the same issue, too. In my workaround I first use virt-customize to set SELinux to permissive mode, then boot the image once with qemu-system to enforce auto-relabelling, followed by a final virt-edit to chance the system to enforcing mode.

https://github.com/tiran/pki-vagans/blob/master/vagrantbuilder/boxbuilder#L105

Comment 3 Jan Kurik 2016-07-26 04:59:58 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 25 development cycle.
Changing version to '25'.

Comment 4 Pino Toscano 2016-10-05 09:15:55 UTC
Sorry for the late reply -- which version of libguestfs was used when reporting the issue?

Since libguestfs 1.33.43 there's a new API for SELinux relabelling used also for --selinux-relabel, which should work much better.

Comment 5 Adam Williamson 2016-10-31 18:49:12 UTC
I dunno, it was months ago, I don't have a record to hand. It would have been whatever was in Fedora 24 and Fedora 25 at the time (the bug occurred on both, I believe).

I discussed it with rwmjones at the time, he had a pretty good idea what was going on, I think. We switched from virt-builder to virt-install for the tool in question after this bug, so I'm not really super invested in it any more.

Comment 6 Richard W.M. Jones 2016-11-01 10:55:08 UTC
Basically as Pino says we substantially fixed SELinux relabelling
starting in libguestfs 1.34.  That should be the version available
in Fedora 24 since around July 2016.  It could be that the bug report
marginally predates these fixes.

I'm therefore going to close this bug.  If it happens reliably with
libguestfs >= 1.34 on the host, then please reopen with the precise
version of libguestfs and command used.