ryanabx
commented
5 days ago This is probably the best page I could find, but it definitely could be improved on:
Open jmpolom opened 1 week ago
ryanabx
commented
5 days ago This is probably the best page I could find, but it definitely could be improved on:
jmpolom
commented
5 days ago This is probably the best page I could find, but it definitely could be improved on:
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
commented
4 days ago Yes, it's in a far from ideal state but we're working on it. A few recent related PRs:
I also moved https://github.com/containers/bootc/pull/887 here which will dramatically reduce the requirements.
cgwalters
commented
4 days ago 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 https://github.com/coreos/rpm-ostree/pull/5135 which will also make it much more obvious how to use dnf upgrade kernel etc.
jmpolom
commented
4 days ago 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 https://github.com/coreos/rpm-ostree/pull/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
commented
4 days ago 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 https://github.com/containers/bootc/pull/889 help on this? "normal" could mean different things to different people but that's the protocol bootc (and ostree) have expected for years.
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).