[Solved] F44: I seem to have borked the rescue kernel. Does anyone know how to fix?

Ask Fedora
, ,
1

Hi,

I’m updating machines to F44. So far it’s been great, no problems at all. On the machine I’m using right now I seem to have borked upgrading the rescue kernel (it was F38!). I’m getting the following:

sudo kernel-install add “$(uname -r)” “/lib/modules/$(uname -r)/vmlinuz”
dracut-install: ERROR: could not locate dependency libsystemd-shared-258.7-1.fc43.so requested by ‘/var/tmp/dracut.dSdeNt5/initramfs/usr/lib64/systemd/libsystem
d-core-258.7-1.fc43.so’
xargs: /usr/lib/dracut/dracut-install: exited with status 255; aborting
dracut[F]: Resolving executable dependencies failed

I think I went a bit overboard cleaning up with autoremove, symlink removal et al. I’ve checked that libsystemd-shared-258.7-1.fc43.so exists, is on the path, and that its 1st level dependencies all exist (ldd). It still fails.

Does anyone know how to troubleshoot this and get back to a good situation?

I haven’t had any problems with installing a rescue kernel previously. I let this one get stale but I that’s not the issue as the old files are deleted already. I feel certain that I blew away something from F43 that I shouldn’t have before I attempted creating the new rescue kernel, but don’t know what (I have copied the old versions but I’m not sure if I should try running a F38 kernel on a F44 build).

As usual, I googled and checked this forum/wiki before creating a topic.

Any help gladly received (although, TBF, I’ve not had to resort to a rescue kernel in 5 or so years of daily driving Fedora, across multiple desktops and laptops).

Thanks!

[ETA] Searched the output of lddtree -a libsystemd-shared-258.7-1.fc43.so and every dependent library in /lib64 exists, probably unsurprisingly.

2

If you run the command sudo rm /boot/*rescue* it will remove the existing rescue kernel and initramfs image.
Then when you successfully install a new kernel it should automatically create a new rescue kernel.

3

Thanks. I did that before attempting to build the new rescue kernel and initramfs (basically following the standard Fedora upgrade document). I’ve done this several times before, this is the first time I’ve had a problem. Like I say, I think I probably inadvertently “cleaned up” something a bit too enthusiastically, but I don’t know what.

I put the old rescue kernels back, just in case, and because GRUB wasn’t updated with anything new, after I’d made several attempts to get the F44 rescue kernel & initramfs installed.

The errors I documented were after cleaning out the previous rescue kernel & initramfs.

I did the usual reboot & re-sync with dnf update etc. but nothing worked so far.

4

This library should not exist on F44, in favor of libsystemd-shared-259.5-1.fc44.so
from the RPM: systemd-shared.x86_64 259.5-1.fc44 fedora

One should suspect thus that the upgrade to F44 is partial.
What gives for example:

dnf list systemd-shared --installed
dnf repoquery --duplicates
dnf check

rpm -qa | grep -c fc44
rpm -qa | grep -c fc43
rpm -qf /usr/lib64/systemd/libsystemd-core-258.7-1.fc43.so

uname -r
ls -1 /boot/vmlinuz*
5

It would seem that more than just my rescue kernel is borked:

dnf check

Check discovered 5358 problem(s) in 5306 package(s)

dnf list systemd-shared --installed

Installed packages (available for reinstall, available for upgrade)
systemd-shared.x86_64 258.7-1.fc43
systemd-shared.x86_64 259.5-1.fc44

rpm -qf /usr/lib64/systemd/libsystemd-core-258.7-1.fc43.so

systemd-258.7-1.fc43.x86_64

uname -r

7.0.9-102.fc43.x86_64

ls -1 /boot/vmlinuz*

/boot/vmlinuz-0-rescue-47e6ab8c092a4c969b5d1b319be69c85
/boot/vmlinuz-6.17.9-300.fc43.x86_64
/boot/vmlinuz-7.0.9-102.fc43.x86_64

The system seems to believe it’s running Fedora 44 via system settings & /etc/os-release but it appears I’ve managed to end up with some sort of half-43, half-44 FrankenFedora (at least as far as on-disk resources).

It would seem that virtually every library is a F43 & F44 duplicate.

dnf repoquery --duplicates | wc -l

5306

I originally said that my F44 upgrades had gone great (this is the 4th, with a few more to go). I haven’t checked the others yet but this is the first time in a series of Fedora upgrades (from 34 IIRC) that has caused an issue like this that I’m aware of. Installing rescue kernels hasn’t until now surfaced a problem, but it’s looking like just the rescue kernel isn’t my issue.

Beyond a clean re-install, is there a straightforward way out of this (without deleting all the fc43 files that I can find!)

Thanks.

I’m now going to check my other upgraded F44 installations to see if there’s anything similar going on.

6

I’ve checked the other systems I upgraded from F43 to F44 recently and they’re clean.

I followed the same directions (& journaled it!) contained in Upgrading Fedora Linux Using DNF System Plugin on all systems, so I don’t know what is different about the one upgrade that left me with a sort of superposition of F43 & F44. Some spooky action at a short distance?

Ah, hang on. I just remembered: the problem machine failed to properly reboot after upgrading. The debug LED on the motherboard was incessantly cycling between telling me it couldn’t find any memory and that the processor didn’t exist! (MSI B550 Unify; it’s always been rock solid for the past 4 years). I left it for the best part of an hour before deciding it wasn’t going to recover and hard cycled it. I presumed it was a hardware boot glitch. And now I have the FrankenFedora. The usual high-level indicators - system settings & /etc/os-release - on successfully booting the system led me to believe that it had upgraded to F44 like the others.

I presume a backup and clean reinstall is in order? dnf thinks everything is OK, but it probably thinks that it’s synced to F43: the 7.0 kernel suggests the system is still mainly F43 - 7.0.9-102.fc43.x86_64.

7

Thanks to @pg-tips who linked this topic to Can’t boot after update initramfs image missing I followed this instruction:

sudo dnf distro-sync \
    --refresh \
    --releasever=44 \
    --allowerasing \
    --skip-broken \
    --setopt=protected_packages=

And that, at least, has cleared up all the duplicates. The system, including dnf, appears to believe it’s F44, although the 7.0 kernel is still show fc43. dnf doesn’t think anything needs updating and that I’m already on F44.

Now to try updating the rescue kernel…

8

OK, I’m closing this as solved.

The system is clean, I have a new (alleged) F44 rescue kernel & initramfs (using right now but uname -r still comes back with 7.0.9-102.fc43.x86_64 for both mainline and rescue kernels).

My other systems have a 7.0 kernel that is designated fc44. I presume that will get fixed with the next kernel update (or there’s always the usual kernel.org alternatives).

Thanks to @francismontagnac for pointing me in the right direction and @pg-tips for putting me onto the command to clean up a partially upgraded system. I’ve learned some more about dnf along the way. As “Big Chris” in Lock, Stock, And Two Smoking Barrels said, “it’s been emotional.”

9

Shout out to @vgaetera also for the dnf command in the topic linked by @pg-tips.

10

That f43 kernel is installed and is essentially the same as the f44 kernel.

You might try to install the f44 kernel with sudo dnf upgrade kernel-*7.0.9* --releasever=44 --refresh

11

Thanks, that was the next command I was looking for.

12

If you don’t see fc44 kernels in the grub menu after that, one may suspect also:

Then, post the output of ls -lR /boot

13

All good now, thanks.