search

coreycothrum / meta-mender-luks

mender with LUKS encrypted partitions
MIT License
11 stars 5 forks source link

mender-partuuid #9

Closed arrow53 closed 2 years ago

arrow53 commented 2 years ago

@coreycothrum I'm using a compulab board with an imx8mp part. They have a mender configuration that uses mender-partuuid. Integrating your layer I see

ERROR: mender-luks does not currently support mender-partuuid

This is the referenced line

https://github.com/compulab-yokneam/meta-mender-compulab/blob/gatesgarth/templates/local.conf.append#L15

Do you have any thoughts on what I can do to resolve this?

coreycothrum commented 2 years ago

Basically this just wasn't my use-case, and I didn't have time or HW to test with this config.

Random thoughts:

Have you tried removing that check? Not likely it'll work with just that, but it might get most the way there.

arrow53 commented 2 years ago

thanks. I'm not really sure what I'm doing so thought I'd at least run it by you first. I commented the check out and seemed to get past it. Im going to leave this open for a bit.

arrow53 commented 2 years ago

ok made it here 

ERROR: mender-luks-initramfs-1.0-r0 do_rootfs: MENDER_EXTRA_PARTS and DISTRO_FEATURE 'mender-partuuid' are both defined and incompatible
coreycothrum commented 2 years ago

ok made it here

ERROR: mender-luks-initramfs-1.0-r0 do_rootfs: MENDER_EXTRA_PARTS and DISTRO_FEATURE 'mender-partuuid' are both defined and incompatible

That's going to be a tough one to get past. MENDER_EXTRA_PARTS is the hook that meta-mender-kernel uses to create the A/B kernel partitions.

To get around this, you'd need to either

  1. have some other way of creating the kernel partitions. I'm not sure if there is another mechanism in meta-mender, or rewrite/reimplement the partition/image creation mender has
  2. not have dual A/B kernels, and move the kernel into /boot

For the second option, you can try

  1. Override MENDER_EXTRA_PARTS to be empty
  2. Override grub-mender-grubenv_git%.bbappend to set mender_kernela_part and mender_kernelb_part to empty ("") or the /boot part number.
  3. The meta-mender-kernel state scripts are probably invalid in this use case (https://github.com/coreycothrum/meta-mender-kernel/tree/master/recipes-mender/mender-kernel-state-scripts). Might want to override that recipe to not install anything.

Again though, this loses the kernel A/B stuff. Might be OK. You'd need to write a state script or update module to update it (https://github.com/coreycothrum/meta-mender-kernel/issues/5).

arrow53 commented 2 years ago

@coreycothrum thanks a ton for the comments. From doing a bit of research, for my target platforms such as imx8, raspberry pi, etc. it seems the second option is the way to go

https://hub.mender.io/t/updating-raspberry-pi-boot-firmware-files-using-yocto-project-and-mender/1719

let me see if I can remove the /boot dependencies

arrow53 commented 2 years ago

@coreycothrum I'm getting DEV_BASE to be blank despite the variables seemingly being find and I can see the image file exists

https://github.com/coreycothrum/meta-mender-luks/blob/master/classes/mender-luks-part-images.bbclass#L68

I've never used sudo in a bbclass before. Is there anything special I need to do?

coreycothrum commented 2 years ago

I hate that I had to (use sudo), but I couldn't find a way around it.

I typically run my builds inside a docker container under WSL. There was some "special" stuff there, but it might not be directly applicable.

What that class/function does is mount the image as a loopback device, and then encrypt it. So basically you need root access to your machine (host) /dev.

When running in a container, I needed to run as sudo/root, use the --privileged flag, and volume mount /dev into the container. If you running natively, I'm not sure there is anything specially to do to get access to /dev

Are there some (host) dependancies with losetup? Can you try those commands manually/natively to confirm you can mount the image on your system?

arrow53 commented 2 years ago

Yes, I see now in the logs its unhappy about not getting a root password. No passwd for sudo fixes it but your docker container idea is definitely the way to go.

arrow53 commented 2 years ago

@coreycothrum I realize I've now gone pretty far afield from your original project. But, I think I'm close now.

For my raspberry pi I now have a /boot and three encrypted partitions. The /boot directory has a /boot/LUKS folder with three 16.8 MB .luks files.

Sorry i'm so clueless on this but is the general strategy to use the .luks files to decode the partition? Do I need grub for that? Right now I just have uboot and it doesn't seem to be doing that step.

Hit any key to stop autoboot:  0 
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
Found U-Boot script /boot.scr
299 bytes read in 1 ms (292 KiB/s)
## Executing script at 02400000
switch to partitions #0, OK
mmc0 is current device
** Unrecognized filesystem type **
Bad Linux ARM64 Image magic!
SCRIPT FAILED: continuing...
Card did not respond to voltage select!
coreycothrum commented 2 years ago

Those files are the 'detached headers' for the LUKS partition(s).

I have only used it with grub, but I don't think that's a requirement. The decryption happens after grub, when the kernel is booting.

So in my use-case, I have dual A/B kernel partitions. grub will choose which patition/kernel to use based on the mender roots partition, and launch that one.

That stuff is likely different, I'm not sure how uboot is doing it.

But there should be a linux kernel in /boot... and it should be "bundled". Meaning, it is both a kernel and an initramfs. This layer has an init script that runs when the kernel is booted, and that unlocks the roots and data paritions.

What's the contents of boot.scr? What's generating it? I couldn't really tell from my QUICK look through meta-mender. Does it not launch the kernel? It may need to be patched so it does.

Hope that helps!

arrow53 commented 2 years ago

ah, good to know. So, if I can get the kernel to boot then I should be in good shape!

Yes, that is my problem though is uboot will no longer boot the kernel when I use your layer. Image is indeed in the \boot directory along with the .dtb files and boot.scr

boot.scr I think comes from here https://github.com/mendersoftware/meta-mender/blob/dunfell/meta-mender-raspberrypi/recipes-bsp/rpi-u-boot-scr/files/boot.cmd.in

and mine looks like this

'V�R�M�����w�,Boot script�fdt addr ${fdt_addr} && fdt get value bootargs /chosen bootargs
run mender_setup
mmc dev ${mender_uboot_dev}
load ${mender_uboot_root} ${kernel_addr_r} /boot/Image
booti ${kernel_addr_r} - ${fdt_addr}
run mender_try_to_recover

What is super weird though is I can take all the \boot files from a good working image and copy them over to the \boot partition on the image I create when I use your layer and it still doesn't work.

There is a hidden partition at the beginning of the .sdimg file and I'm not sure what is there but maybe it's different.

coreycothrum commented 2 years ago

Can KERNEL_IMAGETYPE be set to bzImage? Is that a grub only thing?

arrow53 commented 2 years ago

@coreycothrum using a compressed image is a good idea but I can't seem to build it with the current kernel recipe.

At any rate, I figured out the problem. meta-mender-raspberrypi is indeed A/B'ing the kernel. uboot is being used for partition selection between 2 or 3

load ${mender_uboot_root} ${kernel_addr_r} /boot/Image

where mender_uboot_root starts off as mmc 0:2.

I had assumed it was /boot which is mmc 0:1 but there's actually a /boot partition in the main rootfs parititon.

So, any thoughts on this? Maybe I should just pull the kernel from the /boot partition and not worry about A/B'ing the kernel.

You are using the kernel to decrypt those partitions so I'm not sure I have an alternative?