Do you actually suffer from this? Adding the modprobe call is a hack, and I have a suspicion that its a bug in kmod. I'm happy to provide a patched kmod for you to test if you can actually reproduce the failure...

i was indeed able to reproduce the problem, as i indicated in the thread. i was not affected by it because i have stuff running in initramfs that pretty much guarantees the btrfs module will be loaded long before anything tries to access /dev/btrfs-control, and since btrfs is my /(root) it's automatically included by mkinitcpio (also i'm not using a btrfs-RAID setup, which is required to reproduce).

contrarily, this user was only using btrfs for ancillary reasons, not as the primary /(root).

i would be happy to test a patched kmod if you believe that is the cause -- reproduction was something like:

modprobe -r btrfs
truncate -s1G btrfs.disk.{0,1}
mkfs.btrfs btrfs.disk.{0,1}
losetup -f btrfs.disk.0
losetup -f btrfs.disk.1
btrfs scan btrfs.disk.{0,1}
^^^^ previously failed ... neither `losetup` or `btrfs` were triggering a modprobe
mount /dev/loop1 /mnt
^^^^ bad superblock/etc/etc

... there's been 1-2 kernel point releases since then and im not sure about kmod updates, but no, in my brief test i cannot reproduce [anymore].

> i was indeed able to reproduce the problem

> i was not affected by it

Either you can reproduce it AND it affects you, or you can't reproduce it, and it doesn't affect you. Pick _one_. This isn't a kernel issue.

well i don't give a @#$% about it then, so do what you will.

http://thread.gmane.org/gmane.linux.kernel/1358707/focus=1358709 relevant kernel fix.

This rulefile will go away soon as a replacement will be provided by systemd-190. Hopefully we'll also see the kernel fix soon :)

Could anyone verify if this is still a problem with linux-3.6 (currently in testing) and the most recent systemd?