ArmBoy1988

Orangepi OS (Arch) is custom / re-branded Manjaro and Manjaro is not doing much else then shipping (selling) their Arch derived OS while taking our and community work on kernel maintainace. This is the story how Orangepi "supports" open source - by primarily supporting code dealers that already mainly have negative contribution to open source development. But who cares other then small group of people called "developers"?

In general, HW vendors have interest to block or at least control other OS providers and it is possible they purposefully compiled SPI boot-loader to not load anything else then their OS. This would explain why you can't load our OS. Manjaro already provided (or tried to) this "solution" to Pine64, so average users would have troubles changing OS. Details: https://blog.brixit.nl/why-i-left-pine64/ 
 
For us, this is easy to work-around, but bulk of people might still need to stick to their official promo/spy/pirate-ware.
 
Solution?

Debian based OS:
 
sudo apt update sudo apt install mtd-utils sudo flash_eraseall /dev/mtd0  
Arch based OS:
sudo pacman -Syy sudo pacman -S mtd-utils sudo flash_erase /dev/mtd0  
Then boot armbian from SD card and run:
 
sudo armbian-install  
And choose "update MTD boot-loader" or "Install it to NVME", which will also update boot-loader and transfer image to SSD. Tested right now with Opi5 lying on my desk.

Do you mean armbian-config?  Because, you know, this forum is for supporting Armbian.

I had one OPi5 setup and working properly with one of my TVs.  I was running Kodi and using the remote from my TV to control Kodi using HDMI-CEC.  I went to setup a second one on another TV but this time the TV remote did not work properly.  Through elimination I came to determine the HDMI cable was the issue.  I ordered another HDMI cable that had the Ferrite at each side of the cable.  Now it worked properly.  Thought this might be useful for others.  This is the cable I ordered:  https://www.amazon.ca/dp/B003PDHJ6M
 
Conclusion:  In order to make HDMI-CEC work properly, make sure the HDMI cable is of sufficient quality.  I think ones with the Ferrite may be best to remove any electrical interference.

Needed/wanted to add Bluetooth to my OPi5 and also needed WiFi at the same time.  Did not want to use 2 USB ports so I tried the T2UB.  Working well.  Bluetooth appeared on my Armbian Ubuntu Jammy setup and I plugged in the dongle.  It saw a few of my bluetooth devices.  Reason I wanted bluetooth is to use a controller for some games/emulators.  I'll make another post for that.  My PS4 Dualshock controller is not showing up in the list of devices.  My version is an older version, Armbian 23.06.420 Jammy with Linux 5.10.160-rk35xx  No end-user support: built from trunk
 
Conclusion:  TPLink T2UB should work properly on Armbian Ubuntu desktop.

The info that I gathered from that thread is that the MTD/SPI bootloader that comes with the image I was trying doesn't handle ext4 file system on the NVMe.
 
So I downloaded one of your images:  Armbian_23.02.3_Orangepi5_lunar_legacy_5.10.110.img.xz
 
Verified the SHA-256 hash and then flashed to an SD card.  Flashed the MTD/SPI from that image and then rebooted with the Armbian Debian Bullseye Legacy CLI that did not previously boot up.
 
And...it booted up properly.  I use this version of OS as the software I'm using requires Bullseye.
 
In any case, thanks.

This is solved.  Nothing was changed on the T4, Armbian or OpenMediaVault.  I've decided to stick with the 4.4.x version of Armbian as the shutdown and a few other functions perform/work better than the 4.20.x version.
 
I was trying to set up some testing of the NFS mounts between the client and server and couldn't use the built-in NFS mounting in Kodi as there is no way to change options., etc.  So, I set up external mounts of the drives.  Following that, the issue no longer occurred.  I tried to use NFS version 4, but that isn't supported.  I specified NFS version 3 and no issues.  I tried skipping around and no hanging...I played a video file that was about 1hr 30min and it played properly to completion.
 
So, this is really a workaround.  I use LibreElec version of Kodi on the Raspberry Pi's.  This issue is either in Kodi or the LibreElec version built-in NFS handling.  It could be some mismatched configuration or options.  In any case, the workaround, mounting the drives before starting Kodi, seems to work properly.
 
Issue closed.  I'll post on the Kodi and LibreElec forums.