Igor

This is just one issue out of thousands and we operate all this with budget that is very close to zero. This should be picked by maintainer, if exists. We support them from our business deals, but still, they come and go and in between, we have nobody. For a month and half, there is nobody and I can't cover, its too expensive. Since none of board maintainer is full time, but they should be, this can easily take weeks, or more ... But luckily: automated builds makes it half way. Its there, even smoke tested, where problems are not detected. one can build combo on their own. its open source. You can fix bugs too. we need to push new release by the end of the month. And yes, I heard there are some problems with Rpi kernels. Which will just make us more damages and headaches. Rpi foundation has almost 2 mio EUR yearly budget to fight problems ... Its not Armbian that is making bugs, but you expect us to pay to fix them. I tried to help you with hints. Here I have to stop. Out on vacations.

Remove headers, reboot, install then once again.

Did you reboot before (re)installing headers? If yes and still not ok ... beta repository certainly has matched kernel / headers combo. IMO its pretty safe to upgrade to daily builds, but then freeze kernel (can be done in armbian-config).

Armbian didn't sold you functioning of this device. We are telling you that this hardware is not supported and we don't even think to support it. Support costs money. Even this is perhaps possible to support with several ten thausands per year, we will not do anything as total Orangepi support budget is negative. HW, on the othe hand, needs constant support or it starts to fall apart. They will ofc not tell you that. They simply don't change software stack in any way, so nothing will fall apart ... but there is ofc a problem. Most hardware is sold with privately made Linux kernel (5.1 also 6.1. now). They get code from SoC vendor and for this software most of this https://twitter.com/internetofshit applies and is never resolved, but most of people are unable to understand, don't know or care about. Customer that this is sold is just more uneducated in technical sense. Modern Kernel 6.x (beware on numbers deception) is build from scratch where its impossible that all features works right from start. Costs per each SoC family can go into millions. Orangepi is not involed here, but we are. They don't support development, we (and other FOSS projects) do. Yeah, its that crazy They are flooding market with cheap hardware with as cheap software support as possible. Pirated software? No problem. Who will sue them? Do you (users) care? Supporting projects that are stealing from open source? No problem. There is absolutely no moral code. SoC vendors also doesn't care about anything but numbers of SoCs sold. Revenue, while abusing open source communities, is the only king there is. On a long run and if you don't want to have internet of a shit device, you will use ... Armbian, fork of it, some similar Linux. Which you don't support as they are doing everything to mask the true costs of software development. Also Orangepi is providing modern Linux software that is branded as Orangepi to fake "development" by them. Most of users have no ability to understand that Orangepi is not a software company. They sell hardware, while software they just "get", rebrand, sell. They downloaded Ambian build framework at one point. This was several years ago. Then they ran search for "Armbian" replace with "Orangepi" to impress people with work they never contributed anything to. This is one of ways how (some of) those companies stealls value and show "respect" toward people that finance them. In case you have questions regarding this particilar hardware, contact Orangepi officie directly. I know its a waste of time, but at least they will have support damages. Support = hard cash expense also for open source projects. Developers are asking you for support https://github.com/sponsors/armbian and it years and years that those numbers got to the 10% of 1k per month. Which is a discrase, but its impossible to communicate that. For example two people, which would be lost in this support, costs 10k per month, 10x more it has been asked. Volonteers? Yes, they are happy to help, but bulk of support needs professional backbone or you complain and make dirt, even you pay like nothing. Still you think Aliexpress dealer is the one that provides any software? They invest close to nothing into software development as they are by default affraid they will support their competitions ... so they don't pay any "taxes" for software they take from open source and sell as theirs. One hour of engineering is worth more then 1pcs of hardware. Simply change it to something else and: - there is actively maintained codebase - you will get responsive free regular support - you can get instant professional support - you will support developers not hd just dealers that are already selling you something new with demo software This comes with https://www.armbian.com/bananapicm4io/

Try this https://launchpad.net/~savoury1

Did you reboot after installing headers? I tried on beta software https://paste.armbian.com/ayilamofor and kernel 6.8.7 ... it works https://paste.armbian.com/aqumeheguf.yaml I think this is a problem .... Odroid M1 was merged into rockchip64 kernel ... remove linux-*-edge-rk3568-odroid and install linux-*-edge-rockchip64 and try again. It must work. Tested also on stable branch https://paste.armbian.com/efilumozaq.yaml

Bookworm is latest stable. You can only upgrade to unstable ... which is not recommended for production. You could upgrade kernels, but we don't provide them anymore for bullseye. That is correct. This is the list of packages per distribution: https://fi.mirror.armbian.de/apt/content.html Bullseye only has some files, probably by mistake. It should be just empty as its not supported anymore. Change tags in armbian.list from bullseye to bookworm and update. Should be fine .... at least as far as from Armbian perspective. We can't vouch for packages that are coming from Debian repository as they might come into some conflicts between each other. This is the problem we observe on older releases and have no capacity nor wish to address.

Directly no as it doesn't have any software that would allow this. This way (via SD or eMMC): https://docs.armbian.com/User-Guide_Getting-Started/#how-to-install-to-emmc-sata-nvme-usb

Yes. If you copy and paste everything into the terminal, it should do the job.

(Maintained as) Armbian with Kali applications already exists as an extension. Copy https://github.com/armbian/os/blob/main/userpatches/extensions/kali.sh to extensions of your userspatches/extensions/ and try with: ./compile.sh ENABLE_EXTENSIONS="kali" Not sure if something is missing, but its pretty easy to add. Going this path saves you a lot of time. As far as patched for hacking wireless drivers or/and kernel tweaks, we should have most of them, probably more then Kali Linux. In technical sense there are just userspace applications, which are IMO included into that extension. The rest, majority, about Kali is myth, produced by Hollywood and community. On some download pages, you can already find ready to run images, X86 arch for example: You can try that image on your PC, fine tune, then just build for whatever you want.

In recent images, this patch service should not be preset by default. If service is not there, then you should be fine. Also check / remove this file /etc/apt/apt.conf.d/02-armbian-preupdate if it exists.

sudo systemctl disable armbian-live-patch.service

After applying patch from previous post, it updated to latest version without complaining about unhealthy status:

https://www.armbian.com/bigtreetech-cb1/ We have one device in auto-tests and we might port it to 6.6.y If that screen works, its unknown, but I would assume yes as we are using vendor kernel.

Try adding INCLUDE_HOME_DIR="yes"

https://github.com/armbian/build/pull/6425

Supervisor sometimes losess healthy state https://github.com/home-assistant/supervisor/issues/4381 and this is not Armbian related problem. However, we will fix this problem. Future builds are going to be patched https://github.com/armbian/os/pull/177 and for already installed, users can easyily implement workaround from PR manually: creating bash script creating systemd service that execute that script enable that service Copy and paste instructions for older builds! Login via SSH and execute: sudo bash -c 'cat << EOF > /usr/local/bin/supervisor_fix.sh #!/bin/bash while true; do if ha supervisor info 2>&1 | grep -q "healthy: false"; then echo "Unhealthy detected, restarting" | systemd-cat -t $(basename "$0") -p emerg systemctl restart hassio-supervisor.service sleep 600 else sleep 5 fi done EOF' sudo chmod +x /usr/local/bin/supervisor_fix.sh sudo bash -c 'cat << EOF > /etc/systemd/system/supervisor-fix.service [Unit] Description=Supervisor Unhealthy Fix [Service] ExecStart=/usr/local/bin/supervisor_fix.sh [Install] WantedBy=multi-user.target EOF' sudo systemctl enable supervisor-fix sudo systemctl start supervisor-fix

Temporarily network maintenance issue at that segment Sadly can't fix remote. Tomorrow... Wrote on mobile

@Gunjan Gupta is doing that and sadly its a lot of work: "here are 77 broken patches that need manual fixing" We are looking at weeks.

You can try default Armbian way, but beware this case was not tested, so its recommended for making a full HA backup so you can restore in no time. Mine too: igorp@odroidn2:~$ df -h Dat. sist. Vel. Upor. Prost Upo% Priklop na udev 1,7G 0 1,7G 0% /dev tmpfs 372M 5,9M 366M 2% /run /dev/mmcblk0p1 29G 5,4G 24G 19% / tmpfs 1,9G 0 1,9G 0% /dev/shm tmpfs 5,0M 0 5,0M 0% /run/lock tmpfs 4,0M 0 4,0M 0% /sys/fs/cgroup tmpfs 1,9G 0 1,9G 0% /tmp /dev/zram1 47M 38M 5,7M 87% /var/log tmpfs 372M 0 372M 0% /run/user/1000 I see no reasons to upgrade anywhere. Especially not to buggy USB3 storage.

Open a PR here https://github.com/armbian/build/tree/main/patch/kernel/archive/rockchip-6.1/overlay If he doesn't want to be contacted, there is nothing we can do. This is volunteering position at best effort principle. Some have time, interests and love, some don't. When we notice maintainer becomes unresponsive, board is (at release cycle) moved from "Standard" to "Community support" unless someone else take it over ... https://github.com/ich777/pikvm-rockpi-e This would be much better to be done as extension to the build framework. Examples: https://github.com/armbian/os/blob/main/userpatches/extensions/ha.sh https://github.com/armbian/os/blob/main/userpatches/extensions/openhab.sh Docs: https://docs.armbian.com/Developer-Guide_Extensions/ There is another person, that is around, doing similar https://github.com/srepac/kvmd-armbian perhaps teaming up and do it properly & maintainable? And with IMO less efforts.

Try those things that didn't work for @pgd just to make sure ... Also welcome to make a PR https://github.com/armbian/os/blob/main/userpatches/targets-release-apps.template#L35-L57

Yes. I have also updated instructions in the 1st post.

32bit, expect troubles ... make image and try? How-to is in the first post.