The “surprise” I mentioned was not the fact that having a different
boot for a second install requires a different
efi. I understood what
Having done all this multiple times recently, and very similar to what the OP described trying, my experience has been that Anaconda reliably creates entries in the new
loader/entries directory for all the other fedora installs on the same drive.
So the surprise was “I couldn’t boot the previous installation anymore.”
Not a bad idea, but I think not that vital. Whatever you install last will almost certainly create an acceptable efi partition in every way, other than possibly the uuid in
EFI/fedora/grub.cfg, which is easy to fix afterward if you hadn’t backed it up and had it clobbered by something you expected to not trash it.
But the contents of
/boot/grub2/grub.cfg get messed up by Anaconda and by
dnf and it takes more than a tiny edit to fix them. I think having backups of those is vital. After anything messes with those, I think you want to compare/merge in order to undo all the destructive changes and keep anything that was added or changed for good reason.
When Anaconda does create an entirely new
boot then you want to merge some things from there to your old
boot (and fix the uuid in
EFI/fedora/grub.cfg to get back to using your old
boot). Or merge things from the old
boot to the new
boot and keep the new one and not fix the uuid. But since Anaconda isn’t the only thing messing up the contents of
boot a backup of that is still vital.
Have I misunderstood that? In limited experimentation, I came to the conclusion that was limiting the number of kernels kept in one
root partition and not the number in
boot is shared by multiple
root. Of course, when it removes a kernel from
root it removes the same one from
But for anyone experimenting with versions or variants in any way (even just early adopter of the next version) the default of 3 is dangerously low. Disk space is cheap (even SSD space). I messed up recently by experimenting without raising that limit. I want it high enough that DNF just doesn’t delete kernels. I’d rather go to the effort to clean those up myself when I’m sure I never want them again. Others probably just want it high enough to delay the automatic removal until it is less likely to be a bad idea.
I hate threads that tell you to do something non obvious, with telling how, so:
/etc/dnf/dnf.conf and find the definition of
installonly_limit and change the number there to something safe.