Sunday, July 12, 2026

Setup non-flat btrfs architecture on Arch Linux via CachyOS approach

 UPDATE as of 07/13/26 

Arch Linux is supposed to be preinstalled with default BTRFS Configuration and Snapper via archinstall --advanced

$ lsblk -f
NAME   FSTYPE FSVER LABEL UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
sr0
zram0  swap   1     zram0 049597e2-0935-4472-9087-156e7af672f1                [SWAP]
vda
├─vda1 vfat   FAT32       389E-C9B6      912.9M    11%   /boot
└─vda2 btrfs              bd32bc49-c8fb-4275-885b-51b9fb7aaae3   62.2G    15%  /home
                                                                 /var/log
                                                                 /var/cache/pacman/pkg
                                                                  / 

END UPDATE 

The first phase follows exactly guidelines proposed in Bring CachyOS KDE Plasma 6.7.2 along with kernel 7.1.3 to Arch Linux  

Second phase was developed in collaboration with Google AI Assistant.
Goals achieved in second phase:
1. Package Independence: Installing only btrfs-assistant  and grub-btrfs completely bypasses the CachyOS              configuration meta-packages, keeping Limine off.
2. Predictable mkinitcpio Execution: Cleaning the              BOOTX64.EFI fallback slots before running                        mkinitcpio -P ensures  that the subsequent grub-install    execution writes a clean binary to an empty path.                3.Precise Target Identification:
Pointing --efi-directory directly to /boot accurately reflects 1 GB default FAT32 layout . 

$ sudo pacman -S --noconfirm btrfs-assistant grub-btrfs

Systemd, sd-vconsole switches the initramfs boot environment from a classic BusyBox script setup over to a systemd-managed process.

The systemd hook completely replaces both base and udev. It builds an initramfs that starts a mini-systemd instance to handle device discovery and orchestration instead of relying on older BusyBox shell scripts. Without base, you drop the traditional BusyBox emergency recovery shell. If the system undergoes a catastrophic boot failure, you will instead drop into a systemd-managed emergency shell. Because microcode is listed after autodetect in your configuration,
mkinitcpio will only pack the microcode matching your specific local processor model. If you had placed it before autodetect, it would build a universal image containing every Intel and AMD microcode patch available. This permits you to completely strip out any initrd=...-ucode.img references out of your bootloader configuration (like systemd-boot or GRUB) because the microcode is safely nested directly inside the unified image. HOOKS below represents a modern, optimized, pure systemd-based initramfs layout that strips away legacy configuration defaults

$ sudo sed -i 's/^HOOKS=(.*/HOOKS=(systemd autodetect microcode modconf kms keyboard sd-vconsole block filesystems fsck)/' /etc/mkinitcpio.conf
###  Clean up ######
$ sudo rm -f /boot/EFI/BOOT/BOOTX64.EFI
$ sudo rm -f /boot/EFI/BOOT/bootx64.efi
#################
$ sudo mkinitcpio -P
$ sudo grub-install --target=x86_64-efi --efi-directory=/boot --bootloader-id=grub --recheck
$ sudo grub-install --target=x86_64-efi --efi-directory=/boot --removable --recheck ( required only in VENV )
$ sudo systemctl enable --now grub-btrfsd.service
$ sudo grub-mkconfig -o /boot/grub/grub.cfg












[boris@ArchLinux0712 ~]$ uname -a
Linux ArchLinux0712 7.1.3-2-cachyos #1 SMP PREEMPT_DYNAMIC Wed, 08 Jul 2026 18:34:01 +0000 x86_64 GNU/Linux
[boris@ArchLinux0712 ~]$ df -Th
Filesystem     Type      Size  Used Avail Use% Mounted on
/dev/vda2      btrfs      74G  9.5G   64G  14% /
devtmpfs       devtmpfs  7.6G     0  7.6G   0% /dev
tmpfs          tmpfs     7.7G     0  7.7G   0% /dev/shm
efivarfs       efivarfs  256K   73K  179K  29% /sys/firmware/efi/efivars
tmpfs          tmpfs     3.1G  1.2M  3.1G   1% /run
none           tmpfs     1.0M     0  1.0M   0% /run/credentials/systemd-journald.service
tmpfs          tmpfs     7.7G  4.0K  7.7G   1% /tmp
/dev/vda2      btrfs      74G  9.5G   64G  14% /home
/dev/vda2      btrfs      74G  9.5G   64G  14% /var/cache/pacman/pkg
/dev/vda2      btrfs      74G  9.5G   64G  14% /var/log

