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): mkinitrd-6.0.52-2.fc9.x86_64 How reproducible: Always 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. Actual results: Red Hat nash version 6.0.52 starting Loading /lib/kbd/keymaps/i386/qwerty/us.map 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. Command successful. 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. Expected results: Normal system boot. Booting from the leftover Fedora 8 kernel/initramfs 2.6.24.4-64.fc8 built using mkinitrd 6.0.19 works fine. Additional info: 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 2.6.25.3-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.