Active threads

Very bad advice. You just made all files under /home/odroid executable. Don't run server software unless you have at least a rudimentary understanding of Linux, especially if accessible from the internet. Better get hosting and not pwned and part of a botnet. This topic is not specific to Armbian and thus more suitable to be discussed elsewhere. Closing.

Hi @dale What is your DTS node for your display? My first guess is that your DT node is not being picked up/inexistent since the module loads but the display device is not present. You can use dtc /proc/device-tree to see your loaded DT and find your display node, if any. Then, have you checked dmesg for any tm16xx kernel message? Then, you can ls /sys/class/leds to see if any device were created. The display-service/display-utils scripts expect /sys/class/leds/display. That should not be your issue here, but I'm not sure that aip1688 is the same as tm1628 variants. Googling aip1688 list it besides aip1618, so that would be the tm1618 variant. Whatsoever, I think you should have partial working display if using tm1628. To be 100% of which compatible string to use, we would need the aip1688 datasheet but I couldn't find it online. Good luck with your experimentation! Let me know how you results.

OK, personally I like btrfs and have been using it exclusively for about a decade now, I guess. Reason are manifold, but the one applicable to your case is that it will automatically detect and if possible fix corruption even when mounted. This can help prevent it from mushrooming into a bricked situation. You can also do an online "btrfs scrub" while the system is mounted, akin to the fsck that requires taking the ext4 FS offline. Look into an AB option where you have a (readonly if you like) failsafe boot system somewhere accessible to uboot in addition to your main OS. And if uboot detects main OS boot failure, have it switch over to the failsafe, ssh in to it and fix the FS corruption. How to do that with uboot, I am not sure. @eselarm might know and quite possibly that is the reason he was asking what uboot version you have as it might depend on that. There are also commercial solutions available like qubee, rauc and mender that you might want to look into.

Anyone an idea?

Yup, I opened a bug report about this on his github, I have yet to receive an answer. I'm having trouble figuring out if it's a hardware issue or a software issue, since I don't have a second bug to test at the same time. When I try the Makerbase OS on this same board, I don't have connectivity either, but at least, the link led turns on and off with the cable connect/disconnect.

Did you try to build the image with compile.sh and this following setting? INCLUDE_HOME_DIR=yes See https://docs.armbian.com/Developer-Guide_Build-Switches/#advanced

Hello ! I'm trying to build my custom Armbian image for a Raspberry Pi. When I build it with these settings, I get a rolling release, which I don't want. compile.sh BRANCH=current BUILD_DESKTOP=no BUILD_MINIMAL=yes DISABLE_IPV6=true INCLUDE_HOME_DIR=yes KERNEL_CONFIGURE=no NETWORKING_STACK=network-manager RELEASE=trixie EXPERT=yes BOARD=rpi4b But when I boot with the official armbian minimal image (Armbian_25.8.1_Rpi4b_trixie_current_6.12.41_minimal.img) It's not on the rolling release. Do I miss a setting ? edit: I've tried with building the image on the main and the v25.08 branch.

@Ducdanh Nguyen you forgot these steps choose "Show CSC/WIP/EOS/TVB" choose "I understand and agree" you should see a few x96q in the list.

Yeah, also on my laptop (Arch with upstream 6.16 kernel) this problem does not happen, so it shouldn't be because of specific patches to the rtw88 kernel in the RPi kernel repo. It only happens when I use the kernel built with Armbian build system. I am completely clueless about what could be causing this 🤷‍♂️

