eselarm

It is now half a year later, this SD-card was put back into the RPi4 and no issues there. The RPi4 has been upgraded from Bookworm to Trixie in-place (just latest pre-release) so gets quite some writes. It still has Bookworm Btrfs snapshot as well, total of about 9GB excluding 2GB swap partition and 512MB bootFAT. Avarage Btrfs scrub speed 41MB/s. The ROCK3A has no SD-card inserted anymore, running fine, except that in the last 40 days I see: root@rock3a:~# uname -a Linux rock3a 6.1.115-vendor-rk35xx #1 SMP Fri May 30 01:18:17 UTC 2025 aarch64 GNU/Linux root@rock3a:~# dmesg | grep "page allocation failure:" [ 527.016616] dmcrypt_write/2: page allocation failure: order:0, mode:0x800(GFP_NOWAIT), nodemask=(null),cpuset=/,mems_allowed=0 [2879228.441453] dec0:0:hevc_rkm: page allocation failure: order:5, mode:0x40dc0(GFP_KERNEL|__GFP_COMP|__GFP_ZERO), nodemask=(null),cpuset=user.slice,mems_allowed=0 [2879523.127829] dec0:0:hevc_rkm: page allocation failure: order:5, mode:0x40dc0(GFP_KERNEL|__GFP_COMP|__GFP_ZERO), nodemask=(null),cpuset=user.slice,mems_allowed=0 [3029341.482298] kworker/0:1: page allocation failure: order:0, mode:0x800(GFP_NOWAIT), nodemask=(null),cpuset=/,mems_allowed=0 The middle 2 is clear what source is, the others I do not know. I think I will first upgrade userspace to Trixie. I currently have no clue what the details w.r.t. page faults mean, so have to see and figure out what issue could be or maybe mitigate somehow.

Yes it is dead, that is why my comments between brackets. Start with http://beta.armbian.com then click with your mouse per sub object. Or wait until it is out of beta phase or modify your sources.list.d

i do not use armbian-config normally, but there is a 6.12.35 here http://beta.armbian.com/pool/main/l/linux-6.12.35/ (fix or edit or follow path/mirror youself)

@Ryzer just started it, was updated a week ago or so: root@banlipi:~# uname -a Linux banlipi 6.12.30-current-sunxi #1 SMP Thu May 22 12:29:54 UTC 2025 armv7l GNU/Linux root@banlipi:~# dmesg | grep drm [ 0.996620] sun4i-drm display-engine: bound 1e00000.display-frontend (ops 0xc0bb0c8c) [ 0.996924] sun4i-drm display-engine: bound 1e20000.display-frontend (ops 0xc0bb0c8c) [ 0.997494] sun4i-drm display-engine: bound 1e60000.display-backend (ops 0xc0bb03f8) [ 0.997999] sun4i-drm display-engine: bound 1e40000.display-backend (ops 0xc0bb03f8) [ 0.998903] sun4i-drm display-engine: No panel or bridge found... RGB output disabled [ 0.998973] sun4i-drm display-engine: bound 1c0c000.lcd-controller (ops 0xc0bae8e8) [ 0.999936] sun4i-drm display-engine: No panel or bridge found... RGB output disabled [ 1.000015] sun4i-drm display-engine: bound 1c0d000.lcd-controller (ops 0xc0bae8e8) [ 1.002143] sun4i-drm display-engine: bound 1c16000.hdmi (ops 0xc0bb1688) [ 1.004289] [drm] Initialized sun4i-drm 1.0.0 for display-engine on minor 0 [ 1.004495] sun4i-drm display-engine: [drm] Cannot find any crtc or sizes [ 1.032416] sun4i-drm display-engine: [drm] Cannot find any crtc or sizes [ 6.475086] [drm] Initialized lima 1.1.0 for 1c40000.gpu on minor 1 [ 11.323101] systemd[1]: Starting modprobe@drm.service - Load Kernel Module drm... [ 12.107664] systemd[1]: modprobe@drm.service: Deactivated successfully. [ 12.124764] systemd[1]: Finished modprobe@drm.service - Load Kernel Module drm. no newer kernel available via apt now I see when running update.

BananaPi M1 is A20 SoC. I have 1 but not using HDMI. I just have a permanent USB serial console cable connected to it, much easier than HDMI+keyboard.

