some nice features and maybe fixes :)

[derlocke-ng]

Hello there,

Your little script works wonderfully!

But I have some things to say: At first, it would be nice to choose the ssh port manually. Yeah, I can change it in the script itself, but it would be nice to choose it in the cli.

the second thing is you don't need any unlocking hook for initramfs, imo it's just unnecessary bloat. you can use the authorized_keys for that, it looks like this: no-port-forwarding,no-agent-forwarding,no-x11-forwarding,command="/bin/cryptroot-unlock" ssh-pub-key

The dropbear options can be hardened too: DROPBEAR_OPTIONS=-p xyz -s -j -k -I 300

another idea was too rebuild the script so it uses the official armbian images of supported devices and creates a new image with luks encryption enabled or directly write it to a sd. I hate the dependence on using the hardware itself. I know there's armbian-build but so far most of the self-built images, even without luks, don't work.

Hope you can implement some of that, I could help if you want.

Kind regards, derlocke

[mmgen]

Thanks for the feedback. The SSH port and dropbear options fixes look good. However, running cryptroot-unlock in .profile was done intentionally to allow the user to drop to a shell if something goes wrong. I think it would be best to leave this as-is, unless there's a security-related reason to change it.

I'm not sure I understood your last point. The script already uses the official Armbian images and writes the modified image directly to the SD or eMMC card.

[derlocke-ng]

Okay, it's a good idea with the possible shell. Didn't think of that :) There shouldn't be any security problems with the hook. At least I don't know any and if only used locally there should be no concerns at all.

For the second part:

  For best results, the host and target hardware should also be identical or
  similar.  Building on a host with more memory than the target, for example,
  may lead to disk unlocking failure on the target.  For most users, who’ll be
  building for the currently-running board, this point is a non-issue.

  1. Place an Armbian boot image file for the target system in the current
     directory.  For best results, the image file should match the Debian
     or Ubuntu release of the host system.

I have built an image/sd card on an orange pi 4 lts directly, because those notes sounds like it's a bad idea to user different hardware. My idea was to use docker or podman for the building process, to be not bound to any hw specs at all (qemu in docker could be used for different archs too). Maybe that could even work without containers. But I have to take a closer look at your script. Just did a brief fly-over.

So far, thanks for your awesome work!

[mmgen]

Oh, now I get it. Interesting idea, but this would take oodles of work, and I'm not sure how useful it would be for users: presumably, if someone wants to build an image for a specific board, that means they already have access to the board. In addition, it would be difficult to precisely emulate the specs of the target hardware using a container or VM, I think.

Thanks for identifying your hardware. Okay to add the Orange Pi 4 Ubuntu image to the supported list then?

[derlocke-ng]

Hello again,

sorry for the delay!

Could be a lot of work, but a fun project too. Emulating every hw aspect is impossible, that's right, but arch and ram size (like stated by you in the docs) can be emulated. When I have more time I'll test this.

I have used the Armbian_23.02.2_Orangepi4-lts_bullseye_current_5.15.93_minimal.img. So far everything works like a charm.