Bug#782865: systemd: ext4 filesystem on lvm on raid causes boot to enter emergency shell

[Michael Leuchtenburg]

I have this same result, with use_lvmetad=1 in lvm.conf. I think this
is a dupe of #774082.

I have an LVM PV on /dev/md0. I noticed that ID_FS_TYPE wasn't set on
it and that 69-lvm-metad.rules, which normally calls pvscan --cache on
devices, requires ID_FS_USAGE to be set to LVM2_member|LVM1_member in
order to proceed. This is normally set by 63-md-raid-arrays.rules, but
it does not do so on Debian due to a patch added by Michael Tokarev in
2013: https://anonscm.debian.org/cgit/pkg-mdadm/mdadm.git/commit/debian/patches/use-external-blkid.diff?id=4b8076c851018afdd46a93aff38fde8f0530efb5

If I modify the behavior to still use external blkid but not include
the '-u noraid' option (patch attached; needs to be modified to apply
to the package though), then it works fine. -u noraid otherwise
suppresses the output of any information related to LVM since I guess
that counts as a RAID to blkid.

I don't think this has a negative impact on any other rules since very
few things read the ID_FS_* keys, but it's possible the -u noraid was
set for some good reason. I assume that using the external blkid was
also done for a good reason, though unfortunately none is given in the
commit message - perhaps there was some relevant mailing list
discussion at the time. I'd be in favor of using the builtin blkid if
possible, though, as forking unneeded forks is pretty much always the
right decision.

Cheers,
Michael
-------------- next part --------------
A non-text attachment was scrubbed...
Name: allow-raid-from-blkid.patch
Type: text/x-patch
Size: 713 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-lvm-maintainers/attachments/20150731/506fa0e0/attachment.bin>