laibsch

This may or not be the case. Looking through the Ubuntu bug tracker, I find a lot of similarly failed upgrades. But at least ports.ubuntu.com was not disabled in the past: http://launchpadlibrarian.net/757026143/VarLogDistupgradeMainlog.txt from http://bugs.launchpad.net/ubuntu/+bug/2086530

@Zaf9670 Please run "armbianmonitor -u" on the board and share the link

Sounds like an error with X. @ALL above: Did you recently update any packages? Please pastebin or attach the content of the ~/.xsession-errors file. Go and search for it if necessary "sudo find / -name .xsession-errors*"

A quick google search seems to suggest that the Orange Pi Lite is prone to overheat. Obvious question that you did not mention in your original question: Do you have a heatsink installed? Is there sufficient airflow? In general, are you sure you want to use this board with a mate environment? Even if you get to work around the heat issues. RAM and CPU are likely to cause this to be a bit of an underwhelming experience.

Hello @Domas, are you still trying to achieve this? You are obviously stuck in the middle now, in the twilight zone. I am fairly sure, you can still recover from this. We should first understand better ; Can you give me the output of "aptitude search '~o'" and "apt-cache policy | grep http | awk '{print $2" "$3}' | sort -u"? The way I read what is happening to you is that do-release-upgrade is trying to upgrade ports.ubuntu.com entries, fails, tries to fall back to archive.ubuntu.com but fails with that, too, because there are no armhf packages published, there. Not sure, if that qualifies as a bug in do-release-upgrade. Probably not. PS: Apart from the upgrade issue, you also seem to have an issue with filesystem corruption (lines 608 and 637 to 639 of http://paste.armbian.com/oletimumob). The ability to detect and fix these kind of issues with a live-mounted FS is one of the many reasons I switched to btrfs from ext4 a long time ago.

Thank you for reporting back. Glad you got it solved.

This. Just use the tools that were intended for software installation.

I suggest you simply try. What is holding you back?

Thank you for your question, @Jacob Burckhardt I do not use tags and FWIW, I do not see them on my main laptop, running Ubuntu Noble, either. Is this a Debian thing? Is your Armbian user space Debian?

Thank you for coming back and sharing your "solution". It is always good to hear when things work out in the end, no matter the reason.

@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 ( http://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?