/dev/vda1      vfat     1022M  110M  913M  11% /boot
tmpfs          tmpfs     1.6G   40K  1.6G   1% /run/user/1000
[boris@ArchLinux0712 ~]$ findmnt /
TARGET SOURCE        FSTYPE OPTIONS
/      /dev/vda2[/@] btrfs  rw,relatime,compress=zstd:3,discard=async,space_cache=v2,subvolid=273,subvol=/@
[boris@ArchLinux0712 ~]$ findmnt /var/log
TARGET   SOURCE           FSTYPE OPTIONS
/var/log /dev/vda2[/@log] btrfs  rw,relatime,compress=zstd:3,discard=async,space_cache=v2,subvolid=258,subvol=/@log
[boris@ArchLinux0712 ~]$ findmnt /home
TARGET SOURCE            FSTYPE OPTIONS
/home  /dev/vda2[/@home] btrfs  rw,relatime,compress=zstd:3,discard=async,space_cache=v2,subvolid=257,subvol=/@home
[boris@ArchLinux0712 ~]$ sudo btrfs subvolume list /
[sudo] password for boris:
ID 256 gen 164 top level 5 path @_backup_2026-07-12T08:50:28.780Z
ID 257 gen 206 top level 5 path @home
ID 258 gen 210 top level 5 path @log
ID 259 gen 198 top level 5 path @pkg

ID 260 gen 14 top level 273 path var/lib/portables
ID 261 gen 14 top level 273 path var/lib/machines
ID 262 gen 208 top level 273 path .snapshots
ID 263 gen 207 top level 257 path @home/.snapshots
ID 264 gen 49 top level 263 path @home/.snapshots/1/snapshot
ID 265 gen 49 top level 262 path .snapshots/1/snapshot
ID 266 gen 140 top level 262 path .snapshots/2/snapshot
ID 267 gen 141 top level 262 path .snapshots/3/snapshot
ID 268 gen 143 top level 262 path .snapshots/4/snapshot
ID 269 gen 162 top level 262 path .snapshots/5/snapshot
ID 270 gen 178 top level 5 path @_backup_2026-07-12T08:55:30.375Z
ID 271 gen 187 top level 262 path .snapshots/6/snapshot
ID 272 gen 191 top level 5 path @_backup_2026-07-12T17:38:26.467Z
ID 273 gen 209 top level 5 path @
ID 274 gen 206 top level 263 path @home/.snapshots/2/snapshot
ID 275 gen 207 top level 262 path .snapshots/7/snapshot


Wednesday, July 1, 2026

Setup Debian Trixie with btrfs as root FS and separate boot folder with ext4 in UEFI mode

 This is a final draft  been worked out through several sessions with Google AI Assistant . Same approach would work on Debian forky as well. All commands below are supposed to be issued with root privileges. In case of /boot/efi crash low level btrfs CLI won't help you to recover so creating boot as btrfs subvolume is not a critical part of btrfs flat system layout recovery would have to path via Phase 1 and Phase 2 see for instance Sparky-aptus-upgrade on Sparky Linux 2026 06 instance in UEFI mode

 Final disk layout with btrfs  flat topology

boris@debian13VM:~$ lsblk -f
NAME   FSTYPE  FSVER            LABEL                  UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
sr0    iso9660 Joliet Extension d-live 13.5.0 kd amd64 2026-05-16-09-42-04-00                               
vda                                                                                                         
├─vda1 vfat    FAT32                                   8FCE-9FB4                                69M    11% /boot/efi
├─vda2 ext4    1.0                                     d61d53ab-cf84-46d9-81e3-03dc093713d0    1.4G    15% /boot
└─vda3 btrfs                                           86898dd4-44d9-4e7b-be5d-fa42a32561fa   54.8G    21% /.snapshots
                                                    /
boris@debian13VM:~$ sudo btrfs subvolume list /
[sudo] password for boris:  
ID 258 gen 597 top level 5 path @snapshots
ID 259 gen 542 top level 258 path @snapshots/16/snapshot
ID 260 gen 548 top level 258 path @snapshots/17/snapshot
ID 261 gen 557 top level 258 path @snapshots/18/snapshot
ID 262 gen 558 top level 258 path @snapshots/19/snapshot
ID 263 gen 560 top level 258 path @snapshots/20/snapshot
ID 264 gen 565 top level 258 path @snapshots/21/snapshot
ID 265 gen 577 top level 258 path @snapshots/22/snapshot
ID 266 gen 600 top level 5 path @root_active
ID 267 gen 578 top level 258 path @snapshots/23/snapshot
ID 268 gen 596 top level 258 path @snapshots/24/snapshot
boris@debian13VM:~$ mount | grep @root_active
/dev/vda3 on    /   type btrfs 
(rw,noatime,compress=zstd:3,discard=async,space_cache=v2,subvolid=266,subvol=/@root_active)
boris@debian13VM:~$ mount | grep @snapshots
/dev/vda3 on   /.snapshots   type btrfs (rw,noatime,compress=zstd:3,discard=async,space_cache=v2,subvolid=258,subvol=/@snapshots)

 

======================= 

Starting point 

======================= 

mkdir -p /mnt/btrfs_root
mount -o subvolid=5 /dev/vda3 /mnt/btrfs_root
mkdir -p /mnt/btrfs_root/btrfs_base
btrfs subvolume snapshot /mnt/btrfs_root/@rootfs                                /mnt/btrfs_root/btrfs_base/@root_active
mv /mnt/btrfs_root/btrfs_base/@root_active                                              /mnt/btrfs_root/@root_active
rmdir /mnt/btrfs_root/btrfs_base
umount /mnt/btrfs_root
=================================
mkdir -p /mnt/system-root
mount -o subvol=@root_active /dev/vda3 /mnt/system-root
mount /dev/vda2 /mnt/system-root/boot
mount /dev/vda1 /mnt/system-root/boot/efi
for i in /dev /dev/pts /proc /sys /run; do mount -B $i /mnt/system-root$i; done
=================================
Setup @root_active
======= Add row  
subvol=@root_active  ============
nano /mnt/system-root/etc/fstab

boris@debian13VM:~$ sudo cat /etc/fstab
# /etc/fstab: static file system information.
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# systemd generates mount units based on this file, see systemd.mount(5).
# Please run 'systemctl daemon-reload' after making changes here.
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
# / was on /dev/vda3 during installation
# UUID=86898dd4-44d9-4e7b-be5d-fa42a32561fa /               btrfs   defaults,subvol=@rootfs 0       0
UUID=86898dd4-44d9-4e7b-be5d-fa42a32561fa   /    btrfs  defaults,subvol=@root_active,compress=zstd,noatime  0   1
UUID=86898dd4-44d9-4e7b-be5d-fa42a32561fa   /.snapshots     btrfs  subvol=@snapshots,compress=zstd,noatime  0    0
# /boot was on /dev/vda2 during installation
UUID=d61d53ab-cf84-46d9-81e3-03dc093713d0 /boot           ext4    defaults        0       2
# /boot/efi was on /dev/vda1 during installation
UUID=8FCE-9FB4  /boot/efi       vfat    umask=0077      0       1
/dev/sr0        /media/cdrom0   udf,iso9660 user,noauto     0       0

 
=============================================== 
chroot /mnt/system-root /bin/bash  
grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=debian --recheck  
grub-install --target=x86_64-efi --efi-directory=/boot/efi --removable  
update-initramfs -u -k all  
update-grub
exit
===============================
for i in /run /sys /proc /dev/pts /dev; do umount /mnt/system-root$i; done
umount /mnt/system-root/boot/efi
umount /mnt/system-root/boot
sed -i 's/rootflags=subvol=@rootfs/rootflags=subvol=@root_active/g' /boot/grub/grub.cfg
reboot
===============================
sudo update-grub
sudo mkdir -p /mnt/btrfs_base
sudo mount -o subvolid=5 /dev/vda3 /mnt/btrfs_base
sudo btrfs subvolume create /mnt/btrfs_base/@snapshots
sudo snapper -c root create-config /
sudo btrfs subvolume delete /.snapshots
sudo mkdir /.snapshots
====== Add row 
 subvol=@snapshots ===============
sudo nano /etc/fstab

boris@debian13VM:~$ sudo cat /etc/fstab
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
# / was on /dev/vda3 during installation
# UUID=86898dd4-44d9-4e7b-be5d-fa42a32561fa    /               btrfs   defaults,subvol=@rootfs 0       0
UUID=86898dd4-44d9-4e7b-be5d-fa42a32561fa      /       btrfs  defaults,subvol=@root_active,compress=zstd,noatime  0    1
UUID=86898dd4-44d9-4e7b-be5d-fa42a32561fa   /.snapshots  btrfs  subvol=@snapshots, compress=zstd,noatime 0 0
# /boot was on /dev/vda2 during installation
UUID=d61d53ab-cf84-46d9-81e3-03dc093713d0 /boot           ext4    defaults        0       2
# /boot/efi was on /dev/vda1 during installation
UUID=8FCE-9FB4  /boot/efi       vfat    umask=0077      0       1
/dev/sr0        /media/cdrom0   udf,iso9660 user,noauto     0       0

================================================== 
sudo systemctl daemon-reload
sudo mount -a
sudo chmod 750 /.snapshots
sudo umount /mnt/btrfs_base
sudo snapper -c root create --description "First baseline snapshot" 

boris@debian13VM:~$ findmnt   /
TARGET SOURCE                   FSTYPE OPTIONS
/      /dev/vda3[/@root_active] btrfs  rw,noatime,compress=zstd:3,discard=async,space_cache=v2,subvolid=266,subvol=/@root_active
boris@debian13VM:~$ findmnt    /.snapshots
TARGET      SOURCE                 FSTYPE OPTIONS
/.snapshots /dev/vda3[/@snapshots] btrfs  rw,noatime,compress=zstd:3,discard=async,space_cache=v2,subvolid=258,subvol=/
@snapshots

Kernel 7.0.13 has been back ported from Sid to Trixie  












UPDATE as of 07/03/26

How CachyOS Execute the Restore via CLI (ssh remote connection)
If you are connected via SSH to the read-only instance, btrfs-assistant provides a minimal CLI  wrapper explicitly built for execution when a GUI environment is unavailable.
   First list the available snapshots. Run the following command to check your index numbers:
$ sudo btrfs-assistant --list
   Second restore your target snapshot to roll back the root system to your desired state  (e.g. snapshot with <ID>), invoke the restore command using its target index:  $ sudo btrfs-assistant --restore <ID>  
When you trigger the restore, btrfs-assistant uses its built-in logic to handle the layout flawlessly:  It safely detaches or mirrors the nested subvolumes (.snapshots, var/lib/portables,var/lib/machines) out of the active path. It backs up your current broken @ layout into a secondary subvolume (often named root_broken either root_backup).  It creates a fresh, fully writable clone of selected snapshot directly under subvolume ID 5 named @.It seamlessly migrates your nested .snapshots infrastructure back under the newly restored @ layout

END UPDATE


