laibsch

probably best to specify location for any sales offer

What is the status here?

The OrangePi Zero 2w is maintained by the community and chraac in particular. Maybe try to contact him by e-mail if you don't get a response here. Or talk to other owners of the device here in the forum to see if they can answer your question.

Great news and thank you for reporting back. Do you have any idea what they changed or where they host their sources so we can have a look? There is for example this. There is another user who reported running into problems that sounded a lot like yours.

Thank you for that information, @Mechano. Did you ever get this board to work, with armbian or another image?

looks like a really cool machine. unfortunately, no maintainer in armbian and I am not aware if any of the regular developpers has that SBC. It seems to be based on the H618 which it shares with the Orange Pi Zero3 which is reported working with the latest Armbian release. Did this board ever work with an older release? Is this a regression? I see somebody else mentioning they have issues with the board booting, , apparently due to issues with thermal management. And your crash apparently started in pstate.

Nice. To help other users of the forum, it would be good if you shared what fixed the issue.

To be honest, I'm confused. You reference three different systems and it is unclear to me which one it is that FTBFS for you. Let's take a step back. Do you have the latest git tree of armbian/build? Do you have any local changes? What is the exact command you for compile.sh? I will try to reproduce the problem here.

I do not understand what is "not working". Please elaborate. Also, providing logs with armbianmonitor -u helps with troubleshooting and significantly raises chances that issue gets addressed.

are you sure all storage devices are working without issues?

I am not very familiar with Radxa and Rock. But I cannot find the board among those supported by armbian. Let me ask you where you got your image and kernel?

Can you point to a patch or some code from Ubuntu how they achieve that?

@Diego Dagum are you using an apt caching mirror like apt-cacher-ng?

Ubuntu is not just Debian. Ubuntu has very different policies and sits on top of Debian. For example, Ubuntu is more tolerant with regards to binary blobs and it very much possible that this would explain your finding. I guess the question you should answer first is why not simply use Ubuntu if it works for you and Debian does not?

Be aware that the answer might depend on the filesystem you are using on your board Be aware that a resize operation can easily destroy your data or at least make it inaccessible have a look at shrink-backup for "reverse"

shot in the dark. maybe this is a regression due to a recent commit @sakittelsen Try "git revert 9eaa276457e11" and try again.

/etc/apt/sources.list:1 and /etc/apt/sources.list.d/debian.sources:1 Those are the files and lines that are duplicate that apt tells you about

... but at the same time, others with H3-based boards seem to have similarly high idle temps reported. @Domas Do you own one of those infrared themometers or have another way to ascertain the true temperature of your board? As the title of this thread says, I am curious about the accuracy of the onboard sensors. Maybe the sensors are even accurate but they need proper software calibration.

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 😉