Sorry that was resolved 2 days ago, but I don't see and never seen this long list. Only 3 options vendor 6.1, 6.12 and edge (6.16), This morning I also seen the u-boot wasn't the good one. I downloaded for rock5-itx, but had linux-u-boot-cyber-aib-rk3588-edge instead of linux-u-boot-rock-5-itx-edge, changed it, rebooted (on 6.16) worked, tried again 6.12, still no display. I needed to arch-chroot on the armbian to take a screenshot (but I've the same dispay on armbian itself): I seen 6.16.4 is now available and work, after /boot/config-6.16.4-edge-rockchip64, gcc 13.3.0 is now again used instead of old 11.x :). Debian Trixie has GCC 14.2.0 CONFIG_CC_VERSION_TEXT="aarch64-linux-gnu-gcc (Ubuntu 13.3.0-6ubuntu2~24.04) 13.3.0" And after changelog on kernel.org, patch for AV1 acceleration had been applied on this version: https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.16.4 Fixes: 003afda97c65 ("media: verisilicon: Enable AV1 decoder on rk3588") Sorry I maybe mix too much subjects in the same post, but: I also seen a minimal IoT version of Trixie for Rock5-itx. Can I made safely a debian os upgrade from apt? Or is it better to wait release for desktop version ? Another point. On armbian, only LLVMpipe is used, I compiled last mesa git on arch, will try to do this for debian too. and some application that need to use EGL+dri (wings3D, blender, obs) report broken DRI2 access. I'm not sure if it's due to some kernel patchs (I reuse the armbian 6.16 kernel on arch), or to the current state of mesa-git. They all works with llvmpipe. Othere applications like PPSSPPSDL work fine without it. Ex, with wings3d + forced zink: MESA_LOADER_DRIVER_OVERRIDE=zink GALLIUM_DRIVER=zink wings3d WARNING: Some incorrect rendering might occur because the selected Vulkan device (Mali-G610) doesn't support base Zink requirements: feats.features.fillModeNonSolid feats.features.shaderClipDistance libEGL warning: egl: failed to create dri2 screen WARNING: Some incorrect rendering might occur because the selected Vulkan device (Mali-G610) doesn't support base Zink requirements: feats.features.fillModeNonSolid feats.features.shaderClipDistance

Easiest way is to use the customize-image.sh file in userpatches. Stuff there gets executed within chroot on the sdcard just before its closed and assembled. More advanced way is using extensions. Check extensions folder for examples.

You can either experiment with the CLEAN_LEVEL switch or use kernel-patch or uboot-patch (depending on what you want to modify) to create proper patch files from the diff.

Did you download stretch already, before I remove it to put up Bionic?

Hello, everyone. I'm using Armbian_25.5.2_Orangepizero3_bookworm_current_6.12.30-homeassistant_minimal on 4GB OpiZero3. When booting from sd, the bluetooth controller is initialized correctly. I made a boot from usb-ssd via armbian-config: everything works fine, but the bluetooth controller is not initialized. /sys/class/bluetooth is empty. Switch back to sd - it works again. Boot from ssd - no. I compared whether it transferred the distribution correctly from sd to ssd - all files are the same. What could be the problem?

This looks normal. Most of those boards have bootloaders at locations prior to boot partition. Boot loop. This can be many things - i would guess kernel crash and watchdog issue restart. Why that happens? Hard to tell. This way? sudo screen /dev/ttyUSB0 115200 It should prompt out something.

Hi, I used to run a full docker environment using the Radxa Debian buster image upgraded to bullseye. Lately as the backport repo has been archived I decided to move onto Armbian as upgrading bullseye to bookworm did not boot (or seemed so...). After flashing the latest Rockpi4 image to the Rockpi4, I copied the docker configuration and files backups. I now have a akward behavior: - starting all the stacks (or containers) works fine, all seems ok - rebooting via sudo reboot provokes an endless reboot cycle which is only ended if I unplug the USB Zigbee coordinator key. Once the loop is stopped, the RockPi does not have any IPv4 address (only IPv6) and is unreacheable by SSH. - power cycling with the USB key unplugged fixes the boot loop and everything is back to "normal", except the following dmseg errors: rock@rockpi4b:~$ sudo dmesg -l 0,1,2,3 [ 3.099273] rockchip-pcie f8000000.pcie: PCIe link training gen1 timeout! [ 3.099333] rockchip-pcie f8000000.pcie: probe with driver rockchip-pcie failed with error -110 [ 11.200510] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43456-sdio for chip BCM4345/9 [ 11.731680] brcmfmac: brcmf_c_process_txcap_blob: no txcap_blob available (err=-2) [ 11.732234] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4345/9 wl0: Jun 16 2017 12:38:26 version 7.45.96.2 (66c4e21@sh-git) (r) FWID 01-1813af84 [ 99.980012] cpu cpu4: _set_opp_voltage: failed to set voltage (825000 825000 1250000 mV): -6 [ 99.980072] cpu cpu4: Failed to set regulator voltages: -6 [ 99.980097] cpufreq: __target_index: Failed to change cpu frequency: -6 [ 246.811985] cpu cpu4: _set_opp_voltage: failed to set voltage (825000 825000 1250000 mV): -6 [ 246.812046] cpu cpu4: Failed to set regulator voltages: -6 [ 246.812070] cpufreq: __target_index: Failed to change cpu frequency: -6 [ 400.087329] cpu cpu4: _set_opp_voltage: failed to set voltage (825000 825000 1250000 mV): -6 [ 400.087387] cpu cpu4: Failed to set regulator voltages: -6 [ 400.087410] cpufreq: __target_index: Failed to change cpu frequency: -6 Now this is where it gets strange: if I prevent zigbee2mqtt container to automatically start at boot (which cannot be a permanent solution obviously) it doesn't matter if the USB key is plugged in or not (whichever usb port), Armbian boots ok and all other containers start ok. I already checked the /dev/ttyusb0 access rights, tried to change the docker container user, activate the rockchipdw3 overlay, changing the USB port for the Zigbee key, switching from rolling to stable and vice versa, to no avail. No need to say that the same config worked under bullseye. Does someone have any lead or clue about what's happening ? Where can I look as logs don't show anything special... Any help would be greatly appreciated, thanks in advance! My config: Rockpi4B, Armbian_community_25.11.0-trunk.70_Rockpi-4b_bookworm_current_6.12.43_minimal.img, usb-ITead_Sonoff_Zigbee_3.0_USB_Dongle_Plus

Thank you @Werner, for letting us know and for your efforts

it appears to be a useful application is there a way to use it without a network

@Nick A it has same issue. I thik it is related to the device tree declaration. Should it be something like this? https://github.com/LYU4662/aic8800-sdio-linux-1.0

R-TV Box S10 – I realize this is an older topic, but I’m trying to fix an S10 box for an old colleague.. After an update, it no longer boots, stuck on the startup animation, and won’t load Android. I can’t seem to find any firmware download. Thanks in advance.

I looked a little closer and the included cpufrequtil init script is totally unaware of SoC clustering. If you put in a max value for the A76, it won't work for the A55. So I threw the problem into AI and asked for a flexible SoC solution (I'm of course simplifying it). This is what it gave me. Lightly tested: per cluster governors, per cluster min/max speed, ability to specify "min" and "max" rather than numeric values. cpufrequtils-default -> /etc/default/cpufrequtils cpufrequtils -> /etc/init.d/cpufrequtil YMMV. cpufrequtils cpufrequtils-default

