All Activity
- Past hour
-
networking in bpi-m5 with new 26.03.1 release.
SteeMan replied to gene1934's topic in Software, Applications, Userspace
As a moderator having watched this thread, I'm going to close it down, as I don't think anything else productive will be said at this point. However I do want to thank both @bedna and @eselarm for their time and effort to help. Armbian appreciates all the volunteers who make these forums possible. - Today
-
networking in bpi-m5 with new 26.03.1 release.
gene1934 replied to gene1934's topic in Software, Applications, Userspace
And the email system for is emailing with me erroneos info about bedno report 2x a day, so call off the quard dogs, it been solved without any help from this forum. you've been yelling about dhcp w/out once offering me a single clue as to how I should configure it even when I showed you the results. FYI I have been doing odd things with little machines for a lot longer that most of you have been breathing on your own starting with an rca 1802 in 1978. Do any of you have a track record that long? That bit of production tooling for a medium market tv station was still in use 20+ times a day when the station burned to the ground in the late 90's. I prefer to call it efficiency since most production equipment at a tv station is so heavily used & long since worn out before the IRS lets them amortize the cost. I am also a CET, a test 95% of the EE's out there cannot pass. I call a backup server that draws 19 watts at full song in the middle of backing up 8 machines here, efficient. Took me a while to figure it out the hardware and around $1500 in hardware. But it works as fast as my cat6 wired local net can run. -
Kernel not updating in image with armbian build
eselarm replied to KV1's topic in Armbian Project Administration
I used it once as test. Good thing is it does verification. Hopefully that will help kill the counterfeit SD-card sales and various rubbish SD-card adapters. Bad thing (for me at least) is that there is some image caching option on by default. Good for saving excessive re-downloads, but I did not look how it works and where it is stored. I use differential backups, also via slow/expensive mobile links potentially, so don't want to wast bandwidth and volume on some cache image or chunk of data. To help people with images on this forum, I did run/boot various images as container, can be done with sudo systemd-nspawn -b -i <imagefile> (if rootfs in image is just 1 partition ) You need some working ARM64 computer of course, but that can be the old/running version of the one you want to upgrade. So I suggest you do that, or maybe the build environment cache cleaning fails (your setup). Also you involve an SD-card already. What if that card internal firmware messes up blocks. If you anyhow build image yourself, maybe use Btrfs as rootfs, also make sure U-Boot has option enabled, than you have much better ways to pin-point where the problem is. But you already did bold text for file dates I see, so I guess some caching issue somewhere. -
networking in bpi-m5 with new 26.03.1 release.
eselarm replied to gene1934's topic in Software, Applications, Userspace
/dev/mmcblk0p1 is a partition that contains the filesystem, not a drive. The drive is /dev/mmcblk0 and because you did a low-level sector by sector (or block by block) copy with dd, it also just has the exact same partition table (MBR-table or GPT). Now in modern Linux and various pre-installed images there are methods (possible) to expand the partition and the filesystem to occupy the whole remaining space. It is easier with MBR-table. If GPT, there is a backup GPT at the end of the disk, so in your case 64G. On the 128G SD-card the space after 64G is then hidden. I usually manage all this manually before first boot, with gdisk, not fdisk. As it is text based, it also works via remote ssh and serial console cable. I also deliberately added a dummy partition (number 3) to RPi images in the past so that the auto-expander could not claim the whole SD-card. If no GUI, a Linux install fits within a few GB, especially if you use Btrfs as filesystem for root and use on-the-fly compression (mount option compress-force=zstd). Then it is about 1GB needed, not 100x more. -
apply this patch for a working wifi: diff --git a/extensions/radxa-aic8800.sh b/extensions/radxa-aic8800.sh index e3e99eaa8..7ab721353 100644 --- a/extensions/radxa-aic8800.sh +++ b/extensions/radxa-aic8800.sh @@ -10,7 +10,7 @@ function extension_finish_config__install_kernel_headers_for_aic8800_dkms() { function post_install_kernel_debs__install_aic8800_dkms_package() { - if linux-version compare "${KERNEL_MAJOR_MINOR}" ge 6.20; then + if linux-version compare "${KERNEL_MAJOR_MINOR}" ge 7.1; then display_alert "Kernel version is too recent" "skipping aic8800 dkms for kernel v${KERNEL_MAJOR_MINOR}" "warn" return 0 fi
-
I have tested the latest build (26.2.0-trunk.668) and found that USB 3.0 is still not operational. Has anyone been able to get this working?
-
networking in bpi-m5 with new 26.03.1 release.
gene1934 replied to gene1934's topic in Software, Applications, Userspace
I've wasted 2 days now, screwing around trying to make netplan work and not getting anywhere. So I've taken a screenshot of what works on my e5p. I will nuke the 25-04 image I have and dl a fresh one but to test that idea, I'll first get the card from the e5p and see if it works in this one. But first I'll dl an image of the e5p card. And I may have a clue dd died w/o an error at 64G of a 128G card. So now that image is being written to another 128G u-card to see if it becomes an e5p when booted and the network works in which case i'll edit the hostname and see if it is amanda when repowered again. It was pings yahoo.com like it has a license. At 192.168.71.122 at which point I edit the netplan to put it back at amanda's address of 192.168.71.2. If that works, and it did, install gfs2 & 57 deps and mdadm & see if the /raid6 appears on a pd reboot. It did as /dev/vg0/myraid so while this has been a looooong slog, it all works even if its not an approved method. That img has quite a pile of gcode as it been a 3d printer for over a year. burned up a hot end and 20+ kg of filament. All that can go. And its gone quite nicely so far, got the /raid6 stuff installed and its been making a new 6.18 initramdisk img for about 20 minutes. Assuming its found the raid6 and has to fsck 11.2 Tb it might take a while. The busy circle is still rotating. But its still rotating with a new msg, something about permissions despite me being root to run synaptic. But that did NOT prevent it from rebooting from a powerdown. Or preventing me from mounting the /raid6 after creating its mount point. And recovering from that raid6, the rsync based backup driver script that fills it. I'm logged into it from here and here is a df report: gene@amanda:~$ df Filesystem 1K-blocks Used Available Use% Mounted on tmpfs 385288 6424 378864 2% /run /dev/mmcblk0p1 60102260 12713940 46688204 22% / tmpfs 1926424 0 1926424 0% /dev/shm tmpfs 5120 0 5120 0% /run/lock tmpfs 1926424 68 1926356 1% /tmp /dev/zram1 47960 1524 42852 4% /var/log tmpfs 385284 92 385192 1% /run/user/1000 /dev/mapper/vg0-myraid 11272913680 533576604 10739337076 5% /raid6 So it even thinks /dev/mmcblk01 is a 60G drive, apparently because the one I copied was a 64G, not a 128G like its label says. problem solved but I still haven't the foggiest what the real problem was, only that I burned up two weeks of my remaining life at 91 years old already. Now I need the fstab line that automounts it during the bootup. - Yesterday
-
I have an H50-labeled tv box with a different board (T98-3318-V2.3) but with exactly the same problem - no HDMI even though all the software debug traces show that everything video-related gets called and works. I first tried to make it work 5 years ago and failed and a few months ago I revisited it just to see if I can make it work now in the age of AI. I made a really deep dive into reverse engineering it. I rooted the original Android firmware and dumped anything I could, extracted and analyzed with Ghidra the vendor u-boot and kernel (wasn't particularly helpful) and finally managed to execute the u-boot binary in Renode by emulating a lot of hardware stuff with code or by simply replacing functions with successful returns all the way to the point of u-boot displaying the splash screen and with various hooks and warnings about peripheral accesses I collected a comprehensive trace of everything that u-boot was doing, and in that trace, the AI noticed a certain GPIO access and suggested replacing this vcc-host-vbus { compatible = "regulator-fixed"; enable-active-high; gpio = <0x74 0x00 0x00>; pinctrl-names = "default"; pinctrl-0 = <0x76>; regulator-name = "vcc_host_vbus"; regulator-always-on; regulator-min-microvolt = <0x4c4b40>; regulator-max-microvolt = <0x4c4b40>; vin-supply = <0x77>; phandle = <0x100>; }; with this vcc-display-en { compatible = "regulator-fixed"; gpio = <0x74 0x00 0x01>; pinctrl-names = "default"; pinctrl-0 = <0x76>; regulator-name = "vcc_display_en"; regulator-always-on; regulator-boot-on; regulator-min-microvolt = <0x4c4b40>; regulator-max-microvolt = <0x4c4b40>; vin-supply = <0x77>; phandle = <0x100>; }; in the standard rk3318-box.dts which made HDMI work.
-
Kernel not updating in image with armbian build
KV1 replied to KV1's topic in Armbian Project Administration
Even more confusing the file on the disk, written with armbian-imager is a text file, looks like an apt sources file: > file /mnt/boot/vmlinux-6.18.21-edge-mvebu64 /mnt/boot/vmlinux-6.18.21-edge-mvebu64: ASCII text, with very long lines (1483) > head /mnt/boot/vmlinux-6.18.21-edge-mvebu64 com/daniel-casanueva/haskell/graphviz Description-md5: bd02d2c14f791ffca367313e1957b329 Ghc-Package: graphviz-2999.20.2.0-JKUYtUkvYwE3GbOspxTTfB Section: haskell Priority: optional Filename: pool/main/h/haskell-graphviz/libghc-graphviz-dev_2999.20.2.0-1+b1_arm64.deb Size: 3696512 MD5sum: 36c93a1f30f0234eadffbf9ae0d2336b SHA256: 5b95053c25c02020e9eca717df070591259432e5c125435f5514761417bc8879 The built file looks fine: 1348921 717100 -rw-rw-r-- 1 root root 734305912 Apr 7 17:45 ./cache/sources/linux-kernel-worktree/6.18__mvebu64__arm64/vmlinux.o > file ./cache/sources/linux-kernel-worktree/6.18__mvebu64__arm64/vmlinux.o ./cache/sources/linux-kernel-worktree/6.18__mvebu64__arm64/vmlinux.o: ELF 64-bit LSB relocatable, ARM aarch64, version 1 (SYSV), with debug_info, not stripped -
Kernel not updating in image with armbian build
KV1 posted a topic in Armbian Project Administration
When trying to rebuild the kernel, the image is not taking the updated kernel image: ./compile.sh BOARD=espressobin CLEAN_LEVEL=make-kernel RELEASE=trixie ..... -rwxrwxr-x 1 root root 296665952 Apr 7 16:47 vmlinux.unstripped -rw-rw-r-- 1 root root 220926 Apr 7 16:47 modules.builtin.modinfo -rw-rw-r-- 1 root root 16667 Apr 7 16:47 modules.builtin -rwxrwxr-x 1 root root 296215160 Apr 7 16:47 vmlinux drwxrwxr-x 23 root root 12288 Apr 7 16:47 kernel/ drwxrwxr-x 79 root root 12288 Apr 7 16:47 fs/ drwxrwxr-x 5 root root 36864 Apr 7 16:47 crypto/ drwxrwxr-x 22 root root 20480 Apr 7 16:47 lib/ drwxrwxr-x 27 root root 4096 Apr 7 16:47 sound/ drwxrwxr-x 23 root root 12288 Apr 7 16:47 scripts/ $ armbian-imager # installed the new image... 16:55:21 ● custom_image: Check decompression for /srv/development/espressobin-ultra/armbian-build/build/output/images/Armbian-unofficial_26.05.0-trunk_Espressobin_trixie_edge_6.18.21.img: false 16:55:21 ● operations: Starting flash: /srv/development/espressobin-ultra/armbian-build/build/output/images/Armbian-unofficial_26.05.0-trunk_Espressobin_trixie_edge_6.18.21.img -> /dev/sdb (verify: true) 16:55:21 ● flash::linux::writer: Starting flash: /srv/development/espressobin-ultra/armbian-build/build/output/images/Armbian-unofficial_26.05.0-trunk_Espressobin_trixie_edge_6.18.21.img -> /dev/sdb 16:55:21 ● flash::linux::writer: Image size: 2252341248 bytes (2.10 GB) 16:55:21 ● flash::linux::writer: Unmounting device partitions... 16:55:21 ● flash::linux::writer: Writing image... 16:55:27 ● flash::linux::writer: Write complete: 2148.0 MB in 5.4s (avg 398.9 MB/s) 16:55:27 ● flash::linux::writer: Starting verification... 16:55:27 ● flash::verify: Starting verification of 2252341248 bytes (2.10 GB) 16:55:32 ● flash::verify: Verify complete: 2148.0 MB in 4.9s (avg 441.9 MB/s) 16:55:32 ● flash::linux::writer: Flash complete! 16:55:32 ● operations: Flash completed successfully 16:55:32 ● custom_image: Deleting decompressed custom image: /srv/development/espressobin-ultra/armbian-build/build/output/images/Armbian-unofficial_26.05.0-trunk_Espressobin_trixie_edge_6.18.21.img 16:55:32 ● custom_image: Attempted to delete file outside custom-decompress cache: /srv/development/espressobin-ultra/armbian-build/build/output/images/Armbian-unofficial_26.05.0-trunk_Espressobin_trixie_edge_6.18.21.img $ sudo mount /dev/sdb1 /mnt/ $> ls -ltr /mnt/boot/vmlinux-6.18.21-edge-mvebu64 -rw-r--r-- 1 root root 36108800 Apr 3 18:36 /mnt/boot/vmlinux-6.18.21-edge-mvebu64 When booting: [ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034] [ 0.000000] Linux version 6.18.21-edge-mvebu64 (build@armbian) (aarch64-linux-gnu-gcc (Debian 14.2.0-19) 14.2.0, GNU ld (GNU Binutils for Debian) 2.44) #1 SMP PREEMPT Thu Apr 2 07:23:33 EDT 2026 [ 0.000000] KASLR enabled -
If you want snapshots, you can also do it on filesystem level. Look at Btrfs and snapper. While testing HA 2 years ago, I also took the Intel VM image and made it work in a libvirt VM on an Atom J1900 board. Default size was 32G I think, way too big IMO. So I also took a clone of an existing Debian aarch64 VM (runs on RK3588 or BCM2711) and installed HA in there with supervisor method. I use Btrfs as filesystem, so do not take snapshot of VM image, but just Btrfs snapshot of the rootfs in that VM with HA. Also use Zstd compression, so much smaller than that 32G. But as a matter of fact, HA has good internal backup-restore, so that is also very useful, especially moving between Intel HA en Arm HA.
-
Dear eselarm, thank you for clarification! Really sad that there's no proper arm support yet. VM is really handy using snapshots.
-
Hardware video acceleration with recent armbian/mainline kernel (Kodi)
Joe K replied to XXXBold's topic in Orange Pi 5
Hello, I made a buld with the vendor kernel for mekotronics R58SV2, and build ubutu desktop Gnome. I definately have no HW decoding since with fhd .mp4 h264 videos the beast runs on 100% cpu all cores what did I wrong? Help appreciated -
After installing the latest update, my 3D printer warns about outdated instructions in the MCU and asks to recompile and flash it. What should I do?
-
networking in bpi-m5 with new 26.03.1 release.
bedna replied to gene1934's topic in Software, Applications, Userspace
It's most likely a local ipv6 op is talking about, not a public. ipv6 in range fe80::/10 is local only. To remove ipv6 in that regard, ipv6 has to be disabled on the device or it will get an address like that. And according to what is provided: 2: end0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 link/ether be:63:9c:35:dd:4f brd ff:ff:ff:ff:ff:ff inet 192.168.71.2/24 brd 192.168.71.255 scope global noprefixroute end0 valid_lft forever preferred_lft forever inet6 fe80::bc63:9cff:fe35:dd4f/64 scope link valid_lft forever preferred_lft forever Today I learned a bit more about systemd-resolved, seems 127.0.0.53 IS the correct config for systemd-resolved: https://unix.stackexchange.com/questions/612416/why-does-etc-resolv-conf-point-at-127-0-0-53 And: If dhcp server is configured correctly, nothing has to be done on the devices (except resolving domains to local ip unless that is done on the LAN by dnsmasq) -
This does not support f2fs I guess; standard in U-Boot is only FAT and Ext4 Some never U-Boot builds also include Btrfs. f2fs I have not seens working, but you will need to build a custom u-boot yourself then. Other option is at add Armbian argument to use an extra bootfs, tha will then be FAT or Ext4, so you can still use f2fs for rootfs. I would make U-Boot understand Btrfs and then use Btrfs for rootfs, as for several boards/platforms that is already default (likely only when you use newer/edge/mainline U-Boot).
-
Providing logs with armbianmonitor -u helps with troubleshooting and significantly raises chances that issue gets addressed.
-
networking in bpi-m5 with new 26.03.1 release.
eselarm replied to gene1934's topic in Software, Applications, Userspace
My ISP offers no IPv6, so I usually set IPv6 configuration on disable or ignore. You still might see a link-local IPv6 address (starting with fe80), but that should not matter. I don't know why you can't simply type an IPv4 address in the various fields of nmtui. I have no issues with that. The risks is that you have various other random issues; If you try to do an fsck of /dev/sdc1 and it fails, that is a sign on the wall. It usually is something with SD-card, it might be counterfeit or your SD-card adapter has issues. -
@Werner I imagine there are plenty of people here who could help solve similar problems. In theory, I could provide a pair of an old RPI (master) and a 4A (slave), with the slave serial connected to the master and power controlled via the GPIO, and they are also on the same VLAN. However, if something goes wrong it needs control to the slave's SD card, all I've found is an SD card extender, and it needs something like an emulator that connects to the master via the same USB/SPI.
-
Error at the end of image generation.
Werner replied to Guilherme's topic in UEFI x86 / qemu x86 / arm64
First: https://forum.armbian.com/terms Second: Provide full logs -
Industrial android board - RK3288 (possible EVB)
Mauricio Scotton replied to Mauricio Scotton's topic in Rockchip
Hey tparys! Thank you very much for your reply and apologies for my delay getting back to you. I haven't had much time to play with this board, but lately I've managed to do some very good progress. Basically I've got Armbian 20 Bullseye working with kernel 6.19. that was a victory! Versions that work/don't: [WORKS] Armbian_20.07_Arm-32_bullseye_current_5.7.7_desktop.img (From a MiQi board) [NOPE] Armbian_25.11.1_Tinkerboard_bookworm_current_6.12.58-homeassistant.img [NOPE] Armbian_25.11.1_Tinkerboard_noble_current_6.12.58_minimal.img [NOPE] Armbian_25.11.1_Tinkerboard_trixie_current_6.12.58_minimal.img [NOPE] Armbian_26.2.0-trunk.370_Tinkerboard_noble_current_6.18.8_xfce_desktop.img [NOPE] Armbian_26.2.1_Tinkerboard_trixie_current_6.18.8_minimal.img Armbians 25 up, some times hangs at Starting Kernel, and majority of the times stops at Loading Ramdisk, all of them tested with most of the DTBs provided The android that runs on the other working board has a kernel with version 4.4 Havent test that because I believe it stops earlier than that I have extracted the DTB from the working Android and got a frankenstein EVB DTS working with some of the features. So far I've got working: *4Cores *2GB Ram *Wifi (using rtw8723d_fw.bin ) *Status LED What doesn't work for sure: -Ethernet -FE2.1 USB Hub 2.0 Untested: ? LVDS 1/2 Panel ? EDP 1/2 Panel ? Speaker ? MIC ? SIM Card Module (Attached to the FE2.1 Hub, so defo not working) And maybe some other peripherals that I was not able to test. I'm still to make the FE2.1 USB Hub work as the 4 only USB physical ports are not working. Also ETH has an issue on stmmac that returns the reset value. and this was merged recently to the kernel. (I'm trying to build v6.19 from source with my patch, but thats being painful too ) Here is my stmmac patch: diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c index 01ede5148163..9f0ee9ea96fa --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c @@ -3208,8 +3208,7 @@ static int stmmac_init_dma_engine(struct stmmac_priv *priv) ret = stmmac_reset(priv); if (ret) { - netdev_err(priv->dev, "Failed to reset the dma\n"); - return ret; + netdev_warn(priv->dev, "Failed to reset the dma, device will work with reduced throughput\n"); } I have also attached my current DTS built on top of the EVB version based on the Android with logs from both. Once again, thank you very much for your help! Best Regards, Mauricio. Armbian 20 Bullseye booting log.txt Android Boot Full log.txt android_check.dts rk3288-evb-rk808-armbian-fixed36.dts - Last week
-
Trying to boot Armbian on LinknLink iSG Box SE
Sancho replied to Sancho's topic in Rockchip CPU Boxes
Finally managed to restore the box to stock official Android firmware, everything works as expected. I also tested a firmware for the H96 Max M1, with this one the WiFi is not working, they seem to use a different wifi chip. Any recommendations on where to start with flashing Armbian on this device?
