Comment 3 for bug 2037398

I have confirmed that this issue with not being able to capture kernel dump with a mantic arm64 kernel is not new. using the arm64 6.5 kernel (6.5.0-5) in the release pocket I captured the following during test.

```
ubuntu@cloudimg:~$ sudo kdump-config show
DUMP_MODE: kdump
USE_KDUMP: 1
KDUMP_COREDIR: /var/crash
crashkernel addr: 0xde000000
   /var/lib/kdump/vmlinuz: symbolic link to /boot/vmlinuz-6.5.0-5-generic
kdump initrd:
   /var/lib/kdump/initrd.img: symbolic link to /var/lib/kdump/initrd.img-6.5.0-5-generic
current state: Not ready to kdump

kexec command:
  no kexec command recorded
ubuntu@cloudimg:~$ uname --all
Linux cloudimg 6.5.0-5-generic #5-Ubuntu SMP PREEMPT_DYNAMIC Wed Sep 6 15:36:23 UTC 2023 aarch64 aarch64 aarch64 GNU/Linux
ubuntu@cloudimg:~$ sudo cat /proc/cmdline
BOOT_IMAGE=/vmlinuz-6.5.0-5-generic root=UUID=e7604ab2-200c-4f34-ab11-47e78ac4b8bd ro console=tty1 console=ttyS0 crashkernel=2G-4G:320M,4G-32G:512M,32G-64G:1024M,64G-128G:2048M,128G-:4096M
ubuntu@cloudimg:~$ sudo dmesg | grep -i crash
[ 0.000000] crashkernel reserved: 0x00000000de000000 - 0x00000000fe000000 (512 MB)
[ 0.000000] Kernel command line: BOOT_IMAGE=/vmlinuz-6.5.0-5-generic root=UUID=e7604ab2-200c-4f34-ab11-47e78ac4b8bd ro console=tty1 console=ttyS0 crashkernel=2G-4G:320M,4G-32G:512M,32G-64G:1024M,64G-128G:2048M,128G-:4096M
[ 87.054802] pstore: Using crash dump compression: deflate
ubuntu@cloudimg:~$ sudo cat /proc/sys/kernel/sysrq
176
ubuntu@cloudimg:~$ sudo service kdump-tools status
● kdump-tools.service - Kernel crash dump capture service
     Loaded: loaded (/lib/systemd/system/kdump-tools.service; enabled; preset: enabled)
     Active: active (exited) since Tue 2023-09-26 13:44:22 UTC; 7min ago
    Process: 514 ExecStart=/etc/init.d/kdump-tools start (code=exited, status=0/SUCCESS)
   Main PID: 514 (code=exited, status=0/SUCCESS)
        CPU: 4min 46.461s

Sep 26 13:38:21 cloudimg systemd[1]: Starting kdump-tools.service - Kernel crash dump capture service...
Sep 26 13:38:32 cloudimg kdump-tools[514]: Starting kdump-tools:
Sep 26 13:38:32 cloudimg kdump-tools[535]: * Creating symlink /var/lib/kdump/vmlinuz
Sep 26 13:38:41 cloudimg kdump-tools[577]: kdump-tools: Generating /var/lib/kdump/initrd.img-6.5.0-5-generic
Sep 26 13:44:11 cloudimg kdump-tools[535]: * Creating symlink /var/lib/kdump/initrd.img
Sep 26 13:44:22 cloudimg kdump-tools[535]: * failed to load kdump kernel
Sep 26 13:44:22 cloudimg kdump-tools[5536]: failed to load kdump kernel
Sep 26 13:44:22 cloudimg systemd[1]: Finished kdump-tools.service - Kernel crash dump capture service.
ubuntu@cloudimg:~$ sudo ls -al /var/lib/kdump/vmlinuz
lrwxrwxrwx 1 root root 29 Sep 26 13:38 /var/lib/kdump/vmlinuz -> /boot/vmlinuz-6.5.0-5-generic
ubuntu@cloudimg:~$ sudo file /boot/vmlinuz-6.5.0-5-generic
/boot/vmlinuz-6.5.0-5-generic: gzip compressed data, was "vmlinuz-6.5.0-5-generic.efi.signed", last modified: Thu Sep 7 10:43:26 2023, max compression, from Unix, original size modulo 2^32 54989192
```

.. but the `Cannot determine the file type of /var/lib/kdump/vmlinuz` in the `sudo service kdump-tools status` as @xnox has also reproduced with `kexec` is new.

I have also confirmed that capturing kernel crash dump with the amd64 kernel 6.5.0-5 & 6.5.0-6 works as expected.