Thanks for the feedback, If that was the intention. If you try the version on the testing branch, that won't be an issue because 'btrfs du' (it is just slow and unnecessary) is no longer used. xD There are actually more changes coming to btrfs in the next release. Even looking into conversion from ext4 to btrfs. Oddly enough, I can backup my arch system with boot mounted at /boot/efi using the script on main branch, wonder why yours doesn't, so clearly distro DOES matter. But it doesn't matter for the problem you had, because it will be changed anyway. Besides, shrink-backup is not really intended to be used on a desktop computer, it's for sbc:s that usually are way less convoluted than a desktop setup. Interesting to see you use /boot/efi (discouraged by linux kernel standards), and not /boot as boot partition, wonder why? I do the same, because I use timeshift that is built upon snapper. For others reading this: This is because if you roll back a snapshot where you have changed things in boot process and files inside /boot, you kinda want files inside /boot to be rolled back too or your system won't boot, hence letting /boot be part of the root subvolume and mount boot partition on /boot/efi instead. My point was, that the problem you mentioned, the database might become corrupted is not solved by using snapshots and btrfs, a database has to be closed and locked to be 100% sure it won't become corrupted in ANY copy process. (beside the fact that the database in the case of pihole is only a log and has nothing to do with the integrity of the application itself) I completely disagree with that. If I revert a snapshot because I messed something up on my system or something went wrong, witch happens once in a while, I do NOT want my home to be over-written by an old snapshot. I also want to be able to read old log-files to figure out WHAT went wrong, so /home & /var/log in separate snapshots is absolutely a good thing for me. A snapshot takes no time at all, 1s I would guess, but what about the send|receive? Because a snapshot is completely worthless if the filesystem you took the snapshot from becomes corrupt, COW (copy on write) means you use the exact same data. That is why it's (or should be) general knowledge that a snapshot is NOT A BACKUP, but it kinda becomes a backup if you send|receive it to a completely different filesystem. So the interesting part here is the send|receive because op asked about backups, and that takes about as long as a dd would take, while rsync probably does the file transfer in about 10% of that time. Also, again, shrink-backup takes everything, including boot process parts and makes an img file at small size (for two reasons, saving space and ability to use the img file on smaller storage device) that can be written directly instead of also having to do a bunch of pretty complicated restore processes. And quite a few armbian images utilizes u-boot without a boot partition with header data written to the disk before root partition, shrink-backup covers that as-well. Generally, I treat snapshots as they are intended, as snapshots that can be used as RESTORE POINTS, and I use a backup application to make regular BACKUPS. On my desktop computer I use clonezilla that I have added a menu for in grub to easily boot into, and on all my scb:s I obviously use shrink-backup. (for those who don't know, I am the maintainer of shrink-backup)

apparently new images for OrangePi Zero 3 Debian minimal IOT are out on github and the boards page thanks to @Igor, @TRay, et.al. https://www.armbian.com/orange-pi-zero-3/ https://github.com/armbian/community/releases/tag/25.8.0-trunk.309 ^ apparently a big release many images ( e.g. different variants and boards) are updated, but I checked only OrangePi Zero 3 Debian minimal IOT the feature for OrangePi Zero 3 according to recent build release https://github.com/armbian/build/releases/tag/v25.8.0-trunk.293 is https://github.com/armbian/build/pull/8334 the use of u-boot tag:v2025.04 likely improves boot time ddr ram size detection.

The image from https://dl.armbian.com/orangepi5/Noble_vendor_gnome works well for me. It might be good to see some GDM logs as i am not sure where the problem arises from.

Yes, I know how to compile images. I'm still learning how to use git efficiently, though. Git bisect, I had never heard of before; but from what I read, is seems to be the right tool to find the breaking commit. But before I start into this possibly lengthy process, I came up with one theory, that I intend to check first: The initial assumption was, that the error is due to an API incompatibility in the Arm Trusted Firmware. My first intention was, to check if a newer version of the ATF was available, I just didn't know for wich part exactly I should look. Now I found out, that the working Image starts the "BL31"-thing right at the point where the current images fail: So, the first thing for me to check will be which version of "BL31" is used for the current images and if a newer version would be available and could be used instead. Unfortunately, i might not be able to work on this until next week. But I will report back as soon as there is new information.,

I just mention the very basic, Btrfs has way to many features and options to make a generic image creating script. I see already 2 issues in the shrink-backup scrip, simple test: root@rock5b:~ # btrfs filesystem du -s --raw / Total Exclusive Set shared Filename ERROR: not a btrfs filesystem: /boot/efi WARNING: cannot access 'efi': Invalid argument WARNING: cannot access 'boot': Invalid argument ERROR: cannot check space of '/': Invalid argument This is on Opensuse Tumbleweed, but distro should not matter as I have a custom simple subvolume scheme. It is after 10+ years that I have a fully automated methods that just backup the structure I use in every Linux system so that it also can be 'played back' to a (sparse) image file or just raw device. I don't do any resizing, that is not essential to backup; I just re-create that same partition table (also backed up) so I have the same machine after a failed SD-card or HDD with too many bad sectors or just a clone template for a extra new SBC. I use a tool called snapper to create snapshots, both automatic and ad-hoc. It is also integrated in apt and zypper. So before the upgrade to pihole v6, a (read-only) snapshot is created. Also I was bothered by buggy v6, so I just take a read-write snapshot of the last know good/running read-only snapshot and set that that to default, then reboot, or even sync and power cycle. Of course that snapshot (UUID) is also as a differential created tree/folder on my NAS (in case the SD-card or so would fail). Long time ago installers created a lot of subvolumes, like for /home /var/log and many more. That indeed gets into big problems. Just use 1 for the root and snapshot that. That works fine for a workstation like machine with no real data stored locally (all is on NAS). Note that since kernel 6.1, btrfs send can send compressed data, so as it is stored on storage device. That saves time (and money) on mobile links for example. You can compress and decompress via rsync or ssh or vpn, but it costs extra battery energy. Also how long does "make atomic snapshots" take on a 4TB HDD of a subvolume of 2TB you think?