Igor

Check if getty is running on ttyS2 and stop it: sudo systemctl stop getty@ttyS2

That is correct, we don't deal with generic userland packages. Main focus is: build framework kernel system configuration However we developed an extension for simple patching mechanisms to apply patches to user space, but it is not in use. This whole idea of dealing with this would need a dedicated captain to drive it, develop further. https://github.com/armbian/build/blob/main/extensions/armbian-live-patch.sh For packages that we do - we fix the problem, bump version and push to the repository ...

Sometimes is

Setting up Home Assistant on your own hardware has never been easier. With Armbian, we provide a preloaded Home Assistant supervised installation on a clean Debian base, ensuring a smooth and hassle-free experience. Whether you need a smart home hub or a reliable Linux server, this setup offers the best of both worlds. Why Choose Armbian for Home Assistant? Preinstalled Home Assistant – No complicated setup, just boot and start using it. Clean Debian Base – Our images are debootstrapped and cleanly assembled, ensuring a minimal and optimized system. Armbian-Maintained Kernels – Improved, optimized, and regularly updated for better performance and stability. Supports Various Devices – Runs on Raspberry Pi, Nanopi, Radxa, Orange Pi, and many more. How to Get Started Download the Armbian image with Home Assistant preinstalled (available at board download pages - start here https://www.armbian.com/download ( example of a direct link - for Raspberry Pi: https://dl.armbian.com/rpi4b/Bookworm_current_minimal-homeassistant ) Flash it to an SD card, USB or eMMC, insert it into your device, and power it on. Access Home Assistant in your browser at http://homeassistant.local:8123 and complete the setup. Since it’s built on pure Debian, you can install additional software (via armbian-config or manually) and use it as a full-fledged server alongside Home Assistant. With Armbian, setting up Home Assistant is as simple as it gets - fast, clean, and flexible! In case of troubles: support thread

This is probably happening due to wrong local time. For the cli github package - remove it from /etc/apt/sources.d/ as its not needed anymore. We provide this package via our repo.

System access: - enable & disable root login, password, key, 2FA on SSH access - sandboxed SSH server that allows ssh access without giving keys to the entire server.

I didn't try any 32b image - it can be a challenge in case it doesn't just work. You can try to install it on the top of Debian bookworm: https://docs.armbian.com/User-Guide_Armbian-Software/HomeAutomation/#home-assistant-open-source-home-automation I believe we have latest images for that.

In case you get "Unsupported system warning", replace PRETTY_NAME with PRETTY_NAME="Debian GNU/Linux 12 (bookworm)" inside /etc/os-release following by reboot.

C2 was tested booting from a fresh image. Probably u-boot updating is mandatory prior to upgrade.

Yes, and there is also PCI error before that - could be hw related. I was testing RPi Zero 2W and Rpi5 about two weeks ago and both WiFi worked OOB. Did you try booting our latest official image? We are using K6.12.y since last release and also if you build from sources now, it will be 6.12.y

@TonyB Tested - it works now as expected when installing this image https://dl.armbian.com/rpi4b/Bookworm_current_minimal-homeassistant Also tested other platforms with success: Khadas VIM1S x86 Nanopi M6

Firmware for BT was added https://github.com/armbian/firmware/commits/master/ while for enabling of CM4 refer to official instructions - what needs to be set in /boot/firmware/config.txt in order to get full functionality. This is the same as in official OS.

There are two things - from a quick log check - that are missing: - enabling "something" in the /boot/firmware/config.txt This can be an overlay telling to enable certain overlay specific for CM4 - firmware files (which are for Bluetooth): [ 6.374743] Bluetooth: hci0: BCM: firmware Patch file not found, tried: [ 6.374779] Bluetooth: hci0: BCM: 'brcm/BCM4345C0.raspberrypi,4-compute-module.hcd' [ 6.374787] Bluetooth: hci0: BCM: 'brcm/BCM4345C0.hcd' [ 6.374795] Bluetooth: hci0: BCM: 'brcm/BCM.raspberrypi,4-compute-module.hcd' [ 6.374802] Bluetooth: hci0: BCM: 'brcm/BCM.hcd' Let me check ...

With enabled everything in automatic upgrades. If kernel is not frozen, it will update too. If it's frozen (check with apt-mark showhold) find in the armbian-config to unfreeze it.

Let's ping Radxa engineers if they have a clue on this @RadxaYuntian otherwise I propose trying CURRENT kernel. That should be generally more reliable in those things.

Hardly without logs. Type: sudo armbianmonitor -u and provide URL.

OS is not involved into this, hardware interface (kernel) determines if things works or not and how well. We are using latest Rockchip kernel and this might work better in previous, still in use by Radxa. Guessing that you are using some 5.10.y or 6.1.75 ... since you forgot to tell the most important information Try with mainline based kernel 1st, https://docs.armbian.com/User-Guide_Armbian-Config/System/#install-alternative-kernels -> current , where such hardware usually works better. Or try older vendor kernels, that might be the same as in Radxa OS.

Make sure all parameters of /boot/firmware/cmdline.txt are one after another, in one line. This is correct way on a clean target: sed -i '/./ s/$/ systemd.unified_cgroup_hierarchy=0 apparmor=1 security=apparmor/' /boot/firmware/cmdline.txt I haven't done with all the testings and will continue tomorrow. I have to check major targets, not just Rpi.

I estimate few days, a week, if focusing just into this problem. "Officially supported" also needs someone to act as a maintainer https://docs.armbian.com/User-Guide_Board-Support-Rules/#standard-support On a long term, not just fixing current issue. Every kernel (boot-loader) change can break features partially or completely (boot failure).

It works. I messed up something. Just add that to the cmdline.txt and it should work - works for me. I am fixing now installation methods and testing to make sure everything is alright.

Run this as root: echo " systemd.unified_cgroup_hierarchy=0 apparmor=1 security=apparmor" >> /boot/firmware/cmdline.txt reboot This works for me (after adding this): Fixes: https://github.com/armbian/os/pull/289 https://github.com/armbian/configng/pull/466

Majority of firmware on Armbian images are developed from scratch and around mainline sources (dietpi only download Armbian, re-brand it to dietpi and "support" - they never fixed any common issues). Alternatively we could use Allwinner stack provided by Orangepi to achieve same hardware functional level, but in that case many other things won't be working (well). Static private kernels are in very poor state and not long term solution as nobody is going to maintain them. https://docs.armbian.com/User-Guide_FAQ/#why-does-hardware-feature-xy-work-in-old-kernel-but-not-in-more-recent-one Either use Orangepi fixed kernel or support development that happens at and around projects such as Armbian. We are spiting blood to make those boards working with modern kernel, without any help of this vendor. And very little, close to none, from end users. This is the main reason why things are not at the state you expect. It's a lot of work to get those devices working well and developers are humans with their needs.

which hardware platform / kernel ?

Try armbian-config way - drop your configs before.

This is not Armbian fault by any means. When you buy hardware, you mainly support hardware designers. Proper software support, that is yet to be developed by projects such as ours (with or without collaboration with hardware makers). This board was added to the Armbian build framework by vendor last week (!), which means its support is basic, bugs are expected and it only have community support status ATM: https://docs.armbian.com/User-Guide_Board-Support-Rules/ Probably this will fix it. https://github.com/armbian/build/pull/7903