Hi Experts,
I have a question: For doing A/B partitions, do I have to combine kernelA.img + rootfsA.img into a single rootfsA, and combine kernelB.img + rootfsB.img into rootfsB? Or can I use separate partitions like kernelA, kernelB, rootfsA, rootfsB and still integrate them into the Mender update mechanism?
Hi @ethan,
Thanks for reaching out! The standard approach is to have the kernel on the matching root filesystem, so thats what the bootloader scripts and update modules expect respectively handle out of the box.
However there’s nothing that keeps you from going a different route via customization. You’ll probably have to adjust the integration for your bootloader so it can handle two distinct partitions for kernel loading and passing as rootfs, and the rootfs-image update module to put the kernel into a different place as the filesystem. Not rocket science, but needs a bit of care.
The one thing which requires consideration is, how do you want kernel/rootfs partitions to be connected in terms of identification? Mender offers “just” A and B, so you need to define a way to derive the other partition. Like, A/B is the kernel partition, and the rootfs partition is +1 one. Example:
mmcblk0p1 = boot
mmcblk0p2 = kernel A
mmcblk0p3 = rootfs A
mmcblk0p4 = kernel B
mmcblk0p5 = rootfs B
mmcblk0p6 = data
The partition generation part of image creation obviously needs to be adjusted accordingly.
Greetz,
Josef
Thanks for clarifying! We are considering the customized approach with separate kernel and rootfs partitions. We will look into adjusting the bootloader integration and update module accordingly.
Do you have any best practices or examples for managing the mapping between kernel A/B and rootfs A/B in this setup?
Hi,
I’m very interested to know if you succeeded and if so, how.
Have a nice day.
Stan
Sorry this fell a bit behind.
Concerning best practices, there are none so far. My personal approach would be to us the kernel A and kernel B partitions as the A and B partitions for the Mender configuration, as thats what the bootloader integration logic already knows about and can handle. It might need a little adjustment to be aware of kernel/fitImage/… loading instead of kernel+dtb+rootfs over cmdline, but certainly it’s not rocket science.
The startup script inside this external startup filesystem then needs a bit of logic to identify the matching rootfs partition, like partition number + 1 or so, and act accordingly.
If you have a proof of concept or early stage implementation somewhere visible, I’m also happy to review, test and possibly help with it.
Greetz,
Josef
I see, thank you for your response. I came across this GitHub repo today, which might be useful. I’m not sure yet how it works, and I’m getting compatibility errors during integration.
Hi @Stan,
Yeah, I know the repository. However I never got it to actually build, so my suggestion is to take it with caution more as inspiration, unfortunately.
Greetz,
Josef