Igor

This could be one option: But beware that most of those cards, including this one, uses SATA port multiplication. For spinning rust over gigabit line this is enough ...

Follow instructions armbian-config -> software -> install headers This is the package name: # apt search linux-headers-current-bcm2712 Sorting... Done Full Text Search... Done linux-headers-current-bcm2712/jammy 23.11.3 arm64 Armbian Linux current headers 6.1.74-current-bcm2712

VMware ESXi on non Raspberry Pi is not usable (yet) in production, to install it and forget about. Several features does not work (stable) and overall performance is questionable. Here one can observe more, dunno how up2date is that documentation ... Orangepi is good enough for running Armbian and similar OSes and here one can run KVM virtualization. That will work fine, perhaps not the best with this board as mainline kernel still has rough edges.

Make an apt update + upgrade. Kernel + header combo exists for 6.1.74 and it should be there for future versions.

We have no plans or budget to support this hardware. Finished assembly will be provided only for small selection of boards, most likely we will provide this for platinum support section only. Purpose of the topic is promoting Armbian build framework. If something can be done on board X, we can't help to make it on board Y. Without investing tens or hundreds thousands of dollars. This is your problem. Board provider problem. Not ours. Build framework can do this, but if board is not maintained ... it might not just work.

Yes. https://github.com/armbian/build/commit/833e1c20c63ea3da7f1323429828e94eaa9b52c7 We forgot to pin it to the commit / version. Its still branch: https://github.com/armbian/build/blob/v23.11/config/sources/families/odroidxu4.conf#L24

We pin major releases this way (branch v23.11) https://github.com/armbian/build/commit/d69350a88447ee64bbb50b443f86858a7f6f4075 while main (or some tag) is not. For mainline based, check this: https://github.com/armbian/build/blob/main/config/sources/mainline-kernel.conf.sh Main branch is updated and fixed daily in case upstream messes up. Just keep rebasing.

6.1.74 current and 6.6.13 edge are going to be available on stable repository shortly after this is done: https://github.com/armbian/os/actions/runs/7708966983

I am sure you do. Me too. I am just saying that project doesn't have enough support from users side to cover for maintaining this device. For you and all other open source projects ... I am sure you would not complain if there would be a better option out there. Making sure that everyone that reads this understands, that Armbian project is not to blame for the troubles you have. We didn't sold any promise of support, HW vendors usually do that. That is one reason why I replied and second to inform you that there is some progress on both devices so they are not completely paperweight. There is a hope. It is. I wish you all the best. See, we have something in common

What feelings do you have to people that maintain it with their free time and private savings? Do / did you help them? Without those people, hardware is just a paperweight, a fake promise. Package updates and kernel updates are common for many devices. We officially stop dealing with Helios64 long time / several years ago. I think it was even never officially supported. After that, it was up to random / nobody to maintain it. In past year there was some self organised attempts to improve Helios64 https://forum.armbian.com/tags/helios64/ while I think Helios4 works just fine and also there we have someone that will keep it in good shape.

Reason is in exploitation nature of economical relations between parties - "you don't fund our work, but steal from" vs. "we paid for hardware, software is free" vs. "Buy 16core 32Gb NVME 2.5G PCI ... hardware that runs any Linux" We would very much invest a lot more, but someone needs to pay our bills more then 0.5%. Several people behind Armbian also works full time in order to maintain this place and all our forks and upstream distributions that are "porting from Armbian: Manjaro, Arch, NixOS, Debian, ...". There is big misconception and common believe that hardware vendors helps us. Sadly no. They don't help. With small exceptions they do everything to (ab)use our work and efforts, community development, this place, you. Whatever they are communicating, their aim is to sell hardware with promise of software support, with proprietary builds and closed features where only they have the key. Such as video 3D (opened by community on old chips), acceleration (opened on old chips), AI acceleration (closed ATM). Its a love / hate relationship. Some of things that are done in this (yet another new hardware - why we need Zero 3? 4 needs only making marketing material, board is done in a day) are fun, while (real and long term) maintenance is hard and inglorious work people tend to avoid. Getting amateurs to maintain this large, complex and disorganized egocentric landscape ... is very very hard. A lot of patches we maintain are here because upstream is wild wild west, often unfriendly to community (sometimes with a good reason) and friendly to corporate that can afford to develop at required quality level standards and also a place of deceptions. Vendors efforts are done once their HW is "supported" by mainline Linux (with "supported by Armbian" its the same), but in reality, often nobody maintains those boards and its also impossible to verify if things are alright at merge time. Some patches that we made were also simply up-streamed by removing the origin. Which is the lowest act open source developers can do. Sadly this also happens and its pointless to waste time to prove and take actions. And fight for your (c) for the job you have done for free in organised manner. Armbian is here 10 years. For us maintaining is a long term mission, done in as organised way as possible in order to save our time. u-boot is yet again, a raw material. In ideal world, all this low level job should be covered by vendors. But its not done by them. Its done by you, me and people around communities as ours, once by us, once by OpenWRT, LibreElec or similar project that stick their noise into low level world.

