Active threads

openssh-server should be installed by default on all images/configurations.

thanks again, I'll do this soon.

chatgpt advised to type ":UTC" or ":Europe/Berlin" and it helped.

Same answer as above. Without serial logs impossible to debug. It leaves to mention that this board is not officially supported but configuration has been provided by a community effort. Board status is unknown to the core Armbian team.

No. Yes. This is the most stable and well-developed kernel.

kernel_ramfs is located at /dev/block/mmcblk2p6 Have extracted with dd and copying through wifi adb. Interesting usb debugging is enabled in tvbox, but when connecting usb v3 cable to tvbox, host machine does not see the 'adb device', adb connection over wifi is ok. Has anybody used USB adb on this device?

No, that won’t work. This is a Armbian Linux forum. If you need android support try xda forums.

No one answers...... 🤐 I got tired of waiting and set up autologin according to these instructions. Everything is working.😁 You can use it.💯

I've checked the storage media and it seems to be a NAND - https://files.pine64.org/doc/datasheet/pine64/FORESEE_eMMC_NCEMBSF9-xxG SPEC A0 20150730.pdf Not sure if this is of any use in figuring out why it cannot see the boot partitions.

Well, i have jumped ship on gone to every os i can think of that will run on RPI5 and now IM BACK!!!! Hello again, Jayson Here - And i have decided that Arbian 25 Noble Gnome may be the smallest-strongest multimedia build i can find...so its what i will choose to finish my PI 5 with. I am still wrestling with the sony IMX477 as to produce video. I have just ordered a usb mount for uvc-video rather than csi/cam0-cam1 b/c i cant get it working. at all and need to advance... to the touchscreen which is still just HDMI w/o touch. on the new download of Armbian. its downloading now. I will put pics of the device and more tomorrow. Jay T.

moved

Hi guys Just to thank you for the very relevant information I found in this forum. I am posting my experience with armbian. I successfully installed the unofficial armbian version "25.05.0 onecloud noble 6.12.17 xfce desktop" on a generic MXQ TV Box S805 with HTC-MXQ-V4 card. It was hard work! this box calls the aml_autoscript on boot... but need to be adjusted to allow booting. this procedure works for the board i mentioned, i don´t know about others. Use at your risk !!! But booting from SD is a relativelly safe procedure. download "Armbian-unofficial_25.05.0-trunk_Onecloud_noble_current_6.12.17_xfce_desktop.img.xz" uncompress the image (7zip) save to SDcard (8GB recomended) - I have used rufus Two partitions will be created. Two partiotions will be created ... first FAT32 (armbi_boot) and second EXT4 (armbi_root). On FAT32 partition (boot): file: aml_autoscript (copy commands below and put inside aml_autoscript.cmd) # Define boot only from SD Card setenv bootdev "mmc 0" # SD card # Load armbianEnv.txt fatload ${bootdev} 0x10800000 /armbianEnv.txt && env import -t 0x10800000 ${filesize} # Boot Arguments (provided by armbianEnv.txt) #setenv bootargs "" setenv bootargs "${bootargs} rootwait rw" setenv bootargs "${bootargs} ${consoleargs}" setenv bootargs "${bootargs} ${extraargs}" # Booting fatload ${bootdev} 0x14000000 /uImage || exit 1 fatload ${bootdev} 0x15000000 /uInitrd || exit 1 fatload ${bootdev} 0x11800000 /dtb/meson8b-onecloud.dtb || exit 1 bootm 0x14000000 0x15000000 0x11800000 file: armbianEnv.txt (copy parameters below and put inside armbianEnv.txt) consoleargs="console=ttyS0,115200n8 console=tty0 no_console_suspend splash=verbose" bootargs="root=LABEL=armbi_root" extraargs="loglevel=7 rootfstype=ext4 earlyprintk ip=dhcp" On Linux, put aml_autoscript.cmd on an directory and compile "mkimage -C none -A arm -T script -d aml_autoscript.cmd aml_autoscript" Copy both aml_autoscript.cmd and compiled aml_autoscript to root of FAT32 partition Adjust (with above parameters) or create a file and copy armbianEnv.txt to root of FAT32 partition. Rename "meson8b-mxq.dtb" to "meson8b-onecloud.dtb" to be compatible with same name defined on aml_autoscript (you could rename the file ou change the script ... choose) Boot from SDCard (Turn tvBox off, with a toothpick, click the button inside AV conector, hold down and turn on the TV box, hold the button for 5 to 15 seconds ) if everything went well the firt boot occur and your tvbox could boot from SD in armbian Linux with kernel 6.12 The first boot is extremelly slow... a lot of time... Good luck!!

Ok, I'll wait for the release to land and test again. I agree, upgrading away from legacy is good. That said, as things are now this will break any installation that is using wlan when they upgrade their packages and are on the legacy kernel. And it's even worse as the user needs to know to update to latest release and only then swap kernels due to the timing of the wlan fix. To put it in different words, I'm not proposing we fix the legacy kernel. I'm saying we need to make sure that we're not breaking current users who have no way of knowing that things are going to be breaking.

@Diego Dagum are you using an apt caching mirror like apt-cacher-ng?

Apologies. Didn't realise that. I have no means of connecting to uart - I'll want until a bootable version shows up.

