Issues with updates/upgrades, new kernels no longer added to grub list automatically

Ask Fedora
1

Hi,

a while back I created a tread where I explained issues I had after receiving updates. With the help of the community I was able to apply the proper clean-up however problems persist. (here is the link to the previous tread, Issues booting with FEDORA 43 Kernel 6.18.5 - #12 by diamondgotcat )

Today, as part of the updates I got, kernel 6.18.8-200.fc43.x86_64 should have been applied and should have appeared in my boot loader menu but it wasn’t. After I got the update, I was offered to restart to apply the news changes and the new kernel was not displayed.

I check the lib modules I received and I indeed did get it

❯ls /lib/modules
6.18.7-200.fc43.x86_64 6.18.8-200.fc43.x86_64

So i tried to do this

sudo grub2-mkconfig -o /boot/grub2/grub.cfg

and

sudo dracut --regenerate-all --force

I also noticed that somehow 6.18.3 came back and I did clean that one from there since it was no longer linked to any module…

❯sudo ls -la /boot/loader/entries
total 24
drwx------. 2 root root 4096 Feb 5 09:49 .
drwxr-xr-x. 3 root root 4096 Feb 9 2025 ..
-rw-r--r--. 1 root root 457 Feb 5 09:49 ed3991a0a95240cfb5acb6779334be27-0-rescue.conf
-rw-r--r--. 1 root root 411 Feb 5 09:49 ed3991a0a95240cfb5acb6779334be27-6.18.3-200.fc43.x86_64.conf
-rw-r--r--. 1 root root 411 Feb 5 09:49 ed3991a0a95240cfb5acb6779334be27-6.18.7-200.fc43.x86_64.conf
-rw-r--r--. 1 root root 397 Feb 5 09:49 ed3991a0a95240cfb5acb6779334be27-6.18.8-200.fc43.x86_64.conf

The issue is the kernel should have been listed automatically without me having to do any of this. So I’m trying to understand what is going on. Is anyone else have this issue and is this hiding a bug somewhere that should be fixed?? What the heck is going on?

3

Is there enough free disk space on /boot?
What is the output of lsblk -f?

4

Also worth looking at the output of efibootmgr to see which EFI partition the BIOS is looking at when it boots.

5

Yeah there is enough space there I already checked that before. Look at my updated reply, I think my problem resides there.

6

Yeah this shows the same issue I wrote about in my update but now the question is how to I change those UUID so that /boot and /boot/efi point to the same physical disk.

**❯** sudo efibootmgr 
[sudo] password for tessierp:  
BootCurrent: 0003 
Timeout: 1 seconds 
BootOrder: 0003,0000,0002,0001,0004,0005 
Boot0000* Windows Boot Manager  HD(1,GPT,657514cc-6084-4d53-b23f-f66a50219cc4,0x800,0x32000)/\EFI\Microsoft\Boot\bootmgfw.efi57494e444f5753000100000088000000780000004200430044004f0042004a004500430054003d007b00390064006500610038
003600320063002d0035006300640064002d0034006500370030002d0061006300630031002d006600330032006200330034003400640034003700390035007d00000073690100000010000000040000007fff0400 
Boot0001* UEFI:CD/DVD Drive     BBS(129,,0x0) 
Boot0002  Fedora        HD(1,GPT,19002768-2163-4b1b-91dd-eedf370f3561,0x800,0x12c000)/\EFI\fedora\shimx64.efi 
Boot0003* Fedora        HD(1,GPT,d8042598-1ee1-4b72-8bc6-15130f8f91f6,0x800,0x12c000)/\EFI\fedora\shimx64.efi0000424f 
Boot0004* UEFI:Removable Device BBS(130,,0x0) 
Boot0005* UEFI:Network Device   BBS(131,,0x0)
7

I thought I would recopy this at the end since you guys replied before I could…

I think i finally may have figured out what happened… Recently I moved from a 2 TB to a 4 TB.. I left the 2 TB in my system just in case something would go wrong.. What I forgot to take into account is that the cloning process would also keep the same UUID for the partitions…

Here is what I get with lsblk

❯sudo lsblk
[sudo] password for tessierp:
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sda 8:0 0 1.8T 0 disk
└─sda1 8:1 0 1.8T 0 part
sdb 8:16 0 1.8T 0 disk
└─sdb1 8:17 0 1.8T 0 part
sdc 8:32 0 1.8T 0 disk
└─sdc1 8:33 0 1.8T 0 part /mnt/linux_data
sdd 8:48 1 0B 0 disk
zram0 251:0 0 8G 0 disk [SWAP]
nvme2n1 259:0 0 3.6T 0 disk
├─nvme2n1p1 259:1 0 600M 0 part
├─nvme2n1p2 259:2 0 2G 0 part /boot
├─nvme2n1p3 259:3 0 65G 0 part [SWAP]
└─nvme2n1p4 259:4 0 3.6T 0 part /
nvme0n1 259:5 0 1.8T 0 disk
├─nvme0n1p1 259:6 0 100M 0 part
├─nvme0n1p2 259:7 0 16M 0 part
├─nvme0n1p3 259:8 0 1.8T 0 part
├─nvme0n1p4 259:9 0 731M 0 part
└─nvme0n1p5 259:10 0 674M 0 part
nvme1n1 259:11 0 1.8T 0 disk
├─nvme1n1p1 259:12 0 600M 0 part /boot/efi
├─nvme1n1p2 259:13 0 2G 0 part
├─nvme1n1p3 259:14 0 65G 0 part
└─nvme1n1p4 259:15 0 1.8T 0 part

So my old M.2 SSD is on NVME1N1 while my new one is on NVME2N1. Now if I do this

❯ sudo blkid

/dev/nvme0n1p5: BLOCK_SIZE=“512” UUID=“3EFABB2AFABADD79” TYPE=“ntfs” PARTUUID=“17b786ab-7ad3-4879-b3d5-0183d9af2232” /dev/nvme0n1p3: LABEL=“Windows” BLOCK_SIZE=“512” UUID=“044477BA4477ACD4” TYPE=“ntfs” PARTLABEL=“Basic data partition” PARTUUID=“a60fa095-fcb6-4aec-995b-7ac39eb4fc5e” /dev/nvme0n1p1: LABEL_FATBOOT=“SYSTEM” LABEL=“SYSTEM” UUID=“044F-83AB” BLOCK_SIZE=“512” TYPE=“vfat” PARTLABEL=“EFI system partition” PARTUUID=“657514cc-6084-4d53-b23f-f66a50219cc4” /dev/nvme0n1p4: BLOCK_SIZE=“512” UUID=“2ED09DEAD09DB893” TYPE=“ntfs” PARTUUID=“9aed042f-0907-4b38-ad04-e300b9b9f8aa” /dev/sdb1: LABEL=“Windows Games” BLOCK_SIZE=“512” UUID=“01DAD4AE10418BA0” TYPE=“ntfs” PARTLABEL=“Basic data partition” PARTUUID=“ce200d84-62e7-4e8b-99db-210d1655c939” /dev/nvme2n1p4: LABEL=“fedora” UUID=“b538ad6d-af9b-4609-b05e-5f1591d3195e” UUID_SUB=“975497db-5e10-479f-8a0d-a750167cc351” BLOCK_SIZE=“4096” TYPE=“btrfs” PARTUUID=“07d5caaf-f8a8-4f32-ac29-a70d1cb086de” /dev/nvme2n1p2: UUID=“97c7eb90-9bec-476c-83c1-997c3a836aab” BLOCK_SIZE=“4096” TYPE=“ext4” PARTUUID=“14544b8d-43dd-43bb-9a76-cd314d07a9ed” /dev/nvme2n1p3: UUID=“9263553e-d882-4f57-8afb-d9a2762bcfd9” TYPE=“swap” PARTUUID=“145416e2-3d3a-4e62-842b-3f1aa9ecbfd9” /dev/nvme2n1p1: UUID=“C536-244B” BLOCK_SIZE=“512” TYPE=“vfat” PARTLABEL=“EFI System Partition” PARTUUID=“d8042598-1ee1-4b72-8bc6-15130f8f91f6” /dev/sdc1: LABEL=“Linux Data” UUID=“7a8a4cdf-7200-41d1-9093-73e09c31a13a” UUID_SUB=“21bb96dc-303b-4377-a3d7-37e8b4947d71” BLOCK_SIZE=“4096” TYPE=“btrfs” PARTUUID=“a471403f-0523-4044-8d36-00b41cfecc18” /dev/nvme1n1p4: LABEL=“fedora” UUID=“b538ad6d-af9b-4609-b05e-5f1591d3195e” UUID_SUB=“975497db-5e10-479f-8a0d-a750167cc351” BLOCK_SIZE=“4096” TYPE=“btrfs” PARTUUID=“6c21c3a1-a487-47a0-8b6c-0e5760610d57” /dev/nvme1n1p2: UUID=“97c7eb90-9bec-476c-83c1-997c3a836aab” BLOCK_SIZE=“4096” TYPE=“ext4” PARTUUID=“5f82c95c-85f4-45cd-b97a-69f9e8e6c9c2” /dev/nvme1n1p3: UUID=“9263553e-d882-4f57-8afb-d9a2762bcfd9” TYPE=“swap” PARTUUID=“6c74a855-b000-4238-97ce-12a2395120ac” /dev/nvme1n1p1: UUID=“C536-244B” BLOCK_SIZE=“512” TYPE=“vfat” PARTLABEL=“EFI System Partition” PARTUUID=“19002768-2163-4b1b-91dd-eedf370f3561” /dev/sda1: LABEL=“User Data” BLOCK_SIZE=“512” UUID=“01DA015CD36547A0” TYPE=“ntfs” PARTUUID=“0001a19a-01” /dev/zram0: LABEL=“zram0” UUID=“1a61d0cd-1db0-4c1c-a0c4-70f0028bae4e” TYPE=“swap” /dev/nvme0n1p2: PARTLABEL=“Microsoft reserved partition” PARTUUID=“8f83397e-0729-4ea7-a65d-1da5021e0664”

So I see that /boot/efi is using my OLD M.2 SSD.

And look at what I have in /etc/fstab

UUID=b538ad6d-af9b-4609-b05e-5f1591d3195e / btrfs subvol=root,compress=zstd:1 0 0 UUID=97c7eb90-9bec-476c-83c1-997c3a836aab /boot ext4 defaults 1 2 UUID=C536-244B /boot/efi vfat umask=0077,shortname=winnt 0 2 UUID=9263553e-d882-4f57-8afb-d9a2762bcfd9 none swap defaults 0 0 UUID=7a8a4cdf-7200-41d1-9093-73e09c31a13a /mnt/linux_data btrfs defaults,noatime 0 0

So /boot/efi is using UUID C536-244B. All the UUIDs are the same on nvme1n1 and nvme2n1. I think this may explain a few things.. So I guess I have two choices. So my question is.. How to I change the UUID of a drive and how do I do this so that it goes smoothly and I then update /etc/fstab.. Any recommendation on how to proceed?

8

Well, it demonstrates one additional thing, i.e. that the default boot entry Boot0003 points to the EFI partition on nvme2n1. (i.e. not the one that’s mounted at /boot/efi).

If you need to retain copies of the partitions, it would be easier to change the UUIDs on the old disk (nvme1n1), so no /etc/fstab change would be needed.

Also delete that Boot0002 entry with efibootmgr -B 0002 so the only Fedora boot entry is the one pointing to nvme2n1’s EFI partition.

Or, if the old drive is there “in case of something going wrong”, take it out and keep it somewhere safe until you are happy all is well on your new drive. Is that an option?

9

Changing the UUIDs on the old disk would be the ideal solution but not sure how to go about doing this.. but one thing I’m sure is I’ll probably have to do this by using a rescue disk and editing the partitions.. how should I proceed? And once I’m done, I guess I will suddenly find myself with a /boot/efi that i out of date, should I expect any problems?

10

Boot0002 points to my new disk, if I do that it will go to the old one.

11

As noted Just change the UUID of the “old” partition you don’t want to use so you don’t need to change your fstab. I would do this using a Live USB so you can verify the changes before trying to boot Fedora.

https://itsfoss.gitlab.io/post/how-to-change-uuid-of-partition-in-linux-filesystem/. You can use command-line tools with a Fedora installer or the gparted GUI: https://gparted.org/liveusb.php.

12

Yes, doing it from a live USB is the best way.

tune2fs will handle the ext4 partitions.

For the EFI partition (vfat format) it’s awkward from the command line, but the gparted GUI can do it. I’m not sure whether the Fedora Workstation live ISO has gparted, but you could sudo dnf install gparted within the live session, or use some other distro’s live ISO if you like. SystemRescue is often useful for these things.

I don’t think so. As far as Fedora is concerned, /boot/efi contains:

  • GRUB binaries which change rarely
  • A very simple GRUB config file which just points to the /boot partition to get the “real” GRUB config. It references it by UUID, so the strategy of changing the UUIDs on the old disk should mean the correct partition on the new disk is referenced without needing to change anything.
13

Just updating on this.. Boot0002 points to the right disk while Boot0003 seems to point to my old disk and that is the recues boot entry… how can I update that? Or should I wait until I change my UUIDs on the old drive? Or could I simply just nuke the SSD is I don’t need it?

14

It points to your old disk - note the 19002768... partition UUID.

Boot0002  Fedora        HD(1,GPT,19002768-2163-4b1b-91dd-eedf370f3561,0x800,0x12c000)/\EFI\fedora\shimx64.efi 

/dev/nvme1n1p1: UUID=“C536-244B” BLOCK_SIZE=“512” TYPE=“vfat” PARTLABEL=“EFI System Partition” PARTUUID=“19002768-2163-4b1b-91dd-eedf370f3561”
15

Oh yes, by far the easiest solution!

16

Yeah I think I’ll do that then … So I guess I should nuke the SSD from my current session… and should I update grub2-config again?? Just want to make sure I don’t mess up anything.

17

Yeah but that is my old disk, you see the 1.8T total 2TB for that drive.

image
image550×316 31.8 KB

18

Personally I would deliver the nuke from a live USB session.

There is some subtlety around what disk data is cached and what is truly fresh. If you do your nuke within the session, then different Linux commands may have different views on which partitions still exist, and that particularly might mess up your GRUB update in terms of /boot/efi.

19

Yes, I said “old disk” :grinning_face:

20

Probably the safest bet.. OK I’ll do that… Hopefully all goes OK.

1 Like
21

My bad lol