Conversation
Until the native kernel-install is OSTree and container aware[[1]], we need to have a custom `kernel-install` for kernel replacements to work in a derived build. This will make it so that users don't have to first install the wrappers themselves in their Containerfiles[[2]]. The caveat with this is that if anywhere in the derivation, systemd is updated, the update will retake ownership of `/usr/bin/kernel-install`, which means that a further kernel replacement down the derivation chain would hit issues. We can document that. This still seems worth the UX improvement in the common case. [1]: coreos/rpm-ostree#4726 [2]: https://github.com/coreos/layering-examples/blob/9329023b/replace-kernel/Containerfile#L4
|
Came out of discussions in coreos/fedora-coreos-config#2887. |
All we really want to cliwrap is `dnf` so that a `dnf install ...` will work. Again, as mentioned in the commit that introduced this, ideally we can actually ship dnf itself once it's ready and then we can back this out. Also wrap `kernel-install` for now to make kernel replacements smoother until we can get it to work seamlessly (this matches [[1]]). [1]: CentOS/centos-bootc#377
|
I think this makes sense, but it would also mean we can't do #314 |
|
But note we basically need this cliwrap today for kernel replacements to work. This PR is just moving it from Containerfile-time to compose-time to make the UX a little less awkward. IOW, if we want kernel replacements to keep working, then we have to gate #314 on coreos/rpm-ostree#4726. |
Well, that's not quite true. You could probably still technically replace the kernel in a base image without rpm-ostree by doing e.g. Though it would leak the wrappers into the image. Anyway, this is all just trying to make the short-term better. Cool to just stick with the status quo until we have the proper fix. Mostly did it to match the proposal in coreos/fedora-coreos-config#2887. |
|
I failed to install a new kernel on bootc image with |
3 participants
Until the native kernel-install is OSTree and container aware[1], we need to have a custom
kernel-installfor kernel replacements to work in a derived build.This will make it so that users don't have to first install the wrappers themselves in their Containerfiles[2].
The caveat with this is that if anywhere in the derivation, systemd is updated, the update will retake ownership of
/usr/bin/kernel-install, which means that a further kernel replacement down the derivation chain would hit issues. We can document that. This still seems worth the UX improvement in the common case.