Support kernels with embedded initramfs (e.g. Flattened uImage Tree)

[d4s]

While working on Apertis OS we faced to following issue on i.mx6-based board:

run-init: can't execute '/ostree/boot.1/apertis/cc7dc86689375ba4f9ea187d75825d3bc3354b920c395a8dbb1b78d0a9015852/0/usr/lib/ostree/ostree-prepare-root': No such file or directory
Target filesystem doesn't have requested /ostree/boot.1/apertis/cc7dc86689375ba4f9ea187d75825d3bc3354b920c395a8dbb1b78d0a9015852/0/usr/lib/ostree/ostree-prepare-root.

Core reason

The reason is in hardcoded addition of /usr/lib/ostree/ostree-prepare-root in src/libostree/ostree-sysroot-deploy.c for deployments which do not include the initramfs file.

But in our case we are using the single FIT (Flattened uImage Tree) bootable image which incorporate kernel+initramfs+DTB into a single binary, so it is treated by libostree as a kernel without initramfs.

Problem

Looking into the future it is not enough just to disable that addition of ostree-prepare-root on library level.
There are several approaches to inline kernel and initramfs into the single bootable image, like FIT above or similar for UEFI.

So need to define the common approach allowing to pass a hint for deploy process on commit level -- which binary type is used rather trying to guess as we have for now. This is also useful for cases when OS is switching from classic kernel+initramfs layout to multiplexed binary or vice versa since the init= parameter from kernel's cmdline should be processed additionally.

From my point of view such information could be the part of commit's metadata.

[d4s]

@cgwalters I'd be appreciate for any advice for this problem.

[ricardosalveti]

At the moment having an initrd file is indeed required, and the workaround done in meta-updater when fitImage is used is just creating an empty initrd file (https://github.com/advancedtelematic/meta-updater/blob/master/recipes-sota/ostree-kernel-initramfs/ostree-kernel-initramfs_0.0.1.bb#L39).

While the workaround works, having a proper fix would indeed be nice.

[cgwalters]

(Sorry I missed this one earlier)

Presumably we can detect these types of "flattened kernels" by sniffing the file type or so? Adding an ELF parser to ostree might be a heavy dependency, but if e.g. file can detect it we can probably carry a small amount of equivalent file type sniffing, then the conditionals in the deploy code can detect the embedded initramfs and skip injecting an init= argument or so.

[d4s]

@cgwalters no, file can't detect that as far as I remember. But the problem is a bit deeper -- for example the FIT image could be signed and/or encrypted for the target device (based on i.MX processors for instance). In this case the format is hard to guess.
That's why I'm asking about the having any hint for the ostree deploy instead of automatic guess.

[cgwalters]

Surely even if encrypted, there's some sort of header that allows identifying the file?

(I didn't know much about this, found https://www.nxp.com/docs/en/supporting-information/DWF13_AMF_IND_T0291.pdf - is there a better reference specifically for i.MX encrypted kernels/u-boot integration?)

I think instead of a deploy flag we'd want this flag to be part of the ostree commit metadata; that way it's clearly a property of the build and not how it's deployed. Something like ostree commit ... --add-metadata=ostree.flattened-kernel=true or so, then the deploy code reads that from the commit metadata?

[cgwalters]

I know there are people that do this "flatten kernel + initramfs + kernel cmdline" to a single UEFI binary that can be signed for a SB system, and we should ideally support that too. (Although, that would bring into scope us instead touching the ESP and not /boot which would be a whole other world)

[d4s]

The format for i.MX is indeed pretty simple to detect. Do not know about other formats which may be vary. But tbh I don't like the idea of automation here without ability to provide additional info for deployment process. By deploy flag I exactly mean the readable metadata from the commit as a hint for the deploy.

Any suggestion for metadata hints?
Is it better to use the exact type (like FIT image) or to indicate what some part exists/absent (like initrd and/or DTB)?

[cgwalters]

Any suggestion for metadata hints?
Is it better to use the exact type (like FIT image) or to indicate what some part exists/absent (like initrd and/or DTB)?

I think in this case all the core ostree cares about is whether there's an initramfs included in the kernel (so we know not to auto-inject the init parameter). I gave the strawman above of ostree commit ... --add-metadata=ostree.flattened-kernel=true but maybe --add-metadata=ostree.embedded-initramfs=true is clearer?

[d4s]

from my perspective the --add-metadata=ostree.embedded-initramfs=true is more preferable tbh.

[dbnicholson]

@starnight @dsd I think we're in the process of moving away from FIT images (or already have), but what do you think about this proposal?

[cgwalters]

from my perspective the --add-metadata=ostree.embedded-initramfs=true is more preferable tbh.

SGTM - if someone is going to work on this please claim the issue!