Isorec for Samsung Galaxy S2 family

[gsstudios]

With the introduction of isorec into the mainstream CM12.1 and CM13 kernel, users are wanting to have control over the recovery.

There are some issues that we have to face:

• DorimanX init script is much much more complex than standard CM12.1 init script. Since DorimanX doesn't boot directly into the native recovery.cpio, we will need to rework the patch so it works fine on the kernel
• Dual boot support. For users of dualboot, we may have to give users warning that they will lose dual functionality, which can be restored with a kernel reflash.
• Partition mounting problems? Possible with how StanTRC recovery is configured with our kernel. Finger crossed that this problem doesn't happen.
• More to be added later

Correct me if what I've said is wrong or isn't quite right.

If this causes too many issues for DorimanX kernel, I will abandon this idea as it may not be worth the time or effort.

[gsstudios]

@lanchon @chhapil

Not on the top of my to-do list, but will appreciate any help or advice.

[Lanchon]

can you explain what is the dual boot support you refer to?

[gsstudios]

Whatsoever I mean by dual boot is having the choice to boot to 2 different ROMs installed on the device. Dual boot is required to be set up in stantrc cwm recovery, but isn't required once dual boot is set up. The warning is required (A warning in the OP is sufficient, or maybe in stweaks) as some people may want to start a new dual boot setup which they may discover they can't do so in a non dorimanx recovery. So what I mean by warning is to let them know on my XDA thread about the possible loss of dual boot support.

[Lanchon]

thanks you! could you please provide any recent cpio ramdisk of your kernel for me to take a look? thanks again

[Lanchon]

also, regarding your dual boot concern, i think the best option would be to forgo isorec recovery and boot kernel-bundled recovery if the user is holding the vol_down button. (home+vol_down is bootloader. home+vol_up is recovery. home+vol_up, release on samsung logo, then hold vol_down would mean ignore isorec recovery.)

problem is: -i dont know how to read the state of the button. do you? -maybe different devices have different button mappings. even different boot-select-by-button behaviors.

[Lanchon]

also, looking at your ramdisk source it doen't look too hard to support isorec. i just need some time (can't now). but i don't know the platform, linux nor the startup process that well and there are a few things that baffle me. if you can explain stuff to me it would help.

1) first, this line: https://github.com/CyanogenMod/android_kernel_samsung_smdk4412/blob/cm-13.0/usr/galaxys2_initramfs_files/init#L40 particularly the rm -fr /dev/* part. why is it there? what is it deleting and who created those things being deleted? or is it just a leftover from old code?

2) and what about this? https://github.com/gsstudios/initramfs3/blob/master-lp/sbin/init#L14 why? is rootfs really readonly? why is that line missing from CM's init?

3) then why am i able to straight talk to the device here: https://github.com/CyanogenMod/android_kernel_samsung_smdk4412/blob/cm-13.0/usr/galaxys2_initramfs_files/init#L25 while you seem to need to create a node before using? https://github.com/gsstudios/initramfs3/blob/master-lp/sbin/init#L21

4) finally, what the hell is this? https://github.com/gsstudios/initramfs3/blob/master-lp/sbin/init#L9 and should that setup be done before invoking another recovery? probably yes i guess.

thanks!

[gsstudios]

1) I really don't understand that line either. Seems to be used since ics code according to github 2) Seems to be an important line to boot dorimanx. Commit: 309cbff11529d9f78a889a48585016f995143d12 This is a really really old commit :) 3) Apparently needed to mount/format partitions in recovery Commit: d073aad42a94a89d7ae0ade868b84c55abab33fa 4) Needed for some roms Commit: 634091c947decbf4bba003cf4097a466c6857764 Seems to be left over code as DorimanX added in comments.

[gsstudios]

Dual recovery on DorimanX? Seems like a interesting idea. Have no idea how it would work though :)

[Lanchon]

well, isorec-vs-dori recovery selection would be simple to implement if i knew how to read the status of the VOL_DOWN key.

there i go again, could you please provide any recent cpio ramdisk of your kernel for me to take a look? :)

[gsstudios]

Hehe :) Don't know how to get a hold of one. Wait, lemme check :)

[Lanchon]

:) ok! well when you build you should get one or more *.cpio files in your $OUT tree.

the make script will then bundle all together into the decompressor/kernel/ramdisk tarball we call simply "kernel", but the intermediate files should remain somewhere lying around.

[gsstudios]

Got it. Uploading to google drive.

Link: https://drive.google.com/file/d/0B3ApZsjOd2bzb05Ya0x0RGM4STg/view?usp=sharing

[Lanchon]

thanks! just to check, you found a single *.cpio in the whole tree, right? if not, upload all. thanks!

[gsstudios]

Just single cpio

[Lanchon]

or you can mail my username at gmail if more convenient

[Lanchon]

ok i never saw the edit with the link! lol :) thank you, got it now. only i can't look now :(

[gsstudios]

As in you don't have time or there is a problem with the files? Either way, there is no rush :) If you require me to upload more stuff that would help, I will gladly do so.

