laibsch

Imagine you have package A and it depends on package B. "sudo apt install A B" will install both packages (this might happen during the image build process for the Armbian project). Now you remove package A, package B is no longer needed but is kept around nonetheless because it is not marked as automatically installed. Or imagine package A depends on libB-1 in focal. You upgrade to jammy but something got stuck half-way and somehow libB-1 dropped its mark of being auto-installed (apt does this sometimes to prevent problems). Now the new version of package A in jammy depends on libB-2 and you have both libB-1 and libB-2 installed. Often, this will not be a problem, but let's say you also have package C which conflicts with libB-1. Now you are starting to be in trouble because how is apt to know if you should keep C over libB-1? apt is pretty smart and often makes the right decision, but I am sure you can see how it may not. That is where you are at. They are not obsolete but no longer required AKA explicitly installed or a dependency of one such package. When you mark a package as automatically installed but it is in fact providing something you want (a font, a background image, a function, ...) you will lose that if no other package depends on it and the package gets autoremoved.

Better to open a separate topic, Сергей Гладченко

Sad to say, I would not trust the armbian-tools. Some of them are very, very badly broken and I have zero trust they will get into better shape. That being said, armbian-upgrade is innocent enough, a simple shell script you can easily inspect. In general, it's better to stick with the tried and tested Ubuntu and Debian tools. The reason is simply the aborted upgrades. If this happens repeatedly, the situation obviously worsens and the large number of manual packages then make it impossible for apt and other tools to calculate a proper upgrade path. That is the situation you are in now. You will have a much better chance of fixing the upgrade once this list of manual packages has been trimmed down to the minimum. Did you check them if there were none that you might want to keep? Your screenshot looks a bit funky now, might be a missing font. In any case, it would be easy enough to fix the situation again by reinstalling whatever package you are missing. You do have access to your SBC also over ssh, right? It is not time for your dist-upgrade, yet. Make sure to clean up your situation first. Your screenshot with the 404 confirms my suspicion that somehow do-release-upgrade replaces ports.ubuntu.com sources with archive.ubuntu.com but armhf is not hosted there. Don't worry about that for now. We will deal with this later, I already have an idea. And indeed, this is a bug in do-release-upgrade and we certainly should report it in due time. I quickly looked through your list and consider the following pretty obvious candidates to be marked as automatically installed. # this is a large chunk of packages that should almost certainly be marked automatically installed sudo apt-mark auto fonts-arphic-ukai fonts-arphic-uming fonts-dejavu-core fonts-freefont-ttf fonts-guru fonts-guru-extra fonts-kacst fonts-kacst-one fonts-khmeros-core fonts-liberation fonts-nanum fonts-opensymbol fonts-stix fonts-symbola libacl1 libapparmor1 libargon2-1 libasn1-8-heimdal libassuan0 libatk1.0-data libatk-adaptor libattr1 libaudit1 libaudit-common libavahi-client3 libavahi-common3 libavahi-common-data libblkid1 libblkid-dev libbsd0 libbz2-1.0 libc6 libc6-dev libcairo2 libcap2 libcap2-bin libcap-ng0 libc-bin libc-dev-bin libcom-err2 libcrack2 libcrypt1 libcrypt-dev libcryptsetup12 libdatrie1 libdbus-1-3 libdconf1 libdebconfclient0 libdevmapper1.02.1 libdigest-sha-perl libdpkg-perl libestr0 libexpat1 libfastjson4 libfdisk1 libffi7 libffi-dev libfont-afm-perl libfontconfig1 libfontembed1 libfontenc1 libfreetype6 libfribidi0 libgail-common libgcc-s1 libgcrypt20 libgdk-pixbuf2.0-0 libgdk-pixbuf2.0-common libglib2.0-bin libglib2.0-data libglib2.0-dev libglib2.0-dev-bin libgmp10 libgpg-error0 libgraphite2-3 libgsettings-qt1 libgssapi3-heimdal libgssapi-krb5-2 libgtk2.0-bin libgtk2.0-common libharfbuzz0b libhcrypto4-heimdal libheimbase1-heimdal libheimntlm0-heimdal libhx509-5-heimdal libidn2-0 libip4tc2 libjbig0 libjpeg8 libjpeg-turbo8 libk5crypto3 libkeyutils1 libklibc libkmod2 libkrb5-26-heimdal libkrb5-3 libkrb5support0 libksba8 libldap-common liblocale-gettext-perl liblz4-1 liblzma5 libmnl0 libmount1 libmount-dev libncurses6 libncursesw6 libnewt0.52 libnl-3-200 libnl-3-dev libnl-genl-3-200 libnl-genl-3-dev libnotify-bin libnss-myhostname libp11-kit0 libpam0g libpam-gnome-keyring libpam-modules libpam-modules-bin libpam-runtime libpam-systemd libpango-1.0-0 libpangocairo-1.0-0 libpangoft2-1.0-0 libpcre16-3 libpcre2-16-0 libpcre2-32-0 libpcre2-8-0 libpcre2-dev libpcre3 libpcre32-3 libpcre3-dev libpcrecpp0v5 libpixman-1-0 libpopt0 libproc-processtable-perl libprocps8 libproxy1-plugin-gsettings libproxy1-plugin-networkmanager libpython3-stdlib libroken18-heimdal librsvg2-2 librsvg2-common libsasl2-2 libsasl2-modules-db libseccomp2 libselinux1 libselinux1-dev libsemanage-common libslang2 libsmartcols1 libsqlite3-0 libss2 libssl-dev libstdc++6 libsystemd0 libtasn1-6 libthai0 libthai-data libtiff5 libtinfo6 libu2f-udev libudev1 libunistring2 libuuid1 libuv1 libwind0-heimdal libwmf0.2-7-gtk libwrap0-dev libx11-6 libx11-data libxau6 libxcb1 libxcb-render0 libxcb-shm0 libxcomposite1 libxcursor1 libxdamage1 libxdmcp6 libxext6 libxfixes3 libxi6 libxinerama1 libxml2 libxrandr2 libxrender1 libxtables12 libzstd1 linux-libc-dev uuid-dev zlib1g-dev apt-transport-https gstreamer1.0-pulseaudio lsb-base mime-support p7zip-full policykit-1 Do you need help trimming down your list of manual packages? Please post the output of "aptitude search '~i !~M' " again once you consider yourself done.

You should of course monitor the temperatures now to see if the board becomes abnormally hot (use your hand or the programs sensors or btop, for example). That being said, a quick web search suggests to me that you are simply seeing a software problem AKA bug. I suggest you open a bug ticket on the Armbian bug tracker and patiently wait for the board maintainer to have a look into the issue. https://www.armbian.com/nanopi-neo-2/ lists https://github.com/spendist as the maintainer for your board. Maybe you can send an e-mail? sources: https://forum.armbian.com/topic/9501-opzero-h5-after-update-41917-the-cpu-temperature-is-wrong/ https://community.nxp.com/t5/i-MX-Processors/IMX8MP-not-able-to-read-Thermal-zone0-temperature/m-p/1655665 https://community.nxp.com/t5/QorIQ/Temperature-is-not-available-at-sys-class-thermal-thermal-zoneX/m-p/1343009

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.