Werner

I don't think so. You can check in /boot/armbianEnv.txt if there is panthor overlay enabled. If so, disable it so you can use the proprietary mali blobs.

unsupported host os for build environment. Grant the user access to Docker or use a Noble host.

Use edge or vendor for more features. current will stick to 6.12 LTS kernel which will receive fixes only.

A few days ago jammy and bullseye were moved to eol.
While upstream may support these userspaces a few more years, Armbian does not have the resources to support more than the most current stable releases of Debian and Ubuntu, which are Bookworm and Noble at this time.
 
You can still select them to build when passing EXPERT=yes switch to ./compile.sh but do not ask for support if something breaks. You are on your own.

Great.
Just to avoid cross-contamination. You are sure you have the Orange Pi 3 and not the Orange Pi 3 LTS model?
 
Background: OrangePi naming scheme is kind a ridiculous, makes no sense often enough and introduces confusion. In this particular case they switch to a different PHY chip which I think was migitated by Armbian but not sure if they still have separate images.
 
Seems like a similar topic already exists: https://forum.armbian.com/topic/34024-cannot-attach-to-phy-after-upgrade-to-202381/

That's normal services usually need a few hours to catch up with stuff once a new tag is released. Try tomorrow.
 

Deprecated. Check docs again.
 

known issue. fix is underway

Maybe you find some clues here: https://github.com/armbian/build/pull/6617/files
SoC is the same

As expected. Mainline Linux support for rk35xx soc family is still under heavy development. There is a good overview what should work and what does not:https://gitlab.collabora.com/hardware-enablement/rockchip-3588/notes-for-rockchip-3588/-/blob/main/mainline-status.md

Check how and why this kernel is installed:
/boot/uInitrd-6.12.12+bpo-arm64-16k  
Seems like Debian backports kernel which WILL not work with your board. Make sure the vendor kernel is the only kernel installed.
 
Write a fresh image to microsd and boot from it. chroot into your nvme and remove the wrong kernel. Make sure the symlinks to initramfs and kernel image are correct again. Should be sufficient.
 
 

Could be. btrfs installation, especially on other devices, are not much tested. So breakage could be possible. Needs investigation.
Should usually just work
 
Yes, documentation is a constant problem. We don't have enough helping hands to keep everything in good shape. Keeping up with kernel development is already a challenge with hundreds of boards.
 
Either the answer is right there or a mirror is out of sync which can happen from time to time.
Feel free to fix apt source to a fixed mirror from this list: https://docs.armbian.com/Mirrors/

Check /boot/dtb/rockchip/overlay for available overlays. If you are using mainline kernel overlays might be missing. Use vendor kernel in this case.
 
If armbian-config fails for adding simply add them manually with overlays= in /boot/armbianEnv.txt

Hi
this warning tells you that it is up to you to do a risk assessment if you are fine with the fact, that the device's status is unknown to the Armbian team, that it may break with an upcoming update or never receive an update at all.

Could you check if CONFIG_NLS_ISO8859_2 is enabled in your kernel config?
The package is locales I think.
That it is not installed tells me you are most likely using a Minimal/IoT image which comes with the absolute bare minimum to have a working system. Designed for advanced users knowing how to install such tools afterwards if needed.

iirc xtables-addons was never a part of linux-headers. Though it can be installed separately and needs linux-headers installed to build the necessary kernel module.
Have you tried to build your own set of firmware packages using the build framework? code { font-family: Consolas,"courier new"; color: crimson; background-color: rgba(0, 0, 0, 0.2); padding: 2px; font-size: 105%; } ./compile.sh BOARD=odroid-c2 BRANCH=current kernel

if you need working hdmi use vendor or edge kernels. current (which is 6.12.y) does not have all the necessary patches already since they were (and still are) under heavy development.

We had the case on various boards over a couple of years that sometimes warm reboots fail. Since the reason is always individual, hard to tell by heart.
 
Anyway I suggest to extract proper logs from debug uart console. If you don't know what I am talking about: https://debug.armbian.de

Compare contents of
/etc/apt/sources.list:1 and /etc/apt/sources.list.d/ubuntu.sources:1  
and remove duplicates

please test again.

Should be rk3588-hdmirx.dtbo

Check /boot/armbianEnv.txt
 
overlays=i2c1 i2c2 rockchip-rk3399-i2c7  
 
Try this instead:
overlays=i2c1 i2c2 rk3399-i2c7  

How do you connect a NVMe to this board?
 
Never mind. Wrong prefix.
 
Anyway you need boot loader present on either spi, emmc or sd. Direct boot from nvme isnt possible.

short version: switch to vendor kernel.
 
long version: mainline support for rk3588 is far from being feature-complete. Audio probably hasn't been mainlined yet. Check https://gitlab.collabora.com/hardware-enablement/rockchip-3588/notes-for-rockchip-3588/-/blob/main/mainline-status.md
 
If you need most things to work vendor is the way to go for now which is based on Rockchip SDK.

glxinfo -B

Feel free to build an image with edge branch which is 6.13-rc...5..ish? I don't remember. Anyway this should give you a good idea about what to expect when it becomes stable after rc7.