Where is this coming from? There is nothing in %post that calls kdump at all on a typical system, so it is likely something in /etc/kernel/* but I do have kexec-tools installed and still do not see an entry.

I don't have the slightest idea where it's coming from.


# find /etc/kernel/
/etc/kernel/
/etc/kernel/postinst.d
/etc/kernel/install.d

Interesting.  The kernel itself only calls kernel-install as the post. That goes through the /etc/kernel directories for plugins (dkms uses this), but I see no reference to kdump in kernel-install, nor do I see one in dracut. What is your kernel command line?

Upon doing a Google search for "kdump: kernel 5.17.8-300.fc36.x86_64 doesn't exist" I got this page which includes a reference to "kdump: kernel 5.17.6-300.fc36.x86_64 doesn't exist".

https://forums.fedoraforum.org/showthread.php?328435-After-33-gt-35-36-upgrades-still-using-33-kernel&p=1859062

Oh, and an adjacent reference to 5.17.5 as well, suggesting that wherever this is coming from is not version-specific.

$ cat /proc/cmdline 
initrd=\cde44f2e256c4d7f816b58632df8afa1\5.17.7-300.fc36.x86_64\initrd root=UUID=126898db-f61b-402b-a9ca-4442b79f41a4 ro rhgb quiet rd.lvm=0 rd.luks=0 rd.md=0 rd.dm=0 resume=PARTUUID=ef7284ab-13f9-4698-9555-33fab31dc6c6 intel_iommu=on video=VGA-1:d

In case these are relevant.

I'm not using GRUB (2), I'm using systemd.

# rpm -q -a | fgrep kernel | sort
abrt-addon-kerneloops-2.15.1-1.fc36.x86_64
kernel-core-5.17.7-300.fc36.x86_64
kernel-core-5.17.8-300.fc36.x86_64
kernel-headers-5.17.6-300.fc36.x86_64
kernel-modules-5.17.7-300.fc36.x86_64
kernel-modules-5.17.8-300.fc36.x86_64
kernel-modules-extra-5.17.7-300.fc36.x86_64
kernel-modules-extra-5.17.8-300.fc36.x86_64
kernel-srpm-macros-1.0-14.fc36.noarch
kernel-tools-5.17.6-300.fc36.x86_64
kernel-tools-libs-5.17.6-300.fc36.x86_64
libreport-plugin-kerneloops-2.17.1-1.fc36.x86_64
python3-ipykernel-6.6.1-2.fc36.noarch

`dnf check` does not complain.

# rpm -V -a | tee /tmp/rpm-V-a
.M.......    /boot/efi/EFI
.M.......  g /usr/share/icons/Humanity-Dark/icon-theme.cache
.M.......  g /usr/share/icons/Humanity/icon-theme.cache
S.5....T.  c /etc/security/access.conf
.M.......    /var/lib/AccountsService/icons
S.5....T.  c /var/lib/unbound/root.key
S.5....T.  c /etc/sudoers
.M.......  g /var/lib/colord/mapping.db
.M.......  g /var/lib/colord/storage.db
S.5....T.  c /etc/sysconfig/lm_sensors
.M.......  g /var/lib/plymouth/boot-duration
.M...UG..  g /run/lightdm
..5....T.  c /etc/yum.repos.d/google-chrome.repo
S.5....T.  c /root/.bash_profile
SM5....T.  c /root/.bashrc
.M.......  g /etc/udev/hwdb.bin
.M.......  g /var/lib/systemd/random-seed
.M.......  g /var/lib/selinux/targeted/active/modules/200/smartmon
S.5....T.  c /etc/dhcp/dhcpd.conf
.M.......  g /etc/containers/storage.conf
.......T.    /boot/efi/EFI/efifs/bfs.efi
.......T.    /boot/efi/EFI/efifs/btrfs.efi
.......T.    /boot/efi/EFI/efifs/cpio.efi
.......T.    /boot/efi/EFI/efifs/cpio_be.efi
.......T.    /boot/efi/EFI/efifs/ext2.efi
.......T.    /boot/efi/EFI/efifs/fat.efi
.......T.    /boot/efi/EFI/efifs/hfs.efi
.......T.    /boot/efi/EFI/efifs/iso9660.efi
.......T.    /boot/efi/EFI/efifs/minix.efi
.......T.    /boot/efi/EFI/efifs/minix2.efi
.......T.    /boot/efi/EFI/efifs/minix_be.efi
.......T.    /boot/efi/EFI/efifs/ntfs.efi
.......T.    /boot/efi/EFI/efifs/odc.efi
.......T.    /boot/efi/EFI/efifs/procfs.efi
.......T.    /boot/efi/EFI/efifs/squash4.efi
.......T.    /boot/efi/EFI/efifs/udf.efi
.......T.    /boot/efi/EFI/efifs/ufs1.efi
.....UG..  g /var/lib/nfs/statd/state
.M.......  g /run/libvirt/common
.M...UG..  g /run/libvirt/qemu/dbus
.....UG..  g /run/libvirt/qemu/slirp
S.5....T.  c /etc/dnf/dnf.conf
S.5....T.  c /etc/environment
S.5....T.  c /etc/samba/smb.conf
S.5....T.  c /etc/selinux/targeted/contexts/files/file_contexts.local

I installed kernel-5.17.8-300.fc36.x86_64 in F36 with kexec-tools installed and did not see this message.

# find /etc/kernel/
/etc/kernel/
/etc/kernel/install.d
/etc/kernel/install.d/dkms
/etc/kernel/postinst.d
/etc/kernel/postinst.d/dkms
/etc/kernel/prerm.d
/etc/kernel/prerm.d/dkms

(In reply to Cristian Ciupitu from comment #7)
> In case these are relevant.
> 
> I'm not using GRUB (2), I'm using systemd.
> 
> # rpm -q -a | fgrep kernel | sort
> abrt-addon-kerneloops-2.15.1-1.fc36.x86_64
> kernel-core-5.17.7-300.fc36.x86_64
> kernel-core-5.17.8-300.fc36.x86_64
> kernel-headers-5.17.6-300.fc36.x86_64
> kernel-modules-5.17.7-300.fc36.x86_64
> kernel-modules-5.17.8-300.fc36.x86_64
> kernel-modules-extra-5.17.7-300.fc36.x86_64
> kernel-modules-extra-5.17.8-300.fc36.x86_64
> kernel-srpm-macros-1.0-14.fc36.noarch
> kernel-tools-5.17.6-300.fc36.x86_64
> kernel-tools-libs-5.17.6-300.fc36.x86_64
> libreport-plugin-kerneloops-2.17.1-1.fc36.x86_64
> python3-ipykernel-6.6.1-2.fc36.noarch

Just noticed something odd, you don't appear to actually have kernel-5.17.8-300.fc36.x86_64 installed. On my machines, for each installed kernel version I have a (0-byte) package named kernel. And if I attempt to remove them with dnf, it's allowed (though I didn't actually do it), so not sure what their purpose is.

$ rpm -q kernel
kernel-5.17.6-300.fc36.x86_64
kernel-5.17.7-300.fc36.x86_64
kernel-5.17.8-300.fc36.x86_64

Yeah, you're right. I've removed the plain kernel package from my system long time ago after noticing that it's empty anyway.

Anyway for what it's worth I had the same problem with kernel-core-5.17.9-300.fc36.x86_64.

Also in the mean time I've upgraded more packages and I have also rebooted the system.
After booting into 5.17.9-300.fc36.x86_64 I rerun `dnf install kernel-core-5.17.8-300.fc36.x86_64` and there were no issues.
I run the command multiple times and still no issues, so I guess the issue is sort of solved (though something fishy is or was going on).

I'm guessing the 0-byte package is there to make it easy for applications to check if a kernel is installed (jforbes, is that true?). In any case, regardless of where your kdump message is coming from, it's literally true, if it's referring to that specific package.

I tried removing the 0-byte kernel package for one of my kernels and then reinstalling the corresponding kernel-core and was not able to trigger that message, though.

It happened again today. I booted 5.17.9-300.fc36.x86_64 (according to `uname -r`) then I run

    # dnf upgrade

    Downloading Packages:
    Running transaction check
    Transaction check succeeded.
    Running transaction test
    Transaction test succeeded.
    Running transaction
      Preparing        :                                               1/1 
      Installing       : kernel-core-5.17.11-300.fc36.x86_64           1/3 
      Running scriptlet: kernel-core-5.17.11-300.fc36.x86_64           1/3 
      Installing       : kernel-modules-5.17.11-300.fc36.x86_64        2/3 
      Running scriptlet: kernel-modules-5.17.11-300.fc36.x86_64        2/3 
      Installing       : kernel-modules-extra-5.17.11-300.fc36.x86_64  3/3 
      Running scriptlet: kernel-modules-extra-5.17.11-300.fc36.x86_64  3/3 
      Running scriptlet: kernel-core-5.17.11-300.fc36.x86_64           3/3 
    kdump: kernel 5.17.11-300.fc36.x86_64 doesn't exist
    
      Running scriptlet: kernel-modules-5.17.11-300.fc36.x86_64        3/3 
      Running scriptlet: kernel-modules-extra-5.17.11-300.fc36.x86_64  3/3 
      Verifying        : kernel-core-5.17.11-300.fc36.x86_64           1/3 

If I uninstall kexec-tools, then uninstall the new kernel and reinstall the new kernel, there's no error message.

After some debugging I think there is a bug in the  _find_kernel_path_by_release function  from  /usr/bin/kdumpctl

	local _release="$1" _grubby_kernel_str _kernel_path
	_grubby_kernel_str=$(grubby --info ALL | grep "^kernel=.*$_release")
	_kernel_path=$(_filter_grubby_kernel_str "$_grubby_kernel_str")
	if [[ -z $_kernel_path ]]; then
		derror "kernel $_release doesn't exist"
		return 1
	fi
	echo -n "$_kernel_path"

I'm using systemd-boot instead of GRUB because it does enough for me. The kernel is installed on /boot/efi of course.

I run `grubby --info ALL` separately and it doesn't print anything.

This is what I have installed:

  grub2-common-2.06-40.fc36.noarch          
  grub2-efi-x64-modules-2.06-40.fc36.noarch
  grub2-tools-2.06-40.fc36.x86_64
  grub2-tools-efi-2.06-40.fc36.x86_64
  grub2-tools-extra-2.06-40.fc36.x86_64
  grub2-tools-minimal-2.06-40.fc36.x86_64
  grubby-8.40-57.fc36.x86_64
  systemd-250.6-1.fc36.x86_64
  systemd-bootchart-233-11.fc36.x86_64
  systemd-container-250.6-1.fc36.x86_64
  systemd-libs-250.6-1.fc36.x86_64
  systemd-networkd-250.6-1.fc36.x86_64
  systemd-oomd-defaults-250.6-1.fc36.noarch
  systemd-pam-250.6-1.fc36.x86_64
  systemd-resolved-250.6-1.fc36.x86_64
  systemd-rpm-macros-250.6-1.fc36.noarch
  systemd-udev-250.6-1.fc36.x86_64

Either way, sounds very much like a kexec-tools issue, and not a kernel issue. Reassigning.

It's still happening with kexec-tools-2.0.24-4.fc36.x86_64

Not sure if it's related, but I'm also getting this error after getting rid of grubby because I don't need it (sd-boot FTW) and reinstalling kexec-tools-2.0.24-4.fc36.x86_64.rpm:
    
      Running scriptlet: kexec-tools-2.0.24-4.fc36.x86_64        5/5 
    /bin/kdumpctl: line 1393: grubby: command not found

I was talking about bug #2121912

This message is a reminder that Fedora Linux 36 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora Linux 36 on 2023-05-16.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
'version' of '36'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, change the 'version' 
to a later Fedora Linux version. Note that the version field may be hidden.
Click the "Show advanced fields" button if you do not see it.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora Linux 36 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora Linux, you are encouraged to change the 'version' to a later version
prior to this bug being closed.

This bug appears to have been reported against 'rawhide' during the Fedora Linux 39 development cycle.
Changing version to 39.