Sudo dnf update gives %posttrans scriptlet error: kernel-modules-0:6.17.10-100.fc41.x86_64

Ask Fedora
, , ,
1

After executing sudo dnf update I got:

Running %posttrans scriptlet: kernel-modules-0:6.17.10-100.fc41.x86_64
Non-critical error in %posttrans scriptlet: kernel-modules-0:6.17.10-100.fc41.x86_64
Scriptlet output:
Running: dracut -f --kver 6.17.10-100.fc41.x86_64
dracut[F]: Can’t write to /boot/efi/022440c38d0445ea8da041e033f4949b/6.17.10-100.fc41.x86_64: Directory /boot/efi/022440c38d0445ea8da041e033f4949b/6.17.10-100.fc41.x86_64 does not exist or is not accessible.

[RPM] %posttrans(kernel-modules-6.17.10-100.fc41.x86_64) scriptlet failed, exit status 1

Here’s some bits of context, recently I solved another issue with the thread: Grub boot menu not showing after enlarging /boot/efi partition and restoring Windows bootloader through bcdboot
After doing that I discovered through the help of the user @vekruse that my kernel was updating and booting through UKI, every sudo dnf update since then went smoothly, I just had to manually recreate the Grub menu partition in EFI and delete all of the others entries (like the windows one and the ones pointing directly to fedora UKI kernels) and I’d just boot into the menu and be chill until next update.

Today I tried updating again and found that I had not enough space in /boot for new kernel (I keep 3 kernels at a time), so I thought I’d remove the 3 debug kernels which I never use to free a lot of space and I ran sudo dnf remove kernel-debug* , posting the error I got to chatgpt he said that this is directly correlated because the kernel still uses UKI boot layout because it’s trying to write to: /boot/efi/022440c38d0445ea8da041e033f4949b/6.17.10-100.fc41.x86_64 which is not normal behaviour in fedora, obviously before trying anything he says I wanted to know from you guys what you think.

I still haven’t rebooted from my current fedora session, my guess is that (after regenerating grub entry and deleting other entries from efibootmgr) booting into older kernel versions will be fine, but the latest one won’t boot, what do you guys think?

3

I don’t think so, because it says:
Figure out if you’re affected by testing for presence of /boot/efi/$machineid. If you get an error, you’re not affected by this issue:

$ sudo ls -d "/boot/efi/$(cat /etc/machine-id)"
ls: cannot access '/boot/efi/<machine-id hash here>': No such file or directory

And I do get the error

4

Try running ls /boot/efi and look at the results. If there is a directory with a name similar to the machine ID this still could be the issue.

5

Nope:

ls /boot/efi
 EFI   loader   mach_kernel   System  'System Volume Information'
ls /boot/efi/EFI
Boot  fedora  Linux  Microsoft

Although in /boot/efi/EFI/Linux there are:

022440c38d0445ea8da041e033f4949b-6.17.10-100.fc41.x86_64.efi	      022440c38d0445ea8da041e033f4949b-6.17.7-100.fc41.x86_64.efi	   022440c38d0445ea8da041e033f4949b-6.17.8-100.fc41.x86_64.efi
022440c38d0445ea8da041e033f4949b-6.17.10-100.fc41.x86_64.efi.extra.d  022440c38d0445ea8da041e033f4949b-6.17.7-100.fc41.x86_64.efi.extra.d  022440c38d0445ea8da041e033f4949b-6.17.8-100.fc41.x86_64.efi.extra.d

In the other thread I was told that this Linux directory is not present in their setup

6

Definitely strange.
Mine is

$ sudo ls /boot/efi
EFI  mach_kernel  System

The loader directory should not be there but should show in /boot as /boot/loader

Also you show extra images there. You should see only something like this

$ sudo ls /boot/loader/entries/
594ece762a4b48678f35f7be2ddf7410-0-rescue.conf		       594ece762a4b48678f35f7be2ddf7410-6.17.11-300.fc43.x86_64.conf
594ece762a4b48678f35f7be2ddf7410-6.17.10-300.fc43.x86_64.conf  594ece762a4b48678f35f7be2ddf7410-6.17.9-300.fc43.x86_64.conf

Is it possible you are using systemd-boot instead of grub?

7

Looks like you still have UKI images there.

1 Like
8

If so, you need to remove all occurrences of the kernel-uki-virt packages using dnf. As long as you have it installed, it will be updated with every kernel update. Run 'rpm -q kernel-uki-virt` to get a list of the installed uki packages.

2 Likes
9

The funny part is that loader is also in /boot, the one in /boot/loader contains the actual entries, the one in /boot/efi/loader contains a file called random-seed

10

Yes indeed the output of rpm -q kernel-uki-virt is:
kernel-uki-virt-6.17.7-100.fc41.x86_64
kernel-uki-virt-6.17.8-100.fc41.x86_64
kernel-uki-virt-6.17.10-100.fc41.x86_64

Should I just dnf remove kernel-uki-virt* in this session?

11 
sudo dnf remove kernel-uki-virt-6.17.7-100.fc41.x86_64 kernel-uki-virt-6.17.8-100.fc41.x86_64 kernel-uki-virt-6.17.10-100.fc41.x86_64
12

Simpler and assured to remove all would be sudo dnf remove kernel-uki-virt* which would then remove all similarly named packages without needing to specify the versions.

I note that you are still using Fedora 41. That version became EOL last month and you probably should consider updating to a currently supported version as soon as possible.

13

If I run this command right now, can I be sure that my current session doesnt use some of the packages that will be removed and therefore will not have problems?

14

As long as you are not using the uki kernel it should just work

15

Do run rpm -qa 'kernel*'. It might show installed kernel packages which you should not have one your system, and which would not have been on your system after the initial install.

The uki packages needs space in /boot/efi and not in /boot regardless what chatgpt says.

These are the uki images.

16

That’s the thing, right now I’m booted from GRUB menu, so can I be sure that my boot is not using the uki kernel? If no, how do I check from which image I am booted on?

17

The uname -r command

18

So since it’s 6.17.8-100.fc41.x86_64 I guess I am safe right?

19

That does not appear to be one of the UKI kernels, so removal of all those should be good.

I might note however that f41 currently seems to have the 6.17.10 kernel available, and that f41 has already reached EOL.

I suggest that you remove the uki kernels as already discussed and then upgrade to a currently supported version of fedora using the method shown here.

20

Ok, now that I removed kernel-uki-virt, shouldn’t I “repair” the installation of 6.17.10 kernel? Like it gave the error which is in the OP, or should I just sudo dnf upgrade --refresh as your link says?

Edit: also now that I see after removing kernel-uki-virt packages and doing ls /boot:
efi initramfs-0-rescue-022440c38d0445ea8da041e033f4949b.img symvers-6.17.10-100.fc41.x86_64.xz vmlinuz-0-rescue-022440c38d0445ea8da041e033f4949b
EFI loader symvers-6.17.7-100.fc41.x86_64.xz
grub2 lost+found symvers-6.17.8-100.fc41.x86_64.xz

the vmlinuz, maps and other stuff are gone, is that normal?

This stuff remained though in /boot/efi/EFI/Linux

21

UPDATE: After I removed the uki kernel packages everything was normal (this afternoon) a few minutes ago though gnome glitched out (or at least I think/hope it was gnome) and bugged the whole UI, i couldn’t start a terminal or nothing and I couldnt switch to TTY, so I forced the computer off with the power button, upon rebooting it boots me directly in windows, no biggie same thing as always efibootmgr puttinf windows as first, when I boot in grub menu through F11 though the linux kernel entries are gone, there remains just the rescue image and Windows entry. How do I proceed?