I installed Fedora 36 about a month ago and it’s been working great mostly. Only major issue i’ve had is this one:
After running a sudo dnf update a couple of weeks ago and upgrading from kernel 5.18.16 to 5.18.17, the grub boot menu doesn’t show the updated kernel despite it being installed correctly (afaik). I’ve since run a couple more updates (5.18.18 and 5.18.19) but still the same issue, grub menu only shows 5.18.16 and a broken 5.17.5 (was removed during update i think). Kernel updates prior to this were working fine
Not sure if it’s related but I also ‘fixed’ the BTRFS subvolumes created on OS Installation… They were initially called root and home, I changed these to @ and @home respectively in order to get Timeshift working. BTRFS backups using Timeshift now work great but the kernel updating issue started around the same time… Don’t think these should be related but I’m a btrfs novice, any idea?
~/ sudo grub2-mkconfig -o /boot/grub2/grub.cfg 
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-5.18.19-200.fc36.x86_64
Found initrd image: /boot/initramfs-5.18.19-200.fc36.x86_64.img
Found linux image: /boot/vmlinuz-5.18.16-200.fc36.x86_64
Found initrd image: /boot/initramfs-5.18.16-200.fc36.x86_64.img
Found linux image: /boot/vmlinuz-0-rescue-ab2b085a1785456792f05fbe6626b188
Found initrd image: /boot/initramfs-0-rescue-ab2b085a1785456792f05fbe6626b188.img
Found Windows Boot Manager on /dev/nvme0n1p1@/efi/Microsoft/Boot/bootmgfw.efi
Found Manjaro Linux (21.3.6) on /dev/nvme0n1p3
Found Fedora Linux 36 (Thirty Six) on /dev/nvme1n1p3
Adding boot menu entry for UEFI Firmware Settings ...
You should never need to run the grub2-mkconfig command. Dnf automatically updates the grub.cfg info with each kernel update.
It seems you may have been hit with the small hiccup that has occurred for many with recent kernels (5.18.17 and newer) that caused the upgrade to complete without actually updating grub for booting the new kernel properly.
I myself have seen it once and newer updates seem to have fixed it.
Anyway, glad to assist and good luck going forward.
Looks like the 5.19.4 update recently required a grub2-mkconfig again.
I followed a guide on how to install Fedora to make it compliant with Timeshift requirements for BTRFS backups. One of the steps in the guide was to disable BLSCFG in /etc/default/grub. Think BLSCFG was supposed to be buggy at the time the guide was made. Any idea if it’s safe to re-enable it now?
Do I just edit /etc/default/grub and swap out false with true on the GRUB_ENABLE_BLSCFG=false entry, before the next kernel update?
There is a grub2-switch-to-blscfg that should help you to swithc to bls configuration. It was called during updates on version f30 and f31 and from f32 no more. I don’t know if this script works properly as it is expected that everybody has converted by now. Non-bls configuration depends on grubby-deprecated to update grub.cfg with a new kernel. With f37 there is no grubby-deprecated anymore, so you would need to run grub2-mkconfig after every kernel updates. I guess that would still work, probably.
You might make the change in /etc/default/grub then do an update to install the newer kernel and see if it works. BLS has been active for quite some time and that setting in the default config enables or disables it when the grub.cfg file is generated.
I think they are two separate issues. In general, you have to run mk-config each time you change default grub or any of its files in etc. On the contrary, when you update a kernel or install a new one, it should run mk-config automatically.