[Lanchon]

no, everything is cool! i didn't have time but i made it anyway: https://github.com/Lanchon/initramfs3/pull/1

i just typed this into github, didn't even bother to clone the repo, it could all be horribly wrong! :)

[Lanchon]

btw, answer to my questions 1) & 3): the CM cpio ramdisk comes with the /dev/block nodes already created in the archive, while dori has to create them using scripts. yes, i didn't know that device nodes could be stored in an archive either! :)

[gsstudios]

Thanks for the pull request. Will test soon.

[gsstudios]

I created a new pull request so that I will be able to merge if ready

[gsstudios]

Unfortunately, the patch doesn't work. It just keeps booting into StanTRC CWM recovery instead of TWRP recovery by arnab.

[Lanchon]

of course you didn't forget to flash the separate recovery, right?

can you pull the RECOVERY partition and verify that it matches the *.cpio inside the isorec twrp zip file?

just trying to verify that the recovery zip flasher that put together works on your recovery. it was a quick hack that was done to run under the CM kernel and bin tools.

[Lanchon]

well it turns out that you probably have a bug in dorimanx init. i based myself in your init and ended up replicating that same bug! :)

here is the AMENDED commit for you to try merging: https://github.com/Lanchon/initramfs3/commit/6ae8f20ca58729316f384a75622eaaa81b825c90

i amended because i wanted a single commit to maybe be cherry-picked later (if ever). but the history is in a separate branch here so you can see the changes: https://github.com/Lanchon/initramfs3/commits/master-lp-isorec-history

[Lanchon]

note that I DID NOT FIX your existing bug, only mine (but documented yours anyway). i didn't want to alter the present behavior of dori.

[gsstudios]

Thanks, will try merging later (probably tomorrow).

[gsstudios]

So I tried making a build with your amended fix, but it seems that the kernel is unable to boot into recovery completely. Once again, I flash arnab's TWRP recovery after flashing the isorec-build of dorimanX and still a no go. How do we check the recovery partition? Is it just the recovery folder of the root directory right?

[Lanchon]

hi, thanks! sorry about this. i think this means progress. isorec was detected now (the partition could be accessed), but the boot itself failed.

to test hypothesis: -flash the isorec disabler in my isorec recovery repo: https://www.androidfilehost.com/?w=files&flid=47550 -then flash your patched kernel and boot into recovery.

it should boot normally into dorimanx recovery. if this happens, then it is confirmed that there is a bug in dori's init here: https://github.com/Lanchon/initramfs3/blob/master-lp-isorec/sbin/init#L64

there is also a problem in the isorec patch that is preventing it to boot the isorec recovery. i'll look into this, sorry. thanks!

[Lanchon]

more possible bugs:

i used mkdir and mknod without the $BB (busybox) before it because they are so used in your init. so i thought those were intrinsic to the shell, like exec is. but they are not. i will prepend busybox to them

[gsstudios]

Thanks for the isorec disabler link. Didn't know it existed. Will have to remember to link it when the time comes :)

As for recovery issue, I just reflashed one of my older kernels while in download mode. No harm done :)

[Lanchon]

yes, but what i needed was that you tested that normal dorimanx recovery works. please: flash disabler, then patched kernel, then boot into recovery and dori recovery should come up.

im looking into why isorec didnt boot. the problem is... that /sbin/busybox is a symlink in your ramdrive! so i move and save the link instead of the actual binary. but i want to make sure nothing else is borked before continuing as much as possible.

[gsstudios]

Sure. Will do this when I have the chance.

[Lanchon]

a more touchy subject is that the shell (busybox sh) ceases to work correctly once either its binary or its directory is removed from the file system :) i'm on it!

[Lanchon]

turns out the problem i was having was with a twrp busybox that uses dynamic linking, but dori uses static linking. so i just lost some time, and the only real problem with the script before was that busybox was a symlink.

all fixed now and this commit should work: https://github.com/Lanchon/initramfs3/commit/fe2288665fca2eb33426b71086fc7282ee687e68 third time's a charm! sorry about the bugs before but i can't test this. thanks!

[gsstudios]

thanks, will test again. I will also see if isorec-disabler works.

[gsstudios]

Third time and it's working!!! CWM and TWRP works. Flashing is fine but I haven't tested the wiping yet. Thanks lanchon. Now will test if disabler works.

[gsstudios]

Isorec disabler works!!! The only problem is that TWRP can't mount USB storage so PC won't be able to detect it. Must be selinux related or something else. CWM 6.0.5.1 works perfectly fine.

[Lanchon]

cool, thanks!! well incompatibilities between kernel and user space sometimes happen, fixing that is independent of this patch. but you could take that with arnab if you want, he's super helpful. btw, with CM 12.1 kernel, latest twrp mounts via MTP and USB mass storage.

[gsstudios]

Yep, no worries. Since this is confirmed working, I will close this issue once I merge isorec-test branch with main master branch. Thanks again :)