laibsch

Thank you for that information. Indeed, you have partially upgraded to noble by now. It appears, though, as if you also have some packages that predate even jammy, like clang-10 and crda and possibly others. Did you originally install this board with a release before jammy? I see you do have armbian-focal-desktop-xfce installed, for example. For housekeeping, I suggest you do the following now before anything else. "sudo apt update;sudo apt upgrade" to make sure all packages are up-to-date in jammy. You might run into trouble because some of your packages are already from the noble pocket. Let me know if there were any issues. Next, try to simplify your package set by marking as many packages as automatically installed as possible to make the dist-upgrade path easier. Try to trim the output of "apt-mark showmanual" down to the minimum by marking them via "sudo apt-mark auto $pkg". Specifically, I think all your obsolete packages should be marked as automatically installed. # these look like clear candidates for removal unless some other package depends on them sudo apt-mark auto fonts-ubuntu-font-family-conso libhogweed5 libicu66 libjson-c4 libmpdec2 libnettle7 libpcre2-posix2 libpython3.8-minimal libsepol1 libssl1.1 libssl3t64 libwebp6 numix-blue-gtk-theme perl-modules-5.30 python3.8-minimal systemd-resolved ttf-ubuntu-font-family # these should be clear as well, but have a closer look if you want sudo apt-mark auto armbian-focal-desktop-xfce crda hddtemp Periodically, while trimming down the list of explicitly installed packages, check with "sudo apt autoremove --dry-run" before "sudo apt autoremove" to trim down on the installed packages. Then show me the output of "aptitude search '~i !~M' " once you are done. With regards to your filesystem issue, indeed it seems to be less complicated than I feared. I suggest you boot into your computer, umount sda1 and fsck it. That should take care of it. Monitor the drive if errors come back and if so, consider replacing it.

it could be that there is a bug in one distro that is not present or already fixed in the other it could be that one image is missing a package that should have been installed (this would be a bug in Armbian if it affects one of the images we publish) best you can do is to report bugs if you think there is one

throw out an offer and see if you get any takers 😉

That is true but almost impossible to understand for an outsider.

@dr_toggleswitch If that concerns you, may I suggest to stop using torrents? It appears you don't have a good understanding how torrents work.

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: https://launchpadlibrarian.net/757026143/VarLogDistupgradeMainlog.txt from https://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 https://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 ( 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