Comment # 13 on bug 912170 from Robert Milasan

To see the order, you can always try to run: udevadm test <syspath device> and
you'll see the ordering of or reading of each rules.

I have no idea why it doesn't work. I haven't been involved too much with
btrfs, could it be the dracut initrd is not including all need it as its not a
root file system? Just putting some ideas on the table. Haven't read the hole
bug, so I might be way off.

Also note here: this shouldn't be used:

ENV{DM_NAME}=="" ....

Better to check if the disk/partition has the filesystem btrfs, something like:

ENV{ID_FS_TYPE}=="btrfs", IMPORT{builtin}="btrfs ready $devnode"

That should be all we need, don't get why the rule is written in the way.

This is how I see how the rule should look like:

--- 64-btrfs.rules.orig    2015-01-13 09:40:43.506199377 +0100
+++ 64-btrfs.rules    2015-01-13 09:41:30.038199073 +0100
@@ -2,12 +2,10 @@

 SUBSYSTEM!="block", GOTO="btrfs_end"
 ACTION=="remove", GOTO="btrfs_end"
-ENV{ID_FS_TYPE}!="btrfs", GOTO="btrfs_end"
 ENV{SYSTEMD_READY}=="0", GOTO="btrfs_end"

 # let the kernel know about this btrfs filesystem, and check if it is complete
-ENV{DM_NAME}=="", IMPORT{builtin}="btrfs ready $devnode"
-ENV{DM_NAME}=="?*", IMPORT{builtin}="btrfs ready /dev/mapper/$env{DM_NAME}"
+ENV{ID_FS_TYPE}=="btrfs", IMPORT{builtin}="btrfs ready $devnode"

 # mark the device as not ready to be used by the system
 ENV{ID_BTRFS_READY}=="0", ENV{SYSTEMD_READY}="0"