Silverblue mountpoints and subvolumes for /etc snapshots

Ask Fedora
, ,
1

I’m trying to use snapper to create hourly snapshots for /etc and I’m stuck. I would like to either enable snapper for / or create a separate /etc subvolume. The first doesn’t work because I get the following error:

$  sudo snapper -c root create-config /
IO Error (subvolume is not a btrfs subvolume).

The 2nd option seems risky without understanding better how /etc is handled. It would help if I understood what is really mounted at / and /etc. The mount command isn’t helpful, as it just says they are both the btrfs root subvolume.

Does anyone have pointers to docs or the startup scripts that handle mounting / and /etc ?

2

I am not an expert here and I wasn’t able to find clear documentation on this but /etc isn’t subvolume so you can’t take snapshots of it.

You could try taking snapshots of /sysroot since / is mounted on /sysroot. I did a quick test and the snapshot appeared to contain my modified /etc files.

3

Hello @akvadrako ,
I can see my btrfs subvolumes only if I use sudo in the command. sudo btrfs subvolume show / will show the entire sysroot which is where etc is (/etc) so a snapshot of my / will capture /etc as well.

4

Yeah I would suggest not to, but I am not certain it isn’t okay to do.

5

Are you sure? For me it is not possible to take a snapshot of /. I can, however, take a snapshot of /sysroot.

/etc appears to be part of the deployment so I think dropping a separate subvolume on top of it would exclude /etc changes from the deployment and break the ability to rollback.

6

In my setup, I followed the steps listed here to create snapshots of the root partition. Additionally, I created separate subvolumes for /tmp, /var/log and /var/cache at subvolume level 5 to not backup files stored there to the snapshots. For me, it’s enough to create snapshots before / after performing a system update, so I didn’t configure my system for hourly snapshots.

However, I didn’t manage to setup grub-btrfs to boot from snapshots (tested in a VM), because gdm just won’t start. But creating snapshots and restoring them like it is mentioned in the linked guide works well.

Sadly, the Fedora Installer doesn’t work with the partition scheme of openSUSE, which would probably be the best one, using snapper.

7

Those look like instructions for workstation.

You would not need most of that for silverblue.

8

This is true. OSTree uses an overlayfs as the mount point for /etc. It uses the /usr/etc as its lower directory, with it’s upper directory with your older modifications, and it’s overlayer. Modifications are copied up to the overlay and then commited to the tree for the next deployment. Each deployment starts the cycle of a 3 way merge saving the upper directory for the rollback. The overlayer becomes the upper directory in the next deployment.

sudo ostree admin config-diff command will show you the current mutations on the /etc partition from the original /usr/etc directory.

man ostree-admin-config-diff 
OSTREE ADMIN CONFIG()                                                                                                                              OSTREE ADMIN CONFIG()

NAME
       ostree-admin-config-diff - Diff current /etc configuration versus default

SYNOPSIS
       ostree admin config-diff [OPTIONS...]

DESCRIPTION
       Prints the differences between the current /etc directory and the default configuration in /usr/etc. Newly added files (present in /etc but not in /usr/etc) will
       be prefixed with 'A'. Modified files will be prefixed with 'M', and deleted files with 'D'.

OPTIONS
       --os="STATEROOT"
           Use a different operating system stateroot than the current one.

EXAMPLE
       $ ostree admin config-diff

                   M   shadow
                   A   example.txt

                                                                                                                                                   OSTREE ADMIN CONFIG()
2 Likes
9

Thanks for the replies; I have a better idea what’s going on now and it helped me find this document which explains the 3-way merge of /etc: Deployments | ostreedev/ostree.

The overlayfs part is good additional information which I can’t find the docs for. I guess the upper layer is at /sysroot/ostree/deploy/fedora/deploy/<commit-hash>/ ?

10

Oops! My bad. I was working from WS not SB. So you’re correct that you wouldn’t be able to snapshot. Really I wouldn’t bother snapshotting anything with SB in that case. Simply pinning with ostree and backing up the /home using btrfs subvolume snapshots would be my approach for that.
As for snapshotting / it can be done on SB but you would have had to make a root level btrfs volume on your device that has the root partition then create the subvolume for the / mount point as a child of the root volume. You then manually mount the root volume, take your snapshot then unmount it. Again, on SB this is, IMO, overkill since ostree does a pretty good job at this.

1 Like
11

You‘re right, I missed the fact you were talking about Silverblue. Sorry for that. But then, again, creating snapshots of the root filesystem wouldn’t make any sense on Silverblue anyway.

1 Like
12

/sysroot/ostree/deploy/fedora/deploy/<commit-hash>/ would be the merged filesystem for the deployment.

13

I know how overlayfs works. But where can I find details on how Silverblue uses it?

14

Gives a pretty good break down. Also remeber rpm-ostree has many articles you would have to look into to get the full scope of Silverblue.

1 Like
15

Thanks, but that just seems to have an overview of a historical experiment. It doesn’t mention anything about the /etc mount or overlayfs.

I have looked through the docs at A true hybrid image/package system | coreos/rpm-ostree, but I also don’t see much there.

16

Or read all his articles to get a better idea of what your looking for.

1 Like
17

Thanks again, but that’s from 2014 and doesn’t say anything about how Silverblue mounts the overlayfs of /etc. What would be interesting is the specific mount calls or where I can find them.

But I guess it doesn’t matter because whatever it is, it probably won’t be layout in a way that lets me make/etc (or the upper part of it’s overlayfs mount) a subvolume. And using snapshots for the whole sysroot seems like it would cost too much space to keep around for long, defeating the point.

I think I will just write a script that uses config-diff to copy /etc modifications into a directory on /var and run that after making changes.

1 Like