Werner

In the world of cheap ARM sbcs you cannot simply use image for board X and assume it works for board Y. It may up to a certain point, even boot, but you have to live with regressions. https://docs.armbian.com/User-Guide_FAQ/#why-no-universal-image If there is no pre-made image for a specific board, then you can DIY if it is even supported by the framework. keep in mind, boards in eos or csc status may or may not work. We don't know, we don't pay attention, we don't support.

Perhaps send fix here: https://github.com/armbian/build/blob/main/patch/kernel/archive/rockchip64-6.18/board-nanopi-m5-add-wifi-bt-ufs-and-misc.patch

We're in the middle of the May release, so new packages should eventually hit repo in a few days/weeks.

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

Tested orangepi5 current and vendor. works as expected

Known issue on multiple older 64 bit Allwinner socs Try these: https://fi.mirror.armbian.de/incoming/igorpecovnik/pine64/archive/

none which doesn't break other boards.

I have up on this approach as this break ethernet on an actually supported board.

Hi, this board isn't supported, hence no images available.

code { font-family: Consolas,"courier new"; color: crimson; background-color: rgba(0, 0, 0, 0.2); padding: 2px; font-size: 105%; } dpkg-reconfigure locales and change default locale Tried?

try DIY image with this pr on top of main: https://github.com/armbian/build/pull/9626

yet still giving enough to write a answer. flaming over LPEs (or any vulnerability) does not solve any issues. I suggest to read the license again to get a clue who's responsible about fixing things in general: https://github.com/armbian/build/blob/5e60c0183d035bfd5179373e1eac284790e08904/LICENSE#L265-L268 Both parties also shall read the terms of use again, the very first bullet point in particular. I will not give this hint a second time. fixes will land upstream, stable builds will adapt four times a year. For everyone wants things faster, options were provided.

Try with this commit:https://github.com/armbian/build/commit/b880d98b07090b0b59bb3096c508e5123b224037 Seems like Micha had to cleanup my mess

Quite a while ago I added GPIO names to the rock-3a. Perhaps you can get an idea how to do this. Source: https://docs.radxa.com/en/rock3/rock3a/hardware-design/hardware-interface#gpio-interface Implementation: https://github.com/armbian/build/pull/7403/changes

perhaps the patch is no longer necessary once this lands upstream. We will see once we get there

Why should they?

feel free to send a pr replacing the current patch for review

If you want to do the work you can open a pr including these changes into Armbian. However I believe all opi5* boards are in decent state I'd simply wait for upstream . the patchew link is dead btw.

duplicate https://forum.armbian.com/topic/59601-sd-card-boot-cant-find-my-sda1hdd-after-warning-and-fsck/?do=findComment&comment=237240

That's default Debian behavior. Ubuntu includes sbin in PATH afaik. In any case Armbian does not alter this.

There is no such device. The only device with E and W suffix I know exist are the Radxa Zero 3W and 3E. Double-check what hardware you actually have.

No, probably not. CI takes days to catch up. Best is to use the build framework to create an up-to-date image/kernel This happens automatically after a few days.

It should be available on any armbian installation oob. You can also get it here: https://github.com/armbian/build/blob/main/packages/bsp/common/usr/sbin/armbian-add-overlay

Support for 7.1 has been merged yesterday https://github.com/armbian/build/pull/9784

I verified the overlay above working with diy kernel 7.1.0-rc1 and kernel 6.18.10 from apt repo.