-
Notifications
You must be signed in to change notification settings - Fork 197
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
Integrate with kernel-install.d #4726
Comments
In some experimentation, this is getting pretty close:
|
From the Automotive perspective, a lot of the people in the community at the moment are kernel hackers, as there is plenty of hardware enablement to do in ARM in general. |
@cgwalters LGTM, great patch. Just a small suggestion, could you please use a bash constant for the |
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
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
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
xref: CentOS/centos-bootc#377 |
xref: #4950 |
I'm looking at handling kernel overrides: - coreos#4726 - https://gitlab.com/fedora/bootc/tracker/-/issues/22 And I think the cliwrap thing turned out to be the wrong approach for this. There's consensus now it was the wrong approach, so deprecate it. Signed-off-by: Colin Walters <walters@verbum.org>
I'm looking at handling kernel overrides: - coreos#4726 - https://gitlab.com/fedora/bootc/tracker/-/issues/22 And I think the cliwrap thing turned out to be the wrong approach for this. There's consensus now it was the wrong approach, so deprecate it. Signed-off-by: Colin Walters <walters@verbum.org>
Right now our code dealing with the Fedora-derivatives kernel packaging is a mess. I think what would work well is to add
/usr/lib/kernel/05-rpmostree.install
and:Detect if the system is actively (rpm-)ostree based (otherwise we could cause problems if people just happen to have the package installed...I think for now the important case is
/run/ostree-booted
for hosts and detecting our containers); if it's not we just exit 0.Otherwise, looking at all the stuff in
I think except for the crashkernel bits we handle all of that internally and should basically fork off
rpm-ostree kernel-install add
(we have some cliwrap code for this already).A crucial detail here is that the docs say if a script does an
exit 77
then everything else is skipped, which is what we need.If we do that well, I think we might be able drop our logic for "ignore kernel postinsts" which would be really nice...well almost except it seems that the kernel
post
s still directly run dracut...argh. (What is the50-dracut.install
doing then?)However, there's some important bits we should handle in the container case specifically. With this we'd be really close to having
dnf update kernel
work - except we need (well, want) to do cleanup like:/boot
The text was updated successfully, but these errors were encountered: