Slot Swappin' - Moto Z2 Force Questions & Answers

Some info first:
Carrier: Sprint
Running the Latest TWRP (packaged with Pantheon Kernel), and SuperSu (Huge thanks to joemossjr, Uzephi, and enetec for their respective works, and others!)
So, I'm just trying to grab a little clarity...
Currently I am on "Slot A". When I first purchased the phone, I was on Slot B, and the series of events occurred as such:
Performed all security updates to October
Unlocked Bootloader
Flashed TWRP
Flashed SuperSu
-profited-
Stuck a fork in electrical socket and pressed "reboot system [SLOT A] (When I was on Slot B) - *womp womp*
Was unable to boot to anything except fast-boot
Flash-alled fresh system (Thanks again to all the work over in the development section!)
Performed all security updates to October
Flashed TWRP
Flashed SuperSu
-back in the money-
^^^ Where I am at now, except on SLOT A
So... here's where I need some clarity... if the Slot A / Slot B system works as a pass/trade system between two OS's, effectively allowing consecutive updates.. why did my system hit the crapper when i switched slots?
Theoretically, it should have simply booted into whatever my prior to flashing [what goes here? was it SuperSu that caused the derp, or TWRP?]
Also, now that we have a functioning TWRP as well as a functioning Security check for October, will we get to the point where we are able to actually just flash to separate partitions easily, and thus boot into separate roms easily?
I totally assume I'm missing some vital information above with my understanding about the discrepancies between Slots, as well as other partitions , so feel free to point at laugh at the short-bus kid... so long as you fill me in the gaps in my understanding.
Thanks!

My experiences are according with all you reported... I've done some "stock system" backups too (both A & B...) and I can confirm they differ from day one too...
It seems to be clear that things are a bit more complex than our speculations on them...

So far what I've tested: When you flash all, you go back to slot A (I assume the fastboot erase DDR is what causes it to go back to slot A). In essence, I have had October update on slot A and B by choice by choosing a different flashall zip.
oem is one partition. it is one HUGE partition, but one none-the-less (about 600 MB). The phone sees it as two though (sde19 and sdf19) User data is one partition. (sdb21) SSD is one partition (sdb1).
This means dual booting an OS needs to be similar (where they can share userdata and not cause boot loops) as user data (/data) is shared across both boot-a/boot-b ; system_a/system_b (sde17/sdf17 ; sde18/sdf18)
A lot of vendor specific issues in /crypto of the kernel causes some idiosyncrasies with encryption. any kernel update I do that involves /crypto or /fs edits causes a plethora of headaches.... one kernel update broke ADB and partially broke fastboot
Edit: your user data was decrypted with SU. So slot B was not encrypted. when you went to slot A (was encrypted) your phone couldn't read it.

Uzephi said:
...
This means dual booting an OS needs to be similar (where they can share userdata and not cause boot loops) as user data (/data) is shared across both boot-a/boot-b ; system_a/system_b (sde17/sdf17 ; sde18/sdf18)
Click to expand...
Click to collapse
I agree. When I made some speculations about dual booting (in another thread) I was thinking the same OR switching/recovering different /data by TWRP backup/restore...
Uzephi said:
...
Edit: your user data was decrypted with SU. So slot B was not encrypted. when you went to slot A (was encrypted) your phone couldn't read it.
Click to expand...
Click to collapse
If things here works as on Moto Z (Griffin) your sentence should be... "You have /data decrypted since of SuperSU tweak. Slot B has no more force encryption enabled since of this tweak. When you went to slot A (still with force encryption enabled since of no tweak installed), your phone will begin to encrypt /data partition again (it can read both encrypted and not encrypted, but if not encrypted it will encrypt at first boot) and, since of the long time required by operation on any /data partition not just formatted, it seems to hang/bootlooping..."

enetec said:
If things here works as on Moto Z (Griffin) your sentence should be...
Click to expand...
Click to collapse
The Griffin is different. The kryo msm8998 has it's own encryption chip built on the CPU. our kernels disable that so then everything goes software encryption which causes a bunch of issues. It's the only way we could get TWRP to decrypt the phone.

Uzephi said:
The Griffin is different. The kryo msm8998 has it's own encryption chip built on the CPU. our kernels disable that so then everything goes software encryption which causes a bunch of issues. It's the only way we could get TWRP to decrypt the phone.
Click to expand...
Click to collapse
...interesting!

enetec said:
...interesting!
Click to expand...
Click to collapse
https://www.qualcomm.com/documents/snapdragon-835-mobile-platform-product-brief Page 2 of the PDF, they call it "Qualcomm Haven Suite."

So essentially, Qualcomm took the initiative to "secure" us... For **our** benefit... Potentially against our will... Whereas before, we could choose to software encrypt if we wanted, and software decrypt at our discretion...
Obviously I'm being facetious, this seems to me to clearly be for the benefit of OEMs and Providers. Don't get me wrong, hardware microchipped encryption is kick-ass, especially how fast it manages it.... Just not how it's been utilized here.... As a massive firewall against 3rd party fingers in the pie.

Some_Donkus said:
So essentially, Qualcomm took the initiative to "secure" us... For **our** benefit... Potentially against our will... Whereas before, we could choose to software encrypt if we wanted, and software decrypt at our discretion...
Obviously I'm being facetious, this seems to me to clearly be for the benefit of OEMs and Providers. Don't get me wrong, hardware microchipped encryption is kick-ass, especially how fast it manages it.... Just not how it's been utilized here.... As a massive firewall against 3rd party fingers in the pie.
Click to expand...
Click to collapse
Yes, it's a simple flag in the defconfig file

Here is the slot swappin' solution you were looking for!
Download the most current official Google fastboot:
https://developer.android.com/studio/releases/platform-tools.html
Go into fastboot mode and type on PC:
fastboot set_active _a
(then boot to recovery, check TWRP to see you are on slot _a)
fastboot set_active _b
(then boot to recovery, check TWRP to see you are on slot _b)
Please note: I am sure the a/b switch inside our phone's TWRP will eventually work, but it doesn't currently (as of 17NOV2017); other a/b phones have had the same issue.

What is interesting to me is that flashall flashes both slots, and you can manually choose to flash a specific boot with $flash boot_a or $flash boot_b. With this ability and enough experimenting I'm sure there's a workaround somewhere.

Some_Donkus said:
What is interesting to me is that flashall flashes both slots, and you can manually choose to flash a specific boot with $flash boot_a or $flash boot_b. With this ability and enough experimenting I'm sure there's a workaround somewhere.
Click to expand...
Click to collapse
this method works for me
https://forum.xda-developers.com/showpost.php?p=74543389&postcount=10