I updated my system and it broke again. Had some trouble getting it to work again. For some reason the DTS editor doesn't come up in armbian-config anymore(?). Anyway, it can be done from the console. I decompiled the sun501-h6-orangepi-3-lts.dtb, edited it and compiled it again. It worked as a charm. I noticed that the spi pins had changed to 0x31 and 0x32 and the spi@5011000 phandle was 0x78 instead of 0x7a. I only changed status to "okay" and added the spidev@0 {...} section. Then I removed the dtbo overlay. spi@5011000 { compatible = "allwinner,sun50i-h6-spi\0allwinner,sun8i-h3-spi"; reg = <0x5011000 0x1000>; interrupts = <0x00 0x0b 0x04>; clocks = <0x06 0x53 0x06 0x51>; clock-names = "ahb\0mod"; dmas = <0x2e 0x17 0x2e 0x17>; dma-names = "rx\0tx"; pinctrl-names = "default"; pinctrl-0 = <0x31 0x32>; resets = <0x06 0x20>; status = "okay"; #address-cells = <0x01>; #size-cells = <0x00>; phandle = <0x78>; spidev@0 { compatible = "armbian,spi-dev"; reg = <0x00>; spi-max-frequency = <0xf4240>; }; };

!

I only tested the main configuration to ensure that the kernel and file system rootfs are normal, and other configurations have not been tested yet The attachments are patch files and several modified source files. The testing was conducted in my own buildroot project. It has not been tested in armbian yet (there are currently some issues with the armbian compilation environment). My buildroot project was launched based on the DTS of this post. I believe it should be available in armbian. add-rk3576h96-m9s-dts.patch rk3576-linux.dtsirk3576-h96-m9s.dtsrk3576.dtsi

It's a bit embarrassing, but in my case the fault was entirely mine. I seemed to have messed around a bit too much with the system. However, maybe this helps someone else with their problem as well. One of the changes I did to my system caused the /lib directory to be replaced by an actual directory instead of a symlink to /usr/lib. As the init.d script is stored in /usr/lib/init, the boot process couldn't find it anymore under the path it expects it to, the kernel panicked. I then removed the directory including all its contents and replaced it with the correct symlink again. Since then, my Cubietruck has been working fine.

I have resolved it, modified in the driver.

It would be nice to know what is the actual problem here, so we can at least add instructions. If XZ format is not supported, then probably it needs to be decompressed manually, perhaps renamed to ISO and then flash. Or there is some other trick here? P.S. Mirror fixed the problem on their side.

Released so far: 2025-05-22 18:26:26 lepotato/ 2025-05-22 06:07:29 tritium-h3/ (untested) 2025-05-21 22:12:58 tritium-h5/ (untested) 2025-05-21 13:54:39 nanopi-r2s/ 2025-05-21 13:19:56 nanopi-r4s/ 2025-05-21 13:10:48 bigtreetech-cb2/ 2025-05-21 12:37:56 nanopi-r1/ 2025-05-21 08:24:34 odroidxu4/ 2025-05-20 21:02:21 bananapim2plus/ 2025-05-19 16:34:51 tinkerboard/ 2025-05-19 16:08:37 odroidc1/ 2025-05-19 13:41:51 cubox-i/ 2025-05-19 13:33:57 udoo/ 2025-05-18 18:14:19 rock-5c/ 2025-05-15 20:00:20 odroidm1/ 2025-05-15 19:45:23 odroidn2/ 2025-05-15 19:22:52 uefi-x86/ 2025-05-15 19:07:47 uefi-arm64/ 2025-05-15 17:31:47 odroidc4/ 2025-05-15 17:26:55 bigtreetech-cb1/ 2025-05-15 14:28:07 bananapicm4io/ 2025-05-15 14:10:36 rockpi-e/ 2025-05-15 13:15:45 helios4/ 2025-05-15 13:09:35 bananapim2pro/ 2025-05-15 12:47:30 clearfogpro/ 2025-05-15 12:14:00 nanopik2-s905/ 2025-05-15 11:21:35 mksklipad50/ 2025-05-15 10:05:49 odroidc2/ 2025-05-14 18:48:20 bananapif3/ I do this manually, every day few boards, those which I have around - basically I am manually updating my test farm. Many thanks to all that already helped in making this list longer. Release text is also WIP - even AI helps, its still quite a lot of work to convince (drunk / stupid) AI what do we want If you have time, please help - make image https://docs.armbian.com/Process_CI/#prepare-application-images-for-release-release-manager test it and provide feedback. In case you find something, hit red button here and make a short note. Thank you! code { font-family: Consolas,"courier new"; color: crimson; background-color: rgba(0, 0, 0, 0.2); padding: 2px; font-size: 105%; } code { font-family: Consolas,"courier new"; color: crimson; background-color: rgba(0, 0, 0, 0.2); padding: 2px; font-size: 105%; } code { font-family: Consolas,"courier new"; color: crimson; background-color: rgba(0, 0, 0, 0.2); padding: 2px; font-size: 105%; } Would you like to take on the role of maintainer for a specific board? https://docs.armbian.com/User-Guide_Board-Support-Rules/

Monado's first stable of release of 2025 is here. From enhanced Android support and driver updates to improved runtime stability and tooling, Collabora's XR team delivered a wide array of improvements for the cross-platform, open source OpenXR runtime. View the full article

I found this I hope it helps you @Luiz-SP