All Activity

How to get this working on your Raspberry Pi (5) Hello all. Thanks again, @[member="MMGen"], for offering this fantastic tutorial. As mentioned before, it was the foundation for me to encrypt also my Raspi, although the tutorial wasn't intended for that. I hat to make the following adjustments for that. What's the difference? When investigating the Armbian image for Raspi I noticed that it already comes with two partitions: FAT32 for booting ext4 as a root So it already resembles the result that we try to achieve. I assume that this is due to the different booting process of a Raspi compared to other sige-board computers. To get it running we need to make some adjustments. Download the desired image from: https://www.armbian.com/rpi4b/ https://mirrors.dotsrc.org/armbian-dl/rpi4b/archive/ → more images (I only tested my approach with the minimal Trixie image, kernel version 6.12.58, and would be delighted to know if somebody also got it working with other derrivates.) Changes to the original tutorial: Step 6: As the type of the boot partition needs to be FAT32 instead of ext4, in fdisk change the partition type (hit t) to FAT32 (0b or just b in the partition list l). I also adjusted the size of this partition to +1G, just in case, but that shouldn't make a difference. Here's final partition table: Device Boot Start End Sectors Size Id Type /dev/<your-drive>p1 8192 2105343 2097152 1G b W95 FAT32 /dev/<your-drive>p2 2105344 3907029167 3904923824 1.8T 83 Linux I'm using an NVME drive instead of a SD card. I guess that won't make a difference. I always repaced sda with nvme0n1 when I followed the tutorial. Step 7: mkfs -t vfat /dev/<your-drive>p1 // NOT: mkfs.ext4 /dev/<your-drive>p1 // e2label /dev/sda1 CRYPTO_BOOT won't work on FAT32 partitions Step 8: Because there is no label on the FAT32 partition, just link it manually: BOOT_PART=/dev/<your-device>p1 In my image, the resolv.conf was already present and symlinked to /run/systemd/resolve/stub-resolv.conf. I had to rename it to etc/resolv.conf.old and only then did: cat /etc/resolv.conf > etc/resolv.conf Step 9: Now it gets a bit hairy. As already explained, the Armbian Raspi image works a bit differently. It holds the following partitions: P1: is the boot partition. During (or after?) the boot process it will be mounted to P2:/boot/firmware. P2 contains a cmdline.txt (content covered below) which is the config file to make the adjustments from Step 9.1 for the boot partition. P2: is our root partition. P1:/boot does contain an armbianEnv.txt but that is not the config file used during the boot process. Step 9.1: At this point in the tutorial P2 is mounted to root/boot, so you can nano boot/cmdline.txt and change its content to: console=serial0,115200 console=tty1 loglevel=1 root=/dev/mapper/<custom-name-or-rootfs> rootdev=/dev/mapper/<custom-name-or-rootfs> rootfstype=ext4 fsck.repair=yes rootwait logo.nologo cgroup_enable=cpuset cgroup_memory=1 cgroup_enable=memory I was hesitant to make further changes besides the root and rootdev entries or break the line but probably probably that's also feasible. Step 9.2: Skipped. Step 9.7: As the boot partition is FAT32 etc/fstab has to know about it too. Also notice that commit=600 results in a failure to mount it to /boot/firmware (took me days before I could plug a display to my Raspi, read the boot log and figure out that line as the source of failure). Therefore I deleted the commit declaration. /dev/mapper/<custom-name> / ext4 defaults,noatime,nodiratime,commit=600,errors=remount-ro 0 1 UUID=<UUID> /boot/firmware vfat defaults,noatime,nodiratime,errors=remount-ro 0 2 tmpfs /tmp tmpfs defaults,nosuid 0 0 Step 10: Add systemd to the install list in the chroot (thanks to @[member="the-tall-man"] for mentioning). apt --yes install systemd cryptsetup cryptsetup-initramfs dropbear-initramfs In principle that should be it but I always had to make adjustments, after which I had to recreat the initrd. update-initramfs always is suspiciously fast so I just used the approach from this tutorial: KERNEL_VERSION=ls /lib/modules/ echo "CONFIG_RD_ZSTD=y" > /boot/config-$KERNEL_VERSION # to use the right decompression method mkinitramfs -o /boot/initrd.img $KERNEL_VERSION rm /boot/config-$KERNEL_VERSION # remove the config If you want to keep the original initrd.img as a backup you can just copy it before running the above commands but of course it won't be work with our encrypted boot. You can give the .img a different name. Don't forget to change the line initramfs initrd.img followkernel in boot/config.txt accordingly. Don't forget ssh-keygen -A. That's it Please let me know how if it worked for your Raspi. Good luck. @[member="MMGen"]: If you find this sub-tutorial helpful enough, please consider to link it in your original post or feel free to incorporate it. It took me quite some days to figure all the necessary changes out and borow from other sources. Would be nice to spare others and this thread is a top rank in search engines. I also didn't want to use rootfs as my device name – maybe changing that could be a feature for the next version of your script?

Probably you have to read again the installation instructions in the first page, in particular you have to use the multitool

Hi, you need to provide a boot log, maybe something will be noticed. If you boot without wifi and can access a previous boot log when the machine is freezing, put it here.

did you even research what all these switches do? NEWPKG does not even exist, SKIP_EXTERNAL_TOOLCHAINS was removed recently and KERNELBRANCH is ususally a specific tag and EXPERT....well...are you?

Armbian 25.11.2 Noble XFCE (BSP Kernel: 6.1.115) + PanVk - mesa 26.0 (https://launchpad.net/~ernstp/+archive/ubuntu/mesaaco) + Box64 arm64 v0.4.1 2eb2fd9cd (https://ryanfortner.github.io/box64-debs/) + wine-11.0-staging-tkg-ntsync-amd64-wow64 (https://github.com/Kron4ek/Wine-Builds/releases/tag/11.0) + dgVoodoo2 (https://github.com/dege-diosg/dgVoodoo2/releases) + DXVK-stripped v2.4.1 40~60fps@720p (low settings + high texture setting) box64 environment variables: Bioshock

Hey there! @arizonan so.. if your H96 is stock you wont need any of my instructions.. My box got bricked somehow and this was pretty much the "troubleshoot" to get it working again. What you need to do is follow this instructions: HERE

"While it didn't give an solution, " Well actually it gave many solutions, none of which worked! I've learned from this experience never follow an AI bot blindly, without second-guessing it's suggestions; it will lead you down the Garden path till Christmas. Many of its instructions in other aspects of armbian worked first time like a charm whereas this did not. I'll take a break for a week or two and think about it. Thanks for your suggestions......

Do you still have the download link for the ISO file Station M2 Armbian_community_24.11.0-trunk.167_Station-m2_bookworm_current_6.6.52_minimal.img.xz?

You will need to provide a lot more information. What image are you trying to use? What CPU does your box have? There are different generations of this box and from what I can see they all have different cpus.

I am trying to install armbian on my Xiaomi mi tv box 3 I got the image on a flash drive it's a 16 gig USB 3 stick I got the files ready also but I don't know why it freezes when i enter the recovery screen and click on reboot to boatloader so If any on can help me fix this problem or start again that would be really useful thx

Hi, First of all, sorry for lengthy post and that I ask a lot of things at once, I am very new to linux and this would be my first real experience. I am trying to set up home automation and home assistant server. As I am just getting started to learn all the ropes, I thought about what could be used for sečrver and I remembered that I have an old T9 android TV box see the attachement, I read through this thread and tried to follow the instructions throughout the posts. I burned the armbian image to sd card, which insterted into the sd slot on the T9 board, however I am unable to get the board to boot from the sd card. The box boots normally into android, when no SD card is insterted. When the card is inserted, nothing happens and the box does not turn on at all. It may be a big ask, but would someone be able and willing to help me find out the next possible steps? I feel a bit overwhemed as I am not very knowledgable in this field and unsure how to follow the instructions, or better said, I am not sure if I am following the instructions right. Thank you!

If you need an own build for some reason, you should be able to debug it as well. Why does it fail, others cannot know that from that screenshot. Also you yourself cannot. You need serial console etc, look into bootprocess of RPi, examine files and logs. In general it is rather simple compared to other SBC's, but still you need to do that yourself. It also might be an (additional) problem with you Pi or some SD-card adaptor etc/ Why can't you not use the standard available image? You can remove/tweak/add from there as well.

Ubuntu I see. That I do not have running, so cannot speak from experience.

But I already tried that and it didn't work.

Thanks for the feedback. This is welcome 👾 I'm currently fiddling with Wifi for the 6.18 kernel. No good karma: the adapted bcmdhd sdio wifi from the Spacemit kernel 6.6 was removed from 6.18. So I'm using the bcmdhd extension instead, as it's done with OrangePi 5, based on the github/armbian/bcmdhd-dkms repo. That one has ALLWINNER changes under the #ifdef CUSTOMER_HW_RK (probably Rockchip origin). I need to re-add SPACEMIT changes. Also, I need to revert a Wake-on-WLAN change submitted by Spacemit to RFKILL in order to get the necessary Interrupt init called. Bonus: OPi5-edge also uses that extension driver but does not compile b/c a PR for 6.17 on bcmdhd-dkms from October was ignored. Will need time 🤪 LG // Sven-Ola

Hello! I see you installed the 3318 image on the T9 and everything works fine. Congratulations! I'm not a big Linux expert, but I'd like to make a server out of it. I have the same console, but I'm afraid I can't handle it. I couldn't even find the best image for it...could you share your image for it?

Pardon me, something's always missing 😅 cat /etc/os-release PRETTY_NAME="Armbian 25.11.2 noble" NAME="Ubuntu" VERSION_ID="24.04" VERSION="24.04 LTS (Noble Numbat)" VERSION_CODENAME=noble ID=ubuntu ID_LIKE=debian HOME_URL="https://www.armbian.com" SUPPORT_URL="https://forum.armbian.com" BUG_REPORT_URL="https://www.armbian.com/bugs" PRIVACY_POLICY_URL="https://www.armbian.com" UBUNTU_CODENAME=noble LOGO="armbian-logo" ARMBIAN_PRETTY_NAME="Armbian 25.11.2 noble"

If it is so critical, you should have a backup, not only of the files on the RAID array, but also of the root filesystem. Then you can again make a copy of that backed-up rootfs and do a test upgrade with that. You should also mention what OS/distro it is based (Debian or Ubuntu) , see /etc/os-release I guess it is Bookworm. This usr-merge should work OK if you did normal upgrades and even dist-upgrades. I have seen many warnings when doing Bookworm-> Trixie, but all still works well (not on Odroid-HC4, but various other Armbian installations). I do not use DKMS but that can cause some issues as it is not a standard distro kernel but Armbian's instead. So for me it is easy, I purge it. You should know where you need it for, I guess you don't need it as you do at least not run ZFS on the array AFAIK.

Great I thought RiscV was still much slower than ARMs of similar prices.

I am thinking about getting a Nanopi R3S, which could be a better option, for it has a dedicated designed case for it. The CPU on it is the same one, so computation wise should be feasible.

System Overview Hardware: ODROID HC4 OS: Armbian (current version) Kernel: 6.12.44-current-meson64 Use case: Production NAS with critical data Problem Description During apt upgrade, the following critical warnings appear: dpkg: warning: This system uses merged-usr-via-aliased-dirs, going behind dpkg's dpkg: warning: back, breaking its core assumptions. This can cause silent file dpkg: warning: overwrites and disappearances System state analysis reveals: /bin, /sbin, /lib are correct symlinks to /usr/* BUT: Files exist in duplicate (/bin/bash and /usr/bin/bash identical) DKMS cannot build kernel modules (missing headers) systemd cannot set journal flags (symlink to SD card) NAS Configuration (Critical Infrastructure) Storage Setup: RAID1 with mdadm (two HDDs) + LUKS encryption /var/log relocated to SD card Filesystem: /dev/mmcblk0p1: LABEL="armbi_root" TYPE="ext4" /dev/sda: TYPE="crypto_LUKS" /dev/sdb: TYPE="crypto_LUKS" /dev/mapper/sda_luks: TYPE="linux_raid_member" /dev/mapper/sdb_luks: TYPE="linux_raid_member" /dev/md0: TYPE="ext4" Reproduction $ ls -la /bin /sbin /lib lrwxrwxrwx 1 root root 7 Apr 22 2024 /bin -> usr/bin lrwxrwxrwx 1 root root 7 Apr 22 2024 /lib -> usr/lib lrwxrwxrwx 1 root root 8 Apr 22 2024 /sbin -> usr/sbin $ ls -la /usr/bin/bash /bin/bash -rwxr-xr-x 1 root root 1543048 Mar 31 2024 /bin/bash -rwxr-xr-x 1 root root 1543048 Mar 31 2024 /usr/bin/bash # DUPLICATE! Urgent Questions 1. Root Cause Analysis Has anyone experienced this specific issue with Armbian on ODROID HC4? Is this a known upgrade problem with a particular Armbian version? 2. Solution Paths Which approach do you recommend for a production NAS? A) System repair tool (is there an Armbian-specific one?) Manual cleanup - any experiences with this? C) Migration to new image - best method with LUKS+RAID? D) Install kernel headers first despite warnings? 3. Migration Strategy with LUKS How to safely migrate: LUKS configuration (keys, passphrases) mdadm RAID1 setup Samba/NFS shares and ACLs WireGuard configuration Risk Assessment Current risk: Silent data corruption possible Kernel updates may break filesystem modules System might not boot after next reboot Time pressure: NAS must remain available, but security is top priority. System Details # dpkg --version Debian 'dpkg' package management program version 1.22.6 (arm64). # uname -a Linux odroidhc4 6.12.44-current-meson64 #3 SMP PREEMPT Thu Aug 28 14:31:16 UTC 2025 aarch64 aarch64 aarch64 GNU/Linux # cat /etc/armbian-image-release BOARD=odroidhc4 BOARD_NAME="Odroid HC4" VERSION=25.2.1 REVISION=25.2.1 IMAGE_UUID=54c1127b-9e70-4d3f-bedd-3faf1f5e58fa BUILD_REPOSITORY_COMMIT=1f6972065 Request for assistance with: Immediate actions to stabilize the system Proven migration method for Armbian+ODROID+LUKS Experiences with this specific bug

I got surprised by "GPU: Mesa llvmpipe" ... but then I searched, and it means CPU rendering. But still very nice!

What @Werner means by this comment is that you need to update your code to current github code base. You can't use old code to build. The dependencies that get pulled in during the build process change over time. So you always need to be on current (or near current) github source for armbian build to reliably build images.

While it didn't give an solution, 👆 this is a good answer. It matches my concept of what armbian-build does, as I learned it 3 years ago (from reading the documentation and experimentation)

I just thought that a inserting a cpio file would be accepted, just like inserting a c file into the linux source code. I have never done a source file insertion myself, with neither C or cpio file... but I assumed it would work, since it is a common need for linux patches. In this page, they talk about the "--new-file" feature of the diff command https://unix.stackexchange.com/questions/37287/how-to-include-a-new-file-into-a-patch