Wednesday, August 12, 2026

Sparky Linux 2026 06 OverlayFS BTRFS with Timeshift setup (Assisted by Google AI)

 Review 

Turning on OverlayFS on top of a Btrfs base setup in Sparky Linux 2026.06 brings a fundamentally different set of advantages compared to a standard deployment utilizing Btrfs subvolumes and Timeshift. While both configurations leverage Btrfs, they serve completely different operational philosophies: Timeshift provides a reactive "point-in-time recovery" safety net, whereas OverlayFS converts the environment into a proactive, transient "stateless or immutable" sandboxed workstation. 

Proceed as follows 

$ sudo apt update
$ sudo apt install inotify-tools gawk timeshift
$ git clone https://github.com/Antynea/grub-btrfs.git
$ cd grub-btrfs
$ sudo make install
$ sudo systemctl edit --full grub-btrfsd.service
[Service]
ExecStart=
ExecStart=/usr/bin/grub-btrfsd --syslog --timeshift-auto

=========================================
$ sudo systemctl daemon-reload
$ sudo systemctl enable --now grub-btrfsd.service
$ sudo update-grub                                                                                    $ sudo reboot

=========================================
Install timeshift-autosnap-apt
=========================================
Run the following commands to clone the automation script and install it to your system:
=========================================
$ git clone https://github.com/wmutschl/timeshift-autosnap-apt.git
$ cd timeshift-autosnap-apt
$ sudo make install
=========================================
Quick Verification CheckOnce the installation script finishes tracking files into your /etc/apt/apt.conf.d/ hooks, you can test the manual wrapper parsing structure by executing:
sudo timeshift-autosnap-apt
=========================================
# Verify the configuration file exists:
ls -l /etc/timeshift-autosnap-apt.conf
# Verify the APT hook is active:
ls -l /etc/apt/apt.conf.d/80-timeshift-autosnap-apt
# Verify the executable script is in your system path:
ls -l /usr/bin/timeshift-autosnap-apt
=========================================

$ sudo update-grub                                                                                      $ sudo reboot
==============Overlay Setup =============
We need to swap out Debian's default initramfs-tools and replace it with Dracut, which natively understands the Fedora-style live overlay parameters.
$ sudo apt update
$ sudo apt install dracut dracut-core -y
=============================================
Inject the working parameters exclusively into the Snapshot Configuration
$ sudo nano /etc/default/grub-btrfs/config
GRUB_BTRFS_SNAPSHOT_KERNEL_PARAMETERS="'rd.live.overlay.overlayfs=1 rw'"
==========================================
Force Dracut to re-build your active kernel images with overlay modules enabled
==========================================
$ echo 'add_dracutmodules+=" overlayfs "' | sudo tee /etc/dracut.conf.d/overlayfs.conf
$ sudo dracut -H --hostonly-mode=sloppy --add overlayfs --force
==========================================
Finalize and update your master GRUB boot menu layout
$ sudo update-grub 


Mounting the Lower Layer: Dracut maps your physical Btrfs snapshot (e.g., @the-timeshift-snapshot-name) as a pristine, read-only (ro) lower directory at /run/rootfsbase. Creating the Upper Layer: Because you haven't explicitly attached an external physical drive partition or configured a specific size flag, Dracut calculates a default fallback environment. It looks at your virtual /run directory—which systemd allocates as a memory-backed tmpfs slice restricted to roughly 20% to 40% of available memory architecture defaults .    The Stitching: Dracut creates /run/overlayfs (the writeable layer) and /run/ovlwork (the system scratch directory) directly inside that RAM allocation.
It then uses the kernel's OverlayFS driver to merge /run/rootfsbase and /run/overlayfs into a virtual root device called LiveOS_rootfs.
==================================================
When Dracut exits and hands control over to Sparky Linux's systemd initialization, the operating system interacts entirely with LiveOS_rootfs mounted on / .  If an application tries to modify a file in /etc, /usr, or /opt, the kernel catches the file manipulation, pulls the original file from the read-only Btrfs snapshot, applies the modification, and writes it directly to your RAM buffer. The "Leak" Behavior: Because your /etc/fstab inside that snapshot contains explicit, hardcoded instructions to mount /home, /var/log, and /var/cache using their specific subvolume IDs (subvolid=346 or subvol=/@home), systemd reads those lines and explicitly mounts your real physical drive right over those specific directories. This is why /home remains persistent, while / is sandboxed.











 

