After 33 => 35, 36 upgrades, still using 33 kernel.

[StefanJ]

I have an older laptop I wanted to fix up to take with me on a road trip.

It was running FC33, KDE. I upgraded with:

dnf system-upgrade --nogpgcheck download --releasever=35

Everything went fine. No errors that I saw. After the reboot I checked the kernel version (with uname -a). It showed fc33 kernel was still active.

I saw on getfedora that fc36 was available, so I thought I'd update to that.

That upgrade seemed to go find too! But again, the fc33 kernel was still running.

This morning I noticed that a new fc36 kernel was available. I updated the kernel:

dnf update kernel

The process seemed to go fine. It removed the 35 kernel, and installed the new one. But after a reboot, the system was still running fc33 kernel! The grub menu ONLY shows the 33 kernel, and a rescue kernel, and the Windows boot manager.


I looked in /boot and only see vmlinuz files for the rescue and fc33 kernels:

[root@localhost boot]# ls
config-5.14.18-100.fc33.x86_64                           initrd-plymouth.img
efi                                                      loader
elf-memtest86+-5.31                                      memtest86+-5.31
extlinux                                                 System.map-5.14.18-100.fc33.x86_64
grub2                                                    vmlinuz-0-rescue-3d7164e7868c462abe71568d3db746dd
initramfs-0-rescue-3d7164e7868c462abe71568d3db746dd.img  vmlinuz-5.14.18-100.fc33.x86_64
initramfs-5.14.18-100.fc33.x86_64.img

I checked to see if the kernel packages had been installed:

[root@localhost boot]# dnf list kernel
Last metadata expiration check: 2:10:17 ago on Wed 11 May 2022 06:33:57 AM PDT.
Installed Packages
kernel.x86_64                                    5.14.18-100.fc33                                     @updates
kernel.x86_64                                    5.17.5-300.fc36                                       @fedora 
kernel.x86_64                                    5.17.6-300.fc36                                      @updates

<strike>Is there a way to force construction of a proper Grub menu?</strike>

I ran grub2-mkconfig -o /boot/grub2/grub.cfg

No change. The menu doesn't list the FC36 kernels.


Thank you,

stefan

[lionking62]

I've got the same problem, after upgrade f35-> f36. No f36 kernel.

[mmmmm]

Same here. On two laptops, updated via dnf system-upgrade from f35 to f36, still using f35 kernel.

Reinstalling the f36 kernel (dnf reinstall ...) doesn't help, neither does kernel-install add. The F36 doesn't show up in the EFI boot menu.

by the way - kernel-install add seems to try to install something into the EFI partition, which is quite full. 13 out of 256 megabytes left free after kernel-install on one machine and 56 out of 256 MB free on the other.

Can anybody help?

This is how the boxes look like after the upgrade:

# dnf list kernel
Last metadata expiration check: 1:36:18 ago on Thu 12 May 2022 11:53:48 CEST.
Installed Packages
kernel.x86_64                           5.16.20-200.fc35                            @updates
kernel.x86_64                           5.17.4-200.fc35                             @updates
kernel.x86_64                           5.17.5-200.fc35                             @updates
kernel.x86_64                           5.17.6-300.fc36                             @updates

