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.?
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â?
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.
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?