Werner

Providing logs with armbianmonitor -u helps with troubleshooting and significantly raises chances that issue gets addressed.

3a vendor seems to work nicely. Not your images but built from sources just a few days ago. Should be pretty much identical. emmc is not detected. Though is the first time I tried emmc on this board and I don't know if the modules even work. Edge seems to work nicely as well. Also emmc is detected. I bet the cause of the non-working emmc on vendor is the garbage 2017.09 uboot.

Checked http://fi.mirror.armbian.de/oldarchive/ ?

I don't know if there is an option to disable ipv6 on bootloader level but that's not necessary anyway. You can do that in userspace via sysctl.conf, just use your favorite search engine and you will find how this works.

Without any research I assume this firmware package contains some fw files that are just there in case somebody wants to reflash some otherwise inaccessible fw storage. Similar to u-boot packages which on upgrade will store the necessary binaries for reflash on fs but does not actually reflash itself in the boot sector. Needs to be done manually. So tl;dr: having this optional makes sense.

https://zuckerbude.org/armbian-using-kernel-config/ Once successful tested provide a PR to add the missing module:https://docs.armbian.com/Process_Contribute/

docs don't apply for rpi family since it uses proprietary boot way. Upstream howtos for editing /boot/firmware/config.txt apply. dtoverlay=disable-bt dtoverlay=disable-wifi

Providing logs with armbianmonitor -u helps with troubleshooting and significantly raises chances that issue gets addressed.

https://zuckerbude.org/armbian-using-kernel-config/

HDMI audio has been merged into 6.15. Board may need additional device tree nodes to make it work. Analog audio should work already as well bug may also need additional nodes. Collabora sent for Rock5B and 5B+ only upstream. https://gitlab.collabora.com/hardware-enablement/rockchip-3588/notes-for-rockchip-3588/-/blob/main/mainline-status.md

This should produce an image. That's not needed since it is default anyway.

if NAMESERVER is not set it falls back to default 1.1.1.1 A while ago I made a hack to enforce using whatever hosts nameserver is:https://github.com/armbian/build/blob/e03b1b543cda430fbffcb62c979aecabee42b044/config/templates/config-example.conf.template#L25

Interesting, didnt realize that.

I've seen this error before. I think that's some incompatibility from rpi own packages that have some regex checking if its their own kernel or not. Did not get any further though.

code { font-family: Consolas,"courier new"; color: crimson; background-color: rgba(0, 0, 0, 0.2); padding: 2px; font-size: 105%; } armbian-install should be able to do that. Though since there is no option to select WHICH version, if there are multiple installed, to write, I suggest to first check with code { font-family: Consolas,"courier new"; color: crimson; background-color: rgba(0, 0, 0, 0.2); padding: 2px; font-size: 105%; } dpkg -l which uboot package/s is/are installed and make sure there is only the one that you want to write.

config is there: https://github.com/armbian/build/blob/main/config/boards/orangepi5-ultra.csc DIY: https://docs.armbian.com/Developer-Guide_Overview/ Go for edge

verbosity or loglevel to say cannot exceed 7. https://www.kernel.org/doc/html/v6.12/admin-guide/kernel-parameters.html Make sure your adapter can handle this speed which is rather high. Some chips, CP2102 for example, tend to simply output garbage instead of properly failing if asked to provide a higher baudrate than it can handle. Get FT232R or CP2104 or any other that can handle like and more than 1.5Mbaud.

https://debug.armbian.de

https://docs.armbian.com/User-Guide_Board-Support-Rules/ support a whole soc family would be impossible. For example a vendor could do a poor implementation of something which could never work but we "support" it and people complain why it doesn't but there would be literally nothing we could do about.

Hi ssd or nvme? Both needs different handling kernel? edge? vendor? current?

https://askubuntu.com/questions/1371732/what-is-the-purpose-of-cgroup-enable-cpuset-cgroup-enable-memory-cgroup-memory-1 Without further research the answer here mentions that the flags in question may be specific for RaspberryPi, hence won't work on other kernels/boards.

All images are specifically made for the board. Some share the same kernel package since they are from the same soc family (for example, there are a lot of boards using the rk3588/s soc so they can have the same kernel package. Board's components are defined in device tree). Sample board config: https://github.com/armbian/build/blob/main/config/boards/orangepi5pro.csc BOARD_FAMILY is rockchip-r3588 The sources config: https://github.com/armbian/build/blob/main/config/sources/families/rockchip-rk3588.conf Pro, max and ultra are community contributions and for now entirely unsupported since there is also no support from the vendor for us for these whatsoever to make its software better.

Try looking for hints here: https://jellyfin.org/docs/general/post-install/transcoding/hardware-acceleration/rockchip/ They use mali blobs for hw en-/decoding.

I assume should work with vendor. Maybe missing node in device tree. Maybe missing firmware blobs or same as above. Expected since neither SPI nor eMMC are present by default. Direct boot from NVMe isn't support by any Rockchip soc.

But still possible You can also switch manually to a fixed mirror from the list here: https://docs.armbian.com/Mirrors/