[warm-reboot] Use kexec_file_load instead of kexec_load when available

[saiarcot895]

Signed-off-by: Saikrishna Arcot sarcot@microsoft.com

What I did

On some dev VMs, warm reboot on a VS image fails. Specifically, after kexec is called and the new kernel starts, the new kernel tries to load the initramfs, but fails to do so for whatever reason. There may be messages about gzip decompression failing and that it's corrupted.

[    2.053306] Initramfs unpacking failed: junk within compressed archive
[    2.372704] Failed to execute /init (error -2)
[    2.379385] Kernel panic - not syncing: No working init found.  Try passing init= option to kernel. See Linux Documentation/admin-guide/init.rst for guidance.
[    2.389714] CPU: 2 PID: 1 Comm: swapper/0 Not tainted 5.10.0-12-2-amd64 #1 Debian 5.10.103-1
[    2.396179] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-1ubuntu1.1 04/01/2014
[    2.403078] Call Trace:
[    2.405698]  dump_stack+0x6b/0x83
[    2.408198]  ? memcpy_orig+0xf0/0x10f
[    2.411158]  panic+0x101/0x2d7
[    2.415376]  ? kernel_execve+0x14a/0x1c0
[    2.419642]  ? rest_init+0xb4/0xb4
[    2.422684]  kernel_init+0x101/0x10c
[    2.426119]  ret_from_fork+0x22/0x30
[    2.430313] Kernel Offset: 0x9600000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)
[    2.444160] ---[ end Kernel panic - not syncing: No working init found.  Try passing init= option to kernel. See Linux Documentation/admin-guide/init.rst for guidance. ]---

After some experimentation, it was found that when first loading the new kernel and initramfs into memory, using the kexec_file_load syscall (-s flag in kexec) worked fine, whereas using the default kexec_load syscall resulted in a failure. It's unknown why kexec_file_load worked fine when kexec_load didn't; there shouldn't be any difference for non-secure boot kernels, as far as I can tell. What was seen, however, was that when taking a KVM dump in the failure case, the memory that stored the initramfs had differences compared to what was on disk. It's unknown what caused these differences.

As a workaround (and as a bit of a feature enhancement), use the -a flag with kexec, which tells it to use kexec_file_load if available, and kexec_load if it's not available or otherwise fails. armhf doesn't support kexec_file_load, whereas arm64 gained support for kexec_file_load in the 5.19 kernel (we're currently on 5.10). amd64 has supported kexec_file_load since 3.17. This also makes it possible to do kexec on secure boot systems, where the kernel image must be loaded via kexec_file_load.

How I did it

How to verify it

Previous command output (if the output of a command-line utility has changed)

New command output (if the output of a command-line utility has changed)