Friday, June 26, 2026

Sparky-aptus-upgrade on Sparky Linux 2026 06 instance in UEFI mode

One of the most recent  sparky-aptus-upgrade wipes out old boot-loader and prompts you to install new boot-loader . It suggests the options vda,vda2 (/boot ext4),vda3 ("/" btrfs) , neither one of options suggested is correct due to /boot/efi is mounted on /dev/vda1.  The workaround is to reject install new boot-loader and wait until  sparky-aptus-upgrade would exit warning you that boot-loader is missing. Then initiate ssh session to instance of Sparky Linux and issue 



$ sudo grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=sparky --recheck && \
sudo grub-install --target=x86_64-efi --efi-directory=/boot/efi --removable && \
sudo update-grub

root@devs-SVX8664:~# lsblk -o NAME,FSTYPE,MOUNTPOINT,PARTTYPE | grep -i c12a7328
├─vda1 vfat   /boot/efi  c12a7328-f81f-11d2-ba4b-00a0c93ec93b
├─vda2 ext4   /boot      c12a7328-f81f-11d2-ba4b-00a0c93ec93b
root@devs-SVX8664:~# find / -name grubx64.efi -print
/boot/efi/EFI/sparky/grubx64.efi
/boot/efi/EFI/debian/grubx64.efi
/boot/efi/EFI/boot/grubx64.efi
/usr/lib/grub/x86_64-efi/monolithic/grubx64.efi

 

$ sudo reboot  

This step is important for successful executing of disaster  recovery procedure on Sparky Linux 2026 06 instance with "/" on BTRFS . All commands below are supposed to run in Sparky Live Instance environment against Sparky instance been crashed on vda device (VENV simulation)  

*****************************************************            Phase 1 (in general, standard step utilizing low level btrfs CLI)  

***************************************************** 

# 1. Create mount anchors
mkdir -p /mnt/btrfs-top   /mnt/system-root
 
# 2. Mount top-level BTRFS volume
mount -o subvolid=5 /dev/vda3   /mnt/btrfs-top
 
# 3. Move broken subvolume out of the way
mv /mnt/btrfs-top/@     /mnt/btrfs-top/@_broken
 
# 4. Clone snapshot to target @ (Verify your exact Timeshift folder path here)
btrfs subvolume snapshot /mnt/btrfs-top/timeshift-btrfs/snapshots/YYYY-MM-DD_HH-MM-SS/@  /mnt/btrfs-top/@
 
******************************************** 
Phase 2 ( /boot/efi recovery  proposed by Google AI )
*************************************************
 # 5. Mount newly restored root subvolume
mount -o subvol=@ /dev/vda3 /mnt/system-root
 
# 6. Mount dedicated boot partition
mount /dev/vda2 /mnt/system-root/boot
 
# 7. Wipe and re-create the corrupted FAT32 EFI partition
mkfs.vfat -F32 /dev/vda1
 
# 8. Mount the freshly formatted EFI partition
mount /dev/vda1 /mnt/system-root/boot/efi
 
# 9. Bind-mount required virtual filesystems
for i in /dev /dev/pts /proc /sys /run; do mount -B $i /mnt/system-root$i; done
 
# 10. AUTOMATIC FSTAB REPAIR: Fixed regex for FAT32 UUID matching
NEW_UUID=$(blkid -s UUID -o value /dev/vda1)
sed -i -E "s/UUID=\S+(.*\/boot\/efi)/UUID=$NEW_UUID\1/" /mnt/system-root/etc/fstab
 
# 11. Enter the restored operating system jail and restore both EFI targets
chroot /mnt/system-root /bin/bash -c "
grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=sparky --recheck && \
grub-install --target=x86_64-efi --efi-directory=/boot/efi --removable && \
update-grub
"                                                                                                      
# 12. Clean up and restart
cd /
umount -R /mnt/system-root
umount -R /mnt/btrfs-top
poweroff
 











UPDATE as of 07/03/26

