You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently admins install RPMs (but yum plugin has been prototyped). These RPMs include a kernel module that is loaded; the data is dropped in /var/lib/kpatch (SCAP knows to scan there).
The RPM also regenerates the initramfs to ensure that the kpatch is also applied on the next boot (but that's optional).
I think the most important thing to happen here is to figure out the desired administrator UX, as well as what the update provider supports. There are a lot of fundamental questions.
The RPM-delivery model has kpatches as distinct stream of RPMs (yum repository). Perhaps the simplest start is to just match the kpatch-rpm experience via something like:
$ rpm-ostree install -A "kpatch-patch = $(uname -r)"
(This also heavily intersects with #2883 in that we can make it literally the same command)
There's a bunch of other tweaks to do; ideally rpm-ostree status shows you the kpatches that are applied)
The text was updated successfully, but these errors were encountered:
As of recently, rpm-ostree supports live updates ( #639 ) particularly for "pure package additions".
kpatch is logically a pure package addition.
RHEL spends a lot of effort on generating kpatches, and we should support their use on rpm-ostree systems too.
Currently admins install RPMs (but yum plugin has been prototyped). These RPMs include a kernel module that is loaded; the data is dropped in
/var/lib/kpatch
(SCAP knows to scan there).The RPM also regenerates the initramfs to ensure that the kpatch is also applied on the next boot (but that's optional).
I think the most important thing to happen here is to figure out the desired administrator UX, as well as what the update provider supports. There are a lot of fundamental questions.
The RPM-delivery model has kpatches as distinct stream of RPMs (yum repository). Perhaps the simplest start is to just match the kpatch-rpm experience via something like:
(This also heavily intersects with #2883 in that we can make it literally the same command)
There's a bunch of other tweaks to do; ideally
rpm-ostree status
shows you the kpatches that are applied)The text was updated successfully, but these errors were encountered: