*** Bug 1704568 has been marked as a duplicate of this bug. ***

*** Bug 1708469 has been marked as a duplicate of this bug. ***

Finally was able to find some time over the weekend to debug and root cause this issue. Here are my observations:

1. The standard distro vmlinuz (gun-zipp'ed Image) for aarch64 is nothing but Image.gz:

[root@hpe-apache-cn99xx-03 ~]# file /boot/vmlinuz-4.18.0-103.el8.aarch64 
/boot/vmlinuz-4.18.0-103.el8.aarch64: gzip compressed data, was "Image", last modified: Sat Jun  8 16:16:35 2019, max compression, from Unix, original size 21945120

whereas a vmlinuz compiled from source on a aarch64 machine is a PE/COFF Image file (not the gzipp'ed version):

[root@hpe-apache-cn99xx-03 ~]# file /boot/vmlinuz-5.2.0-rc4+
/boot/vmlinuz-5.2.0-rc4+: MS-DOS executable

2. While, I would try and fix this inconsistency for RHEL, since the distro composes use 'Image.gz' as 'vmlinuz' and 'make install' inside RHEL-8.1 source tree installs a 'Image' as 'vmlinuz', this causes the kexec-tools fil_load() handling to go bad for aarch64. See below:

a). The current handling for do_kexec_file_load() in kexec-tools doesn't handle compressed files properly (i.e. 'Image.gz'):

/* New file based kexec system call related code */
static int do_kexec_file_load(int fileind, int argc, char **argv,
			unsigned long flags) {

<..snip..>
	/* slurp in the input kernel */
	kernel_buf = slurp_decompress_file(kernel, &kernel_size);

	for (i = 0; i < file_types; i++) {
		if (file_type[i].probe(kernel_buf, kernel_size) >= 0)
			break;
	}

<..snip..>
	ret = file_type[i].load(argc, argv, kernel_buf, kernel_size, &info);
	if (ret < 0) {
		fprintf(stderr, "Cannot load %s\n", kernel);
		return ret;
	}

<..snip..>
	ret = kexec_file_load(kernel_fd, info.initrd_fd, info.command_line_len,
			info.command_line, info.kexec_flags); 
}

Since we pass the 'fd' for the compressed file passed via the following command line via 'kernel_fd' to the call made to 'kexec_file_load()' ...

# kexec -s -l /boot/vmlinuz-`uname -r` --initrd=/boot/initramfs-`uname -r`.img --reuse-cmdline -d

... and 'probe' the 'gun-unzipp'ed' 'kernel_buf' instead, this causes a mis-match. As per aarch64 booting.txt (<https://www.kernel.org/doc/Documentation/arm64/booting.txt>), aarch64 kernel expects a 'Decompressed kernel image' to be provided by the bootloader (kexec-tools in this case) and also provide the magic number correctly set to =0x644d5241, while passing on the decompressed kernel image header:

The decompressed kernel image contains a 64-byte header as follows:

  u32 code0;			/* Executable code */
  u32 code1;			/* Executable code */
  u64 text_offset;		/* Image load offset, little endian */
  u64 image_size;		/* Effective Image size, little endian */
  u64 flags;			/* kernel flags, little endian */
  u64 res2	= 0;		/* reserved */
  u64 res3	= 0;		/* reserved */
  u64 res4	= 0;		/* reserved */
  u32 magic	= 0x644d5241;	/* Magic number, little endian, "ARM\x64" */
  u32 res5;			/* reserved (used for PE COFF offset) */

b). On the other hand, if we explicitly pass a uncompressed kernel image in the command-line parameter while calling 'kexec_file_load()', things work just fine:

# kexec -s -l /root/git/linux/arch/arm64/boot/Image --initrd=/boot/initramfs-`uname -r`.img --reuse-cmdline -d

3. So, this requires a fix in upstream kexec-tools, which I plan to send out soon.

4. I think we might be required to delay this feature to RHEL-8.2 (I can send a RHEL only patch for RHEL-8.1 kexec-tools, but I think this feature needs some more thorough testing to make it to a release).

Will come back with more details soon..

Thanks

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2019:3540