jhofseth said:
this method works for me
https://forum.xda-developers.com/showpost.php?p=74543389&postcount=10
Click to expand...
Click to collapse
Oh, haha! I totally missed this post in the thread. Herp-A-Derp! Thank you! (I've been peepin' stuff via the XDA labs on my phone and I'm not used to the notifications and such, thanks for the rewind redirect!)
So... theoretically... if I used the above method to swap into the "other" slot and flash both slots identical, with TWRP and SuperSu... I would be able to swap slots back and forth as I pleased... (even though they would be the same.. and thus making swapping between them.. kind of pointless...) because both would then have the same flag...
If i wanted to modify -ONE- of them, I would have to ensure that it matched the encryption state of the other... correct?

jhofseth said:
Download the most current official Google fastboot:
https://developer.android.com/studio/releases/platform-tools.html
Go into fastboot mode and type on PC:
fastboot set_active _a
(then boot to recovery, check TWRP to see you are on slot _a)
fastboot set_active _b
(then boot to recovery, check TWRP to see you are on slot _b)
Please note: I am sure the a/b switch inside our phone's TWRP will eventually work, but it doesn't currently (as of 17NOV2017); other a/b phones have had the same issue.
Click to expand...
Click to collapse
Great!
Anyway, looking at my a & b backups, it seems to me TWRP a/b switch is already working (they are different...).
---------- Post added at 02:52 PM ---------- Previous post was at 02:50 PM ----------
Some_Donkus said:
What is interesting to me is that flashall flashes both slots, and you can manually choose to flash a specific boot with $flash boot_a or $flash boot_b. With this ability and enough experimenting I'm sure there's a workaround somewhere.
Click to expand...
Click to collapse
I could be wrong but... I've intended from my tests that fastboot without any slot specified flashes only the current one, not both...
---------- Post added at 02:56 PM ---------- Previous post was at 02:52 PM ----------
Some_Donkus said:
...
So... theoretically... if I used the above method to swap into the "other" slot and flash both slots identical, with TWRP and SuperSu... I would be able to swap slots back and forth as I pleased... (even though they would be the same.. and thus making swapping between them.. kind of pointless...) because both would then have the same flag...
If i wanted to modify -ONE- of them, I would have to ensure that it matched the encryption state of the other... correct?
Click to expand...
Click to collapse
Theoretically... yes!
(But don't bet your ass on it... :laugh

Some_Donkus said:
Oh, haha! I totally missed this post in the thread. Herp-A-Derp! Thank you! (I've been peepin' stuff via the XDA labs on my phone and I'm not used to the notifications and such, thanks for the rewind redirect!)
So... theoretically... if I used the above method to swap into the "other" slot and flash both slots identical, with TWRP and SuperSu... I would be able to swap slots back and forth as I pleased... (even though they would be the same.. and thus making swapping between them.. kind of pointless...) because both would then have the same flag...
If i wanted to modify -ONE- of them, I would have to ensure that it matched the encryption state of the other... correct?
Click to expand...
Click to collapse
Once you have successfully booted into the other slot's boot (TWRP), you can see what condition the data partition is in with respect to encryption. If files are encrypted and you already backed up important data (i.e., same data partition shared by both slots, but different systems, boots, etc.), I would recommend formatting data in TWRP. After that, you should do this:
https://forum.xda-developers.com/showpost.php?p=74540731&postcount=21
This way, you will always be able to access data on the data partition, because it won't be encrypted.
(Either system partition can cause data to become encrypted again, so if you have to format data in one and run the above linked command, you would need to do the same in the other boot (TWRP).)

jhofseth said:
Once you have successfully booted into the other slot's boot (TWRP), you can see what condition the data partition is in with respect to encryption. If files are encrypted and you already backed up important data (i.e., same data partition shared by both slots, but different systems, boots, etc.), I would recommend formatting data in TWRP. After that, you should do this:
https://forum.xda-developers.com/showpost.php?p=74540731&postcount=21
This way, you will always be able to access data on the data partition, because it won't be encrypted.
(Either system partition can cause data to become encrypted again, so if you have to format data in one and run the above linked command, you would need to do the same in the other boot (TWRP).)
Click to expand...
Click to collapse
https://plus.google.com/+DeesTroy/posts/i33ygUi7tiu
Hopefully... Encryption won't be a worry

Uzephi said:
https://plus.google.com/+DeesTroy/posts/i33ygUi7tiu
Hopefully... Encryption won't be a worry
Click to expand...
Click to collapse
That all sounds like an insane amount of redundant PitA!!
I really wish I could be of more service in the coding department to help chip away at these types of lockdowns. Unfortunately, my skills are limited to Python and basic C++ console stuff.
This kind of stuff makes me pine for the days when my biggest challenge was trying to modify the UI in Qbasic and installing a power supply without a keyed molex lol.
So, IF we end up at a wall regarding this severe encryption despite the progress made so far, would we be able to patch in security updates "off the cuff" via custom made twrp or fastboot packages?

Uzephi said:
https://plus.google.com/+DeesTroy/posts/i33ygUi7tiu
Hopefully... Encryption won't be a worry
Click to expand...
Click to collapse
Very interesting article about how much Google "love us"...
Please note that at lower level even Motorola did the same on old Griffin (Moto Z)... if you upgraded bootloader (by OTA or by a flashall) during MM->N upgrade, you'll never able to install MM or downgrade bootloader (soft brick in first case and refuse to flash in second one...).
Obviously newer bootloader was't required and gave no benefits on older one...
For this reason on Moto's I ever hint not to flash bootloader even during flashall/debrick...

enetec said:
Very interesting article about how much Google "love us"...
Please note that at lower level even Motorola did the same on old Griffin (Moto Z)... if you upgraded bootloader (by OTA or by a flashall) during MM->N upgrade, you'll never able to install MM or downgrade bootloader (soft brick in first case and refuse to flash in second one...).
Obviously newer bootloader was't required and gave no benefits on older one...
For this reason on Moto's I ever hint not to flash bootloader even during flashall/debrick...
Click to expand...
Click to collapse
Tried adding the code from the pixel 2 because the xl 2 is it's own beast and due to the fact were not running Oreo like there it broke right around 78% and it was due to missing proprietary Google files

Related

[IME][GUIDE][EXPERIMENTAL] HTC U12+ - „Dual-Boot” Slots A & B

{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Hello everybody,
first I have to inform you that this thread is to be regarded as highly experimental. I would like to warn all users, and advise against using this guide, who are not yet fully familiar with Treble A/B devices, and do not know how to debug problems!
If you continue, you are doing so on your own responsibility. I cannot accept any liability and/or responsibility for any problems that might occur during the process, such as bricks and other incidents. If you proceed from here on, you agree to personally take full responsibility for everything you do!​
Prerequisites
You are familiar with the Universal HTC RUU/ROM Decryption Tool and know how to use it.
You have a current RUU.zip for your device downloaded onto your PC (ATTENTION software version has to be the same as on your currently activ full stock slot!)
Your bootloader has to be Unlocked/S-ON
You don't panic when something goes wrong.
Guide
First: Start from scratch! What I'm saying is that the first thing you have to do is RUUing back to Stock.
Second: Never, I repeat, never use a PIN/password for the boot! Of course you can use a PIN, a password, or a screen lock pattern, but never for the boot process as long as you want to use a dual boot!
Okay, let's get started:
Use the Universal HTC RUU/ROM Decryption Tool to extract the system.img and the boot.img using the -sf command.
Copy system.img and boot.img to your fastboot/adb folder on your PC (NOT system_other.img, NOT boot_signed.img).
Rename the RUU to 2Q55IMG.zip, and copy it to the root directory of your extSD
Flash your RUU to restore a full stock system to your primary slot, slot A.
Power off your device
Reboot to download mode
Hold the power button pressed to power up your U12+.
Keep the Power button pressed and wait for the very first vibration.
In this very moment you got to release the Power button, press the Volume Up button immediately and hold it until the bootloader shows up.
If you did everything correctly, you'll now see the bootloader mode.
Navigate with the Volume Down key, until "DOWNLOAD MODE" is shown on the top of the screen.
Press Power once to enter it.
Flash your stock /boot and /system images to inactive second slot
flash boot.img to current inactive slot, using
Code:
fastboot flash boot_b boot.img
flash system.img to current inactive slot, using
Code:
fastboot flash system_b system.img
(this one takes a while to start, and will be flashed in three steps, so give it some time! It'll show an error first, so let's hang it on that very error for some seconds - see post #2 for further details.)
Reboot your device to active slot A, and set everything up
Activate Developer Options and check USB Debugging
Reboot to bootloader using adb reboot bootloader
Change active slot to slot B unsing
Code:
fastboot --set-active=b
Reboot to now active slot B once, and let it settle
Now you can start to modify slot B according to your wishes. So I run slot A as full stock system, while I have installed ViperU12+ in my slot B CleanSlate kernel, Magisk and Magisk, having a custom slot and a stock slot.
If an OTA update is offered, you only have to switch the active slot back to slot A, use the
Code:
fastboot --set-active=a
, reboot the device and install the update.
DISCLAIMER: the modified slot will be completely overwritten during this update process, so you should only install the OTA update when a new RUU is available, if you want to keep the "dual boot" option. If an OTA arrives and there is already a RUU for it, you have to install it after changing the slots as just described, and carry out the steps 1 - 12 for the now inactive slot again to realize a second modified slot.
​
XDA:DevDB Information
HTC U12+ (IME) - „Dual-Boot” Slots A & B
Contributors
@5m4r7ph0n36uru,
Created 2018-09-08
Last Updated 2017-10-17
Error handling during flashes
Error #1: "Cannot load system.img"
What can I do, if fastboot doesn't flash the system image, but throws an error stating
Code:
fastboot flash system_b system.img
Invalid sparse file format at header magic
Sending sparse 'system_b' 1/3 (1041175 KB)
OKAY [ 34.445s]
Writing sparse 'system_b' 1/3
(bootloader) HOSD CL#1050003
(bootloader) [email protected]
(bootloader) [email protected]%
FAILED ()
Finished. Total time: 131.327s
Solution: Well, let the device stay in this state for tiny seconds (in fact, it can be up to 25 seconds), and DO NOT interrupt the process of flashing! This is a fastboot problem that prevents images as large as system.img from being flashed in one step, or rather as a single file. Therefore, fastboot will start splitting system.img into three parts after a certain waiting time, and flashing each part separately, but one after the other. Patience is called for here. Don't panic, because it will have been flashed successfully in the end!
Reserved #2: just in case!
this is smart.
does it mean that I have an untouched 1.15. system on slot a ,cause I ve run that OTA 1.21. with magisk? so I can "downgrade" and can recieve updates again?
wiQbold said:
this is smart.
does it mean that I have an untouched 1.15. system on slot a ,cause I ve run that OTA 1.21. with magisk? so I can "downgrade" and can recieve updates again?
Click to expand...
Click to collapse
Didn't test to switch slot when running to different versions like you do. But in theory this should work, as long as 1.15. is still pristine, as that's what Treble is meant for - having a fallback solution once the first update hit. Maybe you could try and let us know here, for me to add a separate post regarding that very fact.
Sent from my HTC U12+ using XDA Labs
I read somewhere, I think in one of your threads, that there is a trigger on a partition (dont know the name now) that will be triggerd if I root.
thought it is systemwide. so I will try it at next update if I could recieve an OTA, with slot a.
@5m4r7ph0n36uru
This was a great write up. I had the same idea in mind yesterday, but you know this stuff and I don't. So you don't need to install the OS(you know what I mean) in slot-b? Only boot + system? Didn't know that.
Also was thinking what @wiQbold posted regarding switching slots for OTA. Of course that'll only work for the next OTA, will require RUU-ing afterwards. Good for one OTA with the switching.
P.S. - Just want to say THANK YOU for your time, patience and effort with everything you're doing!!!
P.P.S. - Allow just a small, very small token of my appreciation: 7S360226N84122301
k_l_o said:
P.P.S. - Allow just a small, very small token of my appreciation: 7S360226N84122301
Click to expand...
Click to collapse
Thanks a million mate. Really much appreciated! Time for a good and well done Gin I guess
I am asking you to question or deny that my reasoning is correct.
I had v1.15, I made flash Magisk, root. When it was released v1.21 I could not do OTA, so I threw a full RUU.
Without any slots, I uploaded Magiska, root and when it was made public - ViperU12 +
I have an active "slot-A".
And now clou:
If next week HTC will provide v1.25.401.3 (for DUGL) then I will be able to download OTA without a problem after changing the active "slot-A" to "slot-B"?
Now, when writing, I thought I was thinking about "slot-A" when I have ViperU12, Magisk - can I change the active slot on "slot-B" and use STOCK system?
I suspect that user applications will not be on "slot-B"?
regards
q.
qriozum said:
I am asking you to question or deny that my reasoning is correct.
I had v1.15, I made flash Magisk, root. When it was released v1.21 I could not do OTA, so I threw a full RUU.
Without any slots, I uploaded Magiska, root and when it was made public - ViperU12 +
I have an active "slot-A".
And now clou:
If next week HTC will provide v1.25.401.3 (for DUGL) then I will be able to download OTA without a problem after changing the active "slot-A" to "slot-B"?
Now, when writing, I thought I was thinking about "slot-A" when I have ViperU12, Magisk - can I change the active slot on "slot-B" and use STOCK system?
I suspect that user applications will not be on "slot-B"?
regards
q.
Click to expand...
Click to collapse
No you can't as after a RUU slot_b is empty imho. It is used for the first OTA after RUUing, as the update patches all files and copies them onto alot_b. So I'm afraid that, regarding your situation you got to RUU yet again to take the OTA.
That's exactly why I wrote to keep both slots at the same version of dual booting, and to setup the inactive slot_b right after RUUing, and modify that very slot. That way you can run modified on slot_b, and switch to the unmodified still freshly RUU'd slot_a as soon as the update arrives.
The will patch up all files, and copies them over to slot_b overwriting it completely. So the tinkered slot gets lost and replaced by the pristine, updated software version, making slot_b the now active slot. Thus you'd have to wait for the RUU to drop, decrypt it to obtain system and boot image, flash them to the now inactive slot_a, and start modifying slot_a, while you still kept all your apps that'd mean some work to be done after every update, like flashing Magisk and so on to your inactive slot.
That's why I wrote my warnings in the OP, that this one's actually really finicky and should only be done with proper knowledge. You always need to know which ones your pristine slot, as you never ever may boot TWRP if on that very slot to keep the ability to take further OTA. You should only boot TWRP if on the inactive slot, that you ser up as dual boot to tinker with it.
Sent from my HTC U12+ using XDA Labs
Hi, I have followed all of your directions I believe, Have stock ROM on Slot A and fastboot flashed decrypted boot.img and system.img on slot B but cannot get the "fastboot -set-active=b" command to work. Any suggestions? All I get is the usual list of commands when a command doesn't work. Thanks for all you do Buddy.
I noticed as shown in my screenshot that the set active slot commands for a and b are slightly different, with the a slot having a comma at the end. I was just wondering if these commands were accurate?
I can't get either command to be recognized, I've also tried the other similar command from your other thread.
Sorry for the trouble but I am stuck.
LibertyMonger said:
I noticed as shown in my screenshot that the set active slot commands for a and b are slightly different, with the a slot having a comma at the end. I was just wondering if these commands were accurate?
I can't get either command to be recognized, I've also tried the other similar command from your other thread.
Sorry for the trouble but I am stuck.
Click to expand...
Click to collapse
As it turns out, I had an outdated fastboot.exe and that was the issue. But I think the commands in the o.p. are a little off and need corrected? Sorry for the posts.
Anyway, the commands for changing slots that are shown in the O.P. are a little off. They should be
fastboot --set-active=b
fastboot --set-active=a
And if these commands do not work, it is most likely your fastboot.exe (platform-tools) is out of date, needs updated.
LibertyMonger said:
Anyway, the commands for changing slots that are shown in the O.P. are a little off. They should be
fastboot --set-active=b
fastboot --set-active=a
And if these commands do not work, it is most likely your fastboot.exe (platform-tools) is out of date, needs updated.
Click to expand...
Click to collapse
It's correctlly shown when opened on the webview. XDA labs app is the problem here. It tends to not show several lines and mix up code and none code environments. Same applies for multiple quotes, which aren't shown correctly on the Labs App.
Sent from my HTC U12+ using XDA Labs
5m4r7ph0n36uru said:
It's correctlly shown when opened on the webview. XDA labs app is the problem here. It tends to not show several lines and mix up code and none code environments. Same applies for multiple quotes, which aren't shown correctly on the Labs App.
Sent from my HTC U12+ using XDA Labs
Click to expand...
Click to collapse
It was showing the same on my Windows PC as my XDA app but it shows fixed now so no big deal. My main issue was the fastboot .exe but now I can't get "fastboot flash system_b system.img" to work. boot.img flashes fine but I get this error with system.img
Invalid sparse file format at header magic
Sending sparse 'system_b' 1/3 (1046655 KB) OKAY [ 44.078s]
Writing sparse 'system_b' 1/3
(bootloader) HOSD CL#1044991
(bootloader) [email protected]
(bootloader) [email protected]% FAILED () Finished. Total time: 223.063s
I guess it means the image is too big? I don't know but I been trying to figure this out for 3 days now.
I tried everything I could find to fix my slot b and finally resorted to last resort, I ran Sunshine S-Off and reverted back to the 1.15 ROM so I could take the 1.21 OTA and that fixed it. I am currently booted on Slot b. Just in case anyone runs into this issue, S-Off and flashing an older ROM zip in download mode fixes it. Seamless update still worked even though it seemed I had no ROM on slot b.
---------- Post added at 01:33 PM ---------- Previous post was at 01:15 PM ----------
So now I have stock 1.25 on slot a and just set slot b to active and booted up and have stock 1.21 on slot b. So I am thinking for this Dual-Boot to work to customize slot b, would I need to take the OTA on slot b? Kind of confused at this point. But I guess I will figure it out. At least I can boot both slots now.
---------- Post added at 01:47 PM ---------- Previous post was at 01:33 PM ----------
Taking the OTA on slot b didn't work, slot b is still on the 1.21 OTA. This is a little too confusing so I may give up for a while until I learn something. I could try fastboot flashing boot.img and system.img to boot b now I guess. Does it matter in what I order I flash them? Since boot.img was working and system.img was failing, I could try flashing system.img first to see if it is successful and then flash boot.img. Just to be safe. We will see...
---------- Post added at 02:07 PM ---------- Previous post was at 01:47 PM ----------
Fastboot flashing system.img failed again and now can't boot slot b so I am giving up for now. Gonna temp. S-Off and revert back to 1.15 to fix it again and just leave it be for a while. I either have a corrupt decrytped system.img or I have done something else wrong. At least it was a learning experience.
LibertyMonger said:
So now I have stock 1.25 on slot a and just set slot b to active and booted up and have stock 1.21 on slot b. So I am thinking for this Dual-Boot to work to customize slot b, would I need to take the OTA on slot b? Kind of confused at this point. But I guess I will figure it out. At least I can boot both slots now.
Click to expand...
Click to collapse
Actually that's the way it works if you take all OTAs up to the latest. You'll be on 1.25. on Slot A and shouldn't tinker with that very slot, as that's the one to switch to, as soon as the next OTA arrives.
So you'd switch to Slot B for tinkering which is on 1.21. Best would be to have a 1.25. boot.img and system.img at hand. Both can be flashed using fastboot. BUT flashing the system image, fastboot tries to flash it as one large image, which will end in a command prompt output, that the process failed. If you now just leave it there and wait - lets say 30 seconds - fastboot will restart the flashing proceedure and flash the system.img in three parts, one after another.
So you'll be on 1.25 on both slots and not receiving the OTA availability message for 1.25 on Slot B any longer.
Now you can tinker with Slot B, flashing Magisk, a Magisk ROM and the like.
As soon as the next OTA drops, it'll notify you, and you'd have to switch back to Slot A, download the OTA and let it patch up Slot B. After the OTA it'll swith to Slot B and you'll be greated by an updated, full stock system, with software > 1.25. If you want to start tinkering again it is important to backup stock boot.img and system.img from the now active stock Slot B, switch to Slot A, and repeat the procedure written above in italic letters.
Hope that clears things up a bit.
5m4r7ph0n36uru said:
Actually that's the way it works if you take all OTAs up to the latest. You'll be on 1.25. on Slot A and shouldn't tinker with that very slot, as that's the one to switch to, as soon as the next OTA arrives.
So you'd switch to Slot B for tinkering which is on 1.21. Best would be to have a 1.25. boot.img and system.img at hand. Both can be flashed using fastboot. BUT flashing the system image, fastboot tries to flash it as one large image, which will end in a command prompt output, that the process failed. If you now just leave it there and wait - lets say 30 seconds - fastboot will restart the flashing proceedure and flash the system.img in three parts, one after another.
So you'll be on 1.25 on both slots and not receiving the OTA availability message for 1.25 on Slot B any longer.
Now you can tinker with Slot B, flashing Magisk, a Magisk ROM and the like.
As soon as the next OTA drops, it'll notify you, and you'd have to switch back to Slot A, download the OTA and let it patch up Slot B. After the OTA it'll swith to Slot B and you'll be greated by an updated, full stock system, with software > 1.25. If you want to start tinkering again it is important to backup stock boot.img and system.img from the now active stock Slot B, switch to Slot A, and repeat the procedure written above in italic letters.
Hope that clears things up a bit.
Click to expand...
Click to collapse
Thanks a lot buddy, much appreciated. I ended up with 1.21 on slot a cause I reverted back to 1.21, therefore when I took the OTA, it put 1.25 on slot b. So if 1.25 must be on slot a, I will have to revert back to 1.15 so that I will get two OTA's, ultimately leaving me with 1.25 on slot a and 1.21 on slot b. I noticed, trying to flash the RUU on slot b caused my slot b to be unbootable. It bootloops about 10 times before it gives up and returns to boot on slot a.
Thanks again for all your work buddy. I just post my experience to help just in case others run into my issues. Learning from mistakes and experience.
Curiosity, at least for me.
I had a clean system (after RUU) prepared according to your tutorial. On the "B" partition, I applied ViperU12 +, but I had a problem with the weather clock widget (it did not refresh the time after the screen went out under NovaLauncher). Full wipe did not do anything.
I decided to upload a full RUU. I followed the tutorial - I uploaded RUU, I made a flash boot and system on the "B" partition. I checked the active partition (it was "A"), so I started the system to configure it and then change the active partition to "B".
What is my surprise when after the initial configuration, the wizard informs me that I have to enter my Google account information because the account (FRP) was assigned to this device.
I have never met such a message after the RUU. RUU always cleaned the device "to the very bottom".
Hmmm ... what do you think about it?
regards
q.

[TWRP][JOAN][V30/V30+/V30S][UNOFFICIAL] 3.3.1-2, 2020-2-23, Pie Decryption, for N/O/P

This is the new thread for Pie & 10 TWRP Recovery 3.3.1-x​
Feature list:
- Pie stock ROMs are fully decryptable with this TWRP, either protected with secure startup or without :good: OREO encrypted userdata is not decryptable with 3.3 . However, if you're on encrypted oreo and update to pie stock, either via zip or kdz, crypto gets migrated and you're good to go in terms of access to your encrypted data with 3.3. So, with this recovery, the urgent need for flashing no-verity-opt-encrypt zip isn't really there anymore
- everything working: backup & restore even with encrypted userdata, no matter if it's from oreo or pie. If you restore a backup containing an encrypted userdata, you'll need to format userdata before, for crypto removal. But only when coming from another encrypted ROM, otherwise you can just restore, boot up (it will use the encryption settings you"ve set up) ; decryption; time & dat; mtp; adb; installing of ROMs and zips in general; themeable; .........
- Possibility to leave out lockscreen settings when restoring a backup (sometimes you were forced to delete them manually, otherwise no login into your restored ROM possible -.- You can bypass this with this. Note: lockscreensettings ≠ encryption pin/pw/pattern.)
- Time and date is shown correctly, independent of /data. This should work after a few boots of ROM and TWRP, TWRP needs to get the data once and later on it will then be calculated from persist's settings file.
- modem image support: backup, restore, flashing of modem images either taken directly from kdz or diskdump. Same for OP partition (not present on USA and some others possibly)
- For removing encryption completely you can now do it as already known, via format userdata. Crypto is removed with it now again.
- busybox instead of toolbox/toybox, for better zip compatibility as it looks for now
- Pie 3.3.1-x: compiled with full 9.0 TWRP sources
- capable of installing every ROM and zip files
- some extra partitions (see below)
Don't forget your timezone settings after flashing. Also there are some extra partitions you can mount/backup/flash/explore, like LAF, persist-LG and OP configs. There's the thought of some people to flash TWRP as a second copy to LAF partition to be on the sure side when it comes to ROM switching or sth like that. You can do this, anyway it's not really recommended (by me and some others) because you'll lose download mode, but you now have the option.
For extra partitions: Some of them are needed for decryption (modem / persist-lg (drm)), some are for VoLTE (OP), time is stored on /persist/time (and /data/vendor/time), modem should be known and the LAF partition should be known already too (described above).
For decryption: it works as it should. Therefore it is a little bit tricky to restore a backup of a ROM which had encrypted userdata, when you'd installed any other ROM in between. There are some points to remember when restoring, a little guide is available in old thread's third post (https://forum.xda-developers.com/showpost.php?p=77839649&postcount=3), and some tipps too.
Some instructions:
How to flash?
If starting fresh with an unmodified phone, this thread should help you installing it
When you already have TWRP installed, you can flash this recovery from within TWRP:
- Copy the new image file to one of your phone storages
- Tap "Install"
- Tap "Install image" button, located down right
- Locate your downloaded image and select it
- Select "recovery" from the list which shows up then
- Install; and reboot to recovery after installing immediately, don't use it for any other tasks until rebooted pls, as it may not function. Things can go bollox when phone wasn't rebooted to recovery after installing.
And of course you can flash it via fastbootmode. Reboot to bootloader (adb reboot bootloader; when magisk is installed, you can use magisk manager => module => menu on the top right => reboot to bootloader. You can reboot to recovery from there too) and then:
fastboot flash recovery <twrp-image-name.img>
How to (re)boot to TWRP?:
If your phone is rooted:
- Magisk has options to reboot to different targets like bootloader or recovery, but this menu is a little bit hidden: you can access it by starting Magisk.Manager, going to the "Module" menu, tapping on the three dot menu on the top right. Then select your target
- If a terminal emulator is installed, open it, type "su" followed by enter and type "reboot recovery"
- You can do the same with an adb shell, open a shell and type the commands from above, they're the same
- There also are apps for rebooting to recovery or other targets. Just search around in PlayStore
- The good old "button dance" When phone is powered off, press the volume down key and power button at the same time. When a first sign of life is seen on display, immediately release the power button, but just to instantly press it again. A menu will show, which wants you to do a factory reset: do it You have to confirm this two times, and afterwards TWRP will boot without performing a factory reset. TWRP is compiled with a flag which recognizes this procedure and hinders the bootloader to pass the command for factory resetting.
This time no optional version of TWRP is available, it's "one for all". This TWRP works for every V30 model, and only for them. I removed vendor partition too btw, there isn't any active development about that, so it's useless and only confuses ppl. DataImage function is available.
If you want to use data_image, system_image or internal storage included in data backup, first check your filesystem on your external sdcard. It needs to be capable of writing big files, which isn't the case with fat/fat16/fat32. You need exFAT (for stock) or ext4/ntfs (only available with custom kernel and/or AOSP based builds).
CHANGELOG:
February 23rd, 2020, TWRP 3.3.1-2:
- corrected blocksize for formatting crypto related partitions
- included timezone data, maybe helps some ppl with time still not showing correct; should speed up time calc
- used pre-compiled full mke2fs and e2fsdroid binaries
- enabled ntfs experimental support (rw in kernel, NTFS_3G flag in twrp / ofox)
- minimal tweaks
- enabled F2FS and NTFS support
January 1st, 2020, TWRP 3.3.1-1:
- Formatting problem solved, TWRP now removes crypto as it should when user initiates a data format
- small fixings like checkbox layout in restore menu
- Moved a LOGERR to LOGINFO: "E: Unable to decrypt FBE device". Couldn't get rid of it with our needed config...
Dec. 30th, 2019, TWRP 3.3.1-0:
- initial first version
- almost everything working like in 3.2 oreo TWRP
- Formatting your device doesn't remove crypto from disk, so a "fresh" (formatted) userdata gets disturbed by old security lock
DOWNLOADS:
Nougat, Oreo and Pie capable 3.3.1-0 TWRP, but decrypting support only for PIE (AOSP untested, stock confirmed):
Download links below (always the latest and newest only; one version for all):
File name: TWRP-JOAN-3312_2020-02-23.img
MD5sum: 2fd78a606b65274977f1cd63080d5f23
MAIN Download: MEGA, TWRP-JOAN-3312_2020-02-23.img
As always: Use it at your own risk! You are the one who changes stuff on your phone, I'm not responsible for anything which happens to your phone. TWRP is powerful, be careful at what you do with it :good: And it just works.
All you need to compile this yourself:
[url]https://github.com/seader/android_device_lge_joan-twrp[/url]
[url]https://github.com/minimal-manifest-twrp/platform_manifest_twrp_omni[/url]
[url]https://github.com/seader/android_kernel_lge_msm8998[/url] (not really needed as a prebuilt kernel is used)
[url]https://github.com/seader/bootable_recovery-twrp[/url] (copy of twrp recovery with the stuff added. Pie is "encrypt-9.0" branch. omni's android-9.0 branch almost fully compatible, beside not being able to remove crypto (dirty hack, sry )
Much appreciated for your hard work. Twrp after all is the base for all customization
Thanks!
sure, enjoy it
btw, is there someone with oreo encrypted...? would be nice to know if it's decryptable with this new twrp too, and we therefore only need this one (and the other one can be archived...?)?
which is spoken very early, there's a lot left to do for 3.3 running really flawlessly. but, of course, this will be continued and being further worked on :good: starting right now xD
@ChazzMatt: it will take a while until wtf can be updated with this new one here. this is in an late beta stage, it works but has some quirks left. nothing that can destroy a phone but this twrp isn't fully working at this point of time and therefore not possible to use "in productive threads".
Everything works as well as the previous stable recovery.
I have tried:
1. backing up and restoring ROMs
2. Flashing, ROMs(stock pie and aosp Q), kernels and other mods.
Big thanks ??
In my case time is still not correct, I have to choose a different timezone compared to actual.... When booted up normally, it is correct.
kanehun said:
In my case time is still not correct, I have to choose a different timezone compared to actual.... When booted up normally, it is correct.
Click to expand...
Click to collapse
it needs some boots and reboots to recovery. after setting up everything it showed in twrp as it should :good: i'll add the tzdata back, a registry of all timezones, used for calculation of time, maybe it helps.
Time zone is beyond screwed up, 3 hours off without DST. Also, I'm on Oreo and it's asking for the decrypt password to access internal SD.Going back to 3.2.3-7.
ldeveraux said:
, I'm on Oreo and it's asking for the decrypt password to access internal SD.Going back to 3.2.3-7.
Click to expand...
Click to collapse
Try using the Pie compatible Decryption Disabler and then Reformatting data...
Have you tried flashing the @Zackptg5 Disable_Dm-Verity_ForceEncrypt_08.18.2019 (encryption disabler) before reformatting?
Flash Magisk,
Flash Pie-compatible encryption disabler,
Flash JohnFawkes Root Checker disabler,
Reformat data (where you type yes),
Reboot to recovery from within TWRP,
Flash Magisk AGAIN,
Reboot phone.
See this post: https://forum.xda-developers.com/showpost.php?p=79972563&postcount=107
_____________
7. MORE TWRP ACTIONS - Now turn off data encryption and install essential items… all in TWRP:
(This is not a "menu" in TWRP, it's merely a list of what you NEED to do before booting to the OS)
a. Wipe Data – Factory Reset
b. Install – set storage to the External SD (if you have a microSD card) OR drag necessary files over from PC once in TWRP.
c. Install the Magisk zip. (This is to give the encryption disabler root privileges)
d. Install @Zackptg5 Disable_Dm-Verity_ForceEncrypt_08.18.2019 (encryption disabler).
e. Install @JohnFawkes AnyKernel 3 RCTD Remover (root checker disabler); this disables LG's firmware root checks, which may impede performance.
f. FORMAT DATA (Select WIPE, then FORMAT DATA, then select yes.)
Do NOT delete your OS, but you do need to FORMAT your data , not just "wipe" it this time. Otherwise you may get an encryption error when you boot up the first time. If you get any red mount errors, go back to the TWRP reboot menu and select reboot to recovery and try to FORMAT DATA again. Then, after successfully formatting...
g. Reboot – "Reboot Recovery" from TWRP reboot menu (choose to reboot back to Recovery). Now that the data partition has been formatted, TWRP needs to reload the recovery partition for usage. If you skip this step, when Magisk is installed again below, it may think that /data is still encrypted and set "preserve force encryption". This is also a good sanity check that LG encryption has been removed from /data.
h. Re-flash the Magisk zip again. (This is to make sure, due to Pie changes.)
i. Reboot – to System (NOW you are finally rebooting your phone! Until now this whole section has been done within TWRP.)
ChazzMatt said:
Try using the Pie compatible Decryption Disabler and then Reformatting data...
Have you tried flashing the @Zackptg5 Disable_Dm-Verity_ForceEncrypt_08.18.2019 (encryption disabler) before reformatting?
Flash Magisk,
Flash Pie-compatible encryption disabler,
Flash Root Checker disabler,
reformat data (where you type yes),
reboot to recovery from within TWRP,
flash Magisk AGAIN,
reboot phone.
See this post: https://forum.xda-developers.com/showpost.php?p=79972563&postcount=107
_____________
7. MORE TWRP ACTIONS - Now turn off data encryption and install essential items… all in TWRP:
(This is not a "menu" in TWRP, it's merely a list of what you NEED to do before booting to the OS)
a. Wipe Data – Factory Reset
b. Install – set storage to the External SD (if you have a microSD card) OR drag necessary files over from PC once in TWRP.
c. Install the Magisk zip. (This is to give the encryption disabler root privileges)
d. Install @Zackptg5 Disable_Dm-Verity_ForceEncrypt_08.18.2019 (encryption disabler).
e. Install @JohnFawkes AnyKernel 3 RCTD Remover (root checker disabler); this disables LG's firmware root checks, which may impede performance.
f. FORMAT DATA (Select WIPE, then FORMAT DATA, then select yes.)
Do NOT delete your OS, but you do need to FORMAT your data , not just "wipe" it this time. Otherwise you may get an encryption error when you boot up the first time. If you get any red mount errors, go back to the TWRP reboot menu and select reboot to recovery and try to FORMAT DATA again. Then, after successfully formatting...
g. Reboot – "Reboot Recovery" from TWRP reboot menu (choose to reboot back to Recovery). Now that the data partition has been formatted, TWRP needs to reload the recovery partition for usage. If you skip this step, when Magisk is installed again below, it may think that /data is still encrypted and set "preserve force encryption". This is also a good sanity check that LG encryption has been removed from /data.
h. Re-flash the Magisk zip again. (This is to make sure, due to Pie changes.)
i. Reboot – to System (NOW you are finally rebooting your phone! Until now this whole section has been done within TWRP.)
Click to expand...
Click to collapse
No, that's an insane amount of hassle for no apparent gain! I'm just sticking with the older TWRP [emoji6]
ldeveraux said:
No, that's an insane amount of hassle for no apparent gain! I'm just sticking with the older TWRP [emoji6]
Click to expand...
Click to collapse
Were you already on a decrypted ROM using the older version of TWRP? Trying to figure out if the same encrypted internal storage situation will happen to me if I bother to try this Pie version of TWRP. Just would stick with Oreo TWRP if it's going to be this whole hassle to upgrade.
Thanks!
:victory: thank you seadersn!
ldeveraux said:
No, that's an insane amount of hassle for no apparent gain! I'm just sticking with the older TWRP [emoji6]
Click to expand...
Click to collapse
It's the exact steps people have to do when installing TWRP to work with bootloader unlocked Pie KDZ.
We needed new Encryption Disabler and we needed new Root Checker Disabler and we needed to flash Magisk twice.
The order of steps had to be rewritten besides new files.
Those have been in effect ever since EU H930 got Pie. Works on Oreo AND Pie bootloader unlocked KDZ.
drewcu said:
Were you already on a decrypted ROM using the older version of TWRP? Trying to figure out if the same encrypted internal storage situation will happen to me if I bother to try this Pie version of TWRP. Just would stick with Oreo TWRP if it's going to be this whole hassle to upgrade.
Thanks!
Click to expand...
Click to collapse
I'm on the TWRP flashable US99820H, so no clue
ChazzMatt said:
It's the exact steps people have to do when installing TWRP to work with bootloader unlocked Pie KDZ.
Those have been in effect ever since EU H930 got Pie.
Click to expand...
Click to collapse
I guess. I don't have Pie and don't plan on updating soon. I don't even know what the decryption password was all about. My TWRP was working fine, I've learned one thing with Android: if it ain't broke...
ldeveraux said:
I'm on the TWRP flashable US99820H, so no clue
I guess. I don't have Pie and don't plan on updating soon. I don't even know what the decryption password was all about. My TWRP was working fine, I've learned one thing with Android: if it ain't broke...
Click to expand...
Click to collapse
Any TWRP flashable ROM was likely decrypted and is similar to my situation (except I'm on Pie VS99630c). Sounds like upgrading to TWRP 3.3.1 Pie is more hassle than it's worth and I'll stay put.
Thanks.
ldeveraux said:
I'm on the TWRP flashable US99820H, so no clue
I guess. I don't have Pie and don't plan on updating soon. I don't even know what the decryption password was all about. My TWRP was working fine, I've learned one thing with Android: if it ain't broke...
Click to expand...
Click to collapse
Sure. I'm still on stock rooted Oreo firmware, also.
But those two new files, different order of steps work with both Oreo AND Pie Bootloader Unlocked KDZ with 3 2.3.7 -- whereas the older method and (with original decryption and root check disabler files) were in place before Pie.
WTF has always had decryption and root check disabler files and reformat of data to install TWRP.
What's different now is newer files to be effective on Pie KDZ as well as different order of steps -- as well as flashing Magisk at the beginning and again at the end.
I am hoping those files and steps also work with this new TWRP 3.3.1.
---------- Post added at 05:54 PM ---------- Previous post was at 05:51 PM ----------
drewcu said:
Any TWRP flashable ROM was likely decrypted and is similar to my situation (except I'm on Pie VS99630c). Sounds like upgrading to TWRP 3.3.1 Pie is more hassle than it's worth and I'll stay put.
Thanks.
Click to expand...
Click to collapse
Those files and steps I posted work with all Pie KDZ on 3.2.3.7. If they don't work on this 3.3.1 that's strange.
ChazzMatt said:
Sure. I'm still on stock rooted Oreo firmware, also.
But those two new files, different order of steps work with both Oreo AND Pie Bootloader Unlocked KDZ with 3 2.3.7 -- whereas the older method and (with original decryption and root check disabler files) were in place before Pie.
WTF has always had decryption and root check disabler files and reformat of data to install TWRP.
What's different now is newer files to be effective on Pie KDZ as well as different order of steps -- as well as flashing Magisk at the beginning and again at the end.
I am hoping those files and steps also work with this new TWRP 3.3.1.
---------- Post added at 05:54 PM ---------- Previous post was at 05:51 PM ----------
Those files and steps I posted work with all Pie KDZ on 3.2.3.7. If they don't work on this 3.3.1 that's strange.
Click to expand...
Click to collapse
I am on John Fawkes' Pie VS99630c TWRP flashable ZIP using TWRP 3.2.3.7. The concern is whether upgrading TWRP to 3.3.1 is as simple is flashing the IMG file within TWRP 3.2.3.7, or whether we'll have to reflash multiple things in a whole list of steps. If it's the latter, then why not just stay on TWRP 3.2.3.7 which seems to do everything we need in terms of flashing Pie ROMs?
ChazzMatt said:
Those files and steps I posted work with all Pie KDZ on 3.2.3.7. If they don't work on this 3.3.1 that's strange.
Click to expand...
Click to collapse
it's only formatting data switched to "fastboot -w" (reformats cache and data) or "fastboot erase userdata" (reformats data). both remove eventually present encryptions. everything else works like in the default wtf recovery :good: and that's really an enerving point... i want to simply format my userdata in twrp and not have to switch to fastboot...
formatting now works :good:
drewcu said:
I am on John Fawkes' Pie VS99630c TWRP flashable ZIP using TWRP 3.2.3.7. The concern is whether upgrading TWRP to 3.3.1 is as simple is flashing the IMG file within TWRP 3.2.3.7, or whether we'll have to reflash multiple things in a whole list of steps. If it's the latter, then why not just stay on TWRP 3.2.3.7 which seems to do everything we need in terms of flashing Pie ROMs?
Click to expand...
Click to collapse
it's the first: flashing image easily. only thing is, as described above, removing encryption requires fastboot. atm not possible to do this in recovery as usual. therefore nod suitable for wtf thread, but for anybody else, especially the ones who have pie installed and want to acces their data in twrp when encrypted. i'll test oreo decryption compatibility soon, zip needs downloading time lol
oreo decryption compatibility not given with 3.3 but: you can easily migrate from encrypted oreo via fw zip to pie, it adopts the storage encryption then and 3.3 is able to unlock :good: i've got a solution for 3.3 not being able to remove encryption: i keep a copyof 3.2.3-7 image on external sd and install it when formatting needed xD then back to 3.3 and good to go.
workaround no more needed, working now

Is there any way to REFUSE the Android 10 update?

I've just received thenotification that my device will update to android 10 when I retart it.
I'm pretty happy with android 9 and I've read some mixed opinions on that update, so is there a way to prevent that?
yeah, you can do that. go to settings-> developer options and then turn off automatic system updates.
tonguyenducmanh said:
yeah, you can do that. go to settings-> developer options and then turn off automatic system updates.
Click to expand...
Click to collapse
Thanks!
zedacove said:
I've just received thenotification that my device will update to android 10 when I retart it.
I'm pretty happy with android 9 and I've read some mixed opinions on that update, so is there a way to prevent that?
Click to expand...
Click to collapse
It may be too late. If the slot to boot has already been changed...
If you have an unlocked bootloader you can set the slot from fastboot. Or something like TWRP.
Just never reboot again.
a1291762 said:
It may be too late. If the slot to boot has already been changed...
If you have an unlocked bootloader you can set the slot from fastboot. Or something like TWRP.
Just never reboot again.
Click to expand...
Click to collapse
Damn. Is there any way to check the current state of the slot to boot?
zedacove said:
Damn. Is there any way to check the current state of the slot to boot?
Click to expand...
Click to collapse
This is something I have tried to find out but so far I have not been able to figure it out.
If you have root, you can cat /proc/cmdline to see what slot the system booted with. Look for androidboot.slot_suffix=_b near the end (or it could be _a instead).
Then after you reboot to fastboot (adb reboot bootloader) you can use fastboot getvar current-slot to make sure it is the same. If it is not... fastboot set_active slot can apparently change it. I've never needed to do this so I cannot be sure.
I think that the fastboot commands require an unlocked bootloader. While there's instructions for unlocking your bootloader without losing data, plenty of people seem to have trouble making it work.
If you read the thread from when Android 10 first dropped (and broke half the phones), the "fix" was to use fastboot to change the slot (since Android 9 remains on the other slot after the upgrade). Maybe you can just let it install and then do that?
Thanks, This prevent update after Restart.
But is there a way to delete the UPDATE File which is more than 1 Go and How to prevent the phone to Download it again?
Or maybe with the A/B partitions the UPDATE file does not affect storage space and deleting this file would not give more space?
My A2 Lite does not see Android 10 update. System update says "system is up to dat" with last installed version V10.0.20 from 1 March 2020.
flexto said:
Thanks, This prevent update after Restart.
But is there a way to delete the UPDATE File which is more than 1 Go and How to prevent the phone to Download it again?
Or maybe with the A/B partitions the UPDATE file does not affect storage space and deleting this file would not give more space?
Click to expand...
Click to collapse
/data/ota holds temp files. They take space until installed.
Use the setting under settings, system, advanced, developer, automatic system updates.
morcio said:
My A2 Lite does not see Android 10 update. System update says "system is up to dat" with last installed version V10.0.20 from 1 March 2020.
Click to expand...
Click to collapse
You are a lucky guy!

Actual knowledge of system layout/file hierarchy?

Just purchased a 5z since it was on close out has nice specs for the price (except for battery mAh). But I've just run across an issue while trying to flash TWRP on the handset which now I'm sure everyone has missed since this handsets been released and all the guides are missing this as of 2020/July/25. So is there any actual dev working on this and not just piecemealing the hell out of code from other handsets to get half arse junk working?
Oh and for the actual knowledge i was refering too. TWRP on a FACTORY FRESH 5z will NOT LOAD unless both slots have loaded with an ROM how do I know this! Racked my brains for a day following incomplete guides trying to flash a factory 5z outta box from P nothing worked till I decided to try Q which at this point ASUS WW roms from P and under are in slot A once you goto Q it moves to slot B since I tried flashing TWRP in Q also but did not work since guides are trying to tell you there's a inactive slot (not how it works fella's) Once I used the asus downgrader to move my handset back to P (slot A) now TWRP worked since the old Q rom was populated in slot B still (so there is files or a directory needed that is missing when trying to flash from factory my guess a recovery.img) hopefully this will help any new owner (kinda late in the game yes)
Guess i'll need to start working on roms my ocd does not allow non-100%
A/B devices do not need a recovery partition or cache partition because Android no longer uses these partitions. The data partition is now used for the downloaded OTA package, and the recovery image code is on the boot partition. All partitions that are A/B-ed should be named as follows (slots are always named a, b, etc.): boot_a, boot_b, system_a, system_b, vendor_a, vendor_b.

Question Rooting with Magisk failed (FAILED (status read failed (Too many links)))

Hello everyone,
I have a new Xiaomi 11T EEA device, tried rooting it with the following steps, but failed:
- Updated to the latest official MIUI version (13.0.9.0)
- Unlocked bootloader with MiUnlock (shows the unlocked padlock at boot, and also in developer options)
- Downloaded the latest ROM with the updater app in phone (also tried from c.mi.com, same files, checked checksums)
- Used payload dumper at PC to extract the boot.img from the ROM
- Installed latest Magisk Manager (25.2) to the phone
- Pached the boot.img with Magisk
- Installed latest adb and drivers to my PC (restarted it after the install)
And then I tried booting the phone to the patched boot.img (fastboot boot patched_boot.img), but failed (even tried with the stock boot.img, same result):
downloading 'boot.img'...
OKAY [ 3.188s]
booting...
FAILED (status read failed (Too many links))
finished. total time: 11.135s
I tried with my PC, with another notebook, 3 different USB A to C cable, 2 different USB C to C cable (different orientations too), all of the USB ports on the devices, but I got the exact same result.
So far I succeeded with these steps with 3 other Xiaomi phones (Redmi Note7, Mi 9T, Poco F3), but not with this one, and I have no idea what else I can do.
I suspected it has something to do with MediaTek SOC, that's the only meaningful difference I can think of.
Does anyone have any idea what else I can try, or maybe have a working patched boot.img?
Thanks for reading it, have a nice day!
Once the boot modify install with Fastboot, use fastboot reboot.
NOSS8 said:
Once the boot modify install with Fastboot, use fastboot reboot.
Click to expand...
Click to collapse
Maybe I understand it wrong, but I didn't install the boot.img, and don't really want to install it until I am sure I don't soft brink the phone.
s-zoli said:
Maybe I understand it wrong, but I didn't install the boot.img, and don't really want to install it until I am sure I don't soft brink the phone.
Click to expand...
Click to collapse
Obviously if you don't flash the modified boot.img, the phone won't be rooted.
See here (different device but same method).
https://forum.xda-developers.com/t/root-xiaomi-11t-pro-on-latest-miui-13-working.4450535/
NOSS8 said:
Obviously if you don't flash the modified boot.img, the phone won't be rooted.
See here (different device but same method).
https://forum.xda-developers.com/t/root-xiaomi-11t-pro-on-latest-miui-13-working.4450535/
Click to expand...
Click to collapse
It will be rooted until reboot, which is fine for a temporary root and testing things before making it permanent.
From my understanding it should be working either way, booting to it, or flashing right away. Previously I tested the patched boot.img just by booting into it, and worked every time. At the Redmi phone when I tried to flash the boot.img (that was used to boot into and worked), it didn't boot and got stuck to fastboot, and had to flash back the original boot.img.
I read the mentioned thread, it's the same steps I did, except the last booting vs flashing with fastboot.
Am I missing some key information how the booting mechanism works?
s-zoli said:
It will be rooted until reboot, which is fine for a temporary root and testing things before making it permanent.
From my understanding it should be working either way, booting to it, or flashing right away. Previously I tested the patched boot.img just by booting into it, and worked every time. At the Redmi phone when I tried to flash the boot.img (that was used to boot into and worked), it didn't boot and got stuck to fastboot, and had to flash back the original boot.img.
I read the mentioned thread, it's the same steps I did, except the last booting vs flashing with fastboot.
Am I missing some key information how the booting mechanism works?
Click to expand...
Click to collapse
Newer devices have A/B partitions unlike old ones.
NOSS8 said:
Newer devices have A/B partitions unlike old ones.
Click to expand...
Click to collapse
So you are saying that flashing the boot.img replaces both A and B partition and will most probably work, even if booting into it doesn't?
s-zoli said:
So you are saying that flashing the boot.img replaces both A and B partition and will most probably work, even if booting into it doesn't?
Click to expand...
Click to collapse
The .img boot never replaces the partitions, I was answering that you had already rooted other but old devices, that is to say without A/B partitions.
And why do you want to root this model with soc MTK(No or few development for Xiaomi with Mediatek processors)?
NOSS8 said:
The .img boot never replaces the partitions, I was answering that you had already rooted other but old devices, that is to say without A/B partitions.
And why do you want to root this model with soc MTK(No or few development for Xiaomi with Mediatek processors)?
Click to expand...
Click to collapse
The Poco F3 is a newer phone, and I just checked with Treble Check app, that it has seamless system update, therefore A/B system partitions (and so does the 11T).
The reason is the same as for every other phone... customization, automations, battery management... etc.
The things that should be available for power users, not just in fancy gaming phones.
It just happens to have MTK instead of QC (like the 11T Pro).
Do you have any information if this SOC difference can affect the booting and therefore rooting it?
s-zoli said:
The Poco F3 is a newer phone, and I just checked with Treble Check app, that it has seamless system update, therefore A/B system partitions (and so does the 11T).
The reason is the same as for every other phone... customization, automations, battery management... etc.
The things that should be available for power users, not just in fancy gaming phones.
It just happens to have MTK instead of QC (like the 11T Pro).
Do you have any information if this SOC difference can affect the booting and therefore rooting it?
Click to expand...
Click to collapse
MTK=MediaTek
QC=Qualcomm
Change nothing at the root level.
Everything you want to optimize is possible without rooting, moreover you will have to install modules which themselves consume battery.
Except for personalization.
NOSS8 said:
MTK=MediaTek
QC=Qualcomm
Change nothing at the root level.
Everything you want to optimize is possible without rooting, moreover you will have to install modules which themselves consume battery.
Except for personalization.
Click to expand...
Click to collapse
Sure, you're right, but I already started the rooting process, the bootloader is unlocked, so I already lost a few things (Google Pay, Netflix... etc).
The only way out is re-lock the bootloader or find a way to install Magisk and modules for it.
We deviated a bit from the original question...
I haven't found any source of information what does "Too many links" error means?
Also I didn't find any information if I can easily get back to original state if flashing the supposedly good pached boot.img doesn't work. (bootloop, stuck at fastboot... etc)
My way of being somewhat sure it works was first booting to it, but that doeasn't work now, and it's suspicious for me that the flashing won't work either.
To have the play store certified, use Magisk + zygisk.
https://topjohnwu.github.io/Magisk/
https://www.droidwin.com/fix-status-read-failed-too-many-links/
Once the boot modify install with Fastboot, use fastboot reboot.
Long story short... I just went for it and flashed the patched boot.img, and it's working just fine.
I don't know why it didn't want to boot, but flashing worked and now I have root access.
NOSS8 said:
Obviously if you don't flash the modified boot.img, the phone won't be rooted.
See here (different device but same method).
https://forum.xda-developers.com/t/root-xiaomi-11t-pro-on-latest-miui-13-working.4450535/
Click to expand...
Click to collapse
thats snapdragon, and this is mediatek
will this work with mediatek? without specifying a/b partitions?
Code:
fastboot flash boot patched_boot.img
bluviper said:
thats snapdragon, and this is mediatek
will this work with mediatek? without specifying a/b partitions?
Code:
fastboot flash boot patched_boot.img
Click to expand...
Click to collapse
Check:
https://www.xda-developers.com/how-to-check-android-device-supports-seamless-updates/
getprop ro.build.ab_update
Then you will know which command to choose.
NOSS8 said:
Check:
https://www.xda-developers.com/how-to-check-android-device-supports-seamless-updates/
getprop ro.build.ab_update
Then you will know which command to choose.
Click to expand...
Click to collapse
i have the a/b partition
bluviper said:
i have the a/b partition
Click to expand...
Click to collapse
So,use
fastboot flash boot_a patched_boot.img
fastboot flash boot_b patched_boot.img
or
fastboot flash boot_ab patched_boot.img
fastboot reboot
I just flashed without _a _b or _ab and it flashed still to both slots

Categories

Resources