many: copy boot files from build

[supakeen]

In my quest to get things working on systems that don't behave quite the same as other systems I've addressed a concern that was previously raised (turning boot_files into a struct instead of a [2]string).

I've then gone and added a property to that struct that allows for the file to be copied from the build pipeline instead of from whatever the root filesystem is.

This is useful in a few ways:

1. When you don't want to install the package in the root filesystem because it won't get updated anyhow as it doesn't write to the relevant directory (uboot-images-armv8).
2. When you have a BLS-conforming layout that disagrees with the RPM macros contained in efi-srpm-macros and you want to use files from a package that uses those macros to write directly into %{_esp_root} (which is ... /boot/efi).

See teamsbc/distribution#24 for more details on 2.

The latter comes with the caveat that one won't get updates to those files as the package is never inside the actual booted system. This isn't a particularly big problem since if those packages do get installed they can't write to what they think is the ESP root anyhow; as it's defined as /boot/efi which doesn't exist). However, this is still useful to be able to actually build an image that has the ESP directly at /boot.

Perhaps in a follow-up we can format in the information we have about the partition table so the definitions do not need to contain hard coded paths but could instead refer to {{.ESP}} or {{.XBOOTLDR}} or such. But, that's follow-up material.

[brlane-rht]

Looks good so far, manifest checksums still match :)

[brlane-rht]

I was briefly confused by the change to the call to GenCopyFSTreeOptions until I realized those 2 args aren't used. There's another example of that in the platform.BOOTLOADER_SYSTEMD section, it might be useful to set them to "" there as well just to make it consistent.

[avitova]

So I was trying out the drellabot on this PR, so do not mind it, if it produces something sensible, feel free to use it, just wanted to post this idea here now.

[avitova]

In order to make the serialize() function not huge, could we create a function similar to this

func (p *RawImage) addBootFilesStage(
	pipeline *osbuild.Pipeline,
	bootFiles []platform.BootFile,
	inputName string,
	sourcePipelineName string,
	pt *disk.PartitionTable,
) error {
	if len(bootFiles) == 0 {
		return nil
	}

	bootCopyInputs := osbuild.NewPipelineTreeInputs(inputName, sourcePipelineName)
	stage, err := bootFilesCopyStage(bootFiles, bootCopyInputs, inputName, p.Filename(), pt)
	if err != nil {
		return err
	}

	pipeline.AddStage(stage)
	return nil
}

And then you could call something like

	if err := p.addBootFilesStage(&pipeline, treeBootFiles, "root-tree", p.treePipeline.Name(), pt); err != nil {
		return osbuild.Pipeline{}, err
	}

and later the same for buildTree?

[supakeen]

I had something similar initially but if I recall it doesn't generalize over the setup of filtering and the copy inputs so it doesn't save that much space?

[supakeen]

Yea, looking at the drellabot PR it's +13/-13 and +1/-3 not a huge saving so unless you or someone else insists that it makes things more clear I probably won't address this.

[avitova]

Yeah, it was not as much about saving space, but rather about making the code a tiny bit more readable. I don't quite like what drellabot did anyway. I like those tests that it generated, but I am not sure if we even need such coverage:) So, especially if you are saying that you already tried to implement this before, I am good with the current solution.