# ls -l /boot
total 233872
drwxr-xr-x. 3 root root     4096 Nov  5  2017 520f44320ac640c68996d2e055036d31
-rw-r--r--  1 root root   240752 Apr 14 00:27 config-5.16.20-200.fc35.x86_64
-rw-r--r--  1 root root   243904 Apr 20 17:55 config-5.17.4-200.fc35.x86_64
-rw-r--r--  1 root root   243937 Apr 28 17:59 config-5.17.5-200.fc35.x86_64
drwx------  8 root root     4096 Jan  1  1970 efi
-rw-r--r--  1 root root   151452 Jan 27 12:54 elf-memtest86+-5.31
drwxr-xr-x. 2 root root     4096 May 11 14:32 extlinux
drwx------. 4 root root     4096 May 12 11:56 grub2
-rw-------. 1 root root 70030105 Mar 10  2018 initramfs-0-rescue-a7743a6220d7459faf7c2eedff919dfc.img
-rw-------  1 root root 36126853 Apr 19 01:01 initramfs-5.16.20-200.fc35.x86_64.img
-rw-------  1 root root 36204339 Apr 27 01:14 initramfs-5.17.4-200.fc35.x86_64.img
-rw-------  1 root root 36228482 May 11 00:32 initramfs-5.17.5-200.fc35.x86_64.img
drwxr-xr-x  3 root root     4096 Apr 30  2018 loader
drwx------. 2 root root    16384 Mar 10  2018 lost+found
-rw-r--r--  1 root root   149856 Jan 27 12:54 memtest86+-5.31
lrwxrwxrwx  1 root root       47 Apr 19 01:00 symvers-5.16.20-200.fc35.x86_64.gz -> /lib/modules/5.16.20-200.fc35.x86_64/symvers.gz
lrwxrwxrwx  1 root root       46 Apr 27 01:13 symvers-5.17.4-200.fc35.x86_64.gz -> /lib/modules/5.17.4-200.fc35.x86_64/symvers.gz
lrwxrwxrwx  1 root root       46 May 11 00:30 symvers-5.17.5-200.fc35.x86_64.gz -> /lib/modules/5.17.5-200.fc35.x86_64/symvers.gz
-rw-------  1 root root  5962585 Apr 14 00:27 System.map-5.16.20-200.fc35.x86_64
-rw-------  1 root root  6011375 Apr 20 17:55 System.map-5.17.4-200.fc35.x86_64
-rw-------  1 root root  6011681 Apr 28 17:59 System.map-5.17.5-200.fc35.x86_64
-rwxr-xr-x. 1 root root  7475288 Mar 10  2018 vmlinuz-0-rescue-a7743a6220d7459faf7c2eedff919dfc
-rwxr-xr-x  1 root root 11383152 Apr 14 00:27 vmlinuz-5.16.20-200.fc35.x86_64
-rwxr-xr-x  1 root root 11433520 Apr 20 17:55 vmlinuz-5.17.4-200.fc35.x86_64
-rwxr-xr-x  1 root root 11520400 Apr 28 17:59 vmlinuz-5.17.5-200.fc35.x86_64

[smr54]

I have had this happen, but Fedora is not the OS that is booting the system. I boot from VoidLinux grub, and even after running update-grub in Void, though it will show F36 in the grub menu, it will boot to an older kernel. The way I have been able to work around this is to choose Advanced options for Fedora in the boot menu which shows 4 possibilities, without saying what they are, and hitting e for edit. It turns out the last one listed is the latest kernel. I figured this was a Void grub issue, and still consider it as such, rather than a Fedora problem.

[john4685]

I have had this happen, but Fedora is not the OS that is booting the system. I boot from VoidLinux grub, and even after running update-grub in Void, though it will show F36 in the grub menu, it will boot to an older kernel. The way I have been able to work around this is to choose Advanced options for Fedora in the boot menu which shows 4 possibilities, without saying what they are, and hitting e for edit. It turns out the last one listed is the latest kernel. I figured this was a Void grub issue, and still consider it as such, rather than a Fedora problem.

I had that problem with another OS that boots the system.

It was the rescue kernel keeping the newer kernel from being the default, so I got rid of the rescue kernel.

[smr54]

Thanks, I'll have to give that a try, though probably not today.

[DaleDonofrio]

I've done it before, missed a step in the process.
"sudo dnf system-upgrade download --releasever=(any release)"
It downloads all the needed packages and checks.
If you don't "sudo dnf system-upgrade reboot" after the download completes the upgrade never takes place.
You reboot back to what you had when you did the download.
It's easy to overlook, and very frustrating. You can also run "sudo dnf distro-sync --releasever=
to get all the duck in line too.
Hope it helps.
(It's a hobby, but I like it)

[lionking62]

]# dnf list kernel
Last metadata expiration check: 0:53:32 ago on Thu 12 May 2022 19:21:37 CEST.
Installed Packages
kernel.x86_64 5.17.5-200.fc35 @updates
kernel.x86_64 5.17.6-300.fc36 @updates

