I’m running Fedora Server 41 which has been previously upgraded from Fedora Server 40 and Fedora Server 39. Due to firmware limitations, I can’t boot off of the drive I am using for the root partition, and so I elected to have /boot on a seperate drive. (this may hint as to the problem)
Despite upgrading two major versions over the past few years, the contents of my /boot only contain a single bootable kernel, that being vmlinuz-6.9.6-100.fc39.x86_64. Grub will also warn I am running the now unsupported Linux Fedora 39, despite actually being on Linux Fedora 41 (also now recently unsupported). The running kernel as reported by uname is unsurprisingly 6.9.6-100.fc39.x86_64.
Is this a problem? How would I fix this?
I have tried reinstalling kernel-core however that didn’t seem to do anything. Only grub2, and my symvers appear to be getting updated.
Output of ls -la /boot:
dr-xr-xr-x. 5 root root 4096 Jan 12 00:55 .
dr-xr-xr-x. 1 root root 138 Jan 12 00:48 ..
-rw-r--r--. 1 root root 274094 Jun 21 2024 config-6.9.6-100.fc39.x86_64
drwxr-xr-x. 5 root root 71 Jun 29 2024 efi
drwx------. 5 root root 97 Jan 12 01:22 grub2
-rw-------. 1 root root 154983813 Mar 3 2024 initramfs-0-rescue-59a2ba12771a45e1bb4a2a7dad99023e.img
-rw-------. 1 root root 36260743 Jun 29 2024 initramfs-6.9.6-100.fc39.x86_64.img
drwxr-xr-x. 3 root root 21 Mar 3 2024 loader
-rw-r--r--. 1 root root 192156 Sep 6 21:49 symvers-6.16.4-100.fc41.x86_64.xz
-rw-r--r--. 1 root root 183752 Jan 12 00:55 symvers-6.17.10-100.fc41.x86_64.xz
-rw-r--r--. 1 root root 163108 Jun 29 2024 symvers-6.9.6-100.fc39.x86_64.xz
-rw-r--r--. 1 root root 9044456 Jun 21 2024 System.map-6.9.6-100.fc39.x86_64
-rwxr-xr-x. 1 root root 14794568 Mar 3 2024 vmlinuz-0-rescue-59a2ba12771a45e1bb4a2a7dad99023e
-rwxr-xr-x. 1 root root 15780200 Jun 21 2024 vmlinuz-6.9.6-100.fc39.x86_64
-rw-r--r--. 1 root root 160 Jun 21 2024 .vmlinuz-6.9.6-100.fc39.x86_64.hmac
If you run rpm -q --scripts kernel-core, you should see the kernel-install add ... command that would be run when your kernel-core packages are installed. It will dump the scripts from multiple kernel-core packages assuming you have more than one installed. The scripts for the latest package should be at the end.
Try running that kernel-install command manually with an added -v (verbose) option and you might get some hints about what is (or isn’t) happening in the output.
I don’t necessarily care where Fedora is putting the kernels, so long as I can actually boot from them. The partition mounted at /boot is indeed my boot drive.
I seem to already have an install.conf created by Fedora at some point, with the following contents:
# cat /etc/kernel/install.conf
# systemd-boot default anaconda installs
# mounts the ESP at /boot/efi, tell kernel-install
# that it should be putting kernel/initrd/bls/etc
# entries there rather than in /boot
BOOT_ROOT=/boot/efi
I have another Fedora Server machine (with a self-contained /boot), which does not have an install.conf in /etc/kernel. My own Fedora Workstation machine doesn’t either. Presumably this might be created when a seperate boot disk is chosen?
Interesting. I don’t have that file, but my installs are much older.
The comment appears to be saying that the configuration is for systemd-boot, but your earlier output appears to be using GRUB?
It is complicated because GRUB tries to spread things across multiple partitions in its default EFI configuration, but systemd-boot prefers all the content on a single partition. Is your system (U)EFI?
Well, I would try changing BOOT_ROOT to /boot and re-run that kernel-install command with the verbose flag. There is a chance that it could render your system unbootable, but it would be fixable with a Live image if necessary.
Also, after you run kernel-install with the corrected settings, run efibootmgr and verify that there is still a boot entry that points to a valid bootloader on the correct partition. The UUIDs are partition UUIDs. You can use ls -al /dev/disk/by-partuuid and/or lsblk -o +partuuid to see what partitions have what UUIDs.
Edit: I just noticed your edit in your previous post, so scratch all that about verifying the EFI configuration.
IIRC, I think BIOS-mode GRUB will try to find the right “boot” partition via the filesystem UUID. You’ll want to examine the grub.cfg file(s) and make sure that they appear to be pointing at the right filesystems after you run kernel-install with the corrected settings. You can use ls -al /dev/disk/by-uuid and/or lsblk -o +uuid to view the filesystem UUIDs on your system.
Ran kernal-install again after changing BOOT_ROOT. Seems it completed successfully again.
# /bin/kernel-install add -v 6.17.10-100.fc41.x86_64 /lib/modules/6.17.10-100.fc41.x86_64/vmlinuz
BOOT_ROOT (/boot) set via config.
Loaded config.
MACHINE_ID=59a2ba12771a45e1bb4a2a7dad99023e set via /etc/machine-id.
Using entry token: 59a2ba12771a45e1bb4a2a7dad99023e
kernel version (6.17.10-100.fc41.x86_64) set via command line.
kernel image file (/lib/modules/6.17.10-100.fc41.x86_64/vmlinuz) set via command line.
Entry-token directory not found, using layout=other.
Using ENTRY_DIR=/boot/59a2ba12771a45e1bb4a2a7dad99023e/6.17.10-100.fc41.x86_64
Using plugins:
/usr/lib/kernel/install.d/20-grub.install
/usr/lib/kernel/install.d/50-depmod.install
/usr/lib/kernel/install.d/50-dracut.install
/usr/lib/kernel/install.d/51-dracut-rescue.install
/usr/lib/kernel/install.d/60-kdump.install
/usr/lib/kernel/install.d/90-loaderentry.install
/usr/lib/kernel/install.d/90-uki-copy.install
/usr/lib/kernel/install.d/92-crashkernel.install
/usr/lib/kernel/install.d/99-grub-mkconfig.install
Plugin environment:
LC_COLLATE=C.UTF-8
KERNEL_INSTALL_VERBOSE=1
KERNEL_INSTALL_IMAGE_TYPE=pe
KERNEL_INSTALL_MACHINE_ID=59a2ba12771a45e1bb4a2a7dad99023e
KERNEL_INSTALL_ENTRY_TOKEN=59a2ba12771a45e1bb4a2a7dad99023e
KERNEL_INSTALL_BOOT_ROOT=/boot
KERNEL_INSTALL_LAYOUT=other
KERNEL_INSTALL_INITRD_GENERATOR=
KERNEL_INSTALL_UKI_GENERATOR=
KERNEL_INSTALL_STAGING_AREA=/tmp/kernel-install.staging.QnQNBN
Plugin arguments: add 6.17.10-100.fc41.x86_64 /boot/59a2ba12771a45e1bb4a2a7dad99023e/6.17.10-100.fc41.x86_64 /lib/modules/6.17.10-100.fc41.x86_64/vmlinuz
Successfully forked off '(sd-exec-strv)' as PID 102176.
About to execute /usr/lib/kernel/install.d/20-grub.install add 6.17.10-100.fc41.x86_64 /boot/59a2ba12771a45e1bb4a2a7dad99023e/6.17.10-100.fc41.x86_64 /lib/modules/6.17.10-100.fc41.x86_64/vmlinuz
Successfully forked off '(direxec)' as PID 102177.
/usr/lib/kernel/install.d/20-grub.install succeeded.
About to execute /usr/lib/kernel/install.d/50-depmod.install add 6.17.10-100.fc41.x86_64 /boot/59a2ba12771a45e1bb4a2a7dad99023e/6.17.10-100.fc41.x86_64 /lib/modules/6.17.10-100.fc41.x86_64/vmlinuz
Successfully forked off '(direxec)' as PID 102210.
+depmod -a 6.17.10-100.fc41.x86_64
/usr/lib/kernel/install.d/50-depmod.install succeeded.
About to execute /usr/lib/kernel/install.d/50-dracut.install add 6.17.10-100.fc41.x86_64 /boot/59a2ba12771a45e1bb4a2a7dad99023e/6.17.10-100.fc41.x86_64 /lib/modules/6.17.10-100.fc41.x86_64/vmlinuz
Successfully forked off '(direxec)' as PID 102234.
dracut[I]: Executing: /usr/bin/dracut -f --verbose --kernel-image /lib/modules/6.17.10-100.fc41.x86_64/vmlinuz --kver 6.17.10-100.fc41.x86_64 /boot/initramfs-6.17.10-100.fc41.x86_64.img
dracut[I]: *** Including module: systemd ***
dracut[I]: *** Including module: fips ***
dracut[I]: *** Including module: fips-crypto-policies ***
dracut[I]: *** Including module: systemd-ask-password ***
dracut[I]: *** Including module: systemd-initrd ***
dracut[I]: *** Including module: systemd-journald ***
dracut[I]: *** Including module: systemd-modules-load ***
dracut[I]: *** Including module: systemd-sysctl ***
dracut[I]: *** Including module: systemd-sysusers ***
dracut[I]: *** Including module: systemd-tmpfiles ***
dracut[I]: *** Including module: systemd-udevd ***
dracut[I]: *** Including module: nss-softokn ***
dracut[I]: *** Including module: i18n ***
dracut[I]: *** Including module: drm ***
dracut[I]: *** Including module: plymouth ***
dracut[I]: *** Including module: btrfs ***
dracut[I]: *** Including module: crypt ***
dracut[I]: *** Including module: dm ***
dracut[I]: *** Including module: kernel-modules ***
dracut[I]: *** Including module: kernel-modules-extra ***
dracut[I]: *** Including module: pcmcia ***
dracut[I]: *** Including module: systemd-cryptsetup ***
dracut[I]: *** Including module: rootfs-block ***
dracut[I]: *** Including module: terminfo ***
dracut[I]: *** Including module: udev-rules ***
dracut[I]: *** Including module: dracut-systemd ***
dracut[I]: *** Including module: usrmount ***
dracut[I]: *** Including module: base ***
dracut[I]: *** Including module: fs-lib ***
dracut[I]: *** Including module: memstrack ***
dracut[I]: *** Including module: shutdown ***
dracut[I]: *** Including modules done ***
dracut[I]: *** Installing kernel module dependencies ***
dracut[I]: *** Installing kernel module dependencies done ***
dracut[I]: *** Resolving executable dependencies ***
dracut[I]: *** Resolving executable dependencies done ***
dracut[I]: *** Hardlinking files ***
dracut[I]: *** Hardlinking files done ***
dracut[I]: *** Generating early-microcode cpio image ***
dracut[I]: *** Constructing GenuineIntel.bin ***
dracut[I]: *** Store current command line parameters ***
dracut[I]: *** Creating image file '/boot/efi/59a2ba12771a45e1bb4a2a7dad99023e/6.17.10-100.fc41.x86_64/initrd' ***
dracut[I]: Using auto-determined compression method 'zstd'
dracut[I]: *** Creating initramfs image file '/boot/efi/59a2ba12771a45e1bb4a2a7dad99023e/6.17.10-100.fc41.x86_64/initrd' done ***
/usr/lib/kernel/install.d/50-dracut.install succeeded.
About to execute /usr/lib/kernel/install.d/51-dracut-rescue.install add 6.17.10-100.fc41.x86_64 /boot/59a2ba12771a45e1bb4a2a7dad99023e/6.17.10-100.fc41.x86_64 /lib/modules/6.17.10-100.fc41.x86_64/vmlinuz
Successfully forked off '(direxec)' as PID 111465.
Skipping, there is already a rescue image generated with the same input parameters
/usr/lib/kernel/install.d/51-dracut-rescue.install succeeded.
About to execute /usr/lib/kernel/install.d/60-kdump.install add 6.17.10-100.fc41.x86_64 /boot/59a2ba12771a45e1bb4a2a7dad99023e/6.17.10-100.fc41.x86_64 /lib/modules/6.17.10-100.fc41.x86_64/vmlinuz
Successfully forked off '(direxec)' as PID 111466.
/usr/lib/kernel/install.d/60-kdump.install succeeded.
About to execute /usr/lib/kernel/install.d/90-loaderentry.install add 6.17.10-100.fc41.x86_64 /boot/59a2ba12771a45e1bb4a2a7dad99023e/6.17.10-100.fc41.x86_64 /lib/modules/6.17.10-100.fc41.x86_64/vmlinuz
Successfully forked off '(direxec)' as PID 111467.
/usr/lib/kernel/install.d/90-loaderentry.install succeeded.
About to execute /usr/lib/kernel/install.d/90-uki-copy.install add 6.17.10-100.fc41.x86_64 /boot/59a2ba12771a45e1bb4a2a7dad99023e/6.17.10-100.fc41.x86_64 /lib/modules/6.17.10-100.fc41.x86_64/vmlinuz
Successfully forked off '(direxec)' as PID 111468.
/usr/lib/kernel/install.d/90-uki-copy.install succeeded.
About to execute /usr/lib/kernel/install.d/92-crashkernel.install add 6.17.10-100.fc41.x86_64 /boot/59a2ba12771a45e1bb4a2a7dad99023e/6.17.10-100.fc41.x86_64 /lib/modules/6.17.10-100.fc41.x86_64/vmlinuz
Successfully forked off '(direxec)' as PID 111469.
/usr/lib/kernel/install.d/92-crashkernel.install succeeded.
About to execute /usr/lib/kernel/install.d/99-grub-mkconfig.install add 6.17.10-100.fc41.x86_64 /boot/59a2ba12771a45e1bb4a2a7dad99023e/6.17.10-100.fc41.x86_64 /lib/modules/6.17.10-100.fc41.x86_64/vmlinuz
Successfully forked off '(direxec)' as PID 111478.
/usr/lib/kernel/install.d/99-grub-mkconfig.install succeeded.
(sd-exec-strv) succeeded.
Looking at /boot now shows my new and shiny vmlinuz-6.17.10-100.fc41.x86_64 as well as config-6.17.10-100.fc41.x86_64. Looking at grub.cfg at the moment
I can only see one set kernelopts which sets root=UUID=… to the UUID of /dev/dm-0 (using LUKS), which is mounted as / according to df. I would presume this is what I’m wanting to see?
Ehh, LUKS is a whole other layer of complication. I’m not sure about that, but it doesn’t sound right to me if you have a separate /boot partition. Are you sure that your correct boot partition was mounted at /boot before you ran kernel-install? If not, you might need to run something like mv /boot /boot.bak && mkdir /boot && mount /boot. Also, be sure that your /etc/fstab has the right boot partition listed. You can use the findmnt command to see what your active mounts look like.
Edit: Nevermind, set kernelopts would be for the / mount, not for the /boot mount.
I don’t use GRUB anymore, but I thought there was some sort of GRUB command that tried to find the /boot partition and point a variable (unfortunately, named root) to point at the /boot partition. I’m really not sure because I gave up on GRUB a long time ago.
Let me see if I can find an old example online somewhere …
OK, so the line I was thinking of would look something like this:
I can see the UUID of the filesystem providing /boot referenced in search --no-floppy --fs-uuid --set=root … and the larger search --no-floppy --fs-uuid --set=root --hint-bios=hd2,gpt1 --hint-efi=hd2,gpt1 --hint-baremetal=ahci2,gpt1 --hint=‘hd0,gpt1’ … under the section for /etc/grub.d/10_linux.
Comparing to my workstation install sadly isn’t helpful as the section for 10_linux is radically different.
As long as that “search” command is looking for the UUID of the right filesystem (the one on your /boot partition), I think you are OK.
There are a few other things to be aware of, such as that a filesystem driver for whatever /boot is formatted with is available, but I’m assuming you haven’t done anything too exotic there and it should all just work.
