2022-12-15T11:54:14+0000 INFO dracut: Can't write to /boot/efi/70135c696ca547939f1864d32e1cbf74/5.14.0-162.6.1.el9_1.0.1.x86_64: Directory /boot/efi/70135c696ca547939f1864d32e1cbf74/5.14.0-162.6.1.el9_1.0.1.x86_64 does not exist or is not accessible.
After dnf upgrade:
The new kernel for 9.1 has been installed, but is missing from the grub menu, so it currently boots into the previous kernel from 9.0.
It looks like all packages for 9.1 have been installed, but I canāt boot into the new kernelā¦
Why did dracut try to write such non-existing location?
The EFI System Partition (ESP) ā a VFAT filesystem ā is mounted to /boot/efi.
I have never seen anything but directory EFI in /boot/efi/.
The dracut was probably called in āpostinstallā script of some kernel* package.
The rest of the script might have been skipped due to what dracut returns.
That could explain the lack of boot entry.
A trivial thing is to remove&install (or reinstall) the 5.14.0-162* kernel packages.
That would (re)create boot entry, if successful.
However, if the dracut issue persists, then you have to diagnose&fix it first.
The location (it was trying to write to) didnāt look right to me either, but at the top of āman dracutā, it implies that this could be a valid location, based on the boot loader you are using, but all my previous initramfs files were directly under ā/bootā, so I donāt know.
Removing all the 9.1 kernel packages and then running ādnf upgradeā again, seems to have fixed everything, but I donāt know what the original problem was.
Two points related to bootloader (GRUB) config and hence its menu:
The default is to use BLS (Boot Loader Specification). That is, each menu entry is a separate file in directory /boot/loader/entries/ ā not in the grub.cfg. (One can disable BLS to get back to the āall in one fileā config.)
In el9 ā UEFI system ā the EFI loads GRUB binary from /boot/efi/EFI/${vendor}/ and grub.cfg from same location. The difference to el8 is that that grub.cfg is really short and essentially has one statement: include /boot/grub2/grub.cfg
The āreal grub.cfgā is thus the /boot/grub2/grub.cfg, just like in legacy systems. Should you have a need to run grub2-mkconfig, remember to direct the config to /boot/grub2/grub.cfg
In my case, I can see that ā/boot/grub2/grub.cfgā has not been changed since August, but ā/boot/grub2/grubenvā has been updated today, when I ran dnf upgrade. I donāt know if it updates grub before or after creating initramfs, but I gess it should leave grub until last.
Just to be absolutely sure, I have on Ansible āupdateā play two steps:
update everything, except kernel&co
update everything
That way all the packages (except kernel modules) that could go to initramfs or are otherwise involved in installation of kernel are definitely already updated when the new kernel is installed on step two.
Not sure whether that has any real effect or benefit other than the false sense of being in control.
Of all the different %post scripts, and in all the different kernel packages, do you know which one actually invokes dracut to create the ā/bootā initramfs files?
Maybe it only tries to use ādracutā when things go wrong (as a fallback). There must be some ānormalā way that it has been creating initramfs entries for years, before this change. I did notice there was a long pause when it was running ākmod-kvdoā, and perhaps it ended up in a half-finished state, but I did run ādnf checkā and it said everything was ok.