boris@devs-XV8664:~$ uname -a
Linux devs-XV8664 7.1.7+deb14-amd64 #1 SMP PREEMPT_DYNAMIC Debian 7.1.7-1 (2026-08-07) x86_64 GNU/Linux
boris@devs-XV8664:~$ mount | grep 'on / '
LiveOS_rootfs on / type overlay (rw,relatime,lowerdir=/run/rootfsbase,upperdir=/run/overlayfs,workdir=/run/ovlwork,uuid=on)
boris@devs-XV8664:~$ df -Th
Filesystem     Type      Size  Used Avail Use% Mounted on
LiveOS_rootfs  overlay   3.1G  1.4M  3.1G   1% /
devtmpfs       devtmpfs  7.6G     0  7.6G   0% /dev
tmpfs          tmpfs     7.6G   12K  7.6G   1% /dev/shm
efivarfs       efivarfs  256K  125K  127K  50% /sys/firmware/efi/efivars
tmpfs          tmpfs     3.1G  1.4M  3.1G   1% /run
/dev/vda3      btrfs      63G  6.2G   56G  11% /run/rootfsbase
tmpfs          tmpfs     7.6G   12K  7.6G   1% /tmp
none           tmpfs     1.0M     0  1.0M   0% /run/credentials/systemd-journald.service
/dev/vda3      btrfs      63G  6.2G   56G  11% /var/log
/dev/vda3      btrfs      63G  6.2G   56G  11% /var/cache
/dev/vda3      btrfs      63G  6.2G   56G  11% /home
/dev/vda2      ext4      2.0G  181M  1.7G  10% /boot
/dev/vda1      vfat      511M   15M  497M   3% /boot/efi
tmpfs          tmpfs     1.6G   80K  1.6G   1% /run/user/1000

 
boris@devs-XV8664:~$ lsblk -f
NAME   FSTYPE FSVER LABEL UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
sr0                                                                            
vda                                                                            
├─vda1 vfat   FAT32       B174-924B                             496.9M     3% /boot/efi
├─vda2 ext4   1.0         6debd835-d6e3-427f-bb85-e5e0ba944e5a    1.6G     9% /boot
└─vda3 btrfs              2ef2dcbc-5404-4e81-b915-7367c2ed259d     55G                                                                                                                                       10% /home
                               /var/cache
                               /var/log
                               /run/rootfsbase

 
 How dangerous are leaks at /home on Sparky/Timeshift Overlay instances ? Please compare this two greps

root@devs-XV8664:~# uname -a
Linux devs-XV8664 7.1.7+deb14-amd64 #1 SMP PREEMPT_DYNAMIC Debian 7.1.7-1 (2026-08-07) x86_64 GNU/Linux
root@devs-XV8664:~# btrfs subvolume list / | grep -v home
ID 258 gen 2197 top level 5 path @cache
ID 259 gen 2217 top level 5 path @log
ID 324 gen 1549 top level 5 path timeshift-btrfs/snapshots/2026-08-11_10-52-13/@
ID 331 gen 1543 top level 5 path timeshift-btrfs/snapshots/2026-08-11_10-48-18/@
ID 334 gen 1701 top level 5 path timeshift-btrfs/snapshots/2026-08-11_15-47-26/@
ID 335 gen 1623 top level 5 path timeshift-btrfs/snapshots/2026-08-11_11-16-19/@
ID 339 gen 1696 top level 5 path timeshift-btrfs/snapshots/2026-08-11_15-43-18/@
ID 342 gen 1733 top level 5 path timeshift-btrfs/snapshots/2026-08-11_15-54-31/@
ID 343 gen 1725 top level 5 path timeshift-btrfs/snapshots/2026-08-11_15-49-21/@
ID 346 gen 2041 top level 5 path timeshift-btrfs/snapshots/2026-08-12_04-38-11/@
ID 347 gen 1759 top level 5 path timeshift-btrfs/snapshots/2026-08-12_01-38-26/@
ID 349 gen 1968 top level 5 path timeshift-btrfs/snapshots/2026-08-12_03-37-00/@
ID 351 gen 2036 top level 5 path timeshift-btrfs/snapshots/2026-08-12_04-34-45/@
ID 354 gen 2216 top level 5 path @
ID 355 gen 2181 top level 5 path timeshift-btrfs/snapshots/2026-08-12_06-08-42/@

 
root@devs-XV8664:~# btrfs subvolume list / | grep  home
ID 323 gen 1561 top level 5 path timeshift-btrfs/snapshots/2026-08-11_10-52-13/@home
ID 332 gen 1544 top level 5 path timeshift-btrfs/snapshots/2026-08-11_10-48-18/@home
ID 333 gen 1715 top level 5 path timeshift-btrfs/snapshots/2026-08-11_15-47-26/@home
ID 336 gen 1624 top level 5 path timeshift-btrfs/snapshots/2026-08-11_11-16-19/@home
ID 340 gen 1697 top level 5 path timeshift-btrfs/snapshots/2026-08-11_15-43-18/@home
ID 341 gen 1743 top level 5 path timeshift-btrfs/snapshots/2026-08-11_15-54-31/@home
ID 344 gen 1726 top level 5 path timeshift-btrfs/snapshots/2026-08-11_15-49-21/@home
ID 345 gen 2054 top level 5 path timeshift-btrfs/snapshots/2026-08-12_04-38-11/@home
ID 348 gen 1760 top level 5 path timeshift-btrfs/snapshots/2026-08-12_01-38-26/@home
ID 350 gen 1969 top level 5 path timeshift-btrfs/snapshots/2026-08-12_03-37-00/@home
ID 352 gen 2037 top level 5 path timeshift-btrfs/snapshots/2026-08-12_04-34-45/@home
ID 353 gen 2217 top level 5 path @home
ID 356 gen 2182 top level 5 path timeshift-btrfs/snapshots/2026-08-12_06-08-42/@home

There is one-to-one correspondence between lines. Running Timeshift in Overay instance in GUI mode I am always prompted for @home recovery ( on demand ) and it works fine along with recovery for instance from $ sudo rm -fr /usr/lib/modules or $ sudo rm -fr /usr/bin, if I will delete some sub-folders under /home/boris ( intentionally in Overlay mode ) . Then Timeshift in GUI mode makes my bad actions reverted back when I boot into main "rw" Sparky Instance.

No comments:

Post a Comment