Apologies for what may be excessive detail in the below…
I upgraded from f37 to f39 last week using dnf system-upgrade as per usual. Nothing seemed amiss, although I did not watch the process carefully. After rebooting I noticed that I was still running an f37 kernel:
uname -r
6.5.12-100.fc37.x86_64
(And had I paid attention at the GRUB menu, I would have seen that as well.)
After searching forum posts I thought the upgrade might have stalled somehow and not installed everything properly, so I tried dnf distro-sync --releasever=39 --skip-broken (with rpmfusion* repos disabled) but that only installed 12 packages:
git-2.43.2-1.fc39.x86_64
git-core-2.43.2-1.fc39.x86_64
git-core-doc-2.43.2-1.fc39.noarch
perl-Git-2.43.2-1.fc39.noarch
python3-rpm-4.19.1.1-1.fc39.x86_64
rpm-4.19.1.1-1.fc39.x86_64
rpm-build-4.19.1.1-1.fc39.x86_64
rpm-build-libs-4.19.1.1-1.fc39.x86_64
rpm-libs-4.19.1.1-1.fc39.x86_64
rpm-plugin-selinux-4.19.1.1-1.fc39.x86_64
rpm-plugin-systemd-inhibit-4.19.1.1-1.fc39.x86_64
rpm-sign-libs-4.19.1.1-1.fc39.x86_64
So I seemed to have all the f39 packages, or at least not a bunch of old f37 stuff outside of the kernel. At some point in there I removed previous kernels so all I had left was the bootable
6.5.12-100.fc37 and the non-functional 6.7.4-200.fc39.
After the second iteration of dnf remove kernel\*6.7.4-200.fc39 and dnf system-upgrade, I realized my EFI partition was low on space (why the process didn’t throw an error the first time, I’m not sure). At that point the partition was only ~100MB, which had been adequate for about six years.
After spending most of an afternoon with GParted moving partitions around, I ran into a bug with Parted not being able to resize vfat partitions <256MB (grrrr), so I used the workaround documented here (TL;DR: backup /boot/efi, reformat partition to ext4, resize, reformat to fat32, restore data). I used rsync -a to copy the data to an external disk and back on. /boot/efi is now 500MB. I had freed up quite a bit more space with all the partition moving so can resize again if necessary. After all that, the machine still boots (w00t) but the fc37 kernel is still my only option.
Since then a new kernel became available, so today I tried dnf upgrade kernel*. I got some downloading errors which seemed temporary, because at completion it said it had installed all six
6.7.5-200.fc39 packages. However, I also got this:
Running scriptlet: kernel-core-6.7.5-200.fc39.x86_64 6/6
/usr/lib/kernel/install.d/51-dracut-rescue.install: line 81: /boot/efi/loader/entries/ac24b316920f43059ca830943adaac1c-0-rescue.conf: No such file or directory
/usr/lib/kernel/install.d/51-dracut-rescue.install failed with exit status 1.
warning: %posttrans(kernel-core-6.7.5-200.fc39.x86_64) scriptlet failed, exit status 1
Error in POSTTRANS scriptlet in rpm package kernel-core
Running scriptlet: kernel-modules-6.7.5-200.fc39.x86_64 6/6
Running scriptlet: kernel-devel-6.7.5-200.fc39.x86_64 6/6
So despite dnf reporting success with two fc39 different kernels, I’m still where I have been for a week. In /boot the most recent kernel files are:
System.map-6.5.12-100.fc37.x86_64
config-6.5.12-100.fc37.x86_64
vmlinuz-6.5.12-100.fc37.x86_64
initramfs-6.5.12-100.fc37.x86_64.img
I don’t know much about where else I should look. One other piece of info is that the EFI partition appears to be filling up rather quickly (with temp files from previous installs? Again, I know little about the anatomy of these areas…)
df -h /boot/efi
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 497M 304M 194M 62% /boot/efi