All Activity

Hi, Curious what the result is of "parted u s pr" on the unxz'd image? As for the tools you mentioned, the basics like dd or even unxz'ing directly onto your device are a safe bet. I like to see what's going on and add sauce myself when needed. I'll try myself as well later today. Grt,

Hi there, appreciate you answering! I downloaded via the browser and manually ran xz -d Armbian_24.8.1_Helios64_bookworm_current_6.6.47_minimal.img.xz I then ran the dd command using the resulting .img file. However, diskutil does not show a partition called ambi_root. Relevant part of diskutil list: /dev/disk4 (external, physical): #: TYPE NAME SIZE IDENTIFIER 0: FDisk_partition_scheme *31.3 GB disk4 1: Linux 31.0 GB disk4s1 (free space) 325.1 MB - Not sure if this points to something being out of order. Also, I should mention I tried USBImager but it will not even start as macOS says it is "damaged". The balena Etcher is not recommended according to the Armbian documentation. On that documentation page I saw that they recommend specific microSD cards. Comparing with the ones I bought I think I may need to buy one that is actually recommended. Even if it's not the cause of the issues, I saw somewhere that the wrong SD card can be a headache in the long run. As for the drives, I had a full stack of 5 drives in my main Helios, and 4 non-configured ones in the spare Helios (was just using it as cold storage really). I transported the spare Helios without any drives to my place now and verified that the behavior remains the same. So, in short: same behavior with and empty, full, and 4/5 Helios.

Hi there, Some things you might want to check or confirm: I would expect that your OS would detect a new disk with one partition called armbi_root. Are you confident that you have used the correct image? If you are using wget to download an image from the main site's download area (https://www.armbian.com/helios64/) https://dl.armbian.com/helios64/Bookworm_current_minimal, do note that this will download Bookworm_current_minimal, which is actually an .xz image! You need to rename it to .xz and then unxz it to your SDcard. You cannot just dd that as that won't work. djurny@ekspiees:~/Downloads$ wget https://dl.armbian.com/helios64/Bookworm_current_minimal --2025-06-01 08:12:51-- https://dl.armbian.com/helios64/Bookworm_current_minimal Resolving dl.armbian.com (dl.armbian.com)... 152.53.81.238 Connecting to dl.armbian.com (dl.armbian.com)|152.53.81.238|:443... connected. HTTP request sent, awaiting response... 302 Found Location: https://armbian.chi.auroradev.org/dl/helios64/archive/Armbian_24.11.1_Helios64_bookworm_current_6.6.62_minimal.img.xz [following] --2025-06-01 08:12:52-- https://armbian.chi.auroradev.org/dl/helios64/archive/Armbian_24.11.1_Helios64_bookworm_current_6.6.62_minimal.img.xz Resolving armbian.chi.auroradev.org (armbian.chi.auroradev.org)... 23.186.112.5, 2602:fc41::5 Connecting to armbian.chi.auroradev.org (armbian.chi.auroradev.org)|23.186.112.5|:443... connected. HTTP request sent, awaiting response... 200 OK Length: 251530384 (240M) [application/x-xz] Saving to: 'Bookworm_current_minimal' Bookworm_current_minimal 100%[==========================================================================>] 239.88M 24.2MB/s in 10s 2025-06-01 08:13:02 (23.6 MB/s) - 'Bookworm_current_minimal' saved [251530384/251530384] djurny@ekspiees:~/Downloads$ ls -l Bookworm_current_minimal -rw-rw-r-- 1 djurny djurny 251530384 Nov 24 2024 Bookworm_current_minimal djurny@ekspiees:~/Downloads$ file Bookworm_current_minimal Bookworm_current_minimal: XZ compressed data, checksum CRC64 djurny@ekspiees:~/Downloads$ Are you running any disks in your Helios64? When I was testing/playing around with my Helios64 and rebooting a lot, I decided to take out some disks to prevent them from being stopped/started all the time. This led to random stalls in the OS reaching console login. After reinserting all disks this went away. Also, just to be clear where I'm coming from: I'm also still running Buster (5.9.13-rockchip64 #trunk.16) on my Helios64. Did not yet spend any time to go for Bookworm fully. Groetjes,

my current timezone is PST (suppose to be PH starndard time) configured via raspi-config, im guessing it is confusing itself with PST (Pacific standard time US). it really messing with my TZ. For my part the only workaround is to set it manually before i can upgrade the system $ TZ=':UTC'; export TZ

Quick preface: I'm a noob in many ways, though I'm trying to learn. I may make obvious mistakes and may need clearer instructions than most. Would really appreciate someone working with me here! So I realized earlier this year that I was still on Buster and that there were two newer OSs that I could upgrade to. I upgraded to Bullseye with support from ChatGPT which worked nicely. The upgrade to Bookworm hosed my system and it now fails to reboot. System Info (prior to failure): - Helios64 board - Armbian with OMV - Originally running Buster, then upgraded in sequence: first to Bullseye (worked fine), then to Bookworm - System was always booted from an SD card, not eMMC - Upgrade was done via `apt` commands, no manual flashing of U-Boot Current Symptoms: - After Bookworm upgrade, the system fails to boot. - Via USB-C serial connection (using `screen`), I get mostly garbled output like: �`���x�f������������f�������f��~�怘����怘� Or: ZZ���B>��^�������������N��f�&F�goFFWFWGGG�oo{{q�{{{{z{{����_G_�#g�_WN�o.���wgG�WwwwWw�NWN�W�_ow_fW�Wo�v�oNogoWffOgFGFONNfFOW^Wf_G�~gg� - Occasionally, I saw more verbose output including: SetTTY (fd 5): ioctl failed: Invalid argument Sorry, could not find a PTY - No SSH access; connection refused (network stack never comes up). - The fans spin up for a few seconds and the Ethernet LED blinks briefly, then stalls. What I've Tried: - Reflashed several SD cards (Verbatim Premium and Sandisk Extreme Pro) with the latest Armbian Bookworm images (Minimal, OMV, and Noble). - I still have my old SD card that was Buster and got upgraded to Bullseye and then Bookworm, also made a backup image of it. - Repeated all tests on my second, so-far unused Helios64 — same symptoms. - Changed power cables and tried both UPS and direct plugging to wall socket. - Verified serial setup with `screen /dev/tty.usbserial 1500000`. SD Card Behavior: - After flashing via `dd`, macOS warns “Cannot initialize disk” — I believe this is expected. - On insertion and power-up: usually fans spin and LEDs blink, but no consistent or successful boot. Desired Outcome: - I'd like to use Bookworm on Helios 64. If not possible, then I'd like to use Bullseye I guess, but I wasn't able to find an image online. Only Bookworm, Jammy, and Noble. - I'm aware of firmware and DTB tweaks recommended on here to make Bookworm stable — but I can’t try these yet because I never reach a usable system. Questions: 1. Is there any place where I can download an official or community-maintained Bullseye image for Helios64? Should I even try to use Bullseye? 2. Is the serial output I’m seeing a sign of a bootloader issue (U-Boot or DDR init)? 3. Can the Bookworm image be made to boot reliably with certain tweaks *before* boot (e.g. editing partitions manually)? ChatGPT suggested to boot the system without eMMC and this is certainly territory where I don't trust AI anymore. I think I need to try fixing the server with help from you and understanding the process myself. Since my main Helios64 is offsite, I took my second Helios64 home with me until I figure out what the issue is and I'm able to boot it up and get it running. Then I'll hopefully be able to fix my offsite machine during one of my visits there. I should also say that it would occasionally get "stuck" on a reboot attempt and I needed to physically turn it off and an again to boot successfully. This never happened twice in a row, i.e. the manual reboot always fixed it. Regular reboots worked with roughly a 80-90% success rate but it didn't have to reboot very often at all. Still, this makes me believe that maaaybe there is some hardware issue present. Then again, the second Helios experiencing the same issues makes this more unlikely I suppose.

CRDA is deprecated, not needed since Linux 4.15, hence the package removed with Debian Bookworm. Problem is the default regulatory database on Debian works with Debian kernel only, not with Armbian kernel. But wireless-regdb provides the upstream database as well, so you only need to switch: sudo update-alternatives --set regulatory.db /lib/firmware/regulatory.db-upstream

You could try to create chromium.conf yourself. Here's what I have here: cat /etc/armbian/chromium.conf # Default settings for chromium-browser. This file is sourced by /bin/sh from # /usr/bin/chromium-browser # Options to pass to chromium-browser CHROMIUM_FLAGS="--disable-smooth-scrolling \ --disable-low-res-tiling \ --enable-low-end-device-mode \ --num-raster-threads=$(grep -c processor /proc/cpuinfo) \ --profiler-timing=0 \ --disable-composited-antialiasing \ --disk-cache-dir=/tmp/${USER}-cache \ --disk-cache-size=$(findmnt --target /tmp -n -o AVAIL -b | awk '{printf ("%0.0f",$1*0.3); }') \ --no-sandbox \ --test-type"

Armbian already is! uname -a Linux orangepi5-plus 6.15.0-edge-rockchip64 #1 SMP PREEMPT Sun May 25 23:09:23 UTC 2025 aarch64 GNU/Linux Itś on edge, but it's working fine here, apart from the analog audio...

Its 64bit, but support quality (tl;dr;) of Allwinner is behind Rockchip.

Created another standalone version of script for this ... https://gist.github.com/avatar21/e0deca347665bd620d0ea3f9f299028e I believe we need to compile our own armbian/ Kernel 6.13 (or above? because as @elvis claimed user driver is only 1/2 of the equation) before running this script ya? all copy/ flatten to a temp/fake root folder (where I understand the chroot sdcard means, build to a fakeroot not patching existing OS) and repackage as an img file ya? Or better still, can someone compile the whole thing? start from burning image ...

That RK356x would not be much faster than the H618 I think and "sunxi kernel" is 32-bit, I assume you use and mean 64-bit. DKMS always needs attention (in my experience), so I am happy I made/have my computers/boards such that I do not need it. actually, this topic made me do: apt purge dkms -y, as last week dist-upgrade from Bookworm to Trixie/Testing also had some issue (only a warning, not fatal) regarding DKMS. In the past I used it for some SDR hardware module, but for WiFi USB dongles I simply have a red line: If no mainline kernel integrated code, I do not use is. Also what Igor points to, that stick you have is just very low wireless performance. Use RJ45 or buy good WiFi module I would say. zfs-dkms has no hardware/vendor origin, so that is less of a problem, but note that for cheap low end SBC hardware, Btrfs also works fine and is in the Linux kernel so no special care needed. Also works fine on old ARMv6 Raspberry Pi0/1 including Zstd on-the-fly compression etc. You could create an 2-parttiton image (and U-Boot blob will be between partition table and 1st partition). Use Btrfs as rootfs and also install vanilla Debian kernel and GRUB EFI. Tag 1st as 0xEF00 (ESP) type. Then that image can run as Virtual Machine (hardware accelerated) on all ARM64 SoCs and also emulated on fast x86-64 PCs. Run armbian build inside that VM. I did that for 32-bit Allwinner as I have NanoPi-NEOs, don't have 64-bit Allwinner SoCs. So then easier experiementing and developing and you also have kernel log via virtual tty. Still make sure you have real serial cable/console for that H618.

Thanks for your help, and I found the official image not support NPU, only Joshua-Riek image support? @Hqnicolas root@h96-tvbox-3566:~# ls /dev/dri/ by-path card0 card1 renderD128

During the first few boots on my Orange Pi Zero 3 1GB, RAM size seemed to be detected correctly. Yesterday I saw RAM size being reported as 2GB, also after a reboot. As soon as the fixed U-Boot is available to install I am happy to provide test results or other test procedures when needed!

Glade to see you back @sicxnull. Thanks for the shoutout! Tried my best while you were gone. I don’t own one of these boxes. But I guess it doesn’t matter which one I get because theirs so many variations of the same box.

@Igor I have been using uboot V2025.04(2025-snuxi) on orangepi zero2w since 19 April and everything is works as it should no problems. https://github.com/ZjemCiKolege/build/commit/b3eaeb7d2059c3429951da7e6022c9528237c0e7

And I have ruled out that this is Armbian OS problem.

I try your prebuild image, and no luck with wifi/Bluetooth. My tv box new revision and have YC8800D wifi chip. Can i do something to get work WiFi?

Thanks for this!

Just checked in and am surprised this thread has gotten so much attention. Glad people have been able to use and modify the image as needed. Huge shoutout to @Nick A for all the support he's giving in here

Rockchip devices generally cannot be bricked. Short the maskrom pin i showed you and reflash. You can build the image from source or from here https://github.com/armbian/community/releases

I have T95Z Plus w/ H618 and my TV box new revision. It has another wifi chip YC8800D. tried to run this build https://github.com/LYU4662/t95zplus-h618-build It work fine but no wifi and Bluetooth. Looks like it made already with 8800 driver, but system does recognize any wireless interfaces. Also try to run community build Armbian-unofficial_25.05.0-trunk_Vontar-h618_bookworm_edge_6.12.11_server Its running good, but still no wifi and Bluetooth. In android /vendor/lib/modules found attached modules. Can i use them to get work wifi? aic8800_bsp.ko aic8800_btlpm.ko aic8800_fdrv.ko

Try looking for hints here: https://jellyfin.org/docs/general/post-install/transcoding/hardware-acceleration/rockchip/ They use mali blobs for hw en-/decoding.

Hi, I was not expecting someone to debug some old experimental kernel just for me. I've trying to report bug, give back something to the community. It is not build problem, so Github says use forums for that. I've spent more than a week to have latest and greatest experimental kernel (6.14.5, 6.14.8) or not so experimental (6.12.9, 6.12.23, 6.12.30) with DKMS. Did many rebuilds, reinstalls and reflashes. I was using INSTALL_HEADERS=yes in CLI args or config. DKMS drivers (zfs and aic8800) does not work. I am suspecting that problem is in sunxi headers like reported month ago in github issue. There, the same DKMS driver works on same version on the kernel on RaspiOS where it was working. When that person tried to do it on Armbian it doesn't work. If I was skillful enough I would try to fix it by myself, but I am not. Therefore I am reporting this bug here.

30-40% of GH runners we use are on arm64 platform. Compilation work in all combinations. Yes. This was lying around. Allwinner should work the same, but *edge kernels are experimental, adjust expectations. You have all tools you need, but nobody will be debugging some old experimental kernel just for you. Hint: when you generate image from sources, enable kernel headers install (i think parameter is INSTALL_HEADER=yes), so you have the one that are matching your kernel. In repository, they are probably different / not compatible. I checked if it works for latest stable (the only target that is worth spending time) kernel on supported hardware (that was around my desk). Unsupported hardware running unsupported kernel - it is expected that things will be failing.

If I understood correctly, Github job is running on amd64 platform, your test is on rockchip kernel. I am talking about sunxi kernel. Latest sunxi kernel where zfs-dkms worked (on Allwinner H618) was 6.11.2-edge. My RK356x board is on the way, but it would be nice to make this small LonganPi-3H with H618 usable