protect_running_kernel should default to false in a container

[jmarrero]

As part of the rpm-ostree and bootc images integration with kernel-install which enables users to use DNF to install, remove and replace kernels on container builds, we found that when the host kernel and the container kernel version matches the transaction gets blocked by protect_running_kernel default of True from removing the current kernel in the container image.

This is problematic on ostree/bootc systems as we can only have one kernel.

For now we have set it to False on our images configs, but this could have unintended consecuenses when someone enables a usroverlay as @cgwalters shared here: https://gitlab.com/fedora/bootc/base-images/-/merge_requests/149#note_2398660893

On that topic...something to bear in mind here is of course changes like this will affect dnf on the client side today too. So presumably this makes it even easier to do bootc usroverlay and accidentally dnf remove kernel or whatever. Which mostly will break dynamically loading modules, so not that big of a deal, and f course the great thing is, that change goes away on reboot.

While this is non-fatal I think the correct approach would be for DNF to be aware if it's running on a ostree/bootc container and if so default protect_running_kernel to False.

c.c. @evan-goode

[ppisar]

Do I understand correctly that you have a system, doesn't matter whether RPM-driven, or OSTree/bootc one. You spawn a container there for building an ostree/bootc container image. And you need DNF to distinguish this situation from running in a non-OSTree/bootc container?

I don't know how DNF could tell the difference. Do you have an idea?

I think DNF could instead default protect_running_kernel to false when running in any container. In a container you basically don't need any kernel, don't you? However, I heard stories when people run DNF in a container because they need a special DNF/RPM version, and point it with --installroot option to operate on a bind-mounted RPM-driven file system. That would probably break their use case.

[cgwalters]

I don't know how DNF could tell the difference. Do you have an idea?

systemd-detect-virt -c (or if systemd isn't present, https://github.com/bootc-dev/bootc/blob/d63c1b1f72df8873acacd1bdf50afed1b563d70c/ostree-ext/src/container_utils.rs#L27 )

In a container you basically don't need any kernel, don't you?

Application containers don't need a kernel package installed at all - but sometimes one gets pulled in as a dependency (typical examples here are building kernel modules, and libguestfs is a big one). bootc containers do need one, but not while it's running as a container - bootc container lint will bail if the system doesn't have a kernel.

However, I heard stories when people run DNF in a container because they need a special DNF/RPM version, and point it with --installroot option to operate on a bind-mounted RPM-driven file system. That would probably break their use case.

I don't think it'd actively break their use case, just remove the protection against removing the running kernel, right? Maybe the best semantic here is to have protect_running_kernel=!container or so as the compiled-in default, and then that use case could explicitly set protect_running_kernel=yes.

(Alternatively of course, with enough work in such a scenario we could also detect when we're operating on the root filesystem visible to the init namespace's pid1...)

[ppisar]

I don't know how DNF could tell the difference. Do you have an idea?

systemd-detect-virt -c (or if systemd isn't present, https://github.com/bootc-dev/bootc/blob/d63c1b1f72df8873acacd1bdf50afed1b563d70c/ostree-ext/src/container_utils.rs#L27 )

That detects whether it is a container. Not that it is a bootc container. But nevertheless, thanks. We will use it.

However, I heard stories when people run DNF in a container because they need a special DNF/RPM version, and point it with --installroot option to operate on a bind-mounted RPM-driven file system. That would probably break their use case.

I don't think it'd actively break their use case, just remove the protection against removing the running kernel, right?

That's exactly the problem ("unintended consequences") the original poster wants to avoid. Not that it breaks a default workflow, but the protective measure has gone.

Should we negate the container relaxation if the --installroot target file system is a bootc system (i.e. has run/ostree-booted)?

Maybe the best semantic here is to have protect_running_kernel=!container or so as the compiled-in default, and then that use case could explicitly set protect_running_kernel=yes.

The only distinction from the current behavior is that now it would be a problem of dnf instead of bootc container image.

I have not a problem changing the default in upstream in and in a next release, advertising it properly as a change in the default behavior. I have a problem backporting such change to an already released RHEL, which is the place where the original poster targets (otherwise this request would go to dnf5 project).

[cgwalters]

The only distinction from the current behavior is that now it would be a problem of dnf instead of bootc container image.

I think that's an accurate statement; however we are trying to reduce the set of "additional magic" in the bootc base image. People keep asking us why it isn't enough to

FROM quay.io/fedora/fedora:42
RUN dnf -y install kernel ...

and it's exactly stuff like moving this logic into dnf (instead of us overriding the configuration in the base image) that will help that.

Should we negate the container relaxation if the --installroot target file system is a bootc system (i.e. has run/ostree-booted)?

Mmm...but aren't we actually trying to fix the "running dnf from a container with --installroot" case that targets a package-based (not bootc/ostree) install right? That was why I was suggesting checking whether the install root is pid1's rootfs, which will transparently cover both the bootc case and the package case I believe.

I have not a problem changing the default in upstream in and in a next release

As is right now...I think we will be completely fine with just carrying the overrides in the bootc base image for the near future and can track adding this feature just into dnf5.

[cgwalters]

Dracut recently made a similar fix dracut-ng/dracut-ng#1456