Bug 610878

Summary:	mdadm blocks on boot if initrams doesn't support latest superblock of a new encrypted md device
Product:	[Fedora] Fedora	Reporter:	Kai Engert (:kaie) (inactive account) <kengert>
Component:	mdadm	Assignee:	Doug Ledford <dledford>
Status:	CLOSED NOTABUG	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	high	Docs Contact:
Priority:	low
Version:	13	CC:	dledford, harald
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2010-07-20 16:28:20 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 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.