I discovered via an only partly working ssh (I thought was WiFi signal strenght issue or so) that a new version of firewalld was installed and also new conf file that had default set to public instead of trusted (what should be fine for LAN only direct traffic). On a typical generic client-only laptop/computer you probably won't notice. Best is to keep that default and add a zone= statement to the NM profile for a specific connection. I have seen the same for systemd-networkd, but not done anything myself with it. Also should not happen on Debian Stable, but rolling distro is another story.

Hi, I'm testing your Linux image on an Orange Pi 4B/4A with an eMMC installed and wanted to share the results. The image correctly detects the eMMC. The kernel recognizes the device as: mmcblk2: mmc2:0001 ISOCOM 58.3 GiB Operating mode: HS200 image : aurealnix-opi4a-debian13-cli-v0.2.img.xz @AurealNix Thank you for your work. Update: During boot, the kernel reports two reserved-memory warnings: OF: reserved mem: Reserved memory: failed to reserve memory for node 'sec-sram1@42350000' OF: reserved mem: Reserved memory: failed to reserve memory for node 'sec-sram2@43000000' The system remains fully functional. OP-TEE and BL31 reserved-memory nodes are present in the device tree, and eMMC HS200 operation has been tested successfully. root@orangepi-4a:~# uname -a Linux orangepi-4a 6.18.38-g59eb61929e89 #49 SMP PREEMPT Thu Jul 16 00:46:12 CEST 2026 aarch64 GNU/Linux root@orangepi-4a:~# free -m total used free shared buff/cache available Mem: 3830 330 95 9 3592 3500 Swap: 0 0 0 root@orangepi-4a:~# cat /etc/os-release PRETTY_NAME="Debian GNU/Linux 13 (trixie)" NAME="Debian GNU/Linux" VERSION_ID="13" VERSION="13 (trixie)" VERSION_CODENAME=trixie DEBIAN_VERSION_FULL=13.6 ID=debian HOME_URL="https://www.debian.org/" SUPPORT_URL="https://www.debian.org/support" BUG_REPORT_URL="https://bugs.debian.org/" root@orangepi-4a:~# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS mmcblk0 179:0 0 7.4G 0 disk └─mmcblk0p1 179:1 0 7.4G 0 part / mmcblk2 179:32 0 58.3G 0 disk ├─mmcblk2p1 179:33 0 1.2G 0 part └─mmcblk2p2 179:34 0 57.1G 0 part /mnt/emmc-test mmcblk2boot0 179:64 0 4M 1 disk mmcblk2boot1 179:96 0 4M 1 disk root@orangepi-4a:~# fastfetch _,met$$$$$gg. root@orangepi-4a ,g$$$$$$$$$$$$$$$P. ---------------- ,g$$P"" """Y$$.". OS: Debian GNU/Linux 13 (trixie) aarch64 ,$$P' `$$$. Host: OrangePi 4A ',$$P ,ggs. `$$b: Kernel: Linux 6.18.38-g59eb61929e89 `d$$' ,$P"' . $$$ Uptime: 38 mins $$P d$' , $$P Packages: 299 (dpkg) $$: $$. - ,d$$' Shell: bash 5.2.37 $$; Y$b._ _,d$P' Terminal: /dev/pts/2 Y$$. `.`"Y$$$$P"' CPU: sun55i-t527 (8) @ 1.80 GHz `$$b "-.__ GPU: Allwinner sun55i-a523-mali [Integrated] `Y$$b Memory: 331.41 MiB / 3.74 GiB (9%) `Y$$. Swap: Disabled `$$b. Disk (/): 744.36 MiB / 7.19 GiB (10%) - ext4 `Y$$b. Disk (/mnt/emmc-test): 24.49 GiB / 55.91 GiB (44%) - ext4 `"Y$b._ Local IP (eth0): 192.168.7.12/27 `"""" Locale: en_US.UTF-8 root@orangepi-4a:~#

Hi xaja34, The patches and all code modifications used to build the 1 GB Cubie A5E images are already present in my repository. I pushed the complete Git commits alongside the prebuilt images that I published in the Releases section. You can find the changes here: radxa-cubie-a5e-armbian-build@202f1bf Best regards, Guation

@L. Jorge Soares Thanks a lot for testing both — genuinely, this is the most useful thing anyone can do for the project. 🙏 CLI: great to hear it boots and HDMI works on your setup — that's the first confirmation from hardware other than mine, so it means a lot. If you get time, I'd love to hear how it holds up (networking, USB, and the 4 GB variant if that's what you have). Root password: that's by design, not a bug. Root login is locked on purpose — the image ships with a default user / user account and SSH enabled, so an open root account would be a security hole. Use the user account with sudo: root shell: sudo -i (or sudo su) to set a root password if you really want one: sudo passwd root KDE image + Etcher error: let's pin it down. Full disclosure — I flash with dd myself, so I haven't actually run these images through BalenaEtcher; I'll test the Etcher path on my end to try to reproduce it. In the meantime, two quick checks: Verify the download — a truncated/corrupt download is the #1 cause of Etcher errors. The desktop image sha256 is: 63b0019423d2a320aaa5fe58df97db68823b353a30510ffa863fec475904e0ba Check yours: sha256sum on Linux/Mac, or certutil -hashfile <file> SHA256 on Windows. If it doesn't match, re-download. And thanks for the heads up — I'll also double-check on my end that the file on the release didn't get corrupted during upload. Card size — the desktop image is ~5.3 GB when written (bigger than the CLI one), so it needs an 8 GB or larger card. A smaller/oddly-sized card makes Etcher fail. If the checksum matches and the card is 8 GB+ but it still errors, it's most likely Etcher choking on the .xz — try Raspberry Pi Imager (Use custom → pick the .img.xz), Rufus (it writes in DD Image mode and takes the .xz directly), or on Linux just dd: xz -dc aurealnix-opi4a-debian13-v0.2.img.xz | sudo dd of=/dev/sdX bs=4M status=progress And if you can, paste the exact Etcher error text — that tells me straight away whether it's a size, decompression, or validation issue. Thanks again for digging in! 🙌

Mint packages its own Chromium as a deb package, whereas Ubuntu's Chromium is a snap (even `apt install` just installs a snap by default). So, all x64 packages work (and I confirmed by testing xtradeb PPA's x64 package, which works). However, it's also not ARM64 related, as the Chromium ARM64 Snap from Ubuntu 24.04 (I just tested that too) works perfectly fine. It's just the ARM64 deb package from xtradeb that seems broken, which is bizarre.