On a linux system with unencrypted root filesystem, the kernel and device tree images can often simply be included in and booted from the “/boot” directory of the root filesystem. Mender supports this type of system very well, because the entire Linux system (kernel, device-tree, and root filesystem) are all contained in a single image.
Our boot scenario requires that the kernel and device-tree images be separate from the root filesystem, because the kernel itself (via the initramfs) mounts the encrypted filesystem, so it’s impossible to access the “/boot” directory of the root filesystem without running the kernel first. This means that Mender doesn’t just automatically upgrade the kernel/dt by virtue of their being included within the root filesystem.
At first, I thought that this problem could be addressed by simply adding an “ArtifactInstall_Leave” state script that additionally mounted the newly OTAed root filesystem and copying the kernel/dt from it’s “/boot” directory into our boot partition. The problem with that, however, is that our system intentionally does not provide the facilities to mount the newly installed encrypted filesystem from within the running firmware image (mounting the encryted filesystem can only be done from within the initramfs for security reasons).
Failing the first strategy, my next thought was that there should be a way to include both the encrypted root filesystem AND the unencrypted kernel/dts images in the same .mender image. My understanding after more careful reading the documentation however, is that Mender doesn’t actually allow one to simply add extra files into a standard rootfs upgrade image. It looks like it would allow me to define my own “Update Module” type, whose payload could just be a tar file containing the encrypted rootfs, unencrypted kernel, and unencrypted dtb. The problem I see with this approch is that it appears that I’d be completely on my own in terms of implementing the entire mender install procedure for this new payload type. I expect to have to implement the kernel/dtb part of the install, because that’s custom functionality, but it would be much better to be able to re-use Mender’s implemenation of the rootfs install/rollback.
Is there a way to implement the “Update Module” strategy described in the previous paragraph while still leveraging Mender’s built in support for dual rootfs updates? Is there a completely different strategy that I should be considering instead?
