Bug 519253 - booting fails with root on encrypted device on raid --- wrong device passed to cryptsetup
Summary: booting fails with root on encrypted device on raid --- wrong device passed t...
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: mkinitrd
Version: 11
Hardware: x86_64
OS: Linux
low
medium
Target Milestone: ---
Assignee: Peter Jones
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-08-25 20:30 UTC by Albert de Jongh
Modified: 2010-01-12 15:31 UTC (History)
4 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2010-01-12 15:31:39 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Albert de Jongh 2009-08-25 20:30:49 UTC
Raid device /dev/md1 is composed of two block devices /dev/sda2 & /dev/sdb2
(The raid was created with --metadata=1, so the RAID superblock is version 1)
On this raid device /dev/md1 I then create an encrypted device with LUKS
(cryptsetup luksFormat /dev/md1 etc.).  My root filesystem is then created on this encrypted device (/dev/mapper/something).

If I look at the output of "blkid" the UUIDs of sda2, sdb2 and md1 is the same.

Now - mkinitrd creates an "init" script with stuff in it like:
mdadm -As --auto=yes --run /dev/md1
mdadm -As --auto=yes --run /dev/md2
setDeviceEnv LUKSUUID UUID=a30ba93c-2926-4393-80d1-33502caf30fb
echo Setting up disk encryption: $LUKSUUID
buildEnv LUKSUUID cryptsetup luksOpen $LUKSUUID luks-a30ba93c-2926-4393-80d1-33502caf30fb
plymouth --prompt $LUKSUUID ask-for-password --command $LUKSUUID

The problem is - the environment variable LUKSUUID passed to cryptsetup is set to /dev/sda2, and not /dev/md1 (I checked by adding some "plymouth message" statements).

There is this "nashGetPathBySpec" in method "resolveDeviceCommand" that I am assuming is doing the environment setup - is this correct?

I see "blkid" has this "-l" argument that prioritizes which devices are foiund for a particular UUID - does this work the same?


Version-Release number of selected component (if applicable):
Name        : mkinitrd                     Relocations: (not relocatable)
Version     : 6.0.87                            Vendor: Fedora Project
Release     : 3.fc11                        Build Date: Mon 27 Jul 2009 05:19:39 PM SAST
Install Date: Fri 21 Aug 2009 08:21:14 AM SAST      Build Host: x86-3.fedora.phx.redhat.com
Group       : System Environment/Base       Source RPM: mkinitrd-6.0.87-3.fc11.src.rpm
Size        : 83466                            License: GPLv2+
Signature   : RSA/8, Tue 28 Jul 2009 12:44:02 PM SAST, Key ID 1dc5c758d22e77f2
Packager    : Fedora Project
URL         : git://git.fedoraproject.org/git/hosted/mkinitrd

Comment 1 Albert de Jongh 2009-08-25 20:50:33 UTC
I eventually got my system to boot by using the rescue CD, and accessing the /boot and / partitions manually.  Then I edited:
 . made sure mdadm.conf used /dev/md? devices (others don't work well)
 . changed crypttab to use the /dev/md? devices INSTEAD of UUIDs
 . changed fstab to use the correct crypto (/dev/mapper/xxx) and md devices

I then extracted the initrd image that was built during the F11 install, copied in the above mdadm.conf file to the ramdisk /etc directory, and also edited the 'init' script to use /dev/md? devices to pass to cryptsetup.  This then allows you to boot the machine.

Creating a new initrd after that then uses the /dev/md? devices as defined in crypttab, and hopefully no more editing the initrd everytime a kernel upgrade is installed.

Comment 2 Hans de Goede 2010-01-12 15:31:39 UTC
This is a mass edit of all mkinitrd bugs.

Thanks for taking the time to file this bug report (and/or commenting on it).

As you may have heard in Fedora 12 mkinitrd has been replaced by dracut. In Fedora 12 the mkinitrd package is still around as some programs depend on
certain libraries it provides, but mkinitrd itself is no longer used.

In Fedora 13 mkinitrd will be removed completely. This means that all work
on initrd has stopped.

Rather then keeping mkinitrd bugs open and giving false hope they might get fixed we are mass closing them, so as to clearly communicate that no more work will be done on mkinitrd. We apologize for any inconvenience this may cause. 

If you are using Fedora 11 and are experiencing a mkinitrd bug you cannot work around, please upgrade to Fedora 12. If you experience problems with the initrd in Fedora 12, please file a bug against dracut.


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