On Sun, Jan 31 2016, Phil Turmel wrote: > Hi Björn, > > On 01/30/2016 07:21 AM, Björn Augustsson wrote: > >> The question is, what kind of state am in now? > > The kernel is waiting for mdmon (mdadm as a background task) to step > through the stripes. mdmon died and the kernel will wait forever. Close, not quite. 'mdmon' is a background task that mdadm *only* uses for externally managed metadata: IMSM and DDF. For a reshape like this mdadm needs a background "mdadm" task. It used to just fork, but in these enlightened days it asks systemd to run that task. As has already been observed, that failed due to selinux not understanding. So it was an 'mdadm' which exited, rather than an mdmon which died... Maybe you already worked that out. The days of backup files should be numbered. New kernels and new mdadm adjust the data-offset so no back is needed. In that case, no background mdadm is needed either. NeilBrown > >> And how should I recover? >> Will just adding a policy to allow access to that file, and then >> mdadm --grow --continue /dev/md127 >> fix it? > > Probably. Others have fixed this by disabling selinux for the reshape. > Don't forget to specify --backup-file again on the command line. (I > don't use selinux myself, so I can't be more specific.) > > In the future, consider not using a backup file at all -- mdadm > generally leaves enough dead space on devices to avoid the need. > >> Is the broken backup file going to be a problem? > > Shouldn't be. Report back if it is. > > Phil > -- > To unsubscribe from this list: send the line "unsubscribe linux-raid" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html
Attachment:
signature.asc
Description: PGP signature
