| Message ID | 20240114080711.5109-1-jtornosm@redhat.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | [V5,1/2] rpm-pkg: simplify installkernel %post | expand |
On Sun, Jan 14, 2024 at 5:07 PM Jose Ignacio Tornos Martinez <jtornosm@redhat.com> wrote: > > Normally, upper tools and scripts are checking if we want to modify the > running kernel but not always. Check install and remove operation that > affect the running kernel to avoid possible issues. > > Tested with Fedora 38, Fedora 39, RHEL 9, Oracle Linux 9.3, > openSUSE Tumbleweed and openMandrive ROME, using dnf/zypper and rpm tools. > > cc: stable@vger.kernel.org > Signed-off-by: Jose Ignacio Tornos Martinez <jtornosm@redhat.com> > --- > scripts/package/kernel.spec | 10 ++++++++++ > 1 file changed, 10 insertions(+) > > diff --git a/scripts/package/kernel.spec b/scripts/package/kernel.spec > index 74542af8cbfe..216514cbf5f6 100644 > --- a/scripts/package/kernel.spec > +++ b/scripts/package/kernel.spec > @@ -69,6 +69,12 @@ ln -fns /usr/src/kernels/%{KERNELRELEASE} %{buildroot}/lib/modules/%{KERNELRELEA > %clean > rm -rf %{buildroot} > > +%pre > +if [ $(uname -r) == %{KERNELRELEASE} ];then > +echo "same kernel release is running" > /dev/stderr What is the problem with this? > +exit 1 > +fi > + > %post > if [ -x /usr/bin/kernel-install ]; then > /usr/bin/kernel-install add %{KERNELRELEASE} /lib/modules/%{KERNELRELEASE}/vmlinuz > @@ -85,6 +91,10 @@ fi > done > > %preun > +if [ $(uname -r) == %{KERNELRELEASE} ];then > +echo "same kernel release is running" > /dev/stderr > +exit 1 > +fi > if [ -x /sbin/new-kernel-pkg ]; then > new-kernel-pkg --remove %{KERNELRELEASE} --rminitrd --initrdfile=/boot/initramfs-%{KERNELRELEASE}.img > elif [ -x /usr/bin/kernel-install ]; then > -- > 2.43.0 > >
> What is the problem with this?
In my opinion, it is risky to remove the kernel that is running, that is
the reason why I am trying to protect this.
If you try to remove or update (and the running kernel is removed), if the
kernel and modules are already preloaded in memory, it could not happen
anything but some extra action could be necessary or automatically started,
and even the new kernel could not boot.
Fedora and others are taking this into account with upper tools and declare
the running kernel as protected avoinding this action. But others
(i.e. openSUSE Tumbleweed) allow this behavior.
It may only be a safety measure but it can also be beneficial to avoid
problems, just in case.
Besides, in this way, all the tested distributions would have the same
behavior.
If it is ok, I will create a following version patch describing the problem
better and using indentation as you suggested for the other patch.
Thanks
Best regards
José Ignacio
On Thu, Jan 18, 2024 at 11:12 PM Jose Ignacio Tornos Martinez <jtornosm@redhat.com> wrote: > > > What is the problem with this? > In my opinion, it is risky to remove the kernel that is running, that is > the reason why I am trying to protect this. > If you try to remove or update (and the running kernel is removed), if the > kernel and modules are already preloaded in memory, it could not happen > anything but some extra action could be necessary or automatically started, > and even the new kernel could not boot. > Fedora and others are taking this into account with upper tools and declare > the running kernel as protected avoinding this action. But others > (i.e. openSUSE Tumbleweed) allow this behavior. As I replied in 1/2, I see an error like this: vagrant@opensuse-tumbleweed20231218:~> sudo rpm -i kernel-6.7.0_12924_g660a5f4a53e7-4.x86_64.rpm file /lib/modules/6.7.0-12924-g660a5f4a53e7/vmlinuz from install of kernel-6.7.0_12924_g660a5f4a53e7-4.x86_64 conflicts with file from package kernel-6.7.0_12924_g660a5f4a53e7-3.x86_64 You can proceed with 'rpm -i --force', but that is the user's responsibility if something bad happens. > It may only be a safety measure but it can also be beneficial to avoid > problems, just in case. > Besides, in this way, all the tested distributions would have the same > behavior. > > If it is ok, I will create a following version patch describing the problem > better and using indentation as you suggested for the other patch. No, not OK. > > Thanks > > Best regards > José Ignacio > -- Best Regards Masahiro Yamada
> You can proceed with 'rpm -i --force', but > that is the user's responsibility if something bad happens. > No, not OK. Ok, understood and maybe it is interesting for the user. Indeed, zypper tool from openSUSE can be configured to protect the running kernel as dnf. I drop this patch. Thanks Best regards José Ignacio
diff --git a/scripts/package/kernel.spec b/scripts/package/kernel.spec index 74542af8cbfe..216514cbf5f6 100644 --- a/scripts/package/kernel.spec +++ b/scripts/package/kernel.spec @@ -69,6 +69,12 @@ ln -fns /usr/src/kernels/%{KERNELRELEASE} %{buildroot}/lib/modules/%{KERNELRELEA %clean rm -rf %{buildroot} +%pre +if [ $(uname -r) == %{KERNELRELEASE} ];then +echo "same kernel release is running" > /dev/stderr +exit 1 +fi + %post if [ -x /usr/bin/kernel-install ]; then /usr/bin/kernel-install add %{KERNELRELEASE} /lib/modules/%{KERNELRELEASE}/vmlinuz @@ -85,6 +91,10 @@ fi done %preun +if [ $(uname -r) == %{KERNELRELEASE} ];then +echo "same kernel release is running" > /dev/stderr +exit 1 +fi if [ -x /sbin/new-kernel-pkg ]; then new-kernel-pkg --remove %{KERNELRELEASE} --rminitrd --initrdfile=/boot/initramfs-%{KERNELRELEASE}.img elif [ -x /usr/bin/kernel-install ]; then
Normally, upper tools and scripts are checking if we want to modify the running kernel but not always. Check install and remove operation that affect the running kernel to avoid possible issues. Tested with Fedora 38, Fedora 39, RHEL 9, Oracle Linux 9.3, openSUSE Tumbleweed and openMandrive ROME, using dnf/zypper and rpm tools. cc: stable@vger.kernel.org Signed-off-by: Jose Ignacio Tornos Martinez <jtornosm@redhat.com> --- scripts/package/kernel.spec | 10 ++++++++++ 1 file changed, 10 insertions(+)