added initramfs scripts for debian and derivatives

[renaudcerrato]

Just added scripts and instructions for initramfs for Ubuntu (and possibly any debian alternatives ?)

[JMarcosHP]

+1 for this, we need support for debian distributions. @Schievel1

[JMarcosHP]

Tested on Debian 12 with /var/log subvolume and Kde desktop, it works as expected. Can boot and use the desktop environment on a read-only snapper snapshot.

[JMarcosHP]

Using these scripts only a /var subvolume is required.

But, I have an Opensuse btrfs subvolume style installation:

@root
@opt
@srv
@usr-local
@var
@snapshots

[renaudcerrato]

Thanks for testing on Debian!

Using these scripts only a /var subvolume is required.

Could you elaborate on this?

[JMarcosHP]

Could you elaborate on this?

Yes, I mean... I just followed the instructions of the main readme of this repository:

If you wish to use read-only snapshots, /var/log or even /var must be on a separate subvolume. Otherwise, make sure your snapshots are writable.

These scripts for initramfs works well, If I boot a snapshot from the grub menu and then I install a package using apt, these changes takes no effect after reboot, avoiding dpkg database inconsistencies or broken /var. Everything works like in Opensuse.

[JMarcosHP]

So, using these scripts, there is no need to create additional subvolumes like /var/log, /var/lib/AccountsService and /var/lib/gdm3 to boot from snapshots, just create a /var subvolume like in opensuse.

[renaudcerrato]

Those scripts will detect if the root partition is a read-only btrfs partition, and if so will add overlayfs on top of it using temporary (tmpfs) storage under the hood. Your snapshot won't be modified, but you'll still be able to boot.

If you have any other partitions declared under /etc/fstab, they'll be mounted as read/write AFAIK.

[JMarcosHP]

I see, I encountered an issue.
I installed that package on a snapshot, then I reboot and booted to the main subvolume entry, and when I try to execute the package it says is not found but apt says it is installed, what?

[renaudcerrato]

I installed that package on a snapshot

What do you mean? If you booted into a (read-only) snapshot, then you can't install anything in a persistent manner. The snapshot is read-only, any changes will disappear after reboot.

apt says it is installed, what?

apt stores its database in /var. Since you told me that you have a /var subvolume, that volume was mounted and write enabled when you ran your apt-get.

grub-btrfs entries are (read-only) snapshots of @root AFAIK : anything else in /etc/fstab will be mounted as is.

Your @var and @root subvolumes are now inconsistent. In regard to your layout, you should avoid to run any command that will write to the other subvolumes while booted into a snapshot of @root.

My layout consists only of @root and @home to avoid that kind of issue : when booting from a snapshot, any changes will be non persistent, excepted under /home which is rather safe.

[Schievel1]

Why not make this available as an option for sudo make install? See the variables in the make file for OPENRC and SYSTEMD.

[Schievel1]

Before merging this I need some Debian guys to test this properly. Also there should be someone to stick around to maintain those scripts if there is maintenance needed. I am not using a Debian based distro so I can not test it.

Also does this work on Ubuntu as well? Because there is also #250.

[renaudcerrato]

In fact, I only tested on Ubuntu as that's what I'm using, but I'm fairly confident it works exactly the same on Debian. Need some Debian testers.

[Schievel1]

So this make #250 obsolete I guess.

[GrandDuke1106]

You can write in the documentation that the user needs to add executable permissions to both scripts.

sudo chmod +x grub-btrfs-overlayfs-boot
sudo chmod +x grub-btrfs-overlayfs-hook

---

And it'll show you this message when starting up, but it can still get into the system from the snapshot. The file system of root directory has also been changed to overlayfs. So can we just ignore this error?

[    1.882274] systemd[1]: systemd-remount-fs.service: Main process exited, code=exited, status=1/FAILURE
[    1.882382] systemd[1]: systemd-remount-fs.service: Failed with result 'exit-code'.
[    1.882562] systemd[1]: Failed to start systemd-remount-fs.service - Remount Root and Kernel File Systems.

[unonweb]

I have tested the scripts with Debian 13. The overlayfs is applied as expected. Cool, thanks for your work!

BUT: snapper rollback does not work any more when booted into the snapshot ("subvolume is not a btrfs subvolume).
Too bad for me as I wanted to use grub-btrfs together with snapper.
If I don't overlook something I think I have to go back to writable snapshots.

[GrandDuke1106]

BUT: snapper rollback does not work any more when booted into the snapshot ("subvolume is not a btrfs subvolume). Too bad for me as I wanted to use grub-btrfs together with snapper. If I don't overlook something I think I have to go back to writable snapshots.

You can use yabsnap, which can correctly roll back in read-only snapshots by passing parameters. This feature was added just yesterday.

[Payne-X6]

I have tested this on Ubuntu 25.10, works well... You should merge this or #250, they are basically the same (maybe #250 is more user friendly)

[JMarcosHP]

I have tested the scripts with Debian 13. The overlayfs is applied as expected. Cool, thanks for your work!

BUT: snapper rollback does not work any more when booted into the snapshot ("subvolume is not a btrfs subvolume). Too bad for me as I wanted to use grub-btrfs together with snapper. If I don't overlook something I think I have to go back to writable snapshots.

Yep I tested with snapper too, looks like we should stick to create more subvolumes for every directory inside /var

[Payne-X6]

BUT: snapper rollback does not work any more when booted into the snapshot ("subvolume is not a btrfs subvolume). Too bad for me as I wanted to use grub-btrfs together with snapper. If I don't overlook something I think I have to go back to writable snapshots.

You can use yabsnap, which can correctly roll back in read-only snapshots by passing parameters. This feature was added just yesterday.

@GrandDuke1106 It's an common problem.. snapper nor yabsnap will help you with this (overlayfs hide that it's btrfs).. But you can write your own script for rollback when you are inside RO snapshot, it's not hard - copy snapshot as RW and set it with btrfs set-default for root.. Or just use snapper-rollback script here https://github.com/jrabinow/snapper-rollback, when you are booted at RO snapshot.. That should fix your problem..

@JMarcosHP Apart from /var/log, you don't need any other subvolumes in /var. That's why you should use overlayfsfor RO snapshots to avoid creating subvolumes for every other folder in /var.

[GrandDuke1106]

It's an common problem.. snapper nor yabsnap will help you with this (overlayfs hide that it's btrfs).. But you can write your own script for rollback when you are inside RO snapshot, it's not hard - copy snapshot as RW and set it with btrfs set-default for root.. Or just use snapper-rollback script here https://github.com/jrabinow/snapper-rollback, when you are booted at RO snapshot.. That should fix your problem..

@Payne-X6 Starting from version 2.3.0, yabsnap can generate rollback scripts directly within overlayfs, eliminating the need to write them manually. It also allows customizing subvolume mappings via parameters.

Reference: hirak99/yabsnap#62

[Payne-X6]

It's an common problem.. snapper nor yabsnap will help you with this (overlayfs hide that it's btrfs).. But you can write your own script for rollback when you are inside RO snapshot, it's not hard - copy snapshot as RW and set it with btrfs set-default for root.. Or just use snapper-rollback script here https://github.com/jrabinow/snapper-rollback, when you are booted at RO snapshot.. That should fix your problem..

@Payne-X6 Starting from version 2.3.0, yabsnap can generate rollback scripts directly within overlayfs, eliminating the need to write them manually. It also allows customizing subvolume mappings via parameters.

Reference: hirak99/yabsnap#62

I apologize for the confusion. Yesterday, I was trying to configure yabsnap (replace snapper). It was my first time using it, and I didn't get far enough to achieve that.
Now I see that a number of parameters can be added to achieve this with yabsnap.
In my case, snapper-rollback seems more user-friendly to me; all I need is the snapshot ID and to reboot.

[JMarcosHP]

@JMarcosHP Apart from /var/log, you don't need any other subvolumes in /var. That's why you should use overlayfsfor RO snapshots to avoid creating subvolumes for every other folder in /var.

It is up to you to create more subvolumes or not inside /var, depending what things you want to exclude and save space for your snapshots, for example, in a server you don't want to rollback the entire database right?

I think all the overlayfs thing is a mess, and using the traditional way like OpenSUSE does is better and just works.

[JMarcosHP]

I apologize for the confusion. Yesterday, I was trying to configure yabsnap (replace snapper). It was my first time using it, and I didn't get far enough to achieve that.
Now I see that a number of parameters can be added to achieve this with yabsnap.
In my case, snapper-rollback seems more user-friendly to me; all I need is the snapshot ID and to reboot.

Yes snapper is the best tool to manage btrfs snapshots, the suse developers invest time to develop it and integrate this tool in all their products.

The reason why Debian and Archlinux can't have only one RW subvolume for /var is because of their package manager Read the tips and notes from Arch wiki

Apart from /var/lib/AccountsService and the display manager subvolume. You want to exclude more directories inside /var from your snapshots depending the use case.

To rollback the system without issues using snapper, you only need a similar layout like openSUSE, and another script to update your bootloader configuration. See

You simply boot the snapshot with grub-btrfs, and then execute sudo snapper rollback then snapper triggers the plugin for the bootloader configuration and that's it.

Refer to Siduction Linux on how to get the things done without reinventing the wheel.

I adapted their approach for anyone who wants a vanilla Debian that works like openSUSE here

[Payne-X6]

@JMarcosHP Apart from /var/log, you don't need any other subvolumes in /var. That's why you should use overlayfsfor RO snapshots to avoid creating subvolumes for every other folder in /var.

It is up to you to create more subvolumes or not inside /var, depending what things you want to exclude and save space for your snapshots, for example, in a server you don't want to rollback the entire database right?

First of all, I was reacting to @unonweb problem, he has overlayfs... I was just helping him to rollback from RO snapshot, instead of leading him way, that is not acceptable for anyone - splitting /var..

Sure, it may be a matter of opinion, but promoting the splitting of /var when the user is asking about something else is misleading. Especially when there is a solution.

I think all the overlayfs thing is a mess, and using the traditional way like OpenSUSE does is better and just works.

There are at least two reasons why overlayfs is better than partitioning /var... Apart from convenience (you don't need to have two, three, or sometimes even more subvolumes in your fstab)... The biggest advantage is that you have the entire system in a consistent state. When you roll back after updating an application (for which you have a specific subvolume) and the update has changed some internal data (this is when most problems occur), the application may not start because it does not know how to interpret the data in the newer version...