On Aug 5, 2012 6:04 AM, "C Anthony Risinger" <anthony@xtfx.me> wrote:
On Sat, Aug 4, 2012 at 7:53 AM, Jackson Alley <toomanymirrors@gmail.com>
wrote:
I've rebooted and confirmed the udev rule I found does not resolve the issue. I don't believe the problem lies with mkinitcpio as I'm not using a root btrfs system but rather in the init scripts (
https://projects.archlinux.org/initscripts.git/commit/?id=13ca7f028ac775773a... ).
I've attached the boot log and dmesg output. dmesg: http://pastebin.com/PxfnYgAm boot log: http://pastebin.com/Pg9xY4u5
yeah i didn't think mkinitcpio was involved but you said it was throwing an error about a missing btrfs hook, even though you have no hook defined ... so i asked.
AFIAK the FS module is not loaded automatically until mount time -- dmesg shows the module being loaded at that time, not when scanned. dracut loads the module just prior to calling `device scan`:
http://git.kernel.org/?p=boot/dracut/dracut.git;a=blob;f=modules.d/90btrfs/8...
... and since scanning requires /dev/btrfs-control, which is not created until the btrfs module is loaded, the module MUST be loaded to properly register the device. i was able to confirm that `btrfs device scan` DOES NOT automatically load the required `btrfs` module.
your dmesg shows required devices loading at this time:
[ 4.058562] sd 9:0:0:0: [sde] 976773168 512-byte logical blocks: (500 GB/465 GiB)
... but the module is not loaded until after all devices fire:
[ 4.171028] Btrfs loaded
... therefore probably nothing was registered, and thus a few seconds later you see:
[ 6.081051] btrfs: failed to read the system array on sde1
... try this (tested for one device, unverified for more):
# cat /usr/lib/udev/rules.d/70-btrfs.rules ACTION!="remove", SUBSYSTEM=="block", ENV{ID_FS_TYPE}=="btrfs", RUN+="/sbin/modprobe btrfs", RUN+="/usr/bin/btrfs device scan $env{DEVNAME}"
This makes a lot of sense. Please verify. Tom