Bug 470027 - Combination of encrypted and non-encrypted RAID devices not working
Combination of encrypted and non-encrypted RAID devices not working
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: initscripts (Show other bugs)
ia64 Linux
medium Severity medium
: rc
: ---
Assigned To: initscripts Maintenance Team
Alexander Todorov
Depends On:
  Show dependency treegraph
Reported: 2008-11-05 06:18 EST by Alexander Todorov
Modified: 2009-01-20 17:16 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-01-20 17:16:13 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Alexander Todorov 2008-11-05 06:18:44 EST
Description of problem:
/dev/md0 /    not encrypted
/dev/md1 /usr encrypted

Initial system boot fails and forces the user to type root password for maintenance:

Kernel command line: BOOT_IMAGE=scsi0:EFI\redhat\vmlinuz-2.6.18-121.el5 root=/dev/md0  rhgb quiet ro
Red Hat nash version starting
                Welcome to Red Hat Enterprise Linux Server
                Press 'I' to enter interactive startup.
Setting clock  (utc): Wed Nov  5 06:03:45 EST 2008 [  OK  ]
Starting udev: [  OK  ]
Loading default keymap (us): [  OK  ]
Setting hostname localhost.localdomain:  [  OK  ]
Starting disk encryption:
Enter LUKS passphrase: 
Failed to setup dm-crypt key mapping.
Check kernel for support for the aes-cbc-essiv:sha256 cipher spec and verify that /dev/sda2 contains at least 133 sectors.
Failed to read from key storage

Version-Release number of selected component (if applicable):

How reproducible:
Always on one particular machine

Steps to Reproduce:
1.Do an install with this disk layout:
/dev/sda1 vfat /boot/efi
/dev/sda2 software raid
/dev/sda3 software raid

/dev/sdb1 software raid
/dev/sdb2 software raid

/dev/md0, RAID0 (sda3, sdb2) /, ext3, plain
/dev/md1, RAID0 (sda2, sdb1) /usr, ext3, encrypted

sda2 and sdb1 are 5000MB, others are the rest of disk.

2. After reboot type the LUKS pass phrase

Actual results:
After several times trying to enter the pass phrase and the system not unlocking the RAID device it asks for maintenance:

Enter LUKS passphrase: 
Failed to setup dm-crypt key mapping.
Check kernel for support for the aes-cbc-essiv:sha256 cipher spec and verify that /dev/sda2 contains at least 133 sectors.
Failed to read from key storage
Command failed: No key available with this passphrase.

Checking filesystems
Checking all file systems.
[/sbin/fsck.ext3 (1) -- /] fsck.ext3 -a /dev/md0 
/dev/md0: clean, 5066/69107712 files, 2331626/69101696 blocks
[/sbin/fsck.ext3 (1) -- /usr] fsck.ext3 -a /dev/mapper/luks-ac9dfd74-583d-4cb4-ba73-7770ca42f153 
fsck.ext3: No such file or directory while trying to open /dev/mapper/luks-ac9dfd74-583d-4cb4-ba73-7770ca42f153
The superblock could not be read or does not describe a correct ext2
filesystem.  If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193 <device>


*** An error occurred during the file system check.
*** Dropping you to a shell; the system will reboot
*** when you leave the shell.
*** Warning -- SELinux is active
*** Disabling security enforcement for system recovery.
*** Run 'setenforce 1' to reenable.
Give root password for maintenance
(or type Control-D to continue):

Expected results:
System will unlock /dev/md1 and boot 

Additional info:
Comment 1 Alexander Todorov 2008-11-05 06:53:46 EST
running rescue mode on this system:

sh-3.2# blkid
/dev/mapper/luks-ac9dfd74-583d-4cb4-ba73-7770ca42f153: UUID="b096fb23-b971-4738-9dda-269df103c069" TYPE="ext3" 
/dev/sda1: SEC_TYPE="msdos" LABEL="/boot/efi" UUID="4911-72CC" TYPE="vfat" 
/dev/sda2: UUID="ac9dfd74-583d-4cb4-ba73-7770ca42f153" TYPE="crypt_LUKS" 
/dev/sda3: UUID="f5fa951e-67f7-4b1e-915c-df02d5bf6378" TYPE="ext3" 
/dev/md1: UUID="ac9dfd74-583d-4cb4-ba73-7770ca42f153" TYPE="crypt_LUKS" 
/dev/md0: UUID="f5fa951e-67f7-4b1e-915c-df02d5bf6378" TYPE="ext3"
Comment 2 Alexander Todorov 2008-11-05 10:15:23 EST
A note I missed: 
the initial initrd.img didn't appear to have dm-crypt module included. Running mkinitrd --with=dm-crypt didn't fix the issue for me.
Comment 3 Bill Nottingham 2008-11-05 10:16:25 EST
The raid components have the same UUID as the RAID itself. I'm assuming your /etc/crypttab is specifying the encrypted devices by UUID?
Comment 4 Bill Nottingham 2008-11-05 11:07:36 EST

is the upstream HEAD commit that fixes this. It should apply to RHEL 5 with minimal fuss.
Comment 5 Bill Nottingham 2008-11-06 11:27:08 EST
To clarify - we should pull this in - it's going to affect any encrypted RAID0 installs.
Comment 8 Alexander Todorov 2008-11-14 05:08:04 EST
worked like a charm with snap #3. moving to verified
Comment 10 errata-xmlrpc 2009-01-20 17:16:13 EST
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.


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