I use the Station M2 image with dtb joined. Adapt fdtfile entry in /boot/armbianEnv.txt as needed. rk3566-box-demo_x96x6_24-custom.dtb

I get it: DDR Version V1.10 20190926 In ID:0xFFF 330MHz LPDDR3 Bus Width=32 Col=10 Bank=8 Row=15 CS=2 Die Bus-Width=32 Size=2048MB mach:14 rd addr 0xC0000000 = 0xFFED ERR

I had a look in /var/log/gdm3/, which was originally denying me permission but after obtaining access, it is empty, so no GDM log, as least in this folder. I also edited custom.conf to enable GDM logs but it had no effect. I was curious to know why there is a GDM3 folder, rather then GDM.

please show the output of "apt policy zfs-dkms" but essentially, this looks the same as your other rodeo/struggle with this board and dkms. As mentioned there, you are much better off with btrfs instead of zfs on your SBC.

Boring? To learn and have discussions? Strange sentiment. About bcachefs, for your sake, let's hope Linus Torvalds goes back on his comment that he and Kent will split ways in kernel 6.17 then so you won't have to rely on dkms for your unstable filesystem. bcachefs is in beta and should not be used as primary filesystem. Linux kernel mailing list: https://lore.kernel.org/all/CAHk-=wi+k8E4kWR8c-nREP0+EA4D+=rz5j0Hdk3N6cWgfE03-Q@mail.gmail.com/ No, it's impossible to have the same UUID on two btrfs systems at the same time, you can't even format a btrfs system and give it the same UUID, the kernel won't let you. See btrfs documentation: https://btrfs.readthedocs.io/en/latest/Send-receive.html So you are lying for some reason. Maybe the same reason you "don't read links". xD Has nothing to do with "trust", it has to do with how COW and send|receive works witch you don't seem to understand/ignore. And ofc an rsync (suddenly you talk about rsync instead of btrfs send -p) will work, it just checks if the files are changed and update them if necessary, witch is exactly what I have been saying is the better way for backups the whole time. IMHO it's even better to just create the subvolume(s) and rsync from the first run altogether if you want a backup, send|receive is not necessary and is just slow. And in the case of a complete backup incl boot like shrink-backup does by dd:ing the "boot sector" (witch includes potential boot partition), all that has to be done is make sure configs point to the new UUID (in case of rpi derivative systems nothing has to be done, because they use PARTUUID witch can be the same in contrast to UUID). If you "don't want to click links" to learn, I won't pressure you. You already seem triggered for some reason. But for others that might read this I hope my knowledge about backup strategies came through. Again, snapshots are perfect for rollbacks, but NOT for backups. Have a good Saturday.