Red Hat Bugzilla – Bug 447067
mkinitrd can't boot from encrypted LV
Last modified: 2009-05-06 10:58:52 EDT
Description of problem:
mkinitrd in Fedora 9 can't boot from an encrypted LV.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Live upgrade Fedora 8 system using encrypted root on an LV to Fedora 9.
2. Boot system from Fedora 9 kernel/initramfs.
Red Hat nash version 6.0.52 starting
Reading all physical volumes. This may take a while...
Found volume group "VolGroup17" using metadata type lvm2
2 logical volume(s) in volume group "VolGroup17" now active
Enter LUKS passphrase for /dev/mapper/VolGroup17-root:
key slot 0 unlocked.
mount: error while loading shared libraries: libblkid.so.1: failed to map
segment from shared object: Permission denied
At this point Fedora attempts to run the init scripts but the mount error
immediately above appears repeatedly as it tries to remount the filesystem
read/write, etc. Eventually the script starts an SELinux autorelabel and reboot,
but the error persists on the next boot.
Normal system boot. Booting from the leftover Fedora 8 kernel/initramfs
188.8.131.52-64.fc8 built using mkinitrd 6.0.19 works fine.
For background see bug 124789. While Fedora creates encrypted PVs by default,
people who helped develop and test the encrypted root filesystem feature may
have the root fs on encrypted LVs instead.
After doing some further testing this appears to be an SELinux problem. I can
boot fine from the F9 kernel/initrd when I have disabled SELinux.
I was able to boot 184.108.40.206-18 but not able to boot later kernels; don't have
encryption as far as I know, but mount: error while loading shared libraries:
libblkid.so.1 is common.
I have managed to "workaround" my problem: set permissive in
/etc/sysconfig/selinux and "touch /.autorelabel" before making a new initrd and
reboot to the new kernel. One the first boot after, the system does a long
relabeling when it boots, logs a few warnings about denials with libblkid.so.1,
but keeps going, and it basically works from there, and I can set enforcing back
in /etc/sysconfig/selinux . A 2nd reboot to the new kernel is all clean and nice.
I was basically following the instructions for in
http://www.crypt.gen.nz/selinux/disable_selinux.html for *re*-enabling selinux.
It seems that what happened was that selinux wasn't really enabled/enforced
until a few kernel releases after f9, and it further wasn't helped by me
upgrading f8->f9 through yum.
Sorry, I meant that this kind of workaround probably should be mentioned in the
f9 release note (or f10), and definitely be in the yumupgradefaq.
Upgrades to F10 and F11 handle this correctly, I believe.