On Sun, Nov 29, 2020 at 9:52 AM Sreyan Chakravarty sreyan32@gmail.com wrote:

Hi,

I have only 1 partition, which has my root and /home together.

I have installed Fedora33 with the default BTRFS settings, in which it does not create a subvolume for root.

It does. You can check with any or all of these commands:

mount | grep btrfs sudo btrfs subvolume list -t / cat /etc/fstab

I have created a snapshot of my entire root filesystem using:

               sudo btrfs subv snapshot / /root/snapshots/test

Now what do I do ?

How do I restore the snapshot ?

There's a lot more than one way to do this. As one possible example:

$ sudo mount /dev/nvme0n1p7 /mnt $ cd /mnt $ ls -li total 0 256 dr-xr-xr-x. 1 root root 1330 Nov 26 23:25 boot 256 dr-xr-xr-x. 1 root root 1966 Nov 23 22:43 boot.20201126 256 drwxr-xr-x. 1 root root 10 Jul 27 12:22 home 256 drwxr-xr-x. 1 root root 10 Jul 27 12:22 home.20201126-2 256 drwxr-xr-x. 1 root root 26 Nov 1 13:05 images 256 dr-xr-xr-x. 1 root root 132 Nov 5 18:23 root 256 dr-xr-xr-x. 1 root root 132 Nov 5 18:23 root.20201126

These are all subvolumes, as evidence by (a) it's a Btrfs file system, and (b) each has inode 256. Some folks like to put a character in the name of their subvolumes to indicate it's a subvolume, common is using the @ character. So @home and @root. I don't use this convention myself, I just stick only subvolumes in the "top-level" of the file system as you see here.

The other convention I use is I make read-only snapshots with a date. What I do for a rollback is:

# mv root rootold # btrfs sub snap root.20201126 root # reboot

What this does is mounts the "top-level" [1] so you have direct access to the root and home subvolumes. And then rename the current root to something else; and then snapshot the desired snapshot as the new root. I do it this way because I don't have to modify either fstab or GRUB, both of which are expecting a subvolume named "root". You do not need to worry about renaming an active/in-use subvolume. Internally Btrfs is using subvolume ID's anyway, and that won't change. You'll notice if you rename a mounted subvolume, its name is immediately updated, verify this with the mount command before and after renaming.

An alternative approach is a bit advanced only in that it requires knowing about the "default subvolume". And to give a complete answer is a bit of a story. But you can get the gist from 'man btrfs subvolume' and read the set-default and get-default sections in particular.

[1] Nested versus flat layouts. The above example is a flat layout. https://btrfs.wiki.kernel.org/index.php/SysadminGuide#Layout

On Mon, Nov 30, 2020 at 2:38 AM Chris Murphy lists@colorremedies.com wrote:

There's a lot more than one way to do this. As one possible example:

$ sudo mount /dev/nvme0n1p7 /mnt $ cd /mnt $ ls -li total 0 256 dr-xr-xr-x. 1 root root 1330 Nov 26 23:25 boot 256 dr-xr-xr-x. 1 root root 1966 Nov 23 22:43 boot.20201126 256 drwxr-xr-x. 1 root root 10 Jul 27 12:22 home 256 drwxr-xr-x. 1 root root 10 Jul 27 12:22 home.20201126-2 256 drwxr-xr-x. 1 root root 26 Nov 1 13:05 images 256 dr-xr-xr-x. 1 root root 132 Nov 5 18:23 root 256 dr-xr-xr-x. 1 root root 132 Nov 5 18:23 root.20201126

Also tried changing my fstab, but that results in no change.

What is going on here ? How do I restore the snapshot of the root file system ?

Let me know if any other information is needed.

On 11/29/20 5:07 PM, Chris Murphy wrote:

You do not need to worry about renaming an active/in-use subvolume. Internally Btrfs is using subvolume ID's anyway, and that won't change.

I didn't know this. I thought you had to boot off external media in order to revert back the root filesystem snapshot or make the necessary changes in /etc/fstab .

I just did this test in a F33 VM:

- mounted btrfs in /mnt, took snapshot of root as root.20201230 - dnf update (a bunch of updates) - rebooted - mounted btrfs in /mnt, renamed root to root.old, created new snapshot called root off root.20201230 (just the steps you mentioned) - rebooted

While booting a get an error "Failed to start Load Kernel Modules" and "A start job is running for /dev/zram0". The systemd-modules-load.service show some errorrs looking up aliase named fuse, msr, platform-integrity etc...

It eventually booted fine but the issue remains in further rebots (kernel module error and zram issue). So apparently there are still some loose ends doing this in-place snapshot reversal of the root filesystem?

This was just a test on a scratch VM so no need to troublshoot it further.

Thanks.

On Sun, Nov 29, 2020 at 10:37 PM Sreyan Chakravarty sreyan32@gmail.com wrote:

On Mon, Nov 30, 2020 at 2:38 AM Chris Murphy lists@colorremedies.com wrote:

