Some things on '<code>systemctl kexec</code>' as compared to '<code>kexec -e</code>'

Suppose, unfortunately not hypothetically, that you have some machines that the Ubuntu 26.04 LTS installer kernel sometimes gets a kernel oops during a network based reinstall (we don't think this is a hardware flaw, but who knows; these machines were stable on 24.04). Further suppose that you're not network booting these machines but instead you're using kexec to boot them into the installer environment . This creates an awkward situation, where the over the network installer may have gotten far enough before the panic to have written over enough of the disk (with the previous install on it) so you can't reboot from it. Fortunately there is a way out, because you can contrive to kexec the installer environment again from within the installer environment.

(A kernel oops is not a kernel panic, and normally doesn't reboot the system unless you've made specific settings changes , which the Ubuntu 26.04 LTS installer environment hasn't done. In this case, that's a good thing for us.)

Once you've used ' kexec -l ' to load the installer kernel and initrd with the required command line arguments, you have two choices for actually rebooting into the kexec kernel. You can use the plain and normal ' systemctl kexec ', which will "shut down and reboot the system via kexec" (and is what you may have used to boot into the installer from the running system), or you can directly use ' kexec -e '. Based on our recent experiences, if you're rebooting the system because the kernel hit an oops, you probably want to use ' kexec -e ', not ' systemctl kexec '.

The problem with a plain ' systemctl kexec ' is that as the manual page tells you, it will try to go through the usual standard orderly shutdown process. If your system has hit a kernel oops, this process may not finish. Not even ' systemctl kexec --force ' will necessarily finish, because that still tries to do some things in an orderly way. By contrast. ' kexec -e ' proceeds immediately to the new kernel (as I believe ' systemctl kexec --force --force ' also does, cf ). Abruptly rebooting into the new kernel is not normally what you want to do when you're going to use things on the disk and so on later, but when you're already in the middle of the network installer environment, everything is going to get thrown away anyway and an orderly shutdown is pointless (and in this case, dangerous).

(An orderly shutdown at the end of the install process isn't pointless because the installer needs to finalize various things.)

We'll probably keep using ' systemctl kexec ' when we're using kexec to go from an existing local install to booting the install environment over the network. It's always possible we'll change our mind and go back to the regular system ( perhaps I made a mistake ), and in that case an orderly shutdown is better.