Maybe, but maybe the issue won't occur then. If you want it reproducable, first for yourself, make a complete image of that USB stick on other large storage device and use that as 'master problem disk'. I have an old PC with 3x 4T HDD Btrfs multidevice formatted for such cases. Btrfs can make reflink copies or do RW snapshots, so easy and fast to create a slightly modified image. There is gddrescue to make initial copy from USB-stick. Also this is a USB-stick in an SBC, all sorts of power issues might also be a root cause. You can use nbd-server and nbd-client to make large/huge images available via network, I do that for my BananaPi M1 (8T HDD). In the past for Btrfs kernel development itself for example, there was/is? a metadata only imager tool, so in case of a complex filesystem bug, you can share only meta data, the data is actually zeroed/sparse. But you need a good extra Linux computer, Windows exFAT handling makes little sense. Best to also test/use the image with a generic Debian Bookworm/Trixie computer, I use a Armbian virtual machine for such a case, running on RPi4 (if 32-bit) or ROCK5B (64-bit only). They can use NBD (as client). AFAIR you can use the sunxi kernel directly in a KVM, at least did something with a NanoPi-NEO image (same kernel as well).

root@rock3a:/lan/tmp# ffmpeg -i file1.AV1.mkv -c:v hevc_rkmpp -c:a copy file1.x265.mkv ffmpeg version 5.1.6-0+deb12u1 Copyright (c) 2000-2024 the FFmpeg developers ... Unknown encoder 'hevc_rkmpp' root@rock3a:/lan/tmp# /usr/share/jellyfin-ffmpeg/ffmpeg -i file1.AV1.mkv -c:v hevc_rkmpp -c:a copy file1.x265.mkv ffmpeg version 7.0.2-Jellyfin Copyright (c) 2000-2024 the FFmpeg developers ... [out#0/matroska @ 0xaaaaeff1e660] video:223157KiB audio:6460KiB subtitle:0KiB other streams:0KiB global headers:0KiB muxing overhead: 0.220596% frame=27421 fps=138 q=-0.0 Lsize= 230124KiB time=00:15:21.52 bitrate=2045.7kbits/s speed=4.64x video plays fine You might have power issues, that is my thirst thought, as I had several issues with my rock3a when I used USB-C (so with default PD with 5V). Now 12V in and user on-board DC-DC to do proper feeding. OPi5 does not have this AFAIK from schematics. But is is a wild guess. Many other things can be wrong, like who knows something with iommu (I guess not). I might try same command sometime later on my NanoPi-R6C when I will upgrade Armbian from Bookworm to Testing/Trixie, it also has RK3588S, same as OPi5, but check this, it is just top-of-my-head. I use mainline kernels mostly now, so need to tune grub or so first.

My pihole is a virtual machine; I do not use SD-card for it, I keep virtual machine 'objects' around on various machines, so I do not have to wait 'burning' SD-cards. I can tell way more to prevent further assumptions being made about how I operate computers in my home and foreign country, but this is getting boring. I won't click all the various URLs. I would rather start using bcachefs (again) and see how long it will take before Kent Overstreet will have added a send|receive in there like now is available in ZFS and Btrfs. But it seems you did not get the point that I use the word 'snapshot' to identify both: (pseudo code) raspi1:/.snapshots/numberX/snapshot and othermachine:/backups/numberY/snapshot (and multiple othermachines, clone NAS as I said) On raspi1 it is local on SD-card, on othermachine(s) is the exact same filetree and same subvol (received) UUID. If I would not trust btrfs send|receive, which could be the case sometimes when doing btrfs development kernel patching around 2013 timeframe, I could do a an rsync -avxc between the 2, where 1 side is a just taken RW snapshot of the otherwise RO snapshot. So you will see rsync do writes to the RW subvol if something had gone wrong with kernel implementation or userspace. Or if i manually poked 1 sector random data in some some random file at some random offset (simulating a HDD bad sector). I have done that as test several times. It take time to do that between 2 4TB HDDs but not a problem.

