Why is my btrfs root partition mounted on /,/var/cache & log?

Support
,
1

image

2

If you used the Installer to create your btrfs install, you should only have / and /home as subvolumes.

So I don’t know where the /var ones come from.

3

i’ve done / as btrfs and /home as ext4, does that affect?

4

So it’s a manual install. Then your guess is as good as mine.

5

yes, i did the manual installation. anyway should i be worry about anything?

6

I don’t think so. Also, what device is this install on (since you posted it in the ARM section)?

7

Asus laptop, actually i was looking for the general thread

8

I’ve moved to appropriate place.

9

This is only gparted not handling Btrfs subvolumes, thus showing erroneous information. I have the same setup as @Zexu_knub in a VM, and it shows the exact same thing.

Using the btrfs commands should show the actual situation:

sudo btrfs subvolume list /
10

I have a simliar setup, only I use a ext4 /boot partition as well.

To go into more detail (as I understand it):

  • The default btrfs sets up four subvolumes: /, /home,/var/log,/var/cache.
  • The idea is that timeshift will snapshot / (and /home, if selected) and skip /var/log and /var/cache.
  • This helps keep down the size of snapshots as /var/log and /var/cache can contain alot of files that are not needed for rollbacks (the function of timeshift).
  • Another benefit is that if one has to do a timeshift rollback due to a botched install or upgrade, the log files from the “botch” are preserved – allowing for debugging after the fact.
11

/var/cache and /var/log should not be included when you make a snapshot of your root filesystem, which is why they are generally put on their own subvolumes. That way, you can easily make a snapshot of @ without including @cache and @log.

2 Likes
12

Please be aware that an external /boot partition may cause problems when roll back is needed. You will not be able to boot when the kernel-version on /boot does not match the version oft the kernel-modules in /usr/lib/modules :sunglasses:
This problem does only arise, when the kernel changes !
Or you need to roll back /boot to the same point in time :wink:

1 Like
13

Your are very correct. The workaround (found on the arch wiki) is to set up a pacman hook:

/etc/pacman.d/hooks/50-bootbackup.hook
-----------------------------------------------------------------------
[Trigger]
Operation = Upgrade
Operation = Install
Operation = Remove
Type = Path
Target = usr/lib/modules/*/vmlinuz

[Action]
Depends = rsync
Description = Backing up /boot...
When = PostTransaction
Exec = /usr/bin/rsync -a --delete /boot /.bootbackup

(Remember to run the command on the Exec line manually at the start.)
The command in this hook will back up the boot partition to a hidden directory on root – which is then covered by snapshots.
One then copies the contents of the bookbackup directory back to /boot during the restoration process.

2 Likes
14