...

There's a lot more than one way to do this. As one possible example:

$ sudo mount /dev/nvme0n1p7 /mnt $ cd /mnt $ ls -li total 0 256 dr-xr-xr-x. 1 root root 1330 Nov 26 23:25 boot 256 dr-xr-xr-x. 1 root root 1966 Nov 23 22:43 boot.20201126 256 drwxr-xr-x. 1 root root 10 Jul 27 12:22 home 256 drwxr-xr-x. 1 root root 10 Jul 27 12:22 home.20201126-2 256 drwxr-xr-x. 1 root root 26 Nov 1 13:05 images 256 dr-xr-xr-x. 1 root root 132 Nov 5 18:23 root 256 dr-xr-xr-x. 1 root root 132 Nov 5 18:23 root.20201126

When I mount my root filesystem using:

$ cryptsetup luksOpen /dev/sda2 /dm_crypt $ Enter Passphrase: $ mount -t btrfs /dev/mapper/dm_crypt /mnt $ ls

I get: bin boot dev etc home lib lib64 lost+found media mnt opt proc root run sbin srv sys tmp usr var

If it's a default Fedora 33 installation, then it should list: home root

The above output suggests it is either a converted ext4 file system, or 'btrfs subvolume set-default' has been used.

Please post the /etc/fstab

On Mon, Nov 30, 2020 at 6:42 AM Jorge Fábregas jorge.fabregas@gmail.com wrote:

On 11/30/20 8:50 AM, Jorge Fábregas wrote:

...

This was just a test on a scratch VM so no need to troublshoot it further.

Gave it a 2nd thought prior to scratching the VM...

It turns out I applied a bunch of updates (including the kernel). As /boot is not part of the snapshot I took (since it's an ext4 filesystem by default) ...the system booted with the recently installed kernel (and not the one I had when I took the snapshot) so I had an inconsistency there. Once I selected the previous kernel from the GRUB menu the system booted seamless.

I see we put /boot as a separate filesystem during installation (default settings) but really..is it necessary these days considering GRUB supports BTRFS? If I had /boot as a directory of the BTRFS root subvolume, a simple snapshot of the root filesystm would suffice :(

There's a bunch of reasons why it's still on ext4 and they have more to do with resources and logistics than anything else.

A separate $BOOT file system is still needed when the main file system is encrypted. Fedora is unlikely to enhance Anaconda to do the GRUB setup work to support an encrypted $BOOT volume for various reasons, including i18n and a11y limitations in GRUB. The UI/UX just gets pretty ugly.

Another hiccup applies on non-UEFI firmware systems, where the grubenv file is on Btrfs. I address this here: https://ask.fedoraproject.org/t/will-fedora-use-btrfs-for-boot-in-the-future...

And still another hiccup are questions surrounding the BootLoaderSpec. We're trying to follow the spec, but strictly following it has a few difficulties still but it's not clear to me yet what the "grand bargain" is going to be. Or if it's the spec itself that needs to be more flexible. And of course any time there are changes, it causes a certain amount of disruption for everyone. So...yeah.

Chris: do you have /boot as part of BTRFS?

In the earlier example, yes.

In the case of home and root subvolumes on Fedora (the default) while you can snapshot and rollback root as I've described, it's quite a heavy hammer. It will rollback everything: logs, journal, configuration files in etc, caches in var, VM images also in var.

So the logical thing is to add some subvolumes so that it's possible to *not* snapshot some things, while still snapshotting others. The difficulty there is, the more granular you make this, the more difficult it is to keep track of without a helper program like snapper or timeshift.

Another factor in all of this is whether it's desirable to have a Btrfs equivalent of the Discoverable Partition Spec. https://systemd.io/DISCOVERABLE_PARTITIONS/

So what would that look like? One suggestion is to make it xattr based, just stuff a GUID into an xattr for each subvolume. Another idea is to just have a standardized subvolume naming convention. Such a naming convention would be more flexible and self-describing. But either of these requires a design, and (ideally) expand the spec to cover this case.

On Mon, Nov 30, 2020 at 10:12 PM Chris Murphy lists@colorremedies.com wrote:

I don't understand why you're going to another forum to ask the same question, and posting different information. It's just making it more difficult to provide answers. Here is what you posted there:

Since I did not know about BTRFS.

$ btrfs subvolume list / ID 256 gen 3794 top level 5 path fedora ID 264 gen 2296 top level 256 path root/snapshots/test

That is not a default subvolume layout for Fedora 33. I have no idea how you arrived at this layout but it's not the default. If you do a default (automatic) installation of Fedora 33, you will have two subvolumes: home and root, at the top level.

Ok, I have managed to get BTRFS snapshots working.

I must have messed up the installation somehow. Now I have a subvolume under the toplevel volume which I can now rename.

But the problem is that I have to reboot to a live CD just to take a snapshot. Any way to do it within the OS ?