Creating chroot environment with btrfs partition

After adding a couple of hard drives and a new controller, I started getting this error when booting the SSD containing Fedora 33:

Cannot open access to console, the root account is locked.
See sulogin(8) man page for more details.
Press Enter to continue.

Pressing Enter just puts you in a loop. A little research finds that the most likely cause is that the kernel cannot access /home. So I boot off an F33 USB key and try to mount /dev/sda3. The head scratcher is that instead of seeing the familiar /dev,/boot, /home, etc. in /mnt/root I instead see ./root and ./home - and that’s it.

What is this madness? How do I create a functional chroot environment with this oddball file structure, and then mount dev, proc, etc.?

In case you haven’t considered this…,

If you’ve added drives the device enumeration might have changed; what was sda might now be sdc, or with a new controller something else entirely.

(IMO the sanity-preserving approach is to give volumes sensible names of your choice, and set those names as labels. Then use them in mount commands, f.ex. “mount LABEL=clarence /mnt/whereever”, /etc/fstab, and boot loader stanzas.)

In the past Fedora has put the UUID in fstab, but it looks like they’re using the enumerated designations (/dev/sda3, et al). But in the fstab I see two separate entries for /dev/sda3, but one has an option that says “subvol=home” and the other says “subval=root”. What the heck is a ‘subvolume’?

Here is my fstab file:

/dev/sda3               /                       btrfs   subvol=root     0 0
UUID=ca410e57-b1dc-466b-a14b-4e73d909d56a /boot                   ext4    defaults        1 2
UUID=71FC-F1A7          /boot/efi               vfat    umask=0077,shortname=winnt 0 2
/dev/sda3               /home                   btrfs   subvol=home     0 0
/dev/sdb2 /run/media/imrazor/Data ntfs rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096 0 0

It seems the F33 installer chose to install btrfs instead of the much more familiar ext4. I don’t have a clue what to do with ‘subvolumes’ or how to properly prepare a chroot environment with btrfs.

EDIT: At some point it seems likely I changed from using UUIDs to the device path. I did not know about the blkid command, and this time used it to retrieve the correct UUID for /dev/sda3. The ‘subvol’ option is new to me. I’d still like to know how to properly create a chroot environment with a btrfs partition. Once I put the correct UUID into /etc/fstab, the system was able to boot into Fedora 33.

mount the root subvolume with the argument subvol=root?
I think it works the same when manually mounting as in fstab in regards to arguments, so if you juse use subvol=root for the root mount and then mount /home with subvol=home it should work fine.
You can sudo btrfs subvolume list mount point to list the existing subvolumes, and see the names and IDs with which you can mount them.

A btrfs subvolume is the same as a ZFS dataset (if you worked with them).

You can apply some attributes to them separately, and you can snapshot them independently (which is why root “/” is separate from “/home” ; so you can snapshot and then rollback the OS independently from your data).

You can also mount (and therefore boot) from snapshots/subvolumes (same as ZFS datasets).


Since they can be independently snapshot-ed , and because btrfs is a cow filesystem, there’s a docker storage driver.


One day we might be able to apply different btrfs raid levels to different subvolumes (waiting for the day), the datastructures allow it but tooling isn’t there.

Calling this “root” can be confusing (it confused me greatly) because we are used to calling the top of the tree “root”. The Linux root, aka /, is not at the top of the btrfs tree; for you it’s in a subvolume called “root”.

I’ve adopted the usage “top” to avoid confusion. I always set up a mount to that top of the tree in /etc/fstab:

# the true root of the btrfs volume for convenience
LABEL=main     /top          btrfs   defaults,noatime               0   0

(/mnt/top would be more unixy, but /top is shorter.) Then you can

cd /top
ls

and see what’s going on. Or, navigate there with your file manager. Also, I usually rename the subvolumes (using mv) and edit the fstab and grub to match. This allows other installs to be in the same btrfs, and very quick (seconds, a few uses of “mv”) reversions of mistakes or bad updates.

IMO if you’re the type of user who posts in this forum, you’re the type of user who’ll benefit greatly from using btrfs. Juggling partitions for different installs is eliminated. Accessing files as they were months ago is a few clicks.

1 Like

I don’t particularly want to try this with a live system, but it’s a great way to put a VM to use for experimentation. I’ll go ahead and create an F33 VM, install with a btrfs volume and learn how btrfs works. I’m surmising that btrfs is mostly used by enthusiasts rather than enterprise sysadmins, or am I just plain wrong?