Yes. Installing this package on Debian-based build hosts fixed the issue. I don't think we have any developers using Arch so there aren't much tests of any other distros to ensure compatibility. Main focus is on Noble. If there is an equivalent package for arch try installing on the host machine and retry. Having it inside the docker container may not be enough.

that’s a super specific and annoying issue! It sounds like Armbian is still exposing an A2DP (audio) profile even after you tweaked the main.conf. Have you tried disabling the audio sink entirely via Bluetooth CLI or modifying the /etc/bluetooth/audio.conf (if it exists) to set AutoConnect=false under [General]?

Hi. I have Rock Pi S0 boards that I install in an enclosure. It works, but it is conceivable that some critical bug or change with the image is discovered in the future so that customers later need to flash a new image to the emmc. But for them to do this, they would have to open the enclosure and locate the maskrom button, very inconvenient. Is there a way to trigger rebooting into maskrom from software instead of pushing the button? Apparently this is possible on the official radxa OS image by running command "reboot loader" instead of just "reboot", but not on armbian it seems. After investigating I see linux patches made by the rockchip team for kernel modules like “syscon-reboot-mode” and from the code I see something like that it’s supposed to write the value 0x5242C301 to the RK3308’s GRF OS register 0, and I guess this is supposed to be read by the bootloader to direct the boot to bootmask mode instead of the OS? But the armbian distribution is already built with this kernel module by default, and I even tried to manually write this value to the appropriate registers and then rebooting, and yet nothing works, it just boots to Linux like usual. Anyone have any ideas?

Thanks for sharing your installation. Really, the Rockship in TV BOX seems the easier Armbian installations that I already tested, although, I use a TVBOX with ab AMLOGIC S912.