Provide pictures of your board from both sides.

Armbian still support this way. I verified yesterday on Ubuntu Jammy derivative. Just add some command like touch /run/test following by reboot, login and see if file was created at /run I suggest you to use previous build (or latest but choose 5.4 from armbian config -> old kernels menu), freeze kernel upgrade and enjoy. I am not sure at this point what we will do with this kernel. If Hardkernel stop maintaining it, we might need to roll back to 5.4.y. I know. We are trying best to take that pain away. Also this way: https://github.com/armbian/os?tab=readme-ov-file#latest-smoke-tests-results but problem is that all this costs a lot of time and we have to cover this from our own pockets almost entirely. Even doing it for everyone, also for our competitors that only wants you (our users) but not our costs of software support.

Sorry, this hardware is not supported. Putting HA on not supported hardware or just make that hardware usable and stable can be extremely costly. Armbian project helps you greatly to minimise efforts needed for this in first place, but we can't resolve all problems in hardware support (which should be in the domain of people who sold you hardware) or HomeAssistant. This installation was made for expert users of Home Assistant and we made it easier by providing ready to run images. If you can't DIY, IMO its best to get a Raspberry Pi or Odroid N2 (which is tested).

With XU4 we follow Hardkernel official path and provide what they provide - stock kernel with minor modifications. I would suggest you to made a complain here: https://forum.odroid.com/viewforum.php?f=225 or switch to old 5.4.y kernel via armbian-config and freeze it.

FYI. We build all targets in automated way, once per week: https://github.com/armbian/community

Armbian still supports /etc/rc.local startup way: #!/bin/sh -e # # rc.local # # This script is executed at the end of each multiuser runlevel. # Make sure that the script will "exit 0" on success or any other # value on error. # # In order to enable or disable this script just change the execution # bits. # # By default this script does nothing. YOUR_COMMAND exit 0

Armbian is hardware oriented Linux where Debian like userspace is attached on it. In embedded Linux none of this has much value ... and also people who sold you hardware provides Armbian Linux (branded as Orangepi OS) with their Rockchip private static kernel which will never be updated. Its there to die off. This is the norm. There is a long path from that toward some traditional norm. Millions of dollars or thousands of hours of community and business that are investing their time here. tl;dr; Complexity. We needed several years to fix all garbage code in all kernels, where headers compilation is a matter of randomness already on native compilation. When you add different compilers (different debian / ubuntu package base) and cross-compilation ... on 50 different kernel forks, which some, have so many custom code that its hard to say its a Linux kernel. Upstream Ubuntu/Debian usually only deal with clean mainstream world. We provide around 50 different kernels. From UEFI generic down to per SoC and further per vendor. Naming convention, current, edge (and several more) provides some simplicity in this world. And helps you to not think much. Supported hardware is tested daily: https://github.com/armbian/os?tab=readme-ov-file#latest-smoke-tests-results Which means you are generally safe - if you stick to supported hardware! Our hardware support is significantly better then Debian / Ubuntu. There users tests (except generic x86), bug response cycle is significantly longer. Our system was designed from bigger picture then Debian way (Ubuntu just copy this tool as they have no other option). It works perfectly fine and all our secondary tools are adopted to it. We looked into and even trial flash-kernel with Raspberry Pi and I am more than happy we recently drop it. Its unreliable amateur maintained tool which IMO is not very useful when you go outside RPi world. On the other hand, most of Armbian engineers comes from embedded Linux. We have significantly wider know-how about embedded Linux (which is needed to maintain such tool) then generic desktop server Debian / Ubuntu world. We checked that tool and there is nothing to learn / take from there. We have several ideas for improvement and changes here, there are 3rd party special industrial grade solutions too ... but all those ideas quickly dies due to complex and expensive integration. We can't finance this and amateurs don't work on long term complex integrations. No. If HW is not on supported list, we have no information if this hardware boots or what works. This is on you to determine and share withing the community if you like. More can ofc be done, but someone needs to volunteer and assembly this information. Until then, it does not exists, its just a GitHub commit log(s) ... If you do it right, big, if you give this task to maintainers, small, ... hundreds of people are asking for something useful all the time and there is a few people that does something on the other side and are not supported by community. Study build framework, make a PR and make sure it gets to the documentation is the right and friendly way. I hope this at least partially answers. If I would had hours, I could write a lot more on the topic Yes, we have reasons why this is so, but things can always be improved.

There is ongoing activity to set some top level re-design and prepare ground base. I doubt random person would start to do that, so this is what we have to do. I also already answered on similar topic in Documentation tickets: https://github.com/armbian/documentation/issues/390

You are delusional? Offer? From you? You asked a question about the topic you clearly don't understand well, @ag123 sponsored you answer / education / FYI and that's about it. You clearly have no clue what we do. Do your homework. Insulting us is not going into your favor. What are you waiting? If its free for you, invest your time. Ours is not free, so ... good luck.