How CachyOS Execute the Restore via CLI (ssh remote connection)
If you are connected via SSH to the read-only instance, btrfs-assistant provides a minimal CLI  wrapper explicitly built for execution when a GUI environment is unavailable.
   First list the available snapshots. Run the following command to check your index numbers:
$ sudo btrfs-assistant --list
   Second restore your target snapshot to roll back the root system to your desired state  (e.g. snapshot with <ID>), invoke the restore command using its target index:  $ sudo btrfs-assistant --restore <ID>  
When you trigger the restore, btrfs-assistant uses its built-in logic to handle the layout flawlessly:  It safely detaches or mirrors the nested subvolumes (.snapshots, var/lib/portables,var/lib/machines) out of the active path. It backs up your current broken @ layout into a secondary subvolume (often named root_broken either root_backup).  It creates a fresh, fully writable clone of selected snapshot directly under subvolume ID 5 named @.It seamlessly migrates your nested .snapshots infrastructure back under the newly restored @ layout

 

END UPDATE
 

Monday, June 8, 2026

FEDORA SERVER 44 BTRFS SETUP and RECOVERY ENGINE (Assisted by Google AI)

UPDATE as 06/16/2026 

Under certain circumstances another disk layout as shown below might the preferable choice

NAME   FSTYPE FSVER LABEL        UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
sr0                                                                                   
zram0  swap   1     zram0        775647cc-87b6-4e33-a0ea-26d6d18a932c                [SWAP]
vda                                                                                   
├─vda1 vfat   FAT32              0DF8-7114                            1014.1M     1% /boot/efi
└─vda2 btrfs        fedoraVolume 36f60181-685e-4fab-81f9-c9133a34f280   85.7G                                     3% /.snapshots
                                                                                    /home
                                                                                    /

$ findmnt -t btrfs
TARGET      SOURCE               FSTYPE OPTIONS
/           /dev/vda2[/root]     btrfs  rw,relatime,seclabel,compress=zstd:1,discard=async,space_cache=v2,subvolid=266,subvol=/root
├─/.snapshots
│           /dev/vda2[/snapshots]
│                                btrfs  rw,relatime,seclabel,compress=zstd:1,discard=async,space_cache=v2,subvolid=256,subvol=/snapshot
└─/home     /dev/vda2[/home]     btrfs  rw,relatime,seclabel,compress=zstd:1,discard=async,space_cache=v2,subvolid=257,subvol=/home

END UPDATE 
  In general, instance setup was proposed by Google AI (1-5). My choice was to create four subvolumes followed by "Trick snapper method". (6) I've also suggested to run critical "btrfs subvolume snapshot  /mnt/btrfs-top/snapshots/<RECOVERY_SNAPSHOT_ID>/snapshot  /mnt/btrfs-top/root" inside the Live F44 (KDE Plasma) instance against crashed instance F44 Server been built on top vda with flat architecture been spread across four btrfs subvolumes "root","home","boot" and ".snapshots"

Original vda layout setup via Anaconda Blivet GUI installation
=====================================================
boris@fedoraSRV0609:~$ lsblk -f
 
NAME   FSTYPE  FSVER            LABEL              UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
zram0  swap    1                zram0              4f083286-72fc-49fc-807d-d4f9a45b447a                [SWAP]
vda
├─vda1 vfat    FAT32                               1C26-CCBE                            1014.1M     1%                           /boot/efi
└─vda2 btrfs                    fedora-volume      0bdb9d96-5296-4aec-a2a9-e2aceb9f18fd   91.8G     7% /home
                                                                                                                                                                                        /boot
                                                                                                                                                                                        /.snapshots
                                                                                                                                                                                        /
 
Originally created /etc/fstab stays untouched due to Trick Snapper Method
 
