Bug 447067 - mkinitrd can't boot from encrypted LV
Summary: mkinitrd can't boot from encrypted LV
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy
Version: 9
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Daniel Walsh
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-05-17 15:20 UTC by Michael Hampton
Modified: 2009-05-06 14:58 UTC (History)
6 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2009-05-06 14:58:52 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Michael Hampton 2008-05-17 15:20:31 UTC
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.

Comment 1 Michael Hampton 2008-05-17 15:55:55 UTC
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.

Comment 2 Hin-Tak Leung 2008-06-14 19:49:51 UTC
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.

Comment 3 Hin-Tak Leung 2008-06-27 00:53:28 UTC
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.



Comment 4 Hin-Tak Leung 2008-06-27 00:54:31 UTC
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.

Comment 5 Daniel Walsh 2009-05-06 14:58:52 UTC
Upgrades to F10 and F11 handle this correctly, I believe.


Note You need to log in before you can comment on or make changes to this bug.