F38 update failed at 97% complete; how to recover?

I did a system update via Gnome Software on a laptop, and the process appeared to hang displaying “97% complete” after about two hours. I left it overnight to try to complete, and when I got up it was still at “97% complete.” Knowing I would probably end up with an unusable system, I powercycled, and after it went through the Grub menu, I saw the message:

error: …/…/grub-core/fs/fshelp.c:257: file ‘/initramfs-6.4.7-200.fc38.x86_64.img’ not found

From Grub, I was able to list the contents of the /boot partition, and that file was not present.

I can boot the F38 Live system from USB. Would it be possible to mount the old system via the Live system, create the initramfs file and be able to boot the computer? If so, what are the steps to take? Is there anything else I would need to do to get this to work again? I could reinstall but I’d like to make that my last resort.

Many thanks.

The way to fix this would be

1.) from a Live environment, chroot into your existing Fedora install

2.) use dnf to reinstall grub2 and latest kernel

There is information on this forum and in the docs on how to it, and I’m happy to provide the relevant links but before it would be important to know …

  • what the file system is used for / and /home (ext4 vs. btrfs) because the mount options differ
  • if you use encrypted devices (lvm, luks, cryptsetup)
  • if your machine uses (U)EFI or legacy BIOS boot.
1 Like

Thanks for the help - some links would be great.

  • / and /home are both on the same btrfs partition but different subvolumes;
  • No device encryption;
  • UEFI booting

It’s an older Macbook Pro that I’ve repurposed, and as I recently bricked an old Mac Mini doing a reinstall, I’d prefer to rebuild from what’s already there.

I appreciate the help!

I did some investigating, and ended up making some progress.

  • booted the live USB stick and mounted /, /home and /boot under /mnt/disk;
  • did a dns reinstall of the kernel package, which failed because I hadn’t mounted /sys, /dev, /proc in the right places;
  • bind mounted those directories and redid the dns reinstall, which seemed to work;
  • booted up (getting rid of graphical boot so I could see what was happening)

and I ended up with the last lines in the boot log being:

[ 5.853128] ACPI Warning: \_SB.PCI0.IXVE.IGPU._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20230331/nsarguments-61)
[ 5.853928] ACPI: \_SB_.PCI0.IXVE.IGPU: failed to evaluate _DSM
[ 5.854570] nouveau 0000:03:00.0: enabling device (0002 → 0003)
[ 5.855437] ACPI: \_SB_.PCI0.LGPU: Enabled at IRQ 22

That’s the end - apparently the boot hangs right after this last message gets printed to the console.

So this is really weird - I haven’t seen anything like it anytime before. I feel like I’m close to getting this working again. Should I try to play around with enabling/disabling ACPI and see what this does?

One needs to mount /, /boot, /boot/efi, and bind mount /proc, /sys, /run, /dev when doing a chroot. /home is usually not required though it is nice to do that as well.

The kernel and grub reinstall would be done with sudo dnf reinstall kernel* grub2*.

Note that the network must be activated before doing the chroot command and it will then be available within the chroot environment.

If the reinstall does not fix the boot issue then one may also (while within the chroot environment) run the command sudo upgrade --refresh to ensure that everything is fully up to date then run sudo dracut --force 6.4.7-200.fc38.x86_64 to build the initramfs file for the current newest kernel.
Please note that when running in a chroot environment from a live usb for fedora 38 it is likely that the running kernel as seen with ‘uname -r’ would be 6.2.9 which is the kernel at the time F38 was released. Thus one must use the desired kernel version when running dracut.