Werner

Why? Will cause recompilation on every build This does not exist anymore IIRC. Non-standard docker image can cause rebuild since it is now based on Noble. This is not needed since it is default behavior. Also unneeded since default is yes already.

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/

Hi KDE Plasma is not an officially supported DE, therefore hidden behind code { font-family: Consolas,"courier new"; color: crimson; background-color: rgba(0, 0, 0, 0.2); padding: 2px; font-size: 105%; } EXPERT=yes switch. May work, maybe not. No support for it, just like for any user-built image. Example without interactive menu including all available app groups: ./compile.sh build BOARD=orangepi5-plus BRANCH=vendor BUILD_DESKTOP=yes BUILD_MINIMAL=no DESKTOP_APPGROUPS_SELECTED='browsers chat desktop_tools editors internet multimedia office programming remote_desktop' DESKTOP_ENVIRONMENT=kde-plasma DESKTOP_ENVIRONMENT_CONFIG_NAME=config_base EXPERT=yes KERNEL_CONFIGURE=no RELEASE=bookworm

Hi Providing logs with PASTE_SERVER_HOST=paste.armbian.de armbianmonitor -u helps with troubleshooting and significantly raises chances that issue gets addressed.

moved

Hi Providing logs with PASTE_SERVER_HOST=paste.armbian.de armbianmonitor -u helps with troubleshooting and significantly raises chances that issue gets addressed.

moved

This is not Armbian. This fork is using the name Armbian without permission nor do they contribute to the core development process. Ask at their repo for help. We cannot and will not support any forks whatsoever.

duplicate https://forum.armbian.com/topic/51524-x96-x6-configuration/#comment-217412

moved

moved

Maybe you find a working one in oldarchive: https://fi.mirror.armbian.de/oldarchive/orangepiplus2e/archive/

Maybe related https://github.com/armbian/build/pull/8087

moved https://www.armbian.com/orange-pi-plus-2e/

Must have been slipped through. Fixed.

Easiest way would be using the customization script: https://docs.armbian.com/Developer-Guide_User-Configurations/#user-provided-image-customization-script

Seems like the default for sunxi64 family is v2024.01. You can try manually bumping it by overwriting at board level and see what happens. Example: https://github.com/armbian/build/blob/main/config/boards/nanopi-r3s.csc

There are actually just a few situations where updating the boot loader makes sense. So when a new u-boot package is shipped it just provides the binaries but does not write them to the boot sector. I think you can use armbian-install to rewrite the boot loader with the latest binaries.

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

There is a write-up about this: https://zuckerbude.org/armbian-using-kernel-config/ Check the tl;dr: part.

moved

Windows doesn't support proper file systems like btrfs or ext4 by default. You need a driver for such in order to read those or use anything but Windows. moved, title replaced

https://docs.armbian.com/User-Guide_FAQ/#can-i-upgrade-my-userspace-flavor-like-bullseye-to-bookworm-or-jammy-to-noble There is some package (base-files or rootfs, bsp, whatever, cannot remember) that contains this information. Yours is probably outdated. Replace accordingly.