CLI: use the path to the target container's root to find ESP and kernel images#27
Merged
Merged
Conversation
travier
approved these changes
Oct 6, 2025
Member
travier
left a comment
travier
left a comment
There was a problem hiding this comment.
Needs a rebase but logic looks good to me. Thanks
shim was being assigned to the grub attribute and viceversa. It worked correctly because the shim function would return the based on the grub path attribute (that is shim) and viceversa. This commit fixes the typos. Signed-off-by: Beñat Gartzia Arruabarrena <bgartzia@redhat.com>
This commit defines a variable with a default value pointing into the path in which the target container image will be mounted. This will allow us to avoid copying and pasting the path around. Signed-off-by: Beñat Gartzia Arruabarrena <bgartzia@redhat.com>
This submodule models where relevant files such as the shim, grub or kernel binaries are, and tries to locate them given the path to the rootfs of the target container image. Signed-off-by: Beñat Gartzia Arruabarrena <bgartzia@redhat.com>
Contributor
Author
|
Hi @travier, I just updated the PR with:
|
Paths to the kernel directory and the ESP (containing both grub and shim binaries) were received as separate arguments. However, this tool is run against a single container image at a time, meaning that we could easily compute the paths to the kernel dir and the ESP dir just by knowing were the rootfs of that container image is. This commit introduces the simple logic that makes that possible, and introduces the new --rootfs argument to the CLI. Note that this commit only changes the CLI, not the library interface. Now, users of the library can use the RootFSTree abstraction added in a previous commit to compute the vmlinuz and esp paths, and then call the predict functions. This is done as it provides greater flexibility for library consumers (in favour of comfort) and changing it to only accepting the rootfs path would have meant a breaking change instead. Signed-off-by: Beñat Gartzia Arruabarrena <bgartzia@redhat.com>
travier
approved these changes
Oct 13, 2025
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This patch series closes #23.
It's depending upon #24 not for a really good reason, but just because I wanted to run CI integration tests on fcos and rhcos against these changes.
This is a breaking change:
lib's compute_pcrs APIIn both of them, drops
--espand--kernelsarguments in favour of the new--rootfsargument without prior notice. I could have put more effort onto making all of them coexist, but I think that relying uniquely on--rootfsmakes it cleaner, and easier to use.