You are not logged in.
I wanted Devuan to run on an SBC (I have an ARM64 SBC with an RK3566 RockChip SoC) which uses the U-Boot bootloader to boot with LUKS. There are two partitions: boot (ext3) marked as bootable, and cryptroot (LUKSv2).
What I did:
I used file from linux-u-boot-orangepi3b to update bootloader,factory one is from 2017.
I made a Devuan system with the help of debootstrap using the default variant, version ceres, and I added DietPi mirrors (because they have a kernel that fits my board). I installed cryptsetup, the kernel, Wi‑Fi-related packages, added firmware blobs to /lib/firmware, and compiled booster for the initramfs tool.
I wrote boot.cmd and compiled it to boot.scr, and also wrote extlinux.conf (because I had seen one of the Manjaro ARM images boot on my board; it didn't have the syslinux package but also no boot.scr).
The bootloader still doesn't recognize the partition; there was no blinking LED. Debian system from DietPi has no problem booting, I wish DietPi images had a LUKS option.
I also tried converting the fully LUKSv2 partition to LUKSv1 to see if this was a problem, since the first article I saw was https://u-boot.org/blog/unlocking-disks … rint=print ; but I later found https://u-boot.org/blog/unlocking-moder … 2-support/ when digging through their blog, so this was not a problem by itself.
Offline
I have no experience with arm boards, but with x86 I always need to add cryptsetup-initramfs when I install cryptsetup.
Offline
A web search on linux-u-boot-orangepi3b didn't give me any exact match, so I can't verify that it makes the same assumptions about partitioning as you are. If u-boot doesn't find boot.scr it won't boot.
Perhaps it assumes an initial type FAT boot partition, which wouldn't be unusual. That would at least have boot.scr for booting, and usually that will also contain kernel and initrd. Or for example, if your u-boot supports the sysboot command you may use that for an extlinux boot from a differt, type ext partition, which then would contain the extlinux.conf configuration file as well as kernel, FDT and initrd.
(EDIT: added mentioning of FDT = Flat Device Tree, aka DTB = Device Tree Blob)
Ideally you get a serial cable for the box so you can see u-boot logging.
But my suggestion is that you first set up your box with an initial FAT partition for boot.scr, The command to use in boot.cmd would be like this
sysboot mmc 0:2 ext4 0x7ffff000 /boot/extlinux.confwhere mmc is the drive type (for sdcard), 0:2 identifies the boot sdcard, partition 2, ext4 indicates the partition type, and it's then followed by the pathname of the configuration file.
You'll then need to mkimage that into boot.scr.
EDIT: The argument 0x7ffff000 is the load address for the extlinux.conf file, and you must choose a RAM address within your actual RAM. High up in your RAM is good.
The second partition can be a single partition for everything, i.e. boot and root filesystem. Note that I've used ext4 rather than ext3, but that's only because I'm incredibly modern
Though you might have better luck telling sysboot it's an ext2 even if it's an ext4, or perhaps use ext3... whichever.
EDIT: actually, you want rootfs to be encrypted, so then you'll need 3 partitions...
Online
One of the packages that I meant is https://dietpi.com/apt/dists/all/orange … ietpi1.deb (more *.deb files with similar names at the bottom of https://dietpi.com/apt/dists/all/orange … ary-arm64/ ).
I have changed the boot partition's filesystem to ext4 (I am not sure how clear I am coming across, but just to be sure: [MMC] mmcblk0 --> mmcblk0p1 (ext4), mmcblk0p2 (LUKS) with f2fs type underneath).
I do not possess a serial cable at the moment, but I also own an SD card on which I have flashed and succeeded with https://dietpi.com/downloads/images/Die … xie.img.xz and https://github.com/manjaro-arm/opi-3b-images/releases .
Both make the system ext4-based, and it always makes them 'vanilla' without any things like ZFS, LUKS, etc. (that means that there is only one partition that is both boot and root, marked as bootable).
The Manjaro image had only extlinux.conf as its boot option, and the DietPi image had only boot.scr as its boot method. I prefer extlinux; it seems simpler.
Is there anything else I could do?
EDIT:I also see option of doing U-Boot over UEFI...It would make things easier probably(?)
It would be helpfull to get recipe for https://dietpi.com/apt/dists/all/orange … ietpi1.deb , there is also Armbian mirror with this mirror.sjtu.edu.cn/armbian/pool/main/l/linux-u-boot-orangepi3b-edge/
Last edited by thes3pt3mb3r (2026-04-13 19:47:31)
Offline
Ok. DietPi_OrangePi3B-ARMv8-Trixie.img.xz is a good start point, although named badly since it's 7z compression rather than an xz compression.
That disk image file has 2 partitions:
Device Boot Start End Sectors Size Id Type
/dev/loop0p1 * 32768 1875967 1843200 900M 83 Linux
/dev/loop0p2 1875968 1878015 2048 1M c W95 FAT32 (LBA)The disk image file also has a u-boot bootloader in the first sectors, from 16 and up to where the Linux partition starts, plus of course the MBR first section.
So you copy over sectors 16-32767 onto your SD card so as to reuse that boot loader, like
dd if=$IMGFILE skip=16 of=$SDCARD seek=16 count=32752 conv=notruncNext you copy the content of the /boot directory of the Linux partition filesystem into your boot partition at top level, plus set a link /boot -> . so that u-boot can find files with a /boot/ prefix, while you still may mount that partition as /boot in the target filesystem.
Next you need to change the rootdev setting in boot.cmd (and re-wrap it into boot.scr) to be the decrypted filesystem device, something like /dev/crypt_fs perhaps. That device node will be created by initrd in its cryptsetup step.
That decrypted filesystem could well be a Devuan root filesystem. You would add a mounting of the boot partition on /boot to /etc/fstab so it is ready for kernel and/or initrd upgrades.
Note that the Image link and the initrd.img link are used in boot.cmd to be the applicable kernel and initrd to use during boot. Esp. if you want to use a different initrd you need to change that link.
You can change to use sysboot instead of load+load+load+booti and then refer to kernel and inird versions in extlinux.conf, but you will then need to first determine which dtb is in use, and be sure that there is no overlay. Perhaps it's easier to stay with booti while sorting out the decryption.
Online