Closed aafeijoo-suse closed 1 year ago
Hi,
thanks for your kdump patches.
I also came across this. My fix (which I did not push to the repository yet) was to drop the path.getCanonicalPath in KernelPath::KernelPath. Yours seems to be a more thorough fix... But debugging this, I decided to get rid of this part of kdumptool completely, because its a complete mess.
My intention is to always use /boot/vmlinuz, use /usr/bin/get_kernel_version from aaa_base to find its version. And only do this during the generation of the initrd, never during load. In the generation step, I will just remember which kernel the initrd was built for.
And in the longer run, starting this hackweek, I want to get rid of as much old cruft in kdump as possible. It's become an unmaintainable nightmare.
Ok, good to know, thanks for the feedback! Closing then.
If the kernel image is a symlink under
/usr
, the image name does not contain the kernel version, but it can be extracted from its path. I.e.:/boot/image-<kver>
/usr/lib/modules/<version>/image
I ran into this issue while calling
mkdumprd
without specifying the kernel version on a system running Tumbleweed with a custom compiled kernel, wherekdumptool find_kernel
failed to auto detect it, throwingMagic 0x1f 0x8b 0x08 0x0 not found
. Regardless of the fact that my case is not very common, version detection using the image name is failing in TW/ALP, always falling back to extracting the info from within the image.