>
>
>
> Commands line options:
rd.debug rd.udev.debug systems.log_level=debug
That willl be incredibly verbose, and slows things down a lot, so in the
off chance there's a race, you might get different results. But if not, the
log should contain something useful.
I like the hypothesis about mdadm metadata version 0.9, however that's
still really common on RHEL and CentOS. It was used for /boot prior to
about Fedora around Fedora 24 maybe?
It could also be a dracut bug, since that's what's largely responsible for
assembly. But then it can be confused by a change in udev rules. :-D
However, going back to mdadm 0.9 metadata, that version should only be
kernel auto detected. Theoretically, it gets activated before dracut gets
involved. 1.x versions have no kernel autodetect, instead it happens in
dracut (by calling mdadm to assemble and run it).
Oh, is this really dm-cache, not lvmcache? That might be a source of
confusion, if there isn't lvm metadata present to hint at LVM for proper
assembly. Of course, lvmcache still uses device mapper, but with LVM
metadata.
Anyway is quite an interesting, and concerning problem.
Chris Murphy
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
https://lists.centos.org/mailman/listinfo/centos
