In general, files that are provided by packages should only be managed through interacting with the package manager (except for configuration files that are intended to be user-modifiable). Manually messing with package-manager managed files is a recipe for causing weird problems In this case, dnf remove kernel-core-<version-to-drop> would have done what you needed (and also cleaned up all other files from that kernel’s packages, not just the ones you manually deleted from /boot).
To prevent this issue from happening again, you can add a line with installonly_limit=2 to the DNF configuration file (/etc/dnf/dnf.conf). This will cause dnf to only keep the last two kernels instead of the last three - which should, I think, in almost all cases prevent the “full boot prevents updates” issue until the actual underlying issue is resolved.
Instead of modifying the installonly_limit in /etc/dnf/dnf.conf I chose the alternative approach. I enlarged /boot from the default 1G size to 1.5G. After all, there is, as yet, no idea how long it may be until the size of the initramfs images is addressed and shrunk back to near the sizes of the older images. I much prefer to have 3 usable kernels installed which results in a total of 4 initramfs images (one being to the rescue image).
That is a workaround, but does not allow for the potential of replacing or installing new hardware while using the same drive. It limits the image to the exact hardware and drivers already installed.
Correct again. That, OTOH, I digged. They added that parameter in the last dracut version, or the one before that. Default mode was ‘strict’ until then.
In this case,