boris@fedoraSRV0609:~$ cat /etc/fstab
# /etc/fstab
# Created by anaconda on Mon Jun  8 09:56:27 2026
# Accessible filesystems, by reference, are maintained under '/dev/disk/'.
# See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info.
# After editing this file, run 'systemctl daemon-reload' to update systemd
# units generated from this file.
UUID=0bdb9d96-5296-4aec-a2a9-e2aceb9f18fd / btrfs subvol=root,compress=zstd:1 0 0
UUID=0bdb9d96-5296-4aec-a2a9-e2aceb9f18fd /.snapshots btrfs subvol=snapshots,compress=zstd:1 0 0
UUID=0bdb9d96-5296-4aec-a2a9-e2aceb9f18fd /boot btrfs subvol=boot,compress=zstd:1 0 0
UUID=1C26-CCBE /boot/efi vfat umask=0077,shortname=winnt 0 2
UUID=0bdb9d96-5296-4aec-a2a9-e2aceb9f18fd /home btrfs subvol=home,compress=zstd:1 0 0
 
$ sudo dnf install btrfs-assistant snapper gawk inotify-tools libdnf5-plugin-actions git make -y
========================
Trick Snapper Method
========================
$ sudo umount /.snapshots
$ sudo rmdir    /.snapshots
$ sudo snapper -c root create-config  /
$ sudo mount  /.snapshots
                                                   
1. MANUAL GRUB-BTRFS ENHANCEMENT FROM SOURCE
-----------------------------------------------------------------------------------------
$ cd grub-btrfs
$ sudo make install
 
# Modify /etc/default/grub-btrfs/config with these parameters:
GRUB_BTRFS_GRUB_DIRNAME="/boot/grub2"
GRUB_BTRFS_MKCONFIG="/usr/bin/grub2-mkconfig"
GRUB_BTRFS_SCRIPT_CHECK="grub2-script-check"
 
$ sudo grub2-mkconfig -o /boot/grub2/grub.cfg
$ sudo systemctl daemon-reload
$ sudo systemctl enable --now grub-btrfsd
 
2. DNF5 TRANSACTION SNAPSHOT AUTOMATION ENGINE
----------------------------------------------------------------------------------------
sudo nano /usr/local/bin/dnf5-snapper-helper
 
#!/bin/bash
case "$1" in
    pre)
        /usr/bin/snapper -c root create -t pre -p -d "DNF Transaction" -c number > /tmp/snapper_pre_id
        ;;
    post)
        if [ -f /tmp/snapper_pre_id ]; then
            PRE_ID=$(cat /tmp/snapper_pre_id)
            /usr/bin/snapper -c root create -t post --pre-num "$PRE_ID" -d "DNF Transaction Complete" -c number
            rm -f /tmp/snapper_pre_id
        fi
        ;;
esac
 
$ sudo chmod +x /usr/local/bin/dnf5-snapper-helper
$ sudo nano /etc/dnf/libdnf5-plugins/actions.d/snapper.actions
 
pre_transaction::::/usr/local/bin/dnf5-snapper-helper pre
post_transaction::::/usr/local/bin/dnf5-snapper-helper post
 
3. HOUSEKEEPING RETENTION MANAGEMENT
---------------------------------------------------------------------------------------
# Modify /etc/snapper/configs/root with these parameters:
NUMBER_MIN_AGE="1800"
NUMBER_LIMIT="10"
NUMBER_LIMIT_IMPORTANT="10"
TIMELINE_LIMIT_HOURLY="0"
TIMELINE_LIMIT_DAILY="0"
TIMELINE_LIMIT_WEEKLY="0"
TIMELINE_LIMIT_MONTHLY="0"
TIMELINE_LIMIT_YEARLY="0"
 
4. RUNTIME LIVE CLI RECOVERY (WRITABLE SESSIONS ONLY)
---------------------------------------------------------------------------------------
$ sudo btrfs-assistant --restore <SNAPSHOT_ID>
$ sudo reboot
 
