Write boot partition for aboot images #1801
Conversation
If the target image contains an aboot.img, then we automatically write it to the A slot boot partition. Co-Authored-By: Michael Vogt <[email protected]>
mvo5
requested review from
croissanne,
supakeen and
thozza
and removed request for
a team
| sourcePipeline := "build" | ||
| if t.arch.distro.buildSourceInfo != nil { | ||
| sourcePipeline = "target" | ||
| } |
There was a problem hiding this comment.
Thanks to not being heavily involved in the bib development, I have a hard time figuring out why the sourcePipeline is set to these values. I tried to look into the bootc distro and see what the purpose of buildSourceInfo is, but there is no information available on that.
So, IMHO, this would deserve some comment.
There was a problem hiding this comment.
Yeah, I was actually thinking about this too this morning. This comes straight (and unchanged) from bib but I wonder if its incorrect there actually. We do not have a "target" pipeline iirc, only build/image and the image pipeline will not contain the full bootc filesystem view iirc because we do not mount it by default. Maybe @alexlarsson can have a quick look and comment if/what we are missing.
There was a problem hiding this comment.
Normally, we run the "target" container (i.e. the bootc container you want to deploy in the disk image) as the "build" pipeline, but if your bootc container doesn't have the required tooling (such as the automotive minimal images) then we can use another container as the build pipeline.
However, we then need to copy things like disk customization from another source, not the build container. We do this in BootcDiskImage.InstantiateManifestFromContainers() by creating a new pipeline "target" that just copies the target container image to the tree.
I agree that looking at "buildSourceInfo" for this data is a bit hard to understand. Ideally the code in InstantiateManifestFromContainers should store a "ImageCustomizationPipelineName" variable somewhere we can just use.
|
Note, with #1816 merged, and osbuild/bootc-image-builder#1014 on the way, I think maybe we don't need this change? If we add support in the yaml to set payload: raw with a filename, then at least for automotive, I'm fine with moving to use a yaml disk customization and setting the aboot raw source directly in that. |
|
Closing in favor of the new mechanism via disk.yaml which is more flexible #1816 |
4 participants
[port https://github.com/osbuild/bootc-image-builder/pull/1033 to pkg/distro/bootc - need to unblock https://github.com/osbuild/bootc-image-builder/pull/1014]
If the target image contains an aboot.img, then we automatically write it to the A slot boot partition.