boot]# ll
total 55658
drwxr-xr-x. 3 root root 1024 Nov 5 2017 520f44320ac640c68996d2e055036d31
-rw-r--r-- 1 root root 243937 Apr 28 17:59 config-5.17.5-200.fc35.x86_64
drwx------ 9 root root 4096 Jan 1 1970 efi
-rw-r--r-- 1 root root 151452 Jan 27 12:54 elf-memtest86+-5.31
drwxr-xr-x. 2 root root 5120 May 10 17:53 extlinux
drwx------. 4 root root 1024 May 12 19:55 grub2
-rw------- 1 root root 38883346 May 4 07:01 initramfs-5.17.5-200.fc35.x86_64.img
drwxr-xr-x 3 root root 1024 May 4 2018 loader
drwx------. 2 root root 12288 Mar 7 2018 lost+found
-rw-r--r-- 1 root root 149856 Jan 27 12:54 memtest86+-5.31
lrwxrwxrwx 1 root root 46 May 4 07:01 symvers-5.17.5-200.fc35.x86_64.gz -> /lib/modules/5.17.5-200.fc35.x86_64/symvers.gz
-rw------- 1 root root 6011681 Apr 28 17:59 System.map-5.17.5-200.fc35.x86_64
-rwxr-xr-x 1 root root 11520400 Apr 28 17:59 vmlinuz-5.17.5-200.fc35.x86_64

[marko]

You can use the "grubby" command to fix this

grubby --default-kernel
Will show what grub is set to boot as the default kernel

And I use this(--set-default) to set default kernel by path:

https://www.golinuxcloud.com/grubby-...ng_kernel_path

[lionking62]

Yes, but there is no f36 kernel in /boot.

[StefanJ]

Thanks Marko. I hadn't heard of grubby.

The problem is . . . while the later kernels are installed, the /boot directory does not have the vmlinuz* files! So I can't use the grubby directive to point at the fc36 kernel as default.

[StefanJ]

I found a thread about missing vmliunz files:

https://forums.fedoraforum.org/showt...mlinuz+missing

I haven't tried reinstalling grub2 yet, but wanted that thread in the discussion.

OK. Found something odd. I'm going to move over to my laptop where this is happening. I'll edit this message there.

* * *
OK. I reinstalled "kernel" using dnf. I installed the two fc36 kernels. Final result:

Reinstalled:
  kernel-5.17.5-300.fc36.x86_64                         kernel-5.17.6-300.fc36.x86_64

I tried reinstalling kernel-core, per that thread. In the transaction steps:

Running transaction
  Preparing        :                                                                                      1/1 
  Reinstalling     : kernel-core-5.17.6-300.fc36.x86_64                                                   1/4 
  Running scriptlet: kernel-core-5.17.6-300.fc36.x86_64                                                   1/4 
  Reinstalling     : kernel-core-5.17.5-300.fc36.x86_64                                                   2/4 
  Running scriptlet: kernel-core-5.17.5-300.fc36.x86_64                                                   2/4 
  Running scriptlet: kernel-core-5.17.6-300.fc36.x86_64                                                   3/4 
  Cleanup          : kernel-core-5.17.6-300.fc36.x86_64                                                   3/4 
  Running scriptlet: kernel-core-5.17.5-300.fc36.x86_64                                                   4/4 
  Cleanup          : kernel-core-5.17.5-300.fc36.x86_64                                                   4/4 
  Running scriptlet: kernel-core-5.17.6-300.fc36.x86_64                                                   4/4 