5. CLEANUP LEFTOVERS AFTER DEPLOYMENT SWAPS
---------------------------------------------------------------------------------------
$ sudo mkdir -p /mnt/btrfs-top
$ sudo mount -o subvolid=5 /dev/vda2 /mnt/btrfs-top
$ sudo btrfs subvolume delete /mnt/btrfs-top/root_dead
$ sudo btrfs subvolume delete /mnt/btrfs-top/root_broken
$ sudo umount /mnt/btrfs-top
$ sudo rmdir /mnt/btrfs-top
 
Device order during normal runtime
 












Device order to recover via mounting /dev/vda2 on /mnt/btrfs-top 
 

 
6.BARE-METAL BTRFS LIVE ISO RECOVERY PROTOCOL
----------------------------------------------------------------------------------------
Virtual emulation follows below
Right after crash shutdown instance. Switch order of boot-able devices to F44 ( say KDE Plasma ) Live CD and boot up having both device attached to virt-manager session. Commands below are supposed to run in F44 Live Instance environment see snapshots above. They may be cut from Host and paste into spice console.
As liveuser execute  
$ sudo su -
# mkdir -p  /mnt/btrfs-top
# mount -o subvolid=5  /dev/vda2   /mnt/btrfs-top
Next step is required to detect correct snapshot  <RECOVERY_SNAPSHOT_ID>
# btrfs subvolume list /mnt/btrfs-top
# mv /mnt/btrfs-top/root      /mnt/btrfs-top/root_broken
# btrfs subvolume snapshot   /mnt/btrfs-top/snapshots/<RECOVERY_SNAPSHOT_ID>/snapshot      /mnt/btrfs-top/root
# umount /mnt/btrfs-top
 
Then shutdown Live instance and switch order of boot-able devices back to vda and attempt to boot up from recovered virtual drive
 

 ==========================================
Remote SSH session to recover
 /lib/modules/*

==========================================
liveuser@localhost-live:~$  sudo su -
[sudo] password for liveuser:
root@localhost-live:~# mkdir -p  /mnt/btrfs-top
root@localhost-live:~# mount -o subvolid=5  /dev/vda2   /mnt/btrfs-top
Next step is required to detect correct snapshot  (8)
root@localhost-live:~# btrfs subvolume list /mnt/btrfs-top
root@localhost-live:~# mv /mnt/btrfs-top/root      /mnt/btrfs-top/root_broken
root@localhost-live:~# btrfs subvolume snapshot   /mnt/btrfs-top/snapshots/8/snapshot /mnt/btrfs-top/root
Create snapshot of '/mnt/btrfs-top/snapshots/8/snapshot' in '/mnt/btrfs-top/root'
root@localhost-live:~#  umount /mnt/btrfs-top
root@localhost-live:~# poweroff
Broadcast message from root@fedora on pts/3 (Wed 2026-06-10 09:29:18 UTC):
The system will power off now!
Read from remote host 192.168.0.34: Connection reset by peer
Connection to 192.168.0.34 closed.
client_loop: send disconnect: Broken pipe
REBOOT
Check your /etc/fstab
boris@fedoraSRV:~$ cat /etc/fstab
UUID=13868649-f7e9-42a0-b897-3daeb1b442bf / btrfs subvol=root,compress=zstd:1 0 0
UUID=13868649-f7e9-42a0-b897-3daeb1b442bf /.snapshots btrfs subvol=snapshots,compress=zstd:1 0 0
UUID=13868649-f7e9-42a0-b897-3daeb1b442bf /boot btrfs subvol=boot,compress=zstd:1 0 0
UUID=A3DC-5B31 /boot/efi vfat umask=0077,shortname=winnt 0 2
UUID=13868649-f7e9-42a0-b897-3daeb1b442bf /home btrfs subvol=home,compress=zstd:1 0 0

Due to  flat layout, snapshots directory lives completely outside the root folder at the top level (subvolid=5).
By simply running the btrfs subvolume snapshot command a clean, independent root would be created.
Fedora's GRUB will look for subvol=root, find it, its Machine ID matches perfectly,and boot right up.