Bug 785737

Summary: update mdadm/mdmon to work with systemd unrolling mounts to initramfs mount on shutdown
Product: [Fedora] Fedora Reporter: Jes Sorensen <Jes.Sorensen>
Component: mdadmAssignee: Jes Sorensen <Jes.Sorensen>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 16CC: agajania, agk, awilliam, brian.broussard, bugzilla, dledford, fella, harald, Jes.Sorensen, johannbg, johannbg, lpoetter, mark.harfouche, mbroz, metherid, mschmidt, notting, pb, plautrba, robatino, rob, rtguille, shawn.p.huang, systemd-maint
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard: AcceptedNTH
Fixed In Version: mdadm-3.2.3-6.fc16 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 771405 Environment:
Last Closed: 2012-03-10 21:51:50 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:
Bug Depends On: 752593, 771405, 785739    
Bug Blocks: 752651    

Description Jes Sorensen 2012-01-30 13:53:47 UTC
+++ This bug was initially created as a clone of Bug #771405 +++

+++ This bug was initially created as a clone of Bug #752593 +++

 2011-11-14 09:24:28 EST ---

Intel BIOS RAID is the common pattern here.
The problem is that Intel RAID is partially implemented in userspace (mdmonitor) and we kill all userspace processes before umounting.
There's been a discussion about this on systemd-devel recently. The fix will be to stop doing the mdmon takeover on boot. Instead the mdmonitor running from initramfs will be kept alive all the time. On shutdown we won't kill it and umount/remount will succeed.

.com on 2011-11-16 12:17:18 EST ---

(In reply to comment #7)
> Intel BIOS RAID is the common pattern here.
> The problem is that Intel RAID is partially implemented in userspace
> (mdmonitor) and we kill all userspace processes before umounting.
> There's been a discussion about this on systemd-devel recently. The fix will be
> to stop doing the mdmon takeover on boot. Instead the mdmonitor running from
> initramfs will be kept alive all the time. On shutdown we won't kill it and
> umount/remount will succeed.

I'm sorry, but where is this conversation at?  And since the fix is to stop mdmon from doing a takeover, maybe it should have involved the mdadm/mdmon maintainers?

--- Additional comment from kay on 2011-11-16 16:08:36 EST ---

(In reply to comment #11)
> I'm sorry, but where is this conversation at?

  http://www.mail-archive.com/systemd-devel@lists.freedesktop.org/msg03659.html

--- Additional comment from dledford on 2011-11-16 16:57:57 EST ---

I'm not entirely convinced by that thread that all things will be OK with systemd, but we can try and see.

--- Additional comment from dledford on 2012-01-03 11:06:16 EST ---

We need to know what versions of systemd under f15/f16/rawhide implement the mentioned changes (unrolling to the initramfs environment) so we can update mdadm/mdmon to match and include an appropriate Requires: systemd >= for each release to make sure compatibility is maintained.


-----------------------------------------------------------------------------

Needed actions for mdadm/mdmon:

1) Redefine mdmon directory so that it stores its pid file on storage that will remain even after the unroll to initramfs environment is complete (/run/mdadm is likely the right place)
2) Make sure that any SysV init script snippets or systemd service files that would restart mdmon via a takeover are no longer included in the package
3) Optionally, disable takeover operations in the mdmon binary itself just as a safety measure to avoid takeovers from the command line.

Comment 1 Jóhann B. Guðmundsson 2012-02-15 20:54:24 UTC
Proposing this as an NTH for alpha now that dracut has landed the --offroot bits 

Jes you should send testing request with direction to the -test list so reporters with Intel Bios Raid are aware of this fix and could test this.

Comment 2 Jóhann B. Guðmundsson 2012-02-15 21:03:00 UTC
Dennis http://koji.fedoraproject.org/koji/buildinfo?buildID=299771 ( latest dracut ) needs to be pulled on to the spin alpha spin for this.

Comment 3 Adam Williamson 2012-02-15 21:19:43 UTC
I'm +1 nth for this, given the impact on shutdown on systems with intel BIOS raid.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 4 Adam Williamson 2012-02-15 21:42:04 UTC
dgilmore voted +1 nth on IRC.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 5 Adam Williamson 2012-02-15 21:43:44 UTC
Marking as accepted NTH with the votes so far.

Comment 6 Fedora Update System 2012-02-16 15:07:39 UTC
mdadm-3.2.3-5.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/mdadm-3.2.3-5.fc16

Comment 7 Fedora Update System 2012-02-17 00:56:11 UTC
Package mdadm-3.2.3-5.fc16:
* should fix your issue,
* was pushed to the Fedora 16 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing mdadm-3.2.3-5.fc16'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-1862/mdadm-3.2.3-5.fc16
then log in and leave karma (feedback).

Comment 9 Fedora Update System 2012-02-23 11:09:33 UTC
mdadm-3.2.3-6.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/mdadm-3.2.3-6.fc16

Comment 10 Fedora Update System 2012-03-10 21:51:50 UTC
mdadm-3.2.3-6.fc16 has been pushed to the Fedora 16 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 11 Mark Harfouche 2012-12-13 19:05:54 UTC
Fedora 17 x64

mdadm v3.2.6
dracut version 18-105.git20120927.fc17

Still hangs on shutdown.....

This is a new problem (last month of so) because I was rebooting my computer like crazy during the install