All Activity

I fixed in the past some problems with sata drive by setting to "rolling" the sources in armbian-config. A few day ago I wanted to upgrade to trixie (debian 13) sources. I forgot to set up again the armbian-config sources to "stable" and I went in a bad situation with my raid1 : it completely disappeared from /etc/mdadm/mdadm.conf, and was unable to mount. After several struggling with the command line tools, I managed to get it recreated by the following command : mdadm --create --force /dev/md0 \ --level=1 \ --raid-devices=2 \ /dev/sdc1 /dev/sdd1 \ --metadata=1.2 --data-offset=$(( 264192/2 ))K Now it seems to be syncing, but I think the filesystem was damaged... (though I don't now, perhaps all be ok again after sync) Is there a way other than photorec to get my data back ? Thanks a lot.

@Ducdanh Nguyen can you see your axp chip? never heard of bigfish. Is that a heat sink on your SOC? Not sure why it has no writing on it. Install this android app it should give you more information https://play.google.com/store/apps/details?id=com.finalwire.aida64&hl=en_CA&pli=1 Did you apply the secure boot patch?

Hello everyone - I started having problems with installing to eMMC and I assume it is related to uboot. It used to work in the past on my devices but it doesn't anymore. The script runs successfully without any errors (besides not finding the ini file, which is irrelevant supposedly). But when trying to boot from eMMC (sd removed), I get a couple of errors (Card did not respond to voltage select), which indicates, that the eMMC can't be found. It tries booting from USB and ETH and ultimately fails. Is anybody else seeing this issue? I'm running a Vontar X3 (identical with HK1 and X96 max). By the way - the eMMC is fine. When I boot from the SD card, I can mount the eMMC ROOT and BOOT partition and they seem all correct.

This does not seem to work anymore. The flashing works but when trying to boot from eMMC, the device can't initialize the eMMC anymore ("Card did not react to voltage select"). Anybody else seeing this problem?

Hello crew, I have similar issues with installing to eMMC. In the past I was able to flash to eMMC and boot from there. I bought a second device (I'm running 2 Vontar X3, which are identical with HK1 and H96 Max, running 905x3) and flashing the newer versions of Armbian does not work anymore. I can run it from the SD card, I can even run the install script, but it will only boot, when the SD card is still in. When I try booting from the eMMC, it does not work. In the past it worked but something seems to have changed over time. I'm going the clean route and flash the original android firmware before trying to flash Armbian, to have a clean environment. I assume it's a change in U-Boot and the eMMC not being initialized correctly. When trying to boot, I get a bunch of "Card did not respond to voltage select! : -110" error messages. Then it tries booting over USB or ETH, which all fails. Does anybody know, how I could make it boot from eMMC again? Who is responsible for uboot? Thanks in advance!

Specifically, your board is "Community Maintained" That means it is not supported by Armbian resources (beyond the automated infrastructure to make builds and host them for the community) https://docs.armbian.com/User-Guide_Board-Support-Rules/#community-maintained

@Nick A su binary installed, but not working correctly, i don't know why, the chip is def h313 because i used cat /proc/cpuinfo(and others) and with grok commands i can confirm it uses cortex-a53 (which includes in h313) and bigfish manufactor/ or codename idk but it's part of allwinner, i mean enought to prove that mine is h313

@dale you need a display overlay that is compatible with tm16xx. OpenVFD overlays are NOT supported. You can read README.md and dt-bindings documentation at https://github.com/jefflessard/tm16xx-display But note that there has been many changes recently to the code base since the driver is currently in review process to be upstreamed into mainline kernel (targeting v6.18). So double check which bindings version format has been integrated into Armbian rockchip64. The GitHub repo also contains a vfd-convert utility to automatically convert OpenVFD configuration files to expected tm16xx DTSO. But : 1. It requires OpenVFD conf file, not dtso. 2. You may need to go through file history to get the version matching of what has been integrated into Armbian rockchip64.

@Ducdanh Nguyen do you know which axp chip you have on your board? It’s a very small chip with axp written on it. I don’t see the H313 markings on your SOC chip. Are you sure you have a H313? If you don’t see an axp chip you might not even have a allwinner SOC. If your android is rooted then it probably has one installed.

If you can solve the problem, please share it with the community.

@Jean-Francois Lessard I'm sorry for the typo. Yes the controller is tm1628. ls /sys/class/leds --> shows empty. Dmesg doesn't show any message for tm16xx. I've attached the working overlay source for openvfd which I have the clock digits working at least with. (The full icons would be card, usb, Low wifi, hi wifi, apps and eth) openvfd_x98h.dts

When I got my ROCK3A around 2024-12-01 I thought it was a good idea to use a newest Linux userspace so I started with Armbian Ubuntu minimal image. Just getting to know the board HW and only SD-card and serial console and RJ45 that was fine, but soon the problems started. I managed to install NetworkManager and disable networkd, so I could copy a rather complex set of NM files from my other SBC, NanoPi-R6C that is using bridges VLANs and libvirt KVM. Same as I did earlier copy that same *.nmconnection files from RaspberryPi4 (PiOS bullseye/bookworm) . And just changing a cloned-mac address entry essentially in 1 .nmconnection file initially so my router assigns the correct IP address (just initial setting), changed that later. Long story short, it turns out that you need netplan.io and that generates .nmconnection files in /etc/NetworkManager/system-connections/, at least that was my conclusion after doing tricks with apt, maybe it is different, I did not want to waste time on it anymore. Same .nmconnection files (same content) are somewhere in /var or so, I forgot where and those seem to be generated from netplan yaml files. I once constructed yaml files to get 64-bit Ubuntu server image running on RPi4 when RPL only had 32-bit ARMv6 raspbian, but already then I thought never again that netplan stuff. I already removed all snapd stuff myself. So after wasting way too much time I just created a clone image on an SD-card from a Btrfs snapshot of my running NanoPi-R6C, copied some U-Boot and kernel and DTB files then done. Could start even VMs on dedicated VLANs etc. That by the way is also an issue with Ubuntu, they keep certain files needed for running KVM different from Bookworm, so VMs did not start, I needed to look at Ubuntu fora to figure out what the issue was. I forgot what as I wiped it all. So my opinion is more or less that Canonical has some vendor lock-ins here and there and/or 'cookies' to keep you stay with them (Ubuntu). Not internet-browser cookies, but goodies, like adding BSD code to Linux (ZFS). As the world of SBCs is almost exclusively about pre-installed images with most people not able to boot an iso CD-ROM and install Linux themselves, it is easy getting into peoples homes. For me, netplan is like hidden malware as I am unable to just install NetworkManager without also getting netplan and then needing to know/learn 3 network config scripting things. Opensuse Tumbleweed also has its own network managing tool (wicked), but at least that can be ignored if you want NetworkManager (dedicated switch in YaST). Same for Debian although manual apt packages and services actions. And then there is nmtui tool that works via serial console, so for me a key feature to configure networking initially in a good interactive way. It is much easier than reading yaml docs or nmcli command options docs. So lesson learned is that I avoid Armbian Ubuntu, also Armbian Bookworm minimal. Only if downloadable Armbian Bookworm images where NM is default I would maybe use, else just clone 1 of my own installations. For own image generation with Armbian build, there is option to use NM, so I noted that somewhere. Pity is that recommended/supported build host environment is Ubuntu. I did most builds on Armbian Bookworm lately, works fine. But last time I started it on Trixie it failed. Will try again sometime soon.

To replace an image on the eMMC, the MASKROM mode is not necessary. It is only required when the firmware is so damaged that it no longer works, but the signature is still intact and the MASKROM code still executes it. To replace an image, it is sufficient to boot from a rootfs that is not on the eMMC and replace it from there. And the good thing about it is that no device-specific hacks are necessary, just a properly configured bootflow. Furthermore, it is also self-contained, as no external devices with special software or other dependencies are necessary. It can also be automated in such a way that it runs unattended and the user only has to start the process initially.

Wait @Nick A when a device is rooted, do i need a root manager???

@Nick A i flashed it to my card and it's not booting to armbian...

Customizing image and customizing kernel are different tasks. For latter use the code { font-family: Consolas,"courier new"; color: crimson; background-color: rgba(0, 0, 0, 0.2); padding: 2px; font-size: 105%; } kernel-config command and then copy over the created config file from output to userpatches. The framework will look for custom kernel configuration files and uses them if they're detected. More details here: https://zuckerbude.org/armbian-using-kernel-config/

@Nick A success build log : https://paste.armbian.eu/simirepihe

Thanks. I'll have to look into that. I expect that's for customizing the packages installed?

Armbian uses Netplan by default to manage network settings. But when it uses NetworkManager as renderer, it silently changes iptables rules—without asking, without telling. *Neither Netplan nor NetworkManager are supposed to manage firewall settings.* But they do it anyway, behind the scenes. That kind of behavior—making security changes without user consent—feels a lot like what malware does.

@Nick A full log (failed): [💲|🌱] Starting main configuration [💲|🌱] Using REVISION from [ main VERSION file: '25.05.0-trunk' ] [💲|🌿] Enabling extension [ armbian-config ] [💲|🌱] Sourcing family configuration [ /home/nguye/build/config/sources/families/sun50iw9.conf ] [💲|🌿] Enabling extension [ sunxi-tools ] [💲|✅] change-tracking: after sourcing family config [ KERNEL_MAJOR_MINOR='6.12' ] [💲|✅] change-tracking: after sourcing family config [ KERNELBRANCH='tag:v6.12.11' ] [💲|✅] change-tracking: after sourcing family config [ LINUXFAMILY='sunxi64' # (was: 'sun50iw9') ] [💲|✅] change-tracking: after sourcing family config [ KERNELPATCHDIR='archive/warpme-6.12' ] [💲|✅] change-tracking: after sourcing family config [ BOOTBRANCH='tag:v2025.01' ] [💲|✅] change-tracking: after sourcing family config [ BOOTPATCHDIR='u-boot-h616' ] [💲|✅] change-tracking: after sourcing family config [ ATFBRANCH='tag:lts-v2.10.14' ] [💲|✅] change-tracking: after sourcing family config [ NETWORKING_STACK='network-manager' ] [💲|🌱] Sourcing arch configuration [ arm64.conf ] [💲|✅] change-tracking: after sourcing arm64 arch [ ATFDIR='arm-trusted-firmware' ] [💲|🌱] Using NETWORKING_STACK [ NETWORKING_STACK: network-manager ] [💲|🌱] Adding networking extensions [ net-network-manager, net-chrony ] [💲|🌿] Enabling extension [ net-network-manager ] [💲|🌿] Enabling extension [ net-chrony ] [💲|🌱] Extension manager [ processed 17 Extension Methods calls and 27 Extension Method implementations ] [💲|🌱] x96q-lpddr3 [ Using allwinner/sun50i-h313-x96-q-lpddr3.dtb for edge ] [💲|💥] Error 1 occurred in SUBSHELL [ SUBSHELL at /home/nguye/build/lib/functions/configuration/config-desktop.sh:48 ] [💲|💥] Cleaning up [ please wait for cleanups to finish ] [💲|🌿] ANSI log file built; inspect it by running: [ less -RS output/logs/log-build-5e1956f5-4bb3-4cdf-b026-7bcfa7d1794e.log.ans ] [💲|🌱] Share log manually: [ use one of the commands below (or add SHARE_LOG=yes next time!) ] [💲|🌿] Share log manually: [ curl --data-binary @output/logs/log-build-5e1956f5-4bb3-4cdf-b026-7bcfa7d1794e.log.ans https://paste.armbian.com/log ] [💲|🌿] Share log manually: [ curl --data-binary @output/logs/log-build-5e1956f5-4bb3-4cdf-b026-7bcfa7d1794e.log.ans https://paste.armbian.de/log ] [💲|🌿] Share log manually: [ curl --data-binary @output/logs/log-build-5e1956f5-4bb3-4cdf-b026-7bcfa7d1794e.log.ans https://paste.next.armbian.com/log ] [💲|🌿] Share log manually: [ curl --data-binary @output/logs/log-build-5e1956f5-4bb3-4cdf-b026-7bcfa7d1794e.log.ans https://paste.armbian.eu/log ] nguye@DESKTOP-IFEAUMD:~/build$ EDIT: it continued while i tried Debian 12 Next i choosed xfce config_base (onlyone) internet

@Nick A i choosed x96q-lpddr3 (csc) Allwinner H313 TVB with 2gigs of ram and emmc (my box uses emmc) debian 11 image with desktop enviroment

by the way i don't see any options with allwinner h313 and 1gb ram, can i just choose the 2gb x96q?

@Nick A Oh..

@Ducdanh Nguyen on the other side of the board it has two capacitors. I don’t think that’s it.

hey @Nick A, i think i found the serial port look at the yellow mark on the image