Werner

There are for once some inconsistencies in terms of prefixes across various soc families and for the other configng isn't perfect (yet ).
Feel free to share your issue at its repository: https://github.com/armbian/configng/

fixed

Not sure if it is possible to use a local kernel source directory. At least I don't know how to do that. Easiest is probably just to create a repo and define url and branch in board your custom board config.

Yes, DB9 won't work.
But if, as eselarm mentions, a proper chip is on board already a simple usb-a to usb-c or c-to-c cable should do.
Check dmesg when connection to see what pops up.

Between days and month. Depending on time, issues, regressions,... 
Refrain from asking for ETA. Putting pressure on developers who give you something for free is abusive.

BOARD=uefi-x86

Install code { font-family: Consolas,"courier new"; color: crimson; background-color: rgba(0, 0, 0, 0.2); padding: 2px; font-size: 105%; } qemu-user-static package and retry

Try setting ZRAM_PERCENTAGE=50 where 50 would be half of available memory. Not sure if the builder picks this up.
If it doesn't I'd go the customize-image.sh route and use this to modify the /etc/default/armbian-zram-config file just before assembly closure.

No worries. Everyone here started small
edge and vendor are Armbian terms for kernel branches just like current.
You guessed correct, edge is bleeding edge and usually follows latest mainline kernel (6.14.y today).
vendor is based on Rockchip BSP kernel which is 6.1.y at the moment. While a bit out of date most hw functions work here.
current usually follows latest available LTS mainline kernel.
 
As you're a beginner and most likely just want things to work I suggest to try a vendor kernel based image first.

If a kernel package exists as artifact in oci cache it will be downloaded and used. Only if there is no artifact it will be built from scratch. After a new kernel version is released it may take a few days until oci catches up.
However once locally built it will also be cached locally so it will be re-used if you start another build.

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