Beginner's guide to BTRFS

[Thomas00]

I see you got “subvol=@“ and @home options in your fstab. You first mount the actual drive to @ and then further down, not show in your fstab screenshot, you map @ to /mnt, correct?
I’ll try that tomorrow...

[GreyGeek]

I see you got “subvol=@“ and @home options in your fstab. You first mount the actual drive to @ and then further down, not show in your fstab screenshot, you map @ to /mnt, correct?
I’ll try that tomorrow...

Yes, but I didn't write that. The Kubuntu Bionic install wrote it when I installed it.

[Thomas00]

Really strange. Well, I added the subvol tag to fstab and ran the below after a reboot. No change.

thomas@homeserver:~$ cat /etc/fstab         
UUID=9c3b40b6-c716-11e8-a25e-bcaec52979b7       /               btrfs defaults,ssd,autodefrag,noatime,subvol=@ 0 0
UUID=aa3dceed-ea65-4e14-87c8-ad93810e556c       /media/data/    btrfs   defaults,autodefrag 0 0  
UUID=e8ec2376-3087-42e4-a73d-26983ff37bbc       /media/backup   btrfs   noauto  0       0
UUID=f6a03583-3a40-404f-897e-320de7e33746       none            swap sw 0 0 
thomas@homeserver:~$ sudo mount -t btrfs /dev/disk/by-uuid/9c3b40b6-c716-11e8-a25e-bcaec52979b7 /mnt
thomas@homeserver:~$ ll /mnt
total 48
drwxr-xr-x 1 root   root    224 Oct  3 14:16 ./
drwxr-xr-x 1 root   root    224 Oct  3 14:16 ../
drwxr-xr-x 1 root   root   2430 Oct  3 14:38 bin/
drwxr-xr-x 1 root   root    620 Oct  3 14:39 boot/
...

thomas@homeserver:~$ sudo umount /dev/disk/by-uuid/9c3b40b6-c716-11e8-a25e-bcaec52979b7
thomas@homeserver:~$ sudo btrfs subvolume show /
/
     Name:                   <FS_TREE>
     UUID:                   -
     Parent UUID:            -
     Received UUID:          -
     Creation time:          -
     Subvolume ID:           5
     Generation:             3565
     Gen at creation:        0
     Parent ID:              0
     Top level ID:           0
     Flags:                  -
     Snapshot(s):
thomas@homeserver:~$ sudo btrfs subvolume show /home
ERROR: not a subvolume: /home
ERROR: Failed to get subvol info /home: 1
thomas@homeserver:~$

And as far as installation was concerned I didn't do anything special. Had to choose manual disk setup because I wanted to change to btrfs, one partition for / and /home with some spare space left for swap which I set up manually afterwards, and that was it. No other special bits whatsoever...

[oshunluvr]

Back to basics: the "@" is just used to help differentiate a subvolume from a regular folder. It's not a "rule" just a mnemonic device.

Subvolumes are like folders in a file cabinet. The btrfs file system is the drawer and the subvolumes are the folders. If one folder needs more space the other just move down the drawer and make room.

So to identify subvolumes, do what GG says and use the subvolume list command.One thing I think GG may have wrong is you may not have any subvolumes at all, which normally the *buntu installers use - so I don't know what happened. It appears that the installation went to the root BTRFS volume instead of into subvolumes. Subvolumes are important because without then you cannot use the snapshot or backup (send|receive) features of btrfs.

[oshunluvr]

And as far as installation was concerned I didn't do anything special. Had to choose manual disk setup because I wanted to change to btrfs, one partition for / and /home with some spare space left for swap which I set up manually afterwards, and that was it. No other special bits whatsoever...

Here's your problem. When installing to btrfs using manual partitioning, the way to do it is to set only the location for / and then the installer will automatically create the subvolumes. When using BTRFS you do not want or need separate partitions for / and /home as this defeats half or more of the reasons to use btrfs in the first place. A "Proper" BTRFS partitioning scheme is to have a swap partition, whatever partition(s) you need to boot (efi or whatever), and a single btrfs partition.

If you don't have a lot of time invested in this install, I would wipe the partitions, re-partition putting the separate btrfs partitions together, then re-install to just the sole btrfs partition and indicate only "/" when manually setting the installation target. Then you will get @ for / and @home for /home

[Thomas00]

Here's your problem. When installing to btrfs using manual partitioning, the way to do it is to set only the location for / and then the installer will automatically create the subvolumes. When using BTRFS you do not want or need separate partitions for / and /home as this defeats half or more of the reasons to use btrfs in the first place. A "Proper" BTRFS partitioning scheme is to have a swap partition, whatever partition(s) you need to boot (efi or whatever), and a single btrfs partition.

If you don't have a lot of time invested in this install, I would wipe the partitions, re-partition putting the separate btrfs partitions together, then re-install to just the sole btrfs partition and indicate only "/" when manually setting the installation target. Then you will get @ for / and @home for /home

Sorry, I wasn't precise in how I wrote this, what you are proposing is exactly what I did. Both / and /home are on the same partition.
The boot drive has got 3 partitions:
One for the boot loader (sda1), one for the OS (/ and /home) and a third one for swap:

thomas@homeserver:~$ blkid | grep sda
/dev/sda2: LABEL="OS" UUID="9c3b40b6-c716-11e8-a25e-bcaec52979b7" UUID_SUB="9de1419d-bce2-4df0-881a-18b321c698ed" TYPE="btrfs" PARTUUID="73f89684-7bb9-4719-aca5-235a51b8dd2c"
/dev/sda3: UUID="f6a03583-3a40-404f-897e-320de7e33746" TYPE="swap" PARTUUID="03c0c5de-c4ef-4642-bdd2-9a9715bb1880"

btrfs subvolume list comes back with nothing :-(

thomas@homeserver:~$ sudo btrfs subvolume list /
thomas@homeserver:~$

Maybe I just manually create a @ and @home subvolume, move things and see what happens?

As far as a fresh install is concerned, I spent all day yesterday to get the server and services installed, not sure if I go through the effort of a fresh install again or just leave things as they are, nothing won but also not more time wasted. This was supposed to be a quick "btrfs-convert and be done" type project...

[GreyGeek]

oshunluver stated the same conclusion that I had come to. In a correct install of btrfs there is NO need to edit /etc/fstab unless you want to create OTHER subvolumes on the <ROOT_FS> and mount them at boot, as I demoed with @Data in a post above.

My recommendation is to stop wasting any more time on this, clear your partitions as oshunluver says, and install Kubuntu Bionic with btrfs in the correct way.

[Thomas00]

Agree, something went wrong, what it is I don’t know as it looks like what I did was exactly what you guys recommend. I may try the same thing again and hope for a different outcome...although this time round the partisions will all be there already...

[SpecialEd]

...although this time round the partisions will all be there already...

You may be missing the point. Let the install create the partitions.

[GreyGeek]

You may be missing the point. Let the install create the partitions.

Exactly.
If you already have a swap partition then let it alone. For the rest of your free space combine it into ONE partition and assign it to btrfs with a label of "/". Don't do any other fancy stuff. That's what is messing you up. Let the INSTALLER create @ and @home for you.

[oshunluvr]

I do manual partitioning all the time and it works fine, just don't set and mount points except / and it should work fine.

BTW, if you already have a single BTRFS partition, there's no need to re-partition and format. Simply install again, this time point the installer at your existing BTRFS partition and do not check format - just set the mount point as /

It will install into the BTRFS partition without wiping your current install and you should be able to boot to both installs - your current and the new one. Then, you can transition from to new install - transfer settings or docs, whatever - and when ready just delete the files from the old install leaving @ and @home intact.

OBVIOUSLY, make a backup of any data you don't want to lose in case something goes sideways again.

[Thomas00]

OBVIOUSLY, make a backup of any data you don't want to lose in case something goes sideways again.

I like that
There's a single BTRFS partition on the boot drive and I have a good backup, so I guess there is nothing to loose...I think I could even let it format and start really clean, the backup is recent (and is working) I won't miss a thing.
I documented all the installation steps I made on Wednesday to get the server back in shape again so this new attempt should finish a lot quicker. Think I just convinced myself to go through it again :-)

Oshunluvr and all the others on this thread, thanks for having patience, I am not trying to be difficult but rather want to understand what I do and why I do it. This case of a BTRFS file system without any sub-volumes may have been a good playground to learn things, but then again, I need this machine in production again.

[Thomas00]

