[Bug 1551790] Re: mdadm-waitidle must run after umountroot

Stefan Bader stefan.bader at canonical.com
Tue Mar 1 15:09:45 UTC 2016


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

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to mdadm in Ubuntu.
https://bugs.launchpad.net/bugs/1551790

Title:
  mdadm-waitidle must run after umountroot

Status in mdadm package in Ubuntu:
  New

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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/mdadm/+bug/1551790/+subscriptions



More information about the foundations-bugs mailing list