Bug 447067 - mkinitrd can't boot from encrypted LV
mkinitrd can't boot from encrypted LV
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: selinux-policy (Show other bugs)
9
All Linux
low Severity medium
: ---
: ---
Assigned To: Daniel Walsh
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-05-17 11:20 EDT by Michael Hampton
Modified: 2009-05-06 10:58 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-05-06 10:58:52 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Michael Hampton 2008-05-17 11:20:31 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.
Comment 1 Michael Hampton 2008-05-17 11:55:55 EDT
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 15:49:51 EDT
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-26 20:53:28 EDT
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-26 20:54:31 EDT
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 10:58:52 EDT
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.