So I just installed twrp 3.2.2 using the img and then flashing the zip file and it seemed to work correctly, however when I tried to reboot the system, it became stuck on the loading screen, the one with the red dot that moves around. Then I went into the twrp install menu and saw that for the sdcard menu, I have a bunch of files that are just a series of letters like 7kWTXiU752ZJOHWv9DjsYD. Does anyone know how to fix this? Never seen this error before.
blaster42 said:
So I just installed twrp 3.2.2 using the img and then flashing the zip file and it seemed to work correctly, however when I tried to reboot the system, it became stuck on the loading screen, the one with the red dot that moves around. Then I went into the twrp install menu and saw that for the sdcard menu, I have a bunch of files that are just a series of letters like 7kWTXiU752ZJOHWv9DjsYD. Does anyone know how to fix this? Never seen this error before.
Click to expand...
Click to collapse
the quick and dirty way of fixing would be to format data in twrp and phone will boot. the series of number is your files on the phone that are encrypted. When you first start twrp. it should have asked for password which is your lock screen password. You could try installing Magisk-v16.7 link https://forum.xda-developers.com/apps/magisk/beta-magisk-v13-0-0980cb6-t3618589. it could allow the os to boot.
MrSteelX said:
the quick and dirty way of fixing would be to format data in twrp and phone will boot. the series of number is your files on the phone that are encrypted. When you first start twrp. it should have asked for password which is your lock screen password. You could try installing Magisk-v16.7 link https://forum.xda-developers.com/apps/magisk/beta-magisk-v13-0-0980cb6-t3618589. it could allow the os to boot.
Click to expand...
Click to collapse
Huh, it never asked for the lock screen password. My password wasn't set up when I first installed twrp.
blaster42 said:
Huh, it never asked for the lock screen password. My password wasn't set up when I first installed twrp.
Click to expand...
Click to collapse
if no password is setup, then it would not ask 1. are you on stock 5.1.9?
MrSteelX said:
if no password is setup, then it would not ask 1. are you on stock 5.1.9?
Click to expand...
Click to collapse
Yup
blaster42 said:
Yup
Click to expand...
Click to collapse
here is patch boot.img http://www.mediafire.com/file/4gbcsjd1ph41140/boot.img/file
fastboot flash boot_a boot.img
fastboot flash boot_b boot.img
you will still need to flash twrp again after flashing this if you want twrp.
MrSteelX said:
here is patch boot.img http://www.mediafire.com/file/4gbcsjd1ph41140/boot.img/file
fastboot flash boot_a boot.img
fastboot flash boot_b boot.img
you will still need to flash twrp again after flashing this if you want twrp.
Click to expand...
Click to collapse
I've formatted data and now my phone boots again, so thanks so much for the help. I rebooted into recovery and still have twrp on there, is it a faulty one? Should I reflash? Will these img work with twrp 3.2.2?
The phone defaults to being encrypted . . .
I would give myself a security PIN number first and power off and on to see the PIN is working okay first.
Hello,
it is my first time modding my phone (Sony XZ2c) and unfortunately I have run into some issues. Let's start with what I have got working:
bootloader unlocked, Lineage OS 17.1 installed, root access by magisk. I was trying to install Viper4Android using this tutorial:
[MOD][V4a][TUTORIAL] ViPER4Android - How to install
Thread to be closed.
forum.xda-developers.com
Unfortunately, after rebooting I get stuck on Sony logo. I can get into fastboot and boot from twrp image but my data storage is encrypted. I tried uninstalling magisk by sideloading uninstaller and flashing boot with stock Lineage OS boot image without success. Is there anything else I can do?
I do not mind wiping everything but: I would like to recover my contacts and photos, plus I spent a lot of time configuring my system and apps so I would like to avoid doing it all again...
Thanks for help!
ML11 said:
Hello,
it is my first time modding my phone (Sony XZ2c) and unfortunately I have run into some issues. Let's start with what I have got working:
bootloader unlocked, Lineage OS 17.1 installed, root access by magisk. I was trying to install Viper4Android using this tutorial:
[MOD][V4a][TUTORIAL] ViPER4Android - How to install
Thread to be closed.
forum.xda-developers.com
Unfortunately, after rebooting I get stuck on Sony logo. I can get into fastboot and boot from twrp image but my data storage is encrypted. I tried uninstalling magisk by sideloading uninstaller and flashing boot with stock Lineage OS boot image without success. Is there anything else I can do?
I do not mind wiping everything but: I would like to recover my contacts and photos, plus I spent a lot of time configuring my system and apps so I would like to avoid doing it all again...
Thanks for help!
Click to expand...
Click to collapse
There is an adb command to delete all magisk modul;es, while keeping magisk. I dont have the link right now.
Personally, I would go into TWRP and delete the viper folder under /data/adb/modules and also check (ie delete) for scripts in /data/adb/post-fs-data.d and /data/adb/service.d
If the above doesn't work, you've got details on other methods here:
https://www.didgeridoohan.com/magisk/Magisk#hn_Disablinguninstalling_modules_manually
DiamondJohn said:
There is an adb command to delete all magisk modul;es, while keeping magisk. I dont have the link right now.
Personally, I would go into TWRP and delete the viper folder under /data/adb/modules and also check (ie delete) for scripts in /data/adb/post-fs-data.d and /data/adb/service.d
Click to expand...
Click to collapse
/data/adb is encrypted unfortunately...
adb wait-for-device shell magisk --remove-modules
This does not work. The phone reboots and get stuck on Sony logo. I guess it only works when the device gets stuck on OS, otherwise adb cannot access the device?
I am wondering why the device does not boot after flashing stock Lineage OS boot image? After staying on Sony logo for a while it gets into fastboot again (blue LED and fastboot detects the device).
ML11 said:
/data/adb is encrypted unfortunately...
adb wait-for-device shell magisk --remove-modules
This does not work. The phone reboots and get stuck on Sony logo. I guess it only works when the device gets stuck on OS, otherwise adb cannot access the device?
I am wondering why the device does not boot after flashing stock Lineage OS boot image? After staying on Sony logo for a while it gets into fastboot again (blue LED and fastboot detects the device).
Click to expand...
Click to collapse
Let nme start by saying, I have NO experience with encrypted phone recovery, but I do understand you wish to keep your data & config. To check your phone, I would try making a nandroid (of the current broken image), flashing a clean image to see if that boots, and its not something deeper in the ROM or the physical phone.
And again, no experience with recovering an encrypted device, have you tried flashing the boot AND system? ie a dirty flash? This would probably be the first attempt, after a nandroid of course.
DiamondJohn said:
have you tried flashing the boot AND system? ie a dirty flash?
Click to expand...
Click to collapse
Could you please explain exactly how to do that? I have: stock Lineage OS recovery image, Lineage OS flashable zip and images extracted from the payload file from the zip: boot, dtbo, system, vbmeta, vendor. What commands should I use?
Is fastboot flash boot boot.img and fastboot flash system system.img correct?
Should I flash both boot_a and boot_b?
Amazing! after flashing boot_a and boot_b and system my phone boots correctly to Lineage OS.
The only thing that I see is the wallpaper and "Phone is starting". Now how should I get back to the state before installing this module? I made a backup of system partition by adb and twrp.
EDIT: I have access to the settings so I managed to uninstall Viper4Android and reboot to safe mode. Still trying!
Unfortunately, due to encryption I am still not able to access photos but I see the files are still there. Should I now restore the system in twrp? Partitions that I can restore: system image, system, vendor image, boot, oem_image, oem. I have also a backup from adb using this command adb backup --twrp system boot. How should I proceed to get everything working again (Viper4Android is uninstalled, I flashed magisk boot again and used magisk --remove-modules so all the modules should be removed). Is is safe to restore now? Which partitions should I restore?
I flashed boot_a boot_b and system (fastboot used system_b).
Any ideas how I should proceed? I tried to restore system and system image in twrp but the phone does not seem to boot. If I just pull or copy the encrypted data, wipe and reinstall the system and then move the data back, will this work and I will be able to access the data when I boot to the system?
After a lot trials I gave up and decided to wipe everything and reflash the system... Fortunately, the most important stuff had been backed up before. Thanks @Didgeridoohan and @DiamondJohn for help!
It seems the trick is to manually sideload OTA upgrade, then flash vbmeta and patched boot image, all without rebooting in between.
Important Notes:
DO NOT take the OTA directly from your phone's System Upgrade settings item.
This assumes you already wiped your phone once going from 11 to the 12 beta!
In order to get root in 12b5 you had to flash the beta image with --disable-verification and --disable-verity which would force a wipe before you could boot the Magisk patched boot image.
Other guides showed how to do this; e.g., https://forum.xda-developers.com/t/guide-flash-magisk-on-android-12.4242959/post-84605557
So, if you have already flashed the 12 beta with --disable-verification and --disable-verity, and currently have root, here is the general procedure:
Try to make sure you have the latest ADB binary before starting this.
Download release factory AND OTA images from https://developers.google.com/android/images
Extract vbmeta.img and boot.img from the factory image
Patch boot.img using Magisk App on 12b5 phone and pull back to your PC
sideload the OTA image. Then without reboot, switch to fastboot mode
Bash:
$ adb reboot sideload
$ adb sideload redfin-ota-sp1a.210812.015-2596fc07.zip
DO NOT REBOOT AFTER THIS!
Once OTA upgrade is complete, you should be dropped into recovery menu.
Pick "Boot to fastboot"
Pick "Reboot to bootloader"
V0latyle said:
Turns out we should flash vbmeta in bootloader, not fastbootd.
The CRITICAL issue is to not allow the device to boot into system until vbmeta has been disabled. If this happens, a wipe will be required when it is disabled again.
…
What I believe we have to do, as pointed out by @Anonshe , is that we have to reflash vbmeta in bootloader, not fastbootd - and we must not allow the kernel to boot until that is done. Meaning, directly following OTA sideload, immediately reboot into bootloader and reflash vbmeta to both slots with disable flags.
Click to expand...
Click to collapse
flash vbmeta.img; make sure verity is disabled still (you already disabled it when you installed the 12 beta, remember?)
Bash:
$ fastboot --disable-verity --disable-verification flash vbmeta vbmeta.img
STILL DO NOT REBOOT AFTER THIS!
flash magisk_patched_boot.img
Bash:
$ fastboot flash boot magisk_patched-23001_XXXXX.img
NOW you can reboot
Bash:
$ fastboot reboot
Check your magisk, safetynet, gpay, etc.
Optional: Reboot and check again if you want to really be sure, then breathe sigh of relief when root+data are still intact
Has anyone tried this way?
If this works coming from the 12 Beta, I don't see why it wouldn't work coming from Android 11.
I'm guessing this wouldn't work if you're already on the stable A12 release unrooted?
Any insight on what exactly necessitates the wipe between 11 and 12?
killchain said:
Any insight on what exactly necessitates the wipe between 11 and 12?
Click to expand...
Click to collapse
At this point, a lot of guesses, but nothing has been pinpointed. We're basically at the point where we understand that there is a problem, we used to know how to get around it, but our method doesn't seem to work on 12 Stable.
So when the 12 Beta came out, it became quickly apparent that we couldn't just patch and flash the boot image like we had on Android 11. This caused a verification error in bootloader, that we figured out was caused by Android Boot Verification. Flashing /vbmeta with the --disable-verity and --disable-verification flags allowed us to flash /boot with a patched image, and all was well - at least for root. I'm not sure who, if anyone, was able to upgrade from 11 to 12 Beta without wiping /data.
Now on 12 Stable, it seems that we have a new problem - you can only boot without wiping data post upgrade if you leave everything stock. If you don't wipe, AND try to disable verity and verification, the kernel will begin to load, but then will reboot you into recovery with a data corruption message.
Why exactly this is happening is as yet unknown.
It's possible, even likely, that the boot image (which contains kernel and recovery) itself has some sort of boot verification that also must be disabled, most likely through modification of the image itself. Magisk used to have the capability to do this but it was removed some time ago.
It has been suggested that the bootloader is causing this, but the flaw in that theory is that everything passes the initial verification, and it's only when the kernel begins to load that we encounter the problem.
The really confusing thing is that this all seems to hinge on a data wipe. If you upgrade with a wipe, there's no issue disabling AVB and flashing a patched boot image. Doing the same thing post upgrade without a wipe causes the data verification error, but leaving everything stock works, and we are also able to temporarily boot patched images if /vbmeta and /boot are both untouched.
I really hope this doesn't necessitate a wipe after every monthly update since there is a new boot image every single month. That would really suck!
rester555 said:
I really hope this doesn't necessitate a wipe after every monthly update since there is a new boot image every single month. That would really suck!
Click to expand...
Click to collapse
Agreed. And since we don't know exactly what the issue is, it's impossible to say.
PablosCorner said:
I'm guessing this wouldn't work if you're already on the stable A12 release unrooted?
Click to expand...
Click to collapse
I am bumping this reply... Wouldn't this guide apply to someone unrooted on A12 as well?
rester555 said:
I am bumping this reply... Wouldn't this guide apply to someone unrooted on A12 as well?
Click to expand...
Click to collapse
Potentially, but your mileage may vary.
@HumorBaby I'd like to point out that this method only flashes the active slot, and you can't flash both slots from fastboot. You can switch slots in bootloader but that seems to break the whole deal. I'm not completely sure when the phone would switch slots anyway, most likely after an automatic OTA, so while this should work going forward, we'll have to ensure everyone knows to avoid the automatic OTA.
This is what I tried:
-Sideloaded OTA
-Entered fastboot, flashed /vbmeta and /boot
-Rebooted, confirmed I still had root
-Rebooted to bootloader, switched slots, rebooted to recovery, re entered fastboot
-Flashed /vbmeta and /boot again
-Rebooted, got dumped in recovery with the Corrupted Data message
I'm going to have to try everything all over again when I get home today. I'm using the same patched image with the same version of Magisk that worked before, but I don't have root for some odd reason.
I think what I'll do is start in fastboot, then reflash both a and b sides of everything with stock images - I wish we could do this via Android Flash Tool but force flash all partitions requires a data wipe.
Then, switch to slot A, reboot to recovery, apply OTA, enter fastboot, flash vbmeta with disable flags, flash patched boot, confirm successful boot and root.
Then, switch to slot B, and try to do the same thing.
V0latyle said:
This is what I tried:
-Sideloaded OTA
-Entered fastboot, flashed /vbmeta and /boot
-Rebooted, confirmed I still had root
Click to expand...
Click to collapse
Any chance you (or anyone else) tried this for the Nov patch (sp1a.211105)
I tried it this AM and ended up having to wipe.
But I think this was because in my hurry I forgot to patch the boot image on my phone first, and didn't remember until I had sideloaded OTA and dropped to fastbootd. Then, I had to use my Magisk 23001 (same version I am currently running on Pixel 5) on my Pixel 2XL to patch the 5's boot image.
After flashing vbmeta and patched boot (using Magisk on Pixel 2XL), a reboot took me to a system that didn't have root. I am hoping this is because the boot image was patched on a Pixel 2XL and not a 5, and not because the OTA/slot-issues have once again required a wipe even for simple monthly updates
I have just finished restoring and don't want to go through a series of wipe/install/tests if I don't have to .
V0latyle said:
-Rebooted to bootloader, switched slots, rebooted to recovery, re entered fastboot
-Flashed /vbmeta and /boot again
-Rebooted, got dumped in recovery with the Corrupted Data message
I'm going to have to try everything all over again when I get home today. I'm using the same patched image with the same version of Magisk that worked before, but I don't have root for some odd reason.
I think what I'll do is start in fastboot, then reflash both a and b sides of everything with stock images - I wish we could do this via Android Flash Tool but force flash all partitions requires a data wipe.
Then, switch to slot A, reboot to recovery, apply OTA, enter fastboot, flash vbmeta with disable flags, flash patched boot, confirm successful boot and root.
Then, switch to slot B, and try to do the same thing.
Click to expand...
Click to collapse
Related to this (and my previous post), in order to try to salvage my failed root, I did exactly this: reboot to bootloader, switch slots, flash vbmeta and patched boot (patched on Pixel 5 this time). I had the same result: Corruped Data.
My point is: I have a feeling that switching slots is going to reset your "successful boot with disable-verity and disable-verification", which will once again force a wipe… i'm curious to see what you find, as if you do end up having to wipe, this would support my understanding/guess as to what the new bootloader that came with 12b5 (and onwarrds) is doing in regards to storing boot state (based on what I parsed from this section about AVB onward)
HumorBaby said:
Any chance you (or anyone else) tried this for the Nov patch (sp1a.211105)
I tried it this AM and ended up having to wipe.
But I think this was because in my hurry I forgot to patch the boot image on my phone first, and didn't remember until I had sideloaded OTA and dropped to fastbootd. Then, I had to use my Magisk 23001 (same version I am currently running on Pixel 5) on my Pixel 2XL to patch the 5's boot image.
After flashing vbmeta and patched boot (using Magisk on Pixel 2XL), a reboot took me to a system that didn't have root. I am hoping this is because the boot image was patched on a Pixel 2XL and not a 5, and not because the OTA/slot-issues have once again required a wipe even for simple monthly updates
I have just finished restoring and don't want to go through a series of wipe/install/tests if I don't have to .
Click to expand...
Click to collapse
Turns out we should flash vbmeta in bootloader, not fastbootd.
The CRITICAL issue is to not allow the device to boot into system until vbmeta has been disabled. If this happens, a wipe will be required when it is disabled again.
I successfully updated to the November patch exactly like this:
- Sideloaded the OTA in recovery, immediately rebooted to bootloader
- Flashed vbmeta:
Code:
fastboot flash vbmeta --disable-verity --disable-verification --slot=all vbmeta.img
I flashed to both slots because the OTA is typically an out of band update, and I wanted to be safe.
- Booted the patched boot image; got stuck on Google logo with loading bar, so forced reboot and allowed device to boot
- Rebooted to bootloader, booted patched image, confirmed root was working, performed Direct Install, rebooted again, root was retained.
Then, for the sake of proof, I dirty flashed the factory image through Android Flash Tool with verity and verification disabled, and let the device reboot into unrooted system. Rebooted to bootloader, flashed patched boot image, rebooted into rooted system.
As for losing root, it's possibly because you patched Magisk with a different device, as Magisk does leave a signature on the patch.
Try re-patching the stock boot image on the Pixel 5, then boot it and see if it works.
HumorBaby said:
Related to this (and my previous post), in order to try to salvage my failed root, I did exactly this: reboot to bootloader, switch slots, flash vbmeta and patched boot (patched on Pixel 5 this time). I had the same result: Corruped Data.
My point is: I have a feeling that switching slots is going to reset your "successful boot with disable-verity and disable-verification", which will once again force a wipe… i'm curious to see what you find, as if you do end up having to wipe, this would support my understanding/guess as to what the new bootloader that came with 12b5 (and onwarrds) is doing in regards to storing boot state (based on what I parsed from this section about AVB onward)
Click to expand...
Click to collapse
That method failed for me too.
What I believe we have to do, as pointed out by @Anonshe , is that we have to reflash vbmeta in bootloader, not fastbootd - and we must not allow the kernel to boot until that is done. Meaning, directly following OTA sideload, immediately reboot into bootloader and reflash vbmeta to both slots with disable flags.
Alternatively, you can dirty flash the system image with the disable flags.
This seems to be the trick. Once vbmeta has been disabled, it must be kept disabled, and if it gets reflashed without the disable flags for any reason, the device must not leave bootloader until it is disabled again, otherwise a wipe is required.
This is why the automatic OTA requires a wipe to re-root - because it writes /vbmeta without the disable flags, then reboots.
I don't see why switching slots would do it.
V0latyle said:
Turns out we should flash vbmeta in bootloader, not fastbootd.
Click to expand...
Click to collapse
Yep, I realized that this may be the main culprit, since as you noted, OTA works by updating the non-current slot, then switches after a reboot.
V0latyle said:
What I believe we have to do, as pointed out by @Anonshe , is that we have to reflash vbmeta in bootloader, not fastbootd - and we must not allow the kernel to boot until that is done. Meaning, directly following OTA sideload, immediately reboot into bootloader and reflash vbmeta to both slots with disable flags.
Alternatively, you can dirty flash the system image with the disable flags.
This seems to be the trick. Once vbmeta has been disabled, it must be kept disabled, and if it gets reflashed without the disable flags for any reason, the device must not leave bootloader until it is disabled again, otherwise a wipe is required.
Click to expand...
Click to collapse
Thinking back and looking at the old ouput from my commands showed that OTA much has updated _a for me, but since I was in _b, fastboot flash vbmeta/patched-boot was put in _b. Then, reboot changed to _a, and a successful boot reset the verity flag and forced a wipe upon any subsequent actions.
My gut was telling me that I needed to be more aware/thoughtful of the slots as I was doing it, but I ignored it. Lesson learned.
V0latyle said:
Try re-patching the stock boot image on the Pixel 5, then boot it and see if it works.
Click to expand...
Click to collapse
I did try this once I realized I didn't have root, but at this point it was already too late since slot_a already booted without a disabled verity/verification.
V0latyle said:
I don't see why switching slots would do it.
Click to expand...
Click to collapse
Nope, just was floundering. Was hoping since I flashed vbmeta/patched boot into _b, a switch would get me root and bootloader would respect the disabled-verity during flash. However, knowing now that verity status is stored in userdata, it makes sense that it wouldn't work.
HumorBaby said:
Yep, I realized that this may be the main culprit, since as you noted, OTA works by updating the non-current slot, then switches after a reboot.
Thinking back and looking at the old ouput from my commands showed that OTA much has updated _a for me, but since I was in _b, fastboot flash vbmeta/patched-boot was put in _b. Then, reboot changed to _a, and a successful boot reset the verity flag and forced a wipe upon any subsequent actions.
My gut was telling me that I needed to be more aware/thoughtful of the slots as I was doing it, but I ignored it. Lesson learned.
I did try this once I realized I didn't have root, but at this point it was already too late since slot_a already booted without a disabled verity/verification.
Nope, just was floundering. Was hoping since I flashed vbmeta/patched boot into _b, a switch would get me root and bootloader would respect the disabled-verity during flash. However, knowing now that verity status is stored in userdata, it makes sense that it wouldn't work.
Click to expand...
Click to collapse
Well..."A smart man learns from his own mistakes; a wise man learns from other's mistakes." I am by no means wise, so I don't blame you!
I tried backup my data (partition) on the Oneplus Nord by temporarily loading a custom recovery: TWRP.
In FastBoot Mode I executed "fastboot boot twrp.img" with the newest files that I found here: https://twrp.me/oneplus/oneplusnord.html
twrp-3.7.0_12-0-avicii.img
This did not work, the screen just got stuck saying: "1+ Fastboot Mode"
It does not progress from there, I tried different versions, Euro, American, etc.
Now the device is not booting anymore. I only get to the recovery screen where I can choose the language. Here a cryptic msg. says: "kindly reminder system error after select language ..."
What can I do to boot the device back up again?
Maybe flash the boot image: "fastboot flash boot boot.img"
Which boot image should I use?
First off, if you had it on android 12, then it didn’t work because custom recoveries don’t work on the OOS 12/ Color OS 12.
To fix the issue, try booting to recovery (fastboot reboot recovery) and on the phone wipe the data, if that doesn’t work, try doing fastboot reboot fastboot, it will (atleast supposed to) bring you to fastbootd, you gotta do the same thing, wipe data and if THAT doesn’t work too… congrats! You bricked your phone
You just need to flash the OS manually using a fastboot rom thingy; https://forum.xda-developers.com/t/...stock-fastboot-roms-for-oneplus-nord.4142153/
If none of those work, reply to this message I’ll show you the one for hard bricked phones.. technically the last one I showed was for hard bricked but not 100%
Hope this helps!
Hafted said:
First off, if you had it on android 12, then it didn’t work because custom recoveries don’t work on the OOS 12/ Color OS 12.
To fix the issue, try booting to recovery (fastboot reboot recovery) and on the phone wipe the data, if that doesn’t work, try doing fastboot reboot fastboot, it will (atleast supposed to) bring you to fastbootd, you gotta do the same thing, wipe data and if THAT doesn’t work too… congrats! You bricked your phone
You just need to flash the OS manually using a fastboot rom thingy; https://forum.xda-developers.com/t/...stock-fastboot-roms-for-oneplus-nord.4142153/
If none of those work, reply to this message I’ll show you the one for hard bricked phones.. technically the last one I showed was for hard bricked but not 100%
Hope this helps!
Click to expand...
Click to collapse
Thanks a lot, I will give it a try.
And of course it is Android 12. And of course, I had no idea that I can't load TWRP anymore.
I have potentially a lot of data to loos, is there any way to backup the data partition before wiping?
Drift18 said:
Thanks a lot, I will give it a try.
And of course it is Android 12. And of course, I had no idea that I can't load TWRP anymore.
I have potentially a lot of data to loos, is there any way to backup the data partition before wiping?
Click to expand...
Click to collapse
I’m not sure, don’t think so..
Hafted said:
I’m not sure, don’t think so..
Click to expand...
Click to collapse
Oh boy I got it back up!!!
I flashed slot b, apparently there is a slot a that works as sort of a backup.
Check current slot:
fastboot getvar current-slot
> current-slot: b
fastboot --set-active=a
fastboot reboot
Voila.
I still would like to backup the partition though.