[SOLVED] Btrfs file systems will not mount upon boot

OK, I’m breaking down and asking after researching…

I have 2 external HDDs, each with 3 partitions that I use only to back up data (no OS files).

Using parted, on one of the drives, I removed two partitions (“rm”) and created two new ones of type btrfs.

(parted) print free
Model: WD Elements 2620 (scsi)
Disk /dev/sdb: 1953481728kiB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:

Number  Start          End            Size          File system  Name     Flags
        17.0kiB        1024kiB        1007kiB       Free Space
1       1024kiB        943718400kiB   943717376kiB  ext4         disk2s1
2       943718400kiB   1495658496kiB  551940096kiB  btrfs        disk2s2
3       1495658496kiB  1953481711kiB  457823216kiB  btrfs        disk2s3

(parted)

I then used mkfs.btrfs to create the file systems (after exiting parted). Here is lsblk output:

NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS                                            PARTTYPE                             PARTLABEL            PARTUUID                             FSTYPE PARTTYPE
sda           8:0    0   1.8T  0 disk                                                                                                                                                              
|-sda1        8:1    0   900G  0 part /mnt/disk1s1                                           0fc63daf-8483-4772-8e79-3d69d8477de4 disk1s1              3186c702-fd4c-4386-b9e1-2ada6f2ab457 ext4   0fc63daf-8483-4772-8e79-3d69d8477de4
|-sda2        8:2    0 403.9G  0 part /mnt/disk1s2                                           0fc63daf-8483-4772-8e79-3d69d8477de4 disk1s2              bdac9c2f-0e86-4a50-824d-e5dc778efe58 ext4   0fc63daf-8483-4772-8e79-3d69d8477de4
`-sda3        8:3    0 404.2G  0 part /mnt/disk1s3                                           0fc63daf-8483-4772-8e79-3d69d8477de4 disk1s3              6c455fa6-ba46-4de6-aa4e-8c96ded02829 ext4   0fc63daf-8483-4772-8e79-3d69d8477de4
sdb           8:16   0   1.8T  0 disk                                                                                                                                                              
|-sdb1        8:17   0   900G  0 part /mnt/disk2s1                                           0fc63daf-8483-4772-8e79-3d69d8477de4 disk2s1              baaed8f5-307f-439a-9df6-1c6943b7a78e ext4   0fc63daf-8483-4772-8e79-3d69d8477de4
|-sdb2        8:18   0 526.4G  0 part /run/media/rhimbo/c58aa3fe-cb13-4276-b3c5-573313875b90 0fc63daf-8483-4772-8e79-3d69d8477de4 disk2s2              b1218a1b-34a0-43e8-83f8-46fb6dca647c btrfs  0fc63daf-8483-4772-8e79-3d69d8477de4
`-sdb3        8:19   0 436.6G  0 part                                                        0fc63daf-8483-4772-8e79-3d69d8477de4 disk2s3              7ba482f8-e0d8-463e-a008-c9090f9cdd0a btrfs  0fc63daf-8483-4772-8e79-3d69d8477de4
zram0       251:0    0     8G  0 disk [SWAP]                                                                                                                                                swap   
nvme0n1     259:0    0 931.5G  0 disk                                                                                                                                                              
|-nvme0n1p1 259:1    0   600M  0 part /boot/efi                                              c12a7328-f81f-11d2-ba4b-00a0c93ec93b EFI System Partition c28ce58b-3e2a-4a35-a872-1e4905900519 vfat   c12a7328-f81f-11d2-ba4b-00a0c93ec93b
|-nvme0n1p2 259:2    0     1G  0 part /boot                                                  bc13c2ff-59e6-4262-a352-b275fd6f7172                      031a718e-796b-4987-b6de-dc7e28e8c8f3 ext4   bc13c2ff-59e6-4262-a352-b275fd6f7172
`-nvme0n1p3 259:3    0 929.9G  0 part /home                                                  0fc63daf-8483-4772-8e79-3d69d8477de4                      2ad6e087-4fc8-4836-ba64-15e871be02b4 btrfs  0fc63daf-8483-4772-8e79-3d69d8477de4 

I then edited /etc/fstab to indicate the fs_file to be btrfs instead of ext4 (disk2s2 and disk2s3). Here is my /etc/fstab

fs_spec                                  fs_file      fs_vfstype  fs_mntops                    fs_freq  fs_passno

UUID=4a972d32-b4a0-418e-8f6d-f1aabcbe6b5f  /            btrfs       subvol=root,compress=zstd:1 0 0
UUID=0a70d693-9894-45d2-9668-122dffac9304  /boot        ext4        defaults                    1 2
UUID=EBC8-9DD9                             /boot/efi    vfat        umask=0077,shortname=winnt  0 2
UUID=4a972d32-b4a0-418e-8f6d-f1aabcbe6b5f  /home        btrfs       subvol=home,compress=zstd:1 0 0


LABEL=disk1s1        /mnt/disk1s1        ext4           auto,noexec,nosuid,nodev,nofail        0 0
LABEL=disk1s2        /mnt/disk1s2        ext4           defaults,nofail                        0 0
LABEL=disk1s3        /mnt/disk1s3        ext4           defaults,nofail                        0 0

LABEL=disk2s1        /mnt/disk2s1        ext4           auto,noexec,nosuid,nodev,nofail        0 0
LABEL=disk2s2        /mnt/disk2s2        btrfs          defaults,nofail                        0 0
LABEL=disk2s3        /mnt/disk2s3        btrfs          defaults,nofail                        0 0

Neither of the new btrfs file systems are being mounted upon boot. However, I can successfully mount them from the command line:
sudo mount /dev/sdb2 /mnt/disk2s2/

Strangely, this morning I rebooted my system to see what would get mounted. I can’t explain why btrfs file system on /dev/sdb2 got mounted under /run/media/rhimbo (see the lsblk output above). It didn’t get mounted at /mnt/disk2s2. And /dev/sdb3 didn’t get mounted at all.

Here is the “df” output:

Filesystem     1K-blocks      Used Available Use% Mounted on
/dev/nvme0n1p3 975097856 433589176 538782568  45% /
devtmpfs        14097028         0  14097028   0% /dev
tmpfs           14209908        96  14209812   1% /dev/shm
efivarfs             128        30        94  24% /sys/firmware/efi/efivars
tmpfs            5683964      2340   5681624   1% /run
none                1024         0      1024   0% /run/credentials/systemd-journald.service
none                1024         0      1024   0% /run/credentials/systemd-resolved.service
/dev/nvme0n1p3 975097856 433589176 538782568  45% /home
tmpfs           14209912         4  14209908   1% /tmp
/dev/nvme0n1p2    996780    614100    313868  67% /boot
/dev/nvme0n1p1    613184     20512    592672   4% /boot/efi
/dev/sdb1      927423800 238104616 642134904  28% /mnt/disk2s1
/dev/sda2      415700072 232289480 162220756  59% /mnt/disk1s2
/dev/sda3      416053328      2076 394843444   1% /mnt/disk1s3
/dev/sda1      927779112 236405104 644171756  27% /mnt/disk1s1
tmpfs            2841980       228   2841752   1% /run/user/1000
/dev/sdb2      551940096      6208 549825536   1% /run/media/rhimbo/c58aa3fe-cb13-4276-b3c5-573313875b90
$

I can’t figure out what the problem is. I’m thinking it is either that I don’t have the right flags or that the partition type UUID are wrong. The partition UUIDs are unique, so I don’t think that’s the problem.

I do see that the partition type (PARTTYPE) UUID is the same as for the ext4 file systems. Is this OK? I’ve been reading a lot of web pages, and it seems that there are predefined UUID values representing how the file system will be used (what type of data will be written to it) as opposed to the actual file system type. Here are two web pages I’ve been consulting:

https://en.wikipedia.org/wiki/Universally_unique_identifier

https://en.wikipedia.org/wiki/GUID_Partition_Table

Thanks for any help or suggestions…

Correct. An ext4 partition and a btrfs partition will have the same partition type UUID if they have the same purpose.

I wonder if these should be PARTLABEL (label set at the GPT partition table level) rather than LABEL (label set at the filesystem metadata level).

According to the parted documentation, the mklabel command writes a new partition table. For instance,
The “name” command creates (modifies) a name for a partition, and that name is reflected in the PARTLABEL column of the lsblk output.

I don’t believe that the partition table has a name.

(parted) print                                                            
Model: WD Elements 2620 (scsi)
Disk /dev/sdb: 2000GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags: 

Number  Start   End     Size   File system  Name     Flags
 1      1049kB  966GB   966GB  ext4         disk2s1
 2      966GB   1532GB  565GB  btrfs        disk2s2
 3      1532GB  2000GB  469GB  btrfs        disk2s3

(parted)                                                                  

According to the “mount” man page, one can specify both LABEL=label and PARTLABEL=label to identify a file system to mount. Also, one can specify a PARTUUID=uuid. So I can’t figure out why the LABEL in my /etc/fstab is now not working with the btrfs file systems; it works fine mounting the ext4 file systems automatically.

Is parted doing something different when it creates an ext4 filesystem vs a btrfs filesystem? I wonder whether it sets the filesystem’s LABEL for ext4, but not for btrfs.

What does lsblk -o NAME,FSTYPE,LABEL,PARTLABEL show?

Desktop environments may mount filesystems on /run/media. You can get details using journalctl. Use mount |grep ^/dev to see regular filesystem mounts, and journalctl —no-hostname -b -g mount to see all mount attempts. You can isolate errors by adding -p N. You may find it easier to focus on one mount at a time by putting a # in front of all but one of the problematic lines.

Here is the output:

$ lsblk -i -o NAME,FSTYPE,LABEL,PARTLABEL
NAME        FSTYPE LABEL   PARTLABEL
sda                        
|-sda1      ext4   disk1s1 disk1s1
|-sda2      ext4   disk1s2 disk1s2
`-sda3      ext4   disk1s3 disk1s3
sdb                        
|-sdb1      ext4   disk2s1 disk2s1
|-sdb2      btrfs          disk2s2
`-sdb3      btrfs          disk2s3
zram0       swap   zram0   
nvme0n1                    
|-nvme0n1p1 vfat           EFI System Partition
|-nvme0n1p2 ext4           
`-nvme0n1p3 btrfs  fedora  
$ 

Hmmm… and I just now see that there is no LABEL for the btrfs file systems in question…!
But why?! Isn’t this output from parted indicating that there are labels on these two partitions? Or, does the parted output indicate partition labels, not filesystem labels?!

I do not believe that I specified a file system label when I ran mkfs.btrfs. Perhaps I should rerun the command and recreate the btrfs file systems?

Note that those 2 partitions have a PARTLABEL but no LABEL.
If you were to mount using the UUID then the label confusion would be eliminated.

Yes, exactly that. It’s showing you what’s in the partition table (including the partition name aka PARTLABEL), but not the metadata from the filesystems themselves.

You should be able to set the label without recreating the filesystem - I think by sudo btrfs filesystem label /dev/sdb2 disk2s2 and the equivalent thing for the other partition. (Command documentation.)

OK…! Success…!

$ sudo mkfs.btrfs -f --label disk2s2 /dev/sdb2
$ sudo mkfs.btrfs -f --label disk2s3 /dev/sdb3
$ sudo systemctl daemon-reload 

Now I see those two file systems are mounted.
So I need to really read the btrfs command documentation as @pg-tips suggested. I did read through it but just missed the “–label” option.

Thank you to all of you…

Oh, OK. Well, I recreated the file system before I saw your message…! But I’ll remember this for next time. Thank you for the pointer.

Now that this is working, I am going to change the 2 partitions on the second external HDD to also use btrfs file system.
:grinning_face:

Thanks. I have some reading to do…

:grinning_face: