From the “Well that right thar is your problem…” department.
Here’s a screen shot (cropped) of the gparted display of an Armbian XU4 runnable system and the just re-flashed Devuan 2.0 (doesn’t boot) for the XU4. See the difference?
This is Armbian and it works. In particular, note the first 16 MB ‘grey area’ byes. That’s where Odroid has you put their signed boot loader as a binary blob.
Here’s the Devuan image that doesn’t work:
Where’s the boot loader?
This is the bit that makes the Odroids “different”. That grey blob at the front. Hardkernel have directions on their web site for how to put that there ‘on your own’. It is basically a dd of some block size / count, then you dd the rest onto the image starting after that block.
I already know the Devuan 2.0 userland works on the XU4 as I got it to boot using an entirely different kernel (but blew it on the DTB device tree bundle and it didn’t see my keyboard or mouse). So, OK, now I ‘have clue”.
Their full image is more like The Usual boot on other systems with /boot in a FAT partition and the userland in ext4. Somebody just didn’t make the XU4 image in the “odd Hardkernel way” and did it like everyone else…
So I need to find the directions at Hardkernel and “roll my own” installing the boot loader in the grey bits, making the ext file system where it belongs, and loading the tarball Devuan 2.0 into it. In Theory…
So “some assembly required” but at least now I know what to assemble… and what to leave alone.
I think this is the “recipe”, but I might just try a dd from a working earlier version…
Seems to me that “dd bs=1M count=16 if=/SD/Armbian of=/dev/sdx” ought to work… maybe.
So guess what I’m doing “for a while” ? 9-)
IF I have the time, I might actually figure out how to report this as a bug: