[One (M9) Original Android Development] nkk71:
Enabling no-kexec workaround

As of this version you need to manually enable the no-kexec workaround.

Go to TWRP -> MultiROM -> Settings

and enable the No-KEXEC workaround option

once you do you'll also have the option for ADVanced settings, please see below for a detailed description, though in most cases the default should suffice.​

Explanation of the no-kexec workaround advanced options

(the Info page is supposed to provide the same information as here, but I haven't added that yet)

1- Use no-kexec only when needed

This should be the default for most users, the other options are more intended for advanced uses (kernel debugging, and such).

If MultiROM detects a kexec-hardboot enabled kernel in primary slot, it will use the standard kexec method to boot the secondary. If on the other hand it does not detect that the kernel supports kexec-hardboot then it will use the workaround.​

2- ... but also ask for confirmation before booting

Same as option 1 above, but in addition you will be presented with a confirmation message, if the workaround is about to be used: ​

3- Ask whether to kexec or use no-kexec on booting

If the kernel in primary slot does support kexec-hardboot'ing then you will be presented with a choice of which method to use

If the kernel does not support kexec-hardboot then you'll be informed as in option 2 above​

4- Always force using no-kexec workaround

Forces the no-kexec workaround to be used, even if the kernel in primary slot has kexec-hardboot support​

Options 2 and 3, always present the user with a GUI confirmation, whereas option 1 and 4 will act as instructed without prompting the user.
​

Visual feedback provided by the Booting... card

Regular kexec-hardboot boot

Booting using no-kexec-workaround

Booting into primary,

while the previous rom was using the no-kexec-workaround

(in which case the real primary needs to be restored first)

​

How does all this work, etc

The workaround:

MultiROM TWRP recovery works, and is able to flash ROMs to secondary

MultiROM in essence works (in particular, able to change the mount points during bootup)

what does

not work

is being able to use the secondary ROM's kernel (due to the lack of kexec-hardboot kernel and tools)

So how do we deal with booting any ROM if we can't use the proper kernel for the ROM?

Easy :eek: :

Upon selection of the ROM during MultiROM boot menu, we do the following:

"flash" secondary boot.img to primary partition slot

initiate a full reboot (secondary boot.img is in primary slot)

let the ROM auto-boot up on second boot

The good part:

It works.... has been for quite some time, but I kinda kept it hidden

.

Every secondary ROM has a boot.img file we can easily access to use the workaround; when you flash a ROM in MultiROM TWRP, not only are the "virtual" system, data, and cache partitions created, but also the boot.img.

The secondary ROMs' boot.img will be found /data/media/0/multirom/<name of rom>/boot.img or if it's on your external ext4 in the appropriate rom folder

We use that file and flash it to primary

real

boot

partition

and then upon second boot, the correct boot.img is in place for the correct ROM.

The bad part:

Note: the below needs to be revised as the "lingering primary_boot.img" is no longer an issue, however to do my affection for it, I can't just delete all references to it :p

What we (yes, we) have come to affectionately call the "lingering primary_boot.img" this should now be taken care of, as much as possible

.

Unlike secondary ROMs, the primary ROM does not have a boot.img file... since it is the primary ROM, the boot.img should always be in the

real

boot

partition

, since MultiROM expects the primary kernel to have kexec-hardboot capability, but it does not, so I just go ahead and mess with your primary boot partition.

Since we have no "boot.img" file for the primary, my workaround makes a backup of the kernel and names it primary_boot.img

This backup is created and/or used only under certain situations, for example (this is not an exhaustive list):

the last ROM was primary, and we want to boot a secondary ---> backup the primary boot.img, flash secondary one

.

the last ROM was secondary, and we're booting another secondary ---> just flash the secondary boot.img

.

the last ROM was secondary, and want to boot the primary ROM --> restore the primary_boot.img we backed up

.

^^ and here lies the problem, we cannot actually say if the backup we created is actually correct for the primary ROM.... ideally it is, but there are easy ways to break that UPDATE: not so easy to break it all, anymore :)

one very simple example (as mentioned in the FAQs) would be:

