Ubuntu
mdadm package

mdadm-waitidle must run after umountroot

Bug #1551790 reported by Stefan Bader on 2016-03-01

This bug affects 2 people

Affects		Status	Importance	Assigned to	Milestone
	mdadm (Ubuntu)	Confirmed	Medium	Unassigned
Nominated for Trusty by Stefan Bader

Bug Description

In Trusty/14.04 I noticed the problem that a Intel fakeraid (IMSM) which changed to be managed by mdadm would start as dirty whenever anything on that fakeraid was in use (mounted) before. I got /home on it. There are other bug reports about similar symptoms but then not matching the issue completely.

I found that at least for the problem I experience, the reason is the way sysvinit scripts get installed. Looking at /etc/rc0.d for example:

K25mdadm
...
K98mdadm-waitidle
...
S40umountfs
S60umountroot
S90halt

So while mdadm uses the correct (I believe) form of dh_installinit (stop 98 0 6) it ends up being called before umountfs even (verified by adding debug output to the scripts). From the LSB info header it is clear that mdadm-waitidle should be run after umountroot. Which is how things look in Wily/15.10 (where the ordering is started to be done based on the LSB info):

K01mdadm
...
K06umountfs
K07umountroot
K08mdadm-waitidle
K09halt

So I tried what would happen if I just made mdadm-waitidle a "start 70 0 6". Luckily doing so the script still gets run with the stop action on reboot and shutdown. So I would propose the attached change for Trusty. Precise is not affected as there is no waitidle script. And Wily onwards the file ordering is automatically done based on the LSB header, so those are fine as well.

Tags:

Revision history for this message

Stefan Bader (smb) wrote on 2016-03-01:

proposed.debdiff Edit (1.9 KiB, text/plain)

Not sure the check and removal in the postinst is the correct method, but at least something like that was necessary to move the rc[06].d links when upgrading the package.

Revision history for this message

Stefan Bader (smb) wrote on 2016-03-01:

Oops, noticed (of course after attaching it) that I forgot to update the bug number in the comment of the rules file.

Ubuntu Foundations Team Bug Bot (crichton) on 2016-03-01

tags:

added: patch

Brian Murray (brian-murray) on 2016-03-02

tags:

added: trusty

Revision history for this message

Shannon Barber (sgbarber) wrote on 2016-03-23:

I have this problem as well but my colleague does not.
I use Intel fake-raid and he uses pure Linux soft-raid.
I don't know why he doesn't have the problem - looking at the scripts in rc6 everyone using raid >1 should be experiencing this bug regardless of fake vs soft.

I think a work-around is to add a ln -s ../init.d/mdadm S50mdadm link under rc6.d
This should make '../init.d/mdadm stop' run after S40umountfs
It is my understanding that everything in rc6 is passed 'stop' and the K's & S's are ignored for this runlevel *except* the alphabetical ordering still matters (which is why it has to be S50 not K50 to run after the unmount.)

Revision history for this message

Launchpad Janitor (janitor) wrote on 2016-03-23:

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in mdadm (Ubuntu):
status:	New → Confirmed

Revision history for this message

Stefan Bader (smb) wrote on 2016-03-24:

Somehow I would suspect that Intel fake-raid is more affected than pure soft-raid because of the additional complexity. For Intel fake-raid there is always an additional container defined which sort-of groups the defined raid disks. So in my case for example there is a md126 and a md127. That could make it more likely that status updates take a little longer to propagate.
To use S50 would move execution after umountfs and for me personally that would be enough. But comparing to newer releases it should run even after umountroot (which is why I used S70). It sounds sensible as in theory one could also have / on a fake-raid.