What is Kexec?
"Kexec", which is short for 'Kernel Execution' is derived from the Linux Kernel call "exec". It allows the "live" booting of a new kernel "over" the currently booted kernel without taking the device down for a reboot. This is extremely useful on locked bootloader devices, as a user with root authentication can boot a custom kernel without rebooting, and undergoing the security checks enforced by the bootloader. On unlocked devices, it can be used to "multi-boot" kernels on a device without requiring the kernels to be installed to the /boot partition.
Whilst Kexec is extremely useful, it also can be extremely hard to implement, as it needs to take all devices down, and bring them back up along with the new kernel, this can lead to some serious bugs, like devices not working after soft-boot, kernel corruption, device hangs, etc. This make it very device specific, and hard to get fully working, as it requires retrieving kernel crash logs, (often) UART serial output, and a ton of debugging.
What about this whole "Hardboot" thing?
The solution to this was written (initially) by Mike Kassick, who had the idea to "Hardboot" a kernel. Which is when a kernel is loaded into memory, a flag is set, the device is taken down for a full reboot, then the flag is read out by the primary kernel very early in the boot sequence, at which point, the "primary" kernel directly loads the new "secondary" kernel/ramdisk/passes arguements/etc.
This is much easier to implement than the normal Kexec SysCall, as it jumps to the new kernel before most devices are initiated, and in doing this, we allow the secondary kernel to initialize all the devices on its own, and not have to worry about taking them down.
Many people unknowingly make use of Kexec in the form of MultiROM, so, today, I thought I would do a write up on how to use it in practice.
Necessary Components:
* Boot.img (alternatively, the zImage-dtb/ramdisk you want to use)
* Unmkbootimg
* Kexec Binary (can be found in your specific devices MultiROM zip)
* Kexec Hardboot enabled Kernel installed (most custom kernels have it)
* Root Access
Downloads:
All the Binaries I've cross compiled/found can be downloaded here: https://www.dropbox.com/sh/7g5jcofv8j2gwg9/AAA-2b-wLiHq2z0nCMIHSHooa?dl=0
All the Linux Binaries you'll want/need are here: https://www.dropbox.com/sh/qcho8bhaoi8cdkc/AACGvmIQlb_3I9OQtNMqIQwva?dl=0
If you use Windows/Mac, just find the binaries equivalents for your platform.
How to use it?
1. Take the aforementioned Kexec Binary, and place it in /system/bin using ADB or A File Explorer, granting it permissions drwxdr-xdr-x (or chmod 0755 it)
2. Over on your desktop, make sure you have Unmkbootimg in an Executable location, and that you've blessed them as executable (chmod 0755 filename). Then run
This will dump a zImage (rename it to zImage-dtb now, for semantics sake), and a ramdisk, labeled initramfs.cpio.gz (Initial RAM File System, in the form of a cpio.gz archive).
Now, put the kernel and ramdisk in a folder on your SD Card via MTP/ADB Push, I called mine "kexecstuffs".
3. Now open a mobile terminal, or an ADB Shell, and run
Now, lets dissect the different arguments we are passing to Kexec:
--load-hardboot = Tells Kexec to make use of the Kexec Hardboot kernel function, and take the device down for a full reboot as opposed to soft-booting, like that used in the standard Kexec Linux SysCall
zImage-dtb = Name of your kernel file
--initrd = Points to the ramdisk to be used when booting the new kernel, if not set, the current ramdisk in the /boot partition. Most archive types are supported.
--mem-min = A reasonable value in memory where the kernel is loaded, serves as space for Kexec to do its work
--command-line = What arguments are passed to the new kernel, using "$(cat /proc/cmdline)" allows you to pass the currently booted kernel's arguments to the new kernel, which is what we want in the case of Shamu
--dtb = Defines that the board makes use of an Appended Device Tree, can be passed without a value (which will rely on Tasssdar's “boardname” value), or can have a compressed DTB image as its value
--boardname = Tasssdar's way to handle different DTB styles, we just need to pass “shamu” to it, and it'll use our DTB style
Now that we have successfully loaded the kernel into memory, lets execute it!
4. In that same Mobile Terminal/ADB Shell, run:
Although this guide is for the Nexus 6 (shamu), it should work all devices supported bu MultiROM, or on any device with a kernel that supports Kexec/Kexec Hardboot.
I hope this helped you to better understand what Kexec is/how to use it.
"Kexec", which is short for 'Kernel Execution' is derived from the Linux Kernel call "exec". It allows the "live" booting of a new kernel "over" the currently booted kernel without taking the device down for a reboot. This is extremely useful on locked bootloader devices, as a user with root authentication can boot a custom kernel without rebooting, and undergoing the security checks enforced by the bootloader. On unlocked devices, it can be used to "multi-boot" kernels on a device without requiring the kernels to be installed to the /boot partition.
Whilst Kexec is extremely useful, it also can be extremely hard to implement, as it needs to take all devices down, and bring them back up along with the new kernel, this can lead to some serious bugs, like devices not working after soft-boot, kernel corruption, device hangs, etc. This make it very device specific, and hard to get fully working, as it requires retrieving kernel crash logs, (often) UART serial output, and a ton of debugging.
What about this whole "Hardboot" thing?
The solution to this was written (initially) by Mike Kassick, who had the idea to "Hardboot" a kernel. Which is when a kernel is loaded into memory, a flag is set, the device is taken down for a full reboot, then the flag is read out by the primary kernel very early in the boot sequence, at which point, the "primary" kernel directly loads the new "secondary" kernel/ramdisk/passes arguements/etc.
This is much easier to implement than the normal Kexec SysCall, as it jumps to the new kernel before most devices are initiated, and in doing this, we allow the secondary kernel to initialize all the devices on its own, and not have to worry about taking them down.
Many people unknowingly make use of Kexec in the form of MultiROM, so, today, I thought I would do a write up on how to use it in practice.
Necessary Components:
* Boot.img (alternatively, the zImage-dtb/ramdisk you want to use)
* Unmkbootimg
* Kexec Binary (can be found in your specific devices MultiROM zip)
* Kexec Hardboot enabled Kernel installed (most custom kernels have it)
* Root Access
Downloads:
All the Binaries I've cross compiled/found can be downloaded here: https://www.dropbox.com/sh/7g5jcofv8j2gwg9/AAA-2b-wLiHq2z0nCMIHSHooa?dl=0
All the Linux Binaries you'll want/need are here: https://www.dropbox.com/sh/qcho8bhaoi8cdkc/AACGvmIQlb_3I9OQtNMqIQwva?dl=0
If you use Windows/Mac, just find the binaries equivalents for your platform.
How to use it?
1. Take the aforementioned Kexec Binary, and place it in /system/bin using ADB or A File Explorer, granting it permissions drwxdr-xdr-x (or chmod 0755 it)
2. Over on your desktop, make sure you have Unmkbootimg in an Executable location, and that you've blessed them as executable (chmod 0755 filename). Then run
Code:
unmkbootimg /path/to/your/boot.imgNow, put the kernel and ramdisk in a folder on your SD Card via MTP/ADB Push, I called mine "kexecstuffs".
3. Now open a mobile terminal, or an ADB Shell, and run
Code:
su
cd /sdcard/PathToYourFolder/
kexec --load-hardboot zImage-dtb –initrd=initramfs.cpio.gz --mem-min=0x20000000 --command-line="$(cat /proc/cmdline)" --boardname=shamu –dtb--load-hardboot = Tells Kexec to make use of the Kexec Hardboot kernel function, and take the device down for a full reboot as opposed to soft-booting, like that used in the standard Kexec Linux SysCall
zImage-dtb = Name of your kernel file
--initrd = Points to the ramdisk to be used when booting the new kernel, if not set, the current ramdisk in the /boot partition. Most archive types are supported.
--mem-min = A reasonable value in memory where the kernel is loaded, serves as space for Kexec to do its work
--command-line = What arguments are passed to the new kernel, using "$(cat /proc/cmdline)" allows you to pass the currently booted kernel's arguments to the new kernel, which is what we want in the case of Shamu
--dtb = Defines that the board makes use of an Appended Device Tree, can be passed without a value (which will rely on Tasssdar's “boardname” value), or can have a compressed DTB image as its value
--boardname = Tasssdar's way to handle different DTB styles, we just need to pass “shamu” to it, and it'll use our DTB style
Now that we have successfully loaded the kernel into memory, lets execute it!
4. In that same Mobile Terminal/ADB Shell, run:
Code:
kexec -eI hope this helped you to better understand what Kexec is/how to use it.
Last edited:
