The “surprise” I mentioned was not the fact that having a different boot
for a second install requires a different efi
. I understood what EFI/fedora/grub.cfg
does.
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/loader/entries/
and /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
when boot
is shared by multiple root
. Of course, when it removes a kernel from root
it removes the same one from boot
.
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:
Edit /etc/dnf/dnf.conf
and find the definition of installonly_limit
and change the number there to something safe.