On Sun, Jan 19, 2020 at 04:48:30PM +1100, Andrew Greig wrote:
here is the output of blkid
/dev/sdb1: LABEL="Data" UUID="73f55e83-2038-4a0d-9c05-8f7e2e741517" UUID_SUB="77fdea4e-3157-45af-bba4-7db8eb04ff08" TYPE="btrfs" PARTUUID="d5d96658-01" /dev/sdc1: LABEL="Data" UUID="73f55e83-2038-4a0d-9c05-8f7e2e741517" UUID_SUB="8ad739f7-675e-4aeb-ab27-299b34f6ace5" TYPE="btrfs" PARTUUID="a1948e65-01"
I tried the first UUID for sdc1 and the machine hung but gave me an opportunity to edit the fstab and reboot.
That should work. Are you sure you typed or copy-pasted the UUID correctly? The fstab entry should look something like this: UUID="73f55e83-2038-4a0d-9c05-8f7e2e741517" /data btrfs defaults 0 0 edit /etc/fstab so that it looks like that and then (as root) run "mount /data". If that works manually on the command line, it will work when the machine reboots.
When checking the UUID I discovered that the first entry for both drives were identical.
yes, that's normal. they're both members of the same btrfs array.
Should I be using the SUB UUID for sdc1 for the entry in fstab?
No, you should use the UUID. Alternatively, you could use ONE of the PARTUUID values. e.g. one of: PARTUUID="d5d96658-01" /data btrfs defaults 0 0 PARTUUID="a1948e65-01" /data btrfs defaults 0 0 craig PS: I just tested several variations on this on my btrfs testing VM. UUID works. PARTUUID works. /etc/fstab does not support UUID_SUB (and it isn't mentioned in `man fstab`). -- craig sanders <cas@taz.net.au>