All Activity

Try sysctl vm.overcommit_memory=1 QEMU is probably trying to commit lots of virtual memory, but not using it. Don't know why it behaves like this.

Our multimedia engineering team delivered major improvements to GStreamer 1.28: hardware acceleration and zero-copy pipelines, HDR and color support for Wayland, AI inference integration, plus critical codec and RTP/WebRTC interoperability fixes. View the full article

OK I see, now I remember, HAOS aarch64 has been there for download for a long time, I even recommended it to some one on another forum who also only saw the Intel VM, but as I indicated, is a bit hidden on github: https://github.com/home-assistant/operating-system/releases/ and direct latest link: https://github.com/home-assistant/operating-system/releases/download/17.2/haos_generic-aarch64-17.2.img.xz I personally don't want the Proxmox stuff indicated by Markus, I just use the standard packages available In Debian (or Opensuse) for years, on both Intel and Arm. Like indicated install virt-manager. It is manual install, but at least then more control. I used/use a mix of LVM based block devices and also just raw images (like unxz the one referenced). I see on RPi4 I have the HAOS VM configured with 2 vCPUs and 1GB RAM. On RK3588, so OPi5+, you will need CPU pinning if you use the vendor kernel (6.1) as it does not support mixing big and little (Cortex-A76 and Cortex-A55). Or use just 1 vCPU for the VM, then de-facto no mixing. Mixing is no problem with mainline based kernel, so then you can just use 8 vCPU's if you want. I currently have my NanoPi-R6C running with kernel 6.19.10+deb14-arm64-16k (from Debian sid) and works fine with VM's and all 8 cores.

Hello @greg396 What exactly are you trying to achieve? I assume you want to run Home Assistant in a virtual machine on ARM64. That's possible, but you need to install some prerequisites. According to your links, you're using an Orange Pi 5 Plus (RAM unknown). It's powerful enough, but I recommend at least 8GB. 🙂 First, install an ARM64 clone of Proxmox Virtual Environment (PXVirt). https://github.com/jiangcuo/pxvirt Then install HA: https://pimox-scripts.com/scripts?id=pimox-haos-vm `bash -c "$(curl -fsSL https://raw.githubusercontent.com/asylumexp/Proxmox/main/vm/pimox-haos-vm.sh)"` Done. If you run it on a home server it's OK! --- I personally use a Raspberry Pi 4 with 8GB of RAM running Armbian (trixie) since 1,5 year with PXVirt. It's running: Home Assistant (ARM64) Pi-hole OMV VM-Trixie Everything performs very well. 😃 Regards, Markus

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.

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.

@Nick A I tried it — I installed everything and created a secure boot image, but it doesn’t even attempt to boot from it. It just goes straight back into Android. Any idea what I might be missing?

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.

/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?

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.

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.

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

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.

I am asking because I can't find a toggle or anything in the settings and find it a tad anoying especally when it is a game I am playing a fast paced game.

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?

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.

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.