About 10 years ago Suse had own patched/enhanced variant of GRUB that knows about BTRFS subvolumes. For desktop PC that usually have a keyboard and monitor, you can select boot from 'last-known-good' snapshot(= just a BTRFS subvolume, usually read-only). I do not know the current status of it, I use a manual own (scripted) setting of default subvolume. All tools not BTRFS aware see then just /boot /var /etc and so on If they mount the filesystem. But if you use mount option subvolid=0 you would see for example /subvols/root20241004/boot /subvols/root20241004/var /subvols/root20241004/etc and so on. Same if you use the command: btrfs subvolume list . Note that '@' in a name is often used to indicate that the path is a subvolume, not a normal directory.In principle it sounds like most of the work is done by btrfs. Let's assume timeshift doesn't barf on an rpi command line restore - maybe that doesn't happen under bookworm (or can be fixed). Timeshift can be told not to do grub. All it needs to know is about is the fat partition and snapshot that somehow - and retrieve it during a restore.
It would take something substantial to shift me off LVM to BTRFS. Being able to dynamically shrink a partition without unmounting is, admittedly, a temptation. A "one click" (one command) restore would be very favourable. I'll stick "grabbing the timeshift" source code onto my 2do list.
Installing on PC from CD-ROM, it created several subvolumes by default so that it works out of the box in combination with a tool called snapper that does timeline and ad-hoc snapshots and also allows you to do file-level compare/diff in GUI. On Debian by default, it creates a snapshot at boot and also every 'apt upgrade' (pre- and post- ).
This all is more for people/developers who do change quite some in roottree etc, but also perfect if you installed some wrong package, kernel with regression, deleted some file that is a week old on external backup.
Now for headless PC/Pi you cannot manually select an older snapshot, so there is an automatic method nowadays, although I do not use that. I do have a lot of simple USB-serial cables hooked up to GPIO14/15 or similar on other SBCs. With U-boot (default on other SBCs) you can interact before Linux kernel operational, so if you keep a daily clone/copy of the whole main NVME/SSD on SD-card or USB-stick you can boot from that. U-boot can read and write FAT in current Bookworm build AFAIR. The issue with the RPi is that firmware+kernel updates are so frequent, that although RPiOS is more or less "stable" Debian Bookworm, the firmware+kernel is like "unstable" or Testing or rolling release.
The other generic non-Debian distros maintain a U-boot/EFI/GRUB layer between RPi (older) firmware and kernel, so kernel is mainly mainline generic for all Aarch64, it is just the kernel=u-boot.bin line in config.txt. Note that on on UEFI(+DeviceTree) boards with that in flashROM, you can hit ESC and walk though FAT filesystems selecting EFI/boot/bootaa64.efi or EFI/debian/grubaa64.efi or so.
Statistics: Posted by redvli — Sun Oct 06, 2024 9:40 am