This bug is a known issue in Arch Linux, see here
There are also bug reports and discussion filed here and here
The bug appears to reside in systemd or mkinitcpio, as the ArchWiki suggests. Whichever process is responsible for disk discovery and identity allocation seems to get itself in a twist with BTRFS on multi-device volumes. Things were fine for me on RAID 1 before I upgraded to my current RAID 10 set up, so the problem may be more prevalent or pronounced on RAID10 deployments.
I followed the suggestion on the Wiki for a fix to no avail. Besides, why would adding 'btrfs' to the MODULES array rather than HOOKS work anyway? The 'udev' hook handles that stuff in place of the 'btrfs' hook, but nevermind.
After some experimentation I discovered that if you change the
/etc/fstab directive to mount a single device from the BTRFS array rather than using a group identifier like the examples shown below, the system would boot successfully.
LABEL=btrfs_root / btrfs etc.etc.etc.
UUID=fd047936-9253-421a-8d48-219612cb4915 / btrfs etc.etc.etc.
/dev/mapper/disk1-root / btrfs etc.etc.etc.
But, doesn't this mount only the one disk?...... NO! :) BTRFS is smart enough to discover and/or remember that the one disk is a member of an array. As a result, it mounts the entire pool along with the single device being called by
/etc/fstab at boot (see the two snippets at the end of this post for my particular deployment).
So long as the chosen disk survives, everything is fine. In theory I have a 25% chance of that particular disk failing and leaving me locked out and requiring a Live-CD style recovery. If one of the other three fails I should still be able to boot the array albeit in a degraded mode and replace the disk.
If this one particular disk does bite the dust - not a problem. It's not any more complication, really. The solution would be to:
- Boot into an Arch live memory stick
- Set the fstab and kernel parameters to degraded see here
- AND change the disk which is mounted at boot in /etc/fstab - in my case swap out /dev/mapper/disk1-root to /dev/mapper/disk2-root or disk3-root etc.
To close, yes there's a bug somewhere in mkinitcpio or systemd and yes it does add a complication to multi-disk builds which store the root partition on them. It's pretty minor though and hopefully the instructions here will help solve the problem and save people time.
/etc/fstab (last example is correct)
#UUID=fd047936-9253-421a-8d48-219612cb4915 / btrfs rw,relatime,space_cache,subvolid=5,subvol=/ 0 0
#LABEL=btrfs_root / btrfs rw,relatime,space_cache,subvolid=5,subvol=/ 0 0
/dev/mapper/disk1-root / btrfs rw,relatime,space_cache,subvolid=5,subvol=/ 0 0
My BTRFS Array - The other three devices are auto-mounted by BTRFS after disk1-root gets triggered by
root@nasbox ~]# btrfs fi show
Label: 'btrfs_root' uuid: fd047936-9253-421a-8d48-219612cb4915
Total devices 4 FS bytes used 768.09GiB
devid 1 size 831.51GiB used 385.03GiB path /dev/mapper/disk1-root
devid 2 size 831.51GiB used 385.03GiB path /dev/mapper/disk2-root
devid 3 size 831.51GiB used 385.03GiB path /dev/mapper/disk3-root
devid 4 size 831.51GiB used 385.03GiB path /dev/mapper/disk4-root