Bug 610878 - mdadm blocks on boot if initrams doesn't support latest superblock of a new encrypted md device
Summary: mdadm blocks on boot if initrams doesn't support latest superblock of a new e...
Alias: None
Product: Fedora
Classification: Fedora
Component: mdadm
Version: 13
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Doug Ledford
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2010-07-02 16:30 UTC by Kai Engert (:kaie) (inactive account)
Modified: 2010-07-20 16:28 UTC (History)
2 users (show)

Clone Of:
Last Closed: 2010-07-20 16:28:20 UTC

Attachments (Terms of Use)

Description Kai Engert (:kaie) (inactive account) 2010-07-02 16:30:55 UTC
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) (inactive account) 2010-07-02 16:32:42 UTC
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 16:28:20 UTC
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.