do you have correct permissions? maybe run as root on my rock3a content is fine but got [Jul 4 20:19] warn_alloc: 19 callbacks suppressed [ +0.000026] dec0:0:hevc_rkm: page allocation failure: order:5, mode:0x40dc0(GFP_KERNEL|__GFP_COMP|__GFP_ZERO), nodemask=(null),cpuset=user.slice,mems_allowed=0 [ +0.000115] CPU: 2 PID: 2339021 Comm: dec0:0:hevc_rkm Not tainted 6.1.115-vendor-rk35xx #1 [ +0.000011] Hardware name: Radxa ROCK3 Model A (DT) [ +0.000011] Call trace: [ +0.000008] dump_backtrace+0xf0/0x12c [ +0.000023] show_stack+0x20/0x30 [ +0.000011] dump_stack_lvl+0x7c/0xa0 [ +0.000016] dump_stack+0x18/0x34 [ +0.000010] warn_alloc+0xe0/0x17c [ +0.000012] __alloc_pages+0x524/0x854 [ +0.000010] __kmalloc_large_node+0xb8/0x114 [ +0.000012] __kmalloc+0x4c/0x100 [ +0.000009] __regset_get+0x60/0xd8 [ +0.000013] regset_get_alloc+0x1c/0x28 [ +0.000010] elf_core_dump+0x500/0xbc8 [ +0.000011] do_coredump+0xabc/0x100c [ +0.000012] get_signal+0x1b8/0x634 [ +0.000013] do_notify_resume+0x194/0xda8 [ +0.000010] el0_da+0x5c/0x70 [ +0.000012] el0t_64_sync_handler+0xc0/0x13c [ +0.000010] el0t_64_sync+0x19c/0x1a0 [ +0.000013] Mem-Info: [ +0.000010] active_anon:112109 inactive_anon:125820 isolated_anon:0 active_file:31285 inactive_file:45270 isolated_file:0 unevictable:0 dirty:2210 writeback:0 slab_reclaimable:16665 slab_unreclaimable:16446 mapped:15455 shmem:105 pagetables:1861 sec_pagetables:510 bounce:0 kernel_misc_reclaimable:0 free:82604 free_pcp:125 free_cma:35560 [ +0.000022] Node 0 active_anon:448436kB inactive_anon:503280kB active_file:125140kB inactive_file:181080kB unevictable:0kB isolated(anon):0kB isolated(file):0kB mapped:61820kB dirty:8840kB writeback:0kB shmem:420kB writeback_tmp:0kB kernel_stack:4192kB pagetables:7444kB sec_pagetables:2040kB all_unreclaimable? no [ +0.000017] DMA free:330416kB boost:14364kB min:19988kB low:21964kB high:23940kB reserved_highatomic:2048KB active_anon:448188kB inactive_anon:503568kB active_file:125312kB inactive_file:181216kB unevictable:0kB writepending:8840kB present:2095104kB managed:2014252kB mlocked:0kB bounce:0kB free_pcp:544kB local_pcp:0kB free_cma:142240kB [ +0.000018] lowmem_reserve[]: 0 0 0 0 [ +0.000015] DMA: 20626*4kB (UMEHC) 16291*8kB (UMEHC) 4462*16kB (UMHC) 1263*32kB (UMHC) 92*64kB (MHC) 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 330528kB [ +0.000049] Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=1048576kB [ +0.000010] Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=32768kB [ +0.000008] Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=2048kB [ +0.000009] Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=64kB [ +0.000008] 129311 total pagecache pages [ +0.000007] 52636 pages in swap cache [ +0.000006] Free swap = 11240188kB [ +0.000007] Total swap = 11792380kB [ +0.000006] 523776 pages RAM [ +0.000006] 0 pages HighMem/MovableOnly [ +0.000006] 20213 pages reserved [ +0.000007] 135168 pages cma reserved command used /usr/share/jellyfin-ffmpeg/ffmpeg -y -c:v hevc_rkmpp -i 2025-06-29_22-05_rec.ts -map v -c:v h264 _rkmpp -b:v 8000k -map 0:1 -c:a copy -t 300 dvbt2.h264.ts

I have a BananaPi M1, same SoC, same kernel (the upgrade went fine for me last week). Although I only use it for its SATA connector (big HDD as NBD, OS on SD-card), audio 3.5mm plug did work. Maybe I could see what mine does, but rather with a default Debian player, like mpv, works via ssh CLI. I can generate some FLAC file, but I don't want to search for the specific song/title. Also I could do a temp exfat on a loopdev or so or just play from NFS, Btrfs or Ext4 loopdev.

I know, but who cares if it is impractical IMO and various distros by default use that path. And RPiOS needs /boot/firmware, I myself use also /boot/uboot so I am more flexible w.r.t bootloaders. What is on boot FAT or in SPI-flash or tftpboot or else is secondary, the master (from package manager) is in rootfs. Read back my 1st message; there is option -p A snapshot is identified by its UUID, whether local or remote/other/foreign filesystem. So my backup tool/script figures that out. If an SD-card would be end of life or damaged scrub will notice it and then I regenerate the whole thing on a new SD-card from the latest transferred snapshot. I do not use /home for any meaningful data. All is on NAS. Some have no local storage except SPI for bootloader. I also treat all Linux computers the same, except those that are NAS or a clone of it. For rare Windows I indeed use 'imaging' although there is WinBTRFS.

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?

The foreign added SPI-flash makes it custom in terms of Armbian bootloader. Look how to build U-Boot from Armbian build environment (development basically) or find howto on denx.de. It been a while since I last did that myself, so things might have changed a bit.

That is because it is the linux kernel that is driving you own/custom SPI-flash chip. When you power on the board, it follows a certain priority of devices, see schematics of the board. It might be that SPI-flash is not included. And if included, the U-Boot you put in there might assume different wiring or none at all. It is can be because the U-Boot config it is compiled from does not include the right options. So create a custom U-Boot for your custom board.