laibsch

@OP: you need to give more info - what board? - what user space (Ubuntu or Debian, what release)? You said this works on Ubuntu. That was not an SBC? Edit: This issue is known upstream. Ubuntu does not have a delta to Debian and hence should be affected as well. In any case, there is not much Armbian can or is likely going to do.

Please be aware that trixie is as of now still unsupported

You aren't really giving us much of anything to work with. Please provide some logs. Is the process even running? Are the ports open (nmap -p 8200 $IP_of_YOUR_BANANA)? I did a quick local test on my Banana Pi M2+ and the port for minidlna at least is open. $ nmap -p 8200 banana.local Starting Nmap 7.94SVN ( https://nmap.org ) at 2025-04-25 06:43 PST Nmap scan report for banana.local (192.168.8.108) Host is up (0.0044s latency). rDNS record for 192.168.8.108: banana PORT STATE SERVICE 8200/tcp open trivnet1 Nmap done: 1 IP address (1 host up) scanned in 0.27 seconds $ service minidlna status ● minidlna.service - MiniDLNA lightweight DLNA/UPnP-AV server Loaded: loaded (/usr/lib/systemd/system/minidlna.service; enabled; preset: enabled) Active: active (running) since Fri 2025-04-25 06:35:43 PST; 14min ago Docs: man:minidlnad(1) man:minidlna.conf(5) Main PID: 19814 (minidlnad) Tasks: 2 (limit: 2032) Memory: 53.3M (peak: 84.0M) CPU: 717ms CGroup: /system.slice/minidlna.service └─19814 /usr/sbin/minidlnad -f /etc/minidlna.conf -P /run/minidlna/minidlna.pid -S -r Apr 25 06:35:43 banana systemd[1]: Started minidlna.service - MiniDLNA lightweight DLNA/UPnP-AV server. Apr 25 06:35:45 banana minidlnad[19814]: minidlna.c:1163: warn: Starting MiniDLNA version 1.3.3. Apr 25 06:35:45 banana minidlnad[19814]: minidlna.c:392: warn: Creating new database at /var/cache/minidlna/files.db Apr 25 06:35:45 banana minidlnad[19814]: minidlna.c:1211: warn: HTTP listening on port 8200 Apr 25 06:35:45 banana minidlnad[19826]: scanner.c:730: warn: Scanning /var/lib/minidlna Apr 25 06:35:45 banana minidlnad[19826]: scanner.c:819: warn: Scanning /var/lib/minidlna finished (0 files)! Apr 25 06:35:45 banana minidlnad[19826]: playlist.c:135: warn: Parsing playlists... Apr 25 06:35:45 banana minidlnad[19826]: playlist.c:269: warn: Finished parsing playlists. Apr 25 06:35:46 banana minidlnad[19814]: monitor_inotify.c:223: warn: WARNING: Inotify max_user_watches [8406] is low or close to> Apr 25 06:40:30 banana minidlnad[19814]: upnphttp.c:1108: error: recv (state0): Connection reset by peer

armbian already move a lot of directories to tmpfs to reduce the amount of writes. a misconfigured system can of course reduce the lifespan of flash memory but that will be the case regardless of filesystem. there are ways to mitigate write amplification, for example. you will need to monitor the write activity on your memory. don't fill it up completely. iostat or nmon will help you see how often and how much is written to disk.

In general, it is a bad idea to try and fight systemd, I guess. Why not let systemd-resolved handle it?

Thank you for your work. Much appreciated.

Excellent. Thank you for sharing. Are you the author of https://github.com/MathiasStadler/orange-pi-zero-boot-from-spi or one of its consumers?

The way I understood it is that we are talking completely unattended installs here. For mass installations (probably hundreds if not thousands of boards) with no interactions other than other than popping in the flash card and pushing the power button.

I don't see this when following the link

does it make sense to publish both compressed and uncompressed in that case? No: additional compute requirements for CICD to compress images additional storage Yes less bandwidth for our mirrors and users faster downloads What do you say? I have another question: What do you mean exactly by docker support? Are you saying these images have somehow been prepped for easier consumption by docker? Please clarify. I suggest to document this properly somewhere to help in wider adoption and better user experience. This should be good for people testing armbian without having to flash an image to real hardware or without even owning an SBC. Another use case you already mentioned is automatic testing.

"We extend our deepest gratitude to the remarkable contributors who played a pivotal role in this release. Special thanks to: [...] @dependabot" 🤩

I am really happy to see this. I built a Noble image and tested it locally with qemu. ssh into the VM was fine but the framebuffer showed corruption. There was only about 10M of free space on / qemu-system-x86_64 -bios /usr/share/ovmf/OVMF.fd -m 2048 -display gtk,gl=on -device virtio-net,netdev=net0 -netdev user,id=net0,hostfwd=tcp::5800-:22 -drive if=none,id=root,file=./Noble_cloud_minimal-qcow2,format=qcow2 -device virtio-blk,drive=root Is there a reason not to offer these images in xz compressed format? Size goes down from 665 MB to just 153 MB for Armbian_25.2.3_Uefi-x86_bookworm_cloud_6.12.20_minimal.img.qcow2.

as a step in the right direction, there is some work being done to get dnsmasq to install and work properly.

I think neither of the solutions provided by Werner and Igor are really satisfactory and I 100% agree with @Mr. Fennec that the SBC should be easily discoverable after boot. The closest to that is the nmap command from Igor but that does not work reliably for me and requires root. Adding avahi-daemon package is less than half an MB installation size including dependencies. Not even a drop in the bucket for the image sizes. In my opinion, every board should have a minimal image containing nothing but what's necessary to do the following for at least Debian and Ubuntu: network via DHCP ssh server with standard PW avahi tooling to make the SBC discoverable with zeroconf/mDNS From there, you can take your board to anywhere you want it to and very easily. The desktop images provided are purely courtesy and can be easily replicated from a minimal install by simply installing the packages. For one thing, I was disappointed to see that for my board a minimal, CLI-only package is available for Debian but not for Ubuntu.