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 <[email protected]> _______________________________________________ luv-main mailing list [email protected] https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main