==> Reboot from secondary to recovery, flash new primary ROM/kernel ---> the backup of primary_boot.img will still be there, MultiROM will still think the last ROM was a secondary, and therefore restore the backup; which will result in a non-booting primary ROM since the backed up kernel doesnt actually belong to this ROM

this is what I call a "lingering primary_boot.img"

this is just one simple example, but it can happen for a variety of reasons... interrupted boots, some app/method flashed a new kernel, etc.

The solution for the "lingering primary_boot.img":

Delete (if it's there): /data/media/0/multirom/last_rom_was_2nd no longer used

[*]Delete (if it's there): /data/media/0/multirom/primary_boot.img

Reflash or restore the correct boot.img for your primary ROM

New safe guards to avoid a "lingering primary_boot.img":

TWRP will restore the primary boot.img when entering recovery

MultiROM identifies whether the boot.img currently in primary slot is secondary, by checking the boot.img itself;

it no longer relies on a separate file (last_rom_was_2nd)

If the boot.img in primary slot is not tagged as a secondary, it is considered a new primary boot.img

Long story short: the difference between kexec and no-kexec-workaround

Usual kexec-hardboot MultiROM

Select secondary ROM

MultiROM detects a boot.img

MultiROM reads the secondary boot.img into memory

MultiROM initiates a kexec second boot

but

into the secondary boot.img from above

MultiROM continues

No-kexec-workaround MultiROM

Select secondary ROM

MultiROM detects a boot.img

MultiROM

flashes

the secondary boot.img into the primary boot partition

MultiROM initiates a full second boot

but

with the secondary boot.img in the real boot partition

MultiROM continues as usual

so the difference is in point 3... whereas normal kexec'ing loads the secondary boot.img into memory and goes from there, the workaround, actually flashes it to the real primary boot partition... and continues normally from there

Small note regarding encrypted devices using the no-kexec workaround

Since I dont use encryption, I haven't tested this to much extent, but I believe that there is a BOOT PRIMARY ROM option, which you can choose to boot into Internal without decrypting the device first.

Please be aware that this should not be used, if: the last booted ROM was a secondary using the no-kexec workaround.

The reason is that the backup of the primary_boot.img, is stored in the multirom folder, so for the no-kexec to be able to restore it, it needs access to the /data partition:

Booting into primary,

while the previous rom was using the no-kexec-workaround

(in which case the real primary needs to be restored first)

It's not too much of a big deal, because when the no-kexec workaround encounters an error, it reboots to recovery (and since recovery will restore the primary_boot.img), another reboot would be fine.

I do however (until I address this particular issue), encourage you not to use the BOOT PRIMARY ROM option, but instead decrypt the device, and then select the Internal ROM to boot.

Will this remain a "beta" version?

Most probably YES it will.... MultiROM is supposed to work with a kexec-hardboot enabled kernel; since that does not exist (at this time), on arm64 devices, I am using a workaround; since it doesn't exist and doesn't work, just work around it, if possible ... (call it "non-linear thinking" thinking if you wish)

until such time as the original author sees fit, or I decide to rename as "stable" (imho it is), it will remain called a "beta"

I have extensively tested this on the HTC One M7, the M8, and the M9 and have not found any side effects, so as of version 33b (2016-04-16), I consider this a stable release.

Devices using the no-kexec-workaround successfully

MultiROM threads for:

HTC One M7

HTC One M8

HTC One M9

.

Moto G 2015 by [MENTION=5293805]GtrCraft[/MENTION]

Moto X Play by [MENTION=5293805]GtrCraft[/MENTION]

OnePlus One (starting here) by [MENTION=5093942]KINGbabasula[/MENTION]

OnePlus 3 by [MENTION=4139665]martinusbe[/MENTION]

OnePlus X by [MENTION=4139665]martinusbe[/MENTION] ... (alpha status)

Sony Xperia Z5 by [MENTION=3816568]Myself5[/MENTION]

Sony Xperia L by [MENTION=5262839]STRYDER~007[/MENTION]

Sony Xperia SP by [MENTION=2233641]Adrian DC[/MENTION]

Xiaomi Redmi 2 by [MENTION=4453409]premaca[/MENTION]

.

(possibly Samsung Note 4, unsure if that was continued or not)

Others; unofficial builds? (if you are, kindly let me know, and I'll add you to the list)