Bug 610878 - mdadm blocks on boot if initrams doesn't support latest superblock of a new encrypted md device
mdadm blocks on boot if initrams doesn't support latest superblock of a new e...
Product: Fedora
Classification: Fedora
Component: mdadm (Show other bugs)
All Linux
low Severity high
: ---
: ---
Assigned To: Doug Ledford
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2010-07-02 12:30 EDT by Kai Engert (:kaie)
Modified: 2010-07-20 12:28 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2010-07-20 12:28:20 EDT
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 Kai Engert (:kaie) 2010-07-02 12:30:55 EDT
Description of problem:
mdadm blocks on boot when missing the mirror of an encrypted raid 1 array, and initramfs/dracut wasn't able to bring the md device up.

Version-Release number of selected component (if applicable):
Fedora 13, as of July 02.

How reproducible:
- machine has multiple md devices
- one of the md devices gets deleted and recreated 
  for maintenance/data move purposes
- new md partition formatted with luks encryption, inside ext4
- /etc/mdadm.conf updated manually to contain the new UUID
- all old md devices had an old style superblock
  (no superblock version number in /proc/mdstat)
- the new md device reports "super 1.2"
- /etc/crypttab contains an entry for the device 
  name /dev/md0 none
  (as before)
- /etc/fstab contains an entry to mount it
  (as before)

- keeping the old kernel and initramfs, I can boot up just fine,
  I get prompted for password and it gets mounted
- shutdown 
- remove mirror drive
- boot
- dracut unable to bring up md0
- prompt shown "enter password for /home"
- computer is blocked. pressing keys or enter => nothing happens on screen

Actual results:
- boot process blocks with missing mirror device

Expected results:
- mdadm should report some failure and not block

Additional info:
Thanks to Harald for helping me diagnose the problem.
I'll attach both old and new mdadm.conf
Comment 1 Kai Engert (:kaie) 2010-07-02 12:32:42 EDT
I'm not sure if you need to see the actual mdadm.conf

The only difference is, the /dev/md0 configuration line was changed to have a new UUID.
Comment 2 Doug Ledford 2010-07-20 12:28:20 EDT
There are additional steps necessary to do what you want.  Specifically, the device uuid for the root array is specified on the grub boot line as a boot parameter.  So not only do you need to update the mdadm.conf file with the new uuid, you also need to modify /etc/grub.conf to reflect the new uuid so that dracut will look for it.  If you don't, then what's happening is when you boot with the old drive removed, the old uuid specified on the grub boot command is simply not present and so no device is started.  The reason mdadm doesn't issue an error is that mdadm is never invoked.  Dracut scans for the old uuid, doesn't find it, never invokes mdadm, and then says it can't find the boot device and sleeps forever.  Simply updating the grub.conf file should solve your problem.  If it doesn't, then reopen the bug.

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