All Activity

TL;DR: fsck /dev/sdb1 Looks like something corrupted the drive filesystem. I was able fsck repair the drive, and re-apply the image via armbian-imager. The fact that armbian-imager 'validated' the flashed contents multiple times is where things went sideways. Once i tried to manually delete the contents of the drive, and that failed, it became apparent that the drive had been corrupted. I'm not sure what the 'validation' that armbian-imager does is, though.

@Ducdanh Nguyen probably a real H313 SOC. You know this! You were on the other thread.

Have you mounted the image to verify that the problem isn't with the image? (You assume that the issue is with imager but you should first verify that the issue isn't with the image that imager is copying to the storage media.

Armbian-imager is just.. not doing anything useful... I manually deleted the 'kernel' on the device... which was really an apt packages list somehow... rebuilt & 'flashed'... 14:03:51 ● custom_image: Board detection completed successfully 14:03:51 ● frontend::app: Detected board from filename: Espressobin (espressobin) 14:03:52 ● board_queries: Device(s) added: ["/dev/sda", "/dev/sdb", "/dev/nvme0n1"] 14:03:55 ● operations: Requesting write authorization for device: /dev/sdb 14:03:55 ● flash::linux::privileges: Authorization will be requested via polkit when accessing: /dev/sdb 14:03:55 ● operations: Authorization granted for /dev/sdb 14:03:55 ● 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 14:03:55 ● 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) 14:03:55 ● 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 14:03:55 ● flash::linux::writer: Image size: 2139095040 bytes (1.99 GB) 14:03:55 ● flash::linux::writer: Unmounting device partitions... 14:03:55 ● flash::linux::writer: Writing image... 14:04:01 ● flash::linux::writer: Write complete: 2040.0 MB in 5.5s (avg 373.2 MB/s) 14:04:01 ● flash::linux::writer: Starting verification... 14:04:01 ● flash::verify: Starting verification of 2139095040 bytes (1.99 GB) 14:04:05 ● flash::verify: Verify complete: 2040.0 MB in 4.6s (avg 441.9 MB/s) 14:04:05 ● flash::linux::writer: Flash complete! 14:04:05 ● operations: Flash completed successfully 14:04:05 ● 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 14:04:05 ● 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 /mnt bin boot/ dev/ etc/ home/ initrd.img initrd.img.old lib lost+found/ media/ mnt/ opt/ proc/ root/ run/ sbin selinux/ srv/ sys/ tmp/ usr/ var/ vmlinuz vmlinuz.old > ls -ltr /mnt/ total 80 drwxr-xr-x 2 root root 4096 Mar 2 16:50 sys/ lrwxrwxrwx 1 root root 8 Mar 2 16:50 sbin -> usr/sbin/ drwxr-xr-x 2 root root 4096 Mar 2 16:50 proc/ lrwxrwxrwx 1 root root 7 Mar 2 16:50 lib -> usr/lib/ drwxr-xr-x 2 root root 4096 Mar 2 16:50 home/ drwxr-xr-x 2 root root 4096 Mar 2 16:50 dev/ lrwxrwxrwx 1 root root 7 Mar 2 16:50 bin -> usr/bin/ drwxr-xr-x 2 root root 4096 Mar 31 22:57 mnt/ drwxr-xr-x 2 root root 4096 Mar 31 22:57 srv/ drwxr-xr-x 2 root root 4096 Mar 31 22:57 opt/ drwxr-xr-x 2 root root 4096 Mar 31 22:57 media/ drwxr-xr-x 11 root root 4096 Mar 31 22:57 usr/ drwxrwxrwt 2 root root 4096 Mar 31 22:57 tmp/ drwxr-xr-x 12 root root 4096 Apr 7 16:47 var/ drwxrwxr-x 2 root root 4096 Apr 7 16:47 selinux/ lrwxrwxrwx 1 root root 33 Apr 7 16:48 vmlinuz.old -> boot/vmlinux-6.18.21-edge-mvebu64 lrwxrwxrwx 1 root root 33 Apr 7 16:48 vmlinuz -> boot/vmlinux-6.18.21-edge-mvebu64 lrwxrwxrwx 1 root root 36 Apr 7 16:48 initrd.img.old -> boot/initrd.img-6.18.21-edge-mvebu64 lrwxrwxrwx 1 root root 36 Apr 7 16:48 initrd.img -> boot/initrd.img-6.18.21-edge-mvebu64 drwx------ 3 root root 4096 Apr 7 16:48 root/ drwx------ 2 root root 16384 Apr 7 16:49 lost+found/ drwxr-xr-x 91 root root 4096 Apr 7 16:49 etc/ drwxr-xr-x 3 root root 4096 Apr 7 16:49 run/ drwxr-xr-x 3 root root 4096 Apr 8 13:35 boot/ > ls -ltr /mnt/boot/ total 59328 -rw-rw-r-- 1 root root 1592 Apr 3 18:14 boot.cmd -rw-r--r-- 1 root root 5318624 Apr 3 18:36 System.map-6.18.21-edge-mvebu64 -rw-r--r-- 1 root root 224205 Apr 3 18:36 config-6.18.21-edge-mvebu64 lrwxrwxrwx 1 root root 28 Apr 7 16:48 Image -> vmlinux-6.18.21-edge-mvebu64 drwxr-xr-x 3 root root 4096 Apr 7 16:48 dtb-6.18.21-edge-mvebu64/ lrwxrwxrwx 1 root root 24 Apr 7 16:48 dtb -> dtb-6.18.21-edge-mvebu64/ -rw-rw-r-- 1 root root 38518 Apr 7 16:48 boot.bmp -rw-rw-r-- 1 root root 95 Apr 7 16:49 armbianEnv.txt -rw-rw-r-- 1 root root 1664 Apr 7 16:49 boot.scr -rw-r--r-- 1 root root 18372350 Apr 7 16:49 initrd.img-6.18.21-edge-mvebu64 -rw-r--r-- 1 root root 18372414 Apr 7 16:49 uInitrd-6.18.21-edge-mvebu64 lrwxrwxrwx 1 root root 28 Apr 7 16:49 uInitrd -> uInitrd-6.18.21-edge-mvebu64 -rw-r--r-- 1 root root 18398788 Apr 7 16:49 espressobin.itb > ls -ltr /srv/development/espressobin-ultra/armbian-build/build/output/images/Armbian-unofficial_26.05.0-trunk_Espressobin_trixie_edge_6.18.21.img -rw-rw-r-- 1 root root 2139095040 Apr 8 14:02 /srv/development/espressobin-ultra/armbian-build/build/output/images/Armbian-unofficial_26.05.0-trunk_Espressobin_trixie_edge_6.18.21.img > > ls -ltr /mnt/boot/Image lrwxrwxrwx 1 root root 28 Apr 7 16:48 /mnt/boot/Image -> vmlinux-6.18.21-edge-mvebu64 > ls -ltr /mnt/boot/vmlinux-6.18.21-edge-mvebu64 ls: cannot access '/mnt/boot/vmlinux-6.18.21-edge-mvebu64': No such file or directory > so... why is armbian-imager not pushing the kernel files from a custom image?

I have a 512 MB RAM, 4GB Toshiba NAND PocketCHIP with a custome u-boot supporting USB Booting and decided to test the latest armbian community image for the PocketCHIP (https://github.com/armbian/community/releases/download/26.2.0-trunk.668/Armbian_community_26.2.0-trunk.668_Pocketchip-sd_trixie_current_6.18.20_minimal.img.xz) Boot seems to start fine with all kernel files load confirmed by u-boot output (vmlinuz, ramdisk dtb, etc) but then it goes mute while starting the kernel @TheSnowfield, you are listed as the pocketchip board maintainer (thanks a lot for your contribution! 🙏), any ideas of what am I missing? Do you have a suggestion for a working build? Thanks! Serial UART output: U-Boot SPL 2016.01-00115-g5f814bb (Dec 09 2016 - 23:00:24) Fuel Gauge: 77% Battery Voltage: 3776mV DRAM: 512 MiB CPU: 1008000000Hz, AXI/AHB/APB: 3/2/2 Trying to boot from NAND U-Boot 2021.10-rc5+ (Oct 21 2021 - 14:43:51 -0500) Allwinner Technology CPU: Allwinner A13 (SUN5I) Model: NextThing C.H.I.P. I2C: ready DRAM: sunxi SPL version mismatch: expected 3, got 1 512 MiB NAND: 4096 MiB Loading Environment from nowhere... OK Setting up a 480x272 lcd console (overscan 0x0) In: serial Out: vidconsole Err: vidconsole sunxi SPL version mismatch: expected 2, got 1 starting USB... Bus usb@1c14000: USB EHCI 1.00 Bus usb@1c14400: USB OHCI 1.0 scanning bus usb@1c14000 for devices... 5 USB Device(s) found scanning bus usb@1c14400 for devices... 1 USB Device(s) found scanning usb for storage devices... 1 Storage Device(s) found Hit any key to stop autoboot: 0 DIP: PocketCHIP (0x1) from Next Thing Co. (0x9d011a) Found 1 extension board(s). Device 0: Vendor: Mass Rev: 1.00 Prod: Storage Device Type: Removable Hard Disk Capacity: 14832.0 MB = 14.4 GB (30375936 x 512) ... is now current device Scanning usb 0:1... Found U-Boot script /boot/boot.scr 5475 bytes read in 4 ms (1.3 MiB/s) ## Executing script at 43100000 U-boot loaded from NAND 154 bytes read in 4 ms (37.1 KiB/s) sun5i-r8-chip.dtb: No match Load fdt: /boot/dtb/sun5i-r8-chip.dtb 14474151 bytes read in 780 ms (17.7 MiB/s) 10539688 bytes read in 557 ms (18 MiB/s) Found mainline kernel configuration 25215 bytes read in 9 ms (2.7 MiB/s) 2146 bytes read in 7 ms (298.8 KiB/s) Applying kernel provided DT fixup script (sun5i-a13-fixup.scr) ## Executing script at 45000000 Kernel image @ 0x42000000 [ 0x000000 - 0xa0d2a8 ] ## Loading init Ramdisk from Legacy Image at 43400000 ... Image Name: uInitrd Image Type: ARM Linux RAMDisk Image (gzip compressed) Data Size: 14474087 Bytes = 13.8 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ## Flattened Device Tree blob at 43000000 Booting using the fdt blob at 0x43000000 Loading Ramdisk to 49232000, end 49fffb67 ... OK Loading Device Tree to 491c3000, end 49231fff ... OK Starting kernel ...

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.

Newbie on Armbian. I have an Allwinner H313 (confirmed) box that I want to to use as a basic Samba server. CPU:Allwinner H313Quad Core ARM Cortex A53 GPU:Mali-G31 OPenGL ES3.2 Memory:2GB Flash:16GB OS:Android 10.0 The actual firmware is a secure image and, no matter what procedure I do, I can't load any other image but the secure one. Debugging shows that 'fastbootd' has the "secure" flag set. My intention is to create a basic secure arm64 Debian image but I am having a hard time in doing so. Any ideas (specific Wiki, procedures) on how to create the secure image or "reset" the "secure" flag will be very appreciated. Thanks in advance.

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.