Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

bootc image requirements #869

Open
jmpolom opened this issue Nov 5, 2024 · 7 comments
Open

bootc image requirements #869

jmpolom opened this issue Nov 5, 2024 · 7 comments
Labels
area/client Related to the client/CLI

Comments

@jmpolom
Copy link

jmpolom commented Nov 5, 2024

bootc claims to be able to use an "OCI format" archive/image to deploy a system and lifecycle the thing through its paces. We all know that is glossing over some subtle but super important details concerning exactly how that image is structured and what content it has. This needs to be documented and as far as I can tell it really is not documented at all (current docs do not do this subject justice).

@cgwalters cgwalters added the area/client Related to the client/CLI label Nov 6, 2024
@ryanabx
Copy link

ryanabx commented Nov 7, 2024

This is probably the best page I could find, but it definitely could be improved on:

https://containers.github.io/bootc/bootc-images.html

@jmpolom
Copy link
Author

jmpolom commented Nov 7, 2024

This is probably the best page I could find, but it definitely could be improved on:

https://containers.github.io/bootc/bootc-images.html

Yes, that is what I was referring to. It definitely needs improvement as it leaves out many details. For example, kernel changes are left out entirely it seems.

Most of the post processing seems to originate in the src/libpriv/rpmostree-postprocess.cxx source with some calls to bits in rust. Unfortunately both C++ and rust are rather highly verbose to read so I think it would be a stretch to claim the code is the documentation here. Thus, a request to have the image format requirements for bootc explicitly documented so users can assemble compatible images with tooling/processes of their choice.

@cgwalters
Copy link
Collaborator

Yes, it's in a far from ideal state but we're working on it. A few recent related PRs:

I also moved #887 here which will dramatically reduce the requirements.

@cgwalters
Copy link
Collaborator

Jon most of what is happening in that kernel-related bits is related to the fact that there's some changes we want to make to the dracut invocation and we're basically just regenerating the initramfs and nuking the one from /boot. That bit of tech debt is on track to be significantly diminished with coreos/rpm-ostree#5135 which will also make it much more obvious how to use dnf upgrade kernel etc.

@jmpolom
Copy link
Author

jmpolom commented Nov 8, 2024

Jon most of what is happening in that kernel-related bits is related to the fact that there's some changes we want to make to the dracut invocation and we're basically just regenerating the initramfs and nuking the one from /boot.

I gathered that much. The issue for me is the intended outcome isn't documented so I'm left to just infer intention from source.

That bit of tech debt is on track to be significantly diminished with coreos/rpm-ostree#5135 which will also make it much more obvious how to use dnf upgrade kernel etc.

How will this impact bootc? Is bootc effectively going to be able to handle kernels that are in their normal places? It didn't to me seem like bootc has any special handling for kernels today.

@cgwalters
Copy link
Collaborator

Is bootc effectively going to be able to handle kernels that are in their normal places? It didn't to me seem like bootc has any special handling for kernels today.

Does #889 help on this? "normal" could mean different things to different people but that's the protocol bootc (and ostree) have expected for years.

@septatrix
Copy link

It would be fantastic if it were possible to generate a compatible image using mkosi which is used for building OS images and supports OCI archives as an output format

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/client Related to the client/CLI
Projects
None yet
Development

No branches or pull requests

4 participants