kdump: kernel 5.17.6-300.fc36.x86_64 doesn't exist

  Running scriptlet: kernel-core-5.17.5-300.fc36.x86_64                                                   4/4 
kdump: kernel 5.17.5-300.fc36.x86_64 doesn't exist

  Verifying        : kernel-core-5.17.5-300.fc36.x86_64                                                   1/4 
  Verifying        : kernel-core-5.17.5-300.fc36.x86_64                                                   2/4 
  Verifying        : kernel-core-5.17.6-300.fc36.x86_64                                                   3/4 
  Verifying        : kernel-core-5.17.6-300.fc36.x86_64                                                   4/4 

Reinstalled:
  kernel-core-5.17.5-300.fc36.x86_64                    kernel-core-5.17.6-300.fc36.x86_64

Whoa!

But rpm -qa and dnf list show the kernel packages present:

[root@localhost boot]# rpm -qa | grep kernel-5.17.6-300.fc36.x86_64
kernel-5.17.6-300.fc36.x86_64
[root@localhost boot]# locate kernel-5.17.6-300.fc36.x86_64
[root@localhost boot]# dnf list kernel-5.17.6-300.fc36.x86_64
Last metadata expiration check: 0:23:40 ago on Thu 12 May 2022 11:57:18 AM PDT.
Installed Packages
kernel.x86_64                                     5.17.6-300.fc36                                     @updates

Got the same results running "dnf reinstall kernel-*"

Oye . . . any ideas?

[marko]

Thanks Marko. I hadn't heard of grubby.

The problem is . . . while the later kernels are installed, the /boot directory does not have the vmlinuz* files! So I can't use the grubby directive to point at the fc36 kernel as default.

okay, the thread was saying both "no kernel in grub menu" and then later there was mention of missing files.
I suppose in that situation I'd run:

rpm -qv --verify <name of a kernel-core package that's missing files in /boot>

this would make rpm compare the package's files to the on-disk files all the way down to comparing the MD5 sums and permissions of the package files and on-disk files

and also run

dnf history info ##

to see the exact log statement on the number ## transaction (get the numbers with "dnf history list") that installed those kernel-core packages, maybe there's an illuminating error message. "dnf history info ##" retains the exact output that dnf output at the time

[mmmmm]

Hi,

obviously, the F36 installation writes its new kernels into the /boot/efi partition while grub looks for them directly under /boot. That's why grub can't find anything. Grubby doesn't seem to help.

I also tried creating a new grub.conf using grub2-mkconfig. This creates a more modern grub.conf, but that one doesn't find the kernel in the new place either.

Where does F36 normally store the images for grub to boot in an EFI environment? Directly unter /boot - or under /boot/efi?

Is there anybody out there who succeeded in updating an EFI machine from F35 to F36 with the new F36 kernel actually being booted?

Of course, the problem has nothing to do with forgetting (sudo) dnf system-upgrade download or Grubby's default kernel settings. Grub can't find the kernel at all, because it's in a place where Grub doesn't look for it.

And I (probably all of the current contributors to this thread) don't know
a) where the correct place for the new kernels is in F36
b) if it's /boot/efi, what is missing for Grub to find it
c) if it's /boot, why the new kernal is placed unter /boot/efi instead

[mmmmm]

okay, the thread was saying both "no kernel in grub menu" and then later there was mention of missing files.
I suppose in that situation I'd run:

rpm -qv --verify <name of a kernel-core package that's missing files in /boot>

this would make rpm compare the package's files to the on-disk files all the way down to comparing the MD5 sums and permissions of the package files and on-disk files

and also run

dnf history info ##

to see the exact log statement on the number ## transaction (get the numbers with "dnf history list") that installed those kernel-core packages, maybe there's an illuminating error message. "dnf history info ##" retains the exact output that dnf output at the time

I did try rpm -V. And found that the /boot files are so-called ghost files. These copies are not a direct part of the packages. Instead, scripts place should place the files there if required. And they don't in our upgraded installations.

The dnf info shows nothing. No error message.