Bug 519253

Summary:	booting fails with root on encrypted device on raid --- wrong device passed to cryptsetup
Product:	[Fedora] Fedora	Reporter:	Albert de Jongh <redhat-bugzilla>
Component:	mkinitrd	Assignee:	Peter Jones <pjones>
Status:	CLOSED WONTFIX	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	medium	Docs Contact:
Priority:	low
Version:	11	CC:	hdegoede, jonas, pjones, wtogami
Target Milestone:	---
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2010-01-12 15:31:39 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

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.