Two installs later which both ended up with the same result, no btrfs subvolumes, I think I found a hint where things go wrong.
This time I decided to turn on the detailed log when installing and as messages were flipping by I noticed a "..etc/fstab warning". Too quick to actually read it but enough to make me look for an installation log and there's the error again. Somehow the installer picks up a key type encrypted which then seems to make things fall over.

thomas@homeserver:~$ cat /var/log/installer/installer-journal.txt | grep fstab
Oct 05 14:50:42 ubuntu-server curtin_log.1919[2187]: {'WORKING_DIR': '/tmp/tmpgzcfbsxb/scratch', 'OUTPUT_FSTAB': '/tmp/tmpgzcfbsxb/state/fstab', 'OUTPUT_INTERFACES': ...
Oct 05 14:52:56 ubuntu-server curtin_log.1919[2187]: cryptsetup: WARNING: could not determine root device from /etc/fstab
Oct 05 14:53:12 ubuntu-server curtin_log.1919[2187]: This error is probably caused by an invalid /etc/fstab
Oct 05 14:53:15 ubuntu-server curtin_event.1919[2731]: start: cmd-install/stage-curthooks/builtin/cmd-curthooks/writing-etc-fstab: writing etc/fstab
Oct 05 14:53:15 ubuntu-server curtin_event.1919[2731]: finish: cmd-install/stage-curthooks/builtin/cmd-curthooks/writing-etc-fstab: SUCCESS: writing etc/fstab
Oct 05 14:53:15 ubuntu-server curtin_log.1919[2187]: start: cmd-install/stage-curthooks/builtin/cmd-curthooks/writing-etc-fstab: writing etc/fstab
Oct 05 14:53:15 ubuntu-server curtin_log.1919[2187]: finish: cmd-install/stage-curthooks/builtin/cmd-curthooks/writing-etc-fstab: SUCCESS: writing etc/fstab

Looked for more details on crypt:

thomas@homeserver:~$ cat /var/log/installer/installer-journal.txt | grep crypt
Oct 05 14:48:49 ubuntu-server kernel: Key type encrypted registered
Oct 05 14:48:49 ubuntu-server systemd[1]: Reached target Local Encrypted Volumes.
Oct 05 14:49:58 ubuntu-server ureadahead[1015]: ureadahead:/usr/lib/tmpfiles.d/cryptsetup.conf: Error retrieving chunk extents: Operation not supported
Oct 05 14:52:56 ubuntu-server curtin_log.1919[2187]: cryptsetup: WARNING: could not determine root device from /etc/fstab

No idea how cryptsetup gets into this, a leftover flag which survives formatting? But I don't think the boot drive was ever encrypted, I also removed my backup drive and tried to install again, just in case.

I then went through the same process again with ext4, same error but obviously the server is functioning as there is no subvolumes concept with ext4
Yet another install with all partitions deleted first, same error.

So I went ahead an created a VM and installed the server with btrfs...
Same cryptsetup error...so clearly this has got nothing to do with my hardware.
Guess what, same error! No sub-volumes and fstab not properly set up!

The cryptsetup warnning may be a false flag but I'd say this looks like a bug in the Ubuntu 18.04 server installer?

By the way, Oshunluvr, this seems to take a completely different direction, maybe you want to consider to move this conversation into a separate thread?

[GreyGeek]

I doubt that it is a "bug" in the installer. No one else installing Kubuntu Bionic using Btrfs is posting your "bug".

More than likely you are overlooking some aspect of how you use the partition manager, or encryption, or the installer itself. So, what extra sauce are you using before you attempt an install? Are you using some type of encryption software on your HD before you install? Are you still trying to put / on one partition and /home on another, while assigning Btrfs to both?

Can't you just do a normal install and then add encryption to the @ and @home later, in the fstab?

[Thomas00]

This is not Kubuntu Bionic, it's Ubuntu server and no, no secret sauce. Bare metal from a USB stick.
But given that I can replicate this behaviour even in a Virtual Machine I was thinking if maybe the server install is just handling btrfs differently and by default is stopping short on creating the two default subvolumes?
Leaving it to the admin to manually create @ and @home and update fstab

I got my server VM running right now, trying to create those subvolumes manually, so far whatever I do looks slightly different to what I see on my laptop...