mender-partuuid

[arrow53]

mender-partuuid

[coreycothrum]

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

Random thoughts:

• I don't think mender-partuuid should be an issue, but I'm not sure of the implications. meta-mender-kernel relies on MENDER_STORAGE_DEVICE_BASE for the new/separate kernel partitions, is that variable valid when using UUID?
• briefly looking at grub-mender-grubenv seems like it'd work with uuid and the separate A/B kernel partitions

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

[arrow53]

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]

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]

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 (coreycothrum/meta-mender-kernel#5).

[arrow53]

@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]

@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]

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]

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]

@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]

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]

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]

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

[arrow53]

@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?