I should not clean off my desk. I had the instructions. Now…
The upgrade to F38 went fine - everything looks good. However, the rescue image is still showing f36 (or 35). I vaguely recall deleting something in the /boot folder the last time this happened - likely candidates are initramfs-0-rescue???.img and vmlinuz-0-rescue???
Is there anything else?
About Rescue Mode in Fedora tells all. There are some preliminary steps that should be checked to avoid problems before deleting those files.
sudo rm -f /boot/*-rescue-*
sudo kernel-install add $(uname -r) /lib/modules/$(uname -r)/vmlinuz
Avoid reinstalling the latest kernel since there’s a bug that can break it:
Depmod warning, missing files in /lib/modules/kernel* when running dracut - #6 by vgaetera
Since the command I suggested for reinstall includes all the latest kernel-* related rpm files, are you saying that there are some module files missing from the suite?
Also, since I’ve done this after every update since at least f32 with no apparent problems, are you saying this is never a good way to do it?
Of course, there is another option, which works if you default to the y/N query at dnf update time: Wait until a kernel update appears, deny the update, use grubby to delete the old rescue kernel, then go back and do the update. Any kernel update for which a rescue kernel isn’t present will create one for the current version for fedora.
Thanks, as always, for your info on this!
john
Reinstalling the kernel is possible, but starting with the kernel version 6.2 there’s a bug, which is not fixed yet, in addition using sudo to declare a variable/array is wrong.
Both great points! Thanks!
I think that I fixed that now in my post.
I still find this to be the most intuitive way to update the rescue kernel after a system upgrade, besides deleting it prior an to an actual kernel update.
I remember something similar to the first line you have - just remove anything named rescue. After that I rebooted and a new rescue image was created. I don’t recall doing anything with the kernel or modules, but this was some time ago. I’m not looking to upgrade the previous kernel versions that show at boot - just the rescue image.
I confirm this works. Didn’t bother to update mine for a long time 
@jrredho As I understand it, reinstalling kernel triggers a post-transaction script that does the same kernel-install add ... as above. So your method has the same outcome, but in a roundabout way.
TL;DR Don’t use the method that I proposed to accomplish this. It doesn’t work; I’ve deleted the post. Use the @vgaetera method.
I’m glad that you followed up, because I can confirm that, while the method that I’ve been using to do this creates a grub2 rescue boot target, the resulting target doesn’t work! I’ve deleted my suggestion.
I don’t know exactly what the problem is, but when I tried to boot the one that I generated, it failed with a FATAL dracut error. 
I have never had the need in the past to boot one of these, so I had never tried it before now. I’m really glad that this discussion led me to do that before I had a real need for it.
My guess is that the corresponding initramfs requires more modules be loaded than are available to the rescue kernel; maybe @vgaetera can straighten me out on that point.
Thanks everyone!
This seems fixed with kernel 6.4.4, see Commit - rpms/kernel - 05344083c3335a010ac0ca4bd9f3f222750cfa05 - src.fedoraproject.org
I’ve already commented on the ticket, but I’m not the owner, so I cannot close it:
https://bugzilla.redhat.com/show_bug.cgi?id=2173984#c7
Also consider that the rescue kernel after a while no longer have the modules found in /usr/lib/modules available. It then needs to run with the ones baked into the rescue initrd file.
If would be good idea to test that it still works if you want to rely on it.
If the hardware hasn’t changed, one of the older kernels should still boot. For me, the rescue kernel is needed when you add new hardware or replaced failed hardware with a different model, so the common use case has “known unknowns” and is not easy to test.
I just tried to boot the rescue images, and It got stuck in rescue mode where I had to type in the root password to do anything useful.
Running journalctl -b -p err gave this.
Sep 10 20:14:55 fedora kernel: RETBleed: WARNING: Spectre v2 mitigation leaves CPU vulnerable to RETBleed attacks, data leaks possible!
Sep 10 20:14:55 fedora systemd[1]: Invalid DMI field header.
Sep 10 20:14:56 fedora kernel: vmwgfx 0000:00:02.0: [drm] *ERROR* vmwgfx seems to be running on an unsupported hypervisor.
Sep 10 20:14:56 fedora kernel: vmwgfx 0000:00:02.0: [drm] *ERROR* This configuration is likely broken.
Sep 10 20:14:56 fedora kernel: vmwgfx 0000:00:02.0: [drm] *ERROR* Please switch to a supported graphics device to avoid problems.
Sep 10 20:15:09 fedora systemd[1]: Invalid DMI field header.
Sep 10 20:15:09 fedora (sd-execu[887]: /usr/lib/systemd/system-generators/zram-generator failed with exit status 1.
Sep 10 20:15:09 fedora systemd[1]: systemd-journald-audit.socket: Socket service systemd-journald.service already active, refusing.
Sep 10 20:15:09 fedora systemd[1]: Failed to listen on systemd-journald-audit.socket - Journal Audit Socket.
Sep 10 20:15:09 fedora systemd-modules-load[939]: Failed to find module 'fuse'
Sep 10 20:15:09 fedora systemd-modules-load[939]: Failed to find module 'msr'
Sep 10 20:15:09 fedora systemd-modules-load[939]: Failed to find module 'fuse'
Sep 10 20:15:09 fedora systemd-modules-load[939]: Failed to find module 'ip_tables'
Sep 10 20:15:09 fedora systemd-modules-load[939]: Failed to find module 'ip6_tables'
Sep 10 20:15:10 fedora (udev-worker)[996]: vboxguest: /usr/lib/udev/rules.d/60-vboxguest.rules:1 Only network interfaces can be renamed, ignoring NAME="vboxguest".
Sep 10 20:15:10 fedora (udev-worker)[978]: vboxuser: /usr/lib/udev/rules.d/60-vboxguest.rules:2 Only network interfaces can be renamed, ignoring NAME="vboxuser".
Sep 10 20:15:10 fedora systemd[1]: Failed to mount boot-efi.mount - /boot/efi.
Sep 10 20:15:10 fedora systemd[1]: Failed to mount proc-sys-fs-binfmt_misc.mount - Arbitrary Executable File Formats File System.
Sep 10 20:15:10 fedora systemd-binfmt[1076]: Failed to check if /proc/sys/fs/binfmt_misc is mounted: No such device
Sep 10 20:15:10 fedora systemd[1]: Failed to start systemd-binfmt.service - Set Up Additional Binary Formats.
Sep 10 20:15:54 fedora systemd[1]: Timed out waiting for device dev-zram0.device - /dev/zram0.
I still think it is a good idea to just check if it works.
This worked also for me, the default rescue kernel entered in to a text login.
The new one is a graphical one.
So I guess I could do this wihle starting grub hitting ESC, right? Just if I would use it temporary.
(I do have a blinking screen where not let me press Ctrl & Alt & F1.
I had to login via ssh from my other computer.)
Yes, this is explained in the Fedora documentation and applies to any kernel:
Working with the GRUB 2 Boot Loader: Booting to Rescue/Emergency Mode
You can as well make it permanent for the rescue kernel:
sudo grubby \
--update-kernel="/boot/vmlinuz-0-rescue-$(cat /etc/machine-id)" \
--remove-args="rhgb quiet" --args="systemd.unit=rescue.target"