Bug 470027
| Summary: | Combination of encrypted and non-encrypted RAID devices not working | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 5 | Reporter: | Alexander Todorov <atodorov> |
| Component: | initscripts | Assignee: | initscripts Maintenance Team <initscripts-maint-list> |
| Status: | CLOSED ERRATA | QA Contact: | Alexander Todorov <atodorov> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 5.3 | CC: | borgan, harald, notting, syeghiay |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | ia64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2009-01-20 22:16:13 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: | |||
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" 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. The raid components have the same UUID as the RAID itself. I'm assuming your /etc/crypttab is specifying the encrypted devices by UUID? http://git.fedorahosted.org/git/?p=initscripts.git;a=commitdiff;h=dc6f9db8bdf6292ca303369d2f5bc2398fb2610f is the upstream HEAD commit that fixes this. It should apply to RHEL 5 with minimal fuss. To clarify - we should pull this in - it's going to affect any encrypted RAID0 installs. worked like a charm with snap #3. moving to verified 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. http://rhn.redhat.com/errata/RHBA-2009-0245.html |
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 5.1.19.6 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): initscripts-8.45.21-1 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. [FAILED] 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 /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> [FAILED] *** 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: