Galaxy Tab Active3: How to flash GSIs - Galaxy Tab Q&A, Help & Troubleshooting

I am trying to flash an Android 12 GSI onto my Samsung Galaxy Tab Active3. Goal is to install the GSI without root / voiding the warranty. My company produces an app which is primarily used on Android on Galaxy Tab Active devices. It's expected Galaxy Tab Active3 will get Android 12 update in the next few months and we wanted to do some regression testing in advance of that. Hence the need to get Android 12 GSI onto the Tab Active3.
Device is an arm64 so I downloaded the arm64+gms version of Android 12 GSI (from Google's website). I have successfully unlocked the bootloader, and enabled DSU support. The device supports Project Treble and the VNDK isolated namespace, so in theory should support GSIs.
Everything I tried so far has failed. Any ideas to get it working?
Manual DSU​
I have tried to install the GSI by manually starting the DSU via activity manager ("am start-activity -n com.android.dynsystem/com.android.dynsystem.VerificationActivity..." etc). Every time it just says "Installation failed" after reaching about 50% progress. I have tried setting different sizes for the USERDATA: 8GB (Google's recommended size), 2GB and 1GB. I get the same error every time. The device has around 40GB free space and the GSI image size is around 2GB (1GB gzipped), so it shouldn't be anything to do with the space requirements.
Logcat reports an error:
11-11 13:10:09.620 1103 3695 I DynamicSystemService: Failed to install system
11-11 13:10:09.621 16445 23403 E InstallationAsyncTask: java.io.IOException: Failed to start installation with requested size: 1257738436
This doesn't help unfortunately; it is thrown from the following file and this is just thrown if there is any error in the underlying dynamic installation:
packages/DynamicSystemInstallationService/src/com/android/dynsystem/InstallationAsyncTask.java - platform/frameworks/base - Git at Google
PS: Unfortunately the device does not support DSU Loader even though it's running Android 11 (searching for "dsu" in the settings returns no relevant results). Apparently none of the Samsung devices are supporting DSU Loader.
Fastboot / FastbootD​
The device can be rebooted into fastboot mode ("adb reboot bootloader") but every command just hangs forever (except for "fastboot devices", which does detect the device). I tried "fastboot reboot fastboot", but it just reboots into the standard mode of the device and does not enter a fastboot userspace mode (fastbootd mode) as some have suggested it should.
Heimdall​
At least one person has said they can patch GSIs using Heimdall: https://forum.xda-developers.com/t/can-i-flash-gsi-roms-with-odin.4029921/
That person was able to flash their GSI to the SYSTEM partition, but my device doesn't have a SYSTEM partition. The partitions are like SUPER, PRISM, etc.
I'm not able to get Heimdall working properly on Windows 10. I have tried with WinUSB, libusb0 and libusbK, but the same is true for all of them. After rebooting the device into ODIN mode, the device can be detected with "heimdall detect", but I can't do anything more including "heimdall print-pit", as I get a "Failed to access device. libusb error: -12" error.
I managed to set up Heimdall on an Ubuntu instance of WSL and map the USB using USBIPD. Inside WSL, "heimdall print-pit" does work but I can't get further to flashing anything (I tried to flash the GSI to SUPER, not sure if this was a good idea but anyway it failed) as I get a "Protocol initialisation failed!" error.
Odin​
I am not sure if Odin itself even supports GSIs and I can't find anyone saying it supports them. I have tried flashing the GSI as an AP in Odin 3.12, 3.13, 3.14 and the patched 3.14 which removes signature checks. But every time it just fails.
Custom recovery​
Just to also note, it seems none of the custom recoveries (TWRP, SHRP, Orangefox etc) support the Tab Active3, or I could have tried to flash those using Heimdall/Odin and then use them to flash the GSI. But I feel it's likely I would have had the same issues, at least with Heimdall.

you need custom recovery with dynamic partition support

aIecxs said:
you need custom recovery with dynamic partition support
Click to expand...
Click to collapse
as I mentioned, I couldn't find any custom recovery which supports my device...
Also, if I did have say TWRP or LOS recovery for my device, it seems I could run fastboot through the custom recovery (fastbootd). Then I assume I could just flash GSI using instructions like these: https://forum.xda-developers.com/t/...devices-with-dynamic-super-partition.4256667/
But it's a moot point because no such custom recovery exists for my device. There are custom recoveries for Tab Active 1 and 2, but not 3. So I'm trying to see what I can do with Heimdall
Also, quote from the above-linked thread in response to someone who asked about flashing using TWRP:
kusti420 said:
you can only do it in twrp if you rebuild the whole super partition with the gsi of your choice and flash that
Click to expand...
Click to collapse
if someone could tell me how to "rebuild the whole super partition with the gsi of your choice", that may help. because if I could convert gsi to super partition and if I could get Heimdall working (e.g. using native Linux version off a live USB or whatever), then I could use Heimdall to flash SUPER (in theory)
On that note, I found a couple of possible leads:
(1) https://forum.xda-developers.com/t/...r-img-and-flashing-our-modifications.4196625/ - shows how to unpack and re-pack super image using lpunpack and lpmake. I am wondering if I could use this to replace the system.img in my existing super partition with the one from GSI. But how to get the vendor.img and product.img? I don't think Heimdall has any command to backup existing partitions from a device
(2) https://source.android.com/devices/tech/ota/dynamic_partitions/implement#factory-images - it suggests that you can use "make dist" to build super.img, but I'm not sure if this requires me to completely rebuild AOSP from source or I can do it from existing system.img (i.e. GSI)

super_image_dumper

regarding build TWRP from source there are helpful users here

I ran Heimdall on native Linux rather than on WSL or the Windows version. This worked better and fixed the issues I was having before with Heimdall.
I then tried to flash VBMETA (the one bundled with the GSI) using Heimdall which worked, however my device was then soft-bricked, could only boot into Download Mode, and gave the following error:
ODIN MODE (AVB fail)
vbmeta: Public key used to sign data rejected. (5)
vbmeta: VERIFICATION_DISABLED bit is set.
CUSTOM VBMETA
VBMETA : No sign info
VBMETA ,
I also tried a VBMETA from avbtool, which gave a very similar error on boot:
ODIN MODE (AVB fail)
vbmeta: Error verifying vbmeta image: OK_NOT_SIGNED (3)
vbmeta: VERIFICATION_DISABLED bit is set.
CUSTOM VBMETA
VBMETA : No sign info
VBMETA ,
I managed to restore my stock vbmeta by extracting it from the stock ROM and installing using Heimdall, so my device can boot again, but it's back to vbmeta with verification enabled. How can I resolve this?

I tried to run lpmake, but I don't know my super partition size ("--device super:...") I thought it might be the partition block count from the PIT. but that is 1740800 for SUPER, whereas my system.img has size 2752909312, so surely it doesn't fit inside?

Got it fixed eventually (i.e. I am now able to run the GSI on Samsung Galaxy Tab Active3). I had made a really stupid error when running the DSU command. For KEY_SYSTEM_SIZE I was passing the gzipped system size, not original system image size. This is why the installation always failed after 50%, because it was only installing 50% of the system image. Also another really important thing to note is that after running DSU, you have to restart the system from the DSU notification and not from the normal power menu of the device.
In addition, I did flash "vbmeta_samsung.img" but I'm not sure if this was strictly necessary or not (I happened to notice that vbmeta_samsung.img has the same file size as the vbmeta disable images - 4KB vs 10KB for stock vbmeta). I'm going to be trying to help one of my colleagues to follow the same process, probably in the next few days, so will hopefully be able to report back on whether this flash is strictly necessary.
Also, I found that both Heimdall on native Linux and Heimdall on WSL actually suffer from the same problem. You can only post one command to the device, then subsequent commands fail with "protocol initialisation failed". On WSL I was doing things like "heimdall print-pit --no-reboot" and that's why I was facing issues when flashing. Basically, if you get protocol initialisation failed, just reboot the device and it should work.

ajbcc said:
I tried to run lpmake, but I don't know my super partition size ("--device super:...") I thought it might be the partition block count from the PIT. but that is 1740800 for SUPER, whereas my system.img has size 2752909312, so surely it doesn't fit inside?
Click to expand...
Click to collapse
stumbled across this post
https://forum.xda-developers.com/showpost.php?p=82241115&postcount=70
edit: bytes = block count × block size

aIecxs said:
stumbled across this post
https://forum.xda-developers.com/showpost.php?p=82241115&postcount=70
edit: bytes = block count × block size
Click to expand...
Click to collapse
Thanks for pointing this out, but this doesn't help me unfortunately. The number I'm trying to calculate here is the number 4294967296 in that post, which is the one number the guide doesn't explain how to calculate. Also, the PIT doesn't give my block size, only the "block size/offset". This seems to be just a plain offset, as it increases for every partition, even the small ones. So I have no idea what my block size is.

Just ran through the install steps with one of my colleagues (also with Samsung Galaxy Tab Active3) and there was no need to disable AVB as part of the process. We managed to get through with just the vanilla steps from Google. So all that stuff about "vbmeta_samsung.img" was just a red herring.

Related

[GUIDE][XT1789-06+][EU/intl.] How to safely BLunlock/TWRP/Root/BusyBox/Xposed

WARNING #1: operations indicated on this post might potentially brick your device, make it unusable, to cause explosions, eruptions of nearest volcano and a lot of similar disasters.
For sure they will void your warranty in most countries and need all of your data permanently deleted, so make a copy of anything valuable before starting and don't do any operations if you are not a trained guy and sure about what you are going to do.
These are *not* operations for rookies. I will not be responsible in any case about eventual damages. XDA is your friend: if unsure, please ask! :fingers-crossed:
WARNING #2: operations elencated on this post are indicated and first hand tested as working only on Moto Z2 Force (Nash) XT1789-06 GSM/3G/LTE dual sim 6GB RAM 64GB storage unbranded international version on sale on German market with Nougat v.7.1.1 onboard.
They will probably work on most of unlockable bootloader & SIM unlocked versions, included US -04 versions too, but you'll test them yourself.
They are not intended for (US mainly...) CDMA versions (-01 & -03 if I don't go wrong...) since of a bit different hw/fw so avoid to apply them "as is" on those devices.
WARNING #3: there will probably be better methods to obtain same results and, for sure, there would be more in future. This is only a "recap" of what I've found working and applied first hand on my unbranded XT1789-06 Nash - with, IMHO, great results... - on November 2017.
I think this could be useful for many.
WARNING #4: I'm Italian, English is not my first Language, so... be patient!
1. INTRODUCTION
On this guide you will not find anything particularly new and/or not already present on this section of XDA.
So, why this guide? For some reasons...
First of all, to date every guide posted here is for a single operation (e.g. root, TWRP, etc...) and do not take in needed consideration interactions between single operations that, often, can be present, potentially dangerous and/or lead to unexpected behaviours.
More, for a single operation here there are often different posts with different guides/solutions and this could leads to errors and or doubts about what's better for our device...
Last but not the least, to date Nash developers here are mainly from US and so working on devices for the most part provided with branded fw and/or a bit different hw/fw respect to international unbranded versions sold on Europe, Asia, South America & Australia.
From my previous experience with my "old" Griffin (Moto Z) Motorola's fws are often interchangeable between devices with no (or only minimal...) issues at all, but, anyway, having a guide with operations first hand tested on same device is surely safer...
So, in this guide I'll link all best single guides posted here and I'll comment & link them to obtain a single complete "to do list" of works...
2. WHAT WE'LL GET
Following this guide we'll get a Moto Z2 Force with unlocked bootloader, latest available firmware (at present...) on board, a working TWRP recovery, complete root access, BusyBox support (needed for A LOT of interesting sw/tasks...) and Xposed support (I don't think I need to explain Xposed features & benefits here... ).
Taking in consideration how Moto's devices come with a "quite stock/vanilla" Android version on board, they are between the best devices to be rooted & Xposed provided to obtain a great customized system.
If you want to remain stock with your device eventually go with Samsungs (or similar...), but if you want a device that is a "blank canvas" for your customizations, Motorolas and this configuration would quite be the best you could want.
You are surely thinking about lack of Magisk and "SU hiding" solutions... obviously there are reasons for this.
Magisk: I have first hand seen how Magisk is a "very intrusive" software with its installation, it goes to modify *A LOT* of things on system partitions and this could leads to eventual issues/incompatibility.
More, it has its own rooting system (that in my humble opinion isn't better than SuperSU) that I preferred not to use (beneath I think it could be disabled... ) and that could conflict with SuperSU, if not now, maybe on successive Magisk updates (as it happened on my old Griffin... ).
Last but not the least, it seems to still have issues with particular partitioning present on our device (we'll see them later) and with TWRP flashing for same reasons...
Not to mention how, to date, it has really so few functions/modules we can't have using Xposed....
SUhide: there is a detailed guide on how to install succesfully SuperSU with its SUhide function on our device. On the same guide it's reported how that method is uncompatible with Xposed and leads to unsolvable bootloops if we setup both of them.
It is still not clear (to me...) if this is related to SUhide itself or to the different SU installation needed for SUhide to work but, anyway, I preferred Xposed obviously.
Not to mention that for Xposed have been developed some modules to succesfully hidden root (even if I don't know if they already works with Nougat... )
3. LET'S TAKE A LOOK TO OUR DEVICE
Knowledge is power. So, taking a look to our device particular features will help us to avoid errors and eventual issues...
Motorola developed our device with a new configuration/partitioning scheme seen before only on Google Pixels / Pixels XL, making our device probably the first "not Google" one to adopt it.
It is mainly marked by two news:
- there is no more a recovery partition :crying:
- there are two copies of boot and system partitions, called boot_a, boot_b, system_a & system_b and device is capable eventually to boot from every of them :cyclops:
Let's look them in details..
Recovery is obviously still present victory BUT it has no more its own partition, it is instead included in boot partition (where before there was only kernel and little more...) creating a potentially unwanted (by us tweakers, probably wanted by Google for the opposite reason! ) link between boot and recovery where safe rules would want them as unlinked as possible!
This leads to the need to flash a boot.img containing both kernel and recovery when we want to update only one of them (e.g. installing TWRP...) and this will have to be taken in account every time we would go to update kernel, TWRP but even when rooting (in fact, at first, developers were not able to gain root together with TWRP... issue then solved succesfully :highfive.
On Pixels their developers have found some methods to overcome this problem, but on our device, to date, we still don't have a complete solution to this issue. Anyway we are going in the right direction and it will be only matter of time in my opinion (especially since I'm "stressing" our developers to realize a similar solution...! ).
Double partitions for boot & system, often referred as "A/B partitioning" is a system introduced by Google to distribute OTAs in safer & seamless way, without interrupting user work during updates... (bah... ).
They are so totally unuseful as originally designed for US, since of going with TWRP/root, OTAs are no more a solution to upgrade and this partitioning scheme introduced some complications which have led to issues as with Magisk (as already seen...).
BUT as soon as we'll learn how to well manage them, new horizons will open (like updating fw on a partition still having the older one on the other for safety reasons and/or having two different fw versions and be able to choose what to boot from.. ). It's only matter of time...
Anyway in this guide we'll face them ever with safe in mind at the moment...
4. READY? LET'S GO WITH UNLOCKING BOOTLOADER!
If your device has unlockable bootloader (and if it is an international unbranded XT1789-06 it should have...!), you can easily unlock it with this good guide:
https://forum.xda-developers.com/z2-force/how-to/how-to-unlock-bootloader-t-mobile-t3654657
There is no more to say about this guide since it is well done, only some notes:
- guide title speaks of T-Mobile but obviously is suitable for international/unbranded too...
- please note that unlocking bootloader will wipe from your device all data & media storage (and they will be wiped again in successive steps, so *be sure* not having nothing valuable - e.g. your girl pics.. - before starting with procedures);
- install Motorola's latest drivers & fastboot provided on their site as hinted on guide. Don't skip this step to avoid potential issues in successive steps...
- if I don't wrong remember, step 8 of guide has to be repeated two times to confirm unlocking. Anyway look at your console messages and follow directions...
Reboot to system and make a fast configuration (we'll wipe them in minutes... ) to check all is ok and re-enabling usb debugging is preferred.
5. DOWNLOAD & UPDATE YOUR FW
I don't know with what firmware your device will come, BUT if it has anything *before* Nougat v.7.1.1 rel. NXPS26-122-68-1 we well go to update to this for following reasons:
- we need a (good) complete stock fw image to be flashed in case of problems;
- it is updated to September 2017 security patch;
- we have a TWRP with *this exact kernel* (they are linked in same image, remember?) for those (like me... ) which like a "so close to stock as possible" system...
This firmware can be downloaded from the following link: https://mirrors.lolinet.com/firmwar...ubsidy-DEFAULT_regulatory-DEFAULT_CFC.xml.zip (about 2,35 GB..)
PLEASE NOTE: If you have newer firmware don't use this BUT try to download a matching version with your actual one.
Zipped file has to be fully unzipped into the folder containing fastboot executable (downloaded from Motorola!) on your PC.
If you get any error unzipping, *DON'T FLASH* anything and download again (eventually from another browser/PC).
Fastboot sequence I used is the following:
Code:
fastboot devices
pause
fastboot flash modem NON-HLOS.bin
pause
fastboot flash fsg fsg.mbn
pause
fastboot erase modemst1
pause
fastboot erase modemst2
pause
fastboot flash bluetooth BTFM.bin
pause
fastboot flash dsp adspso.bin
pause
fastboot flash logo logo.bin
pause
fastboot flash boot boot.img
pause
fastboot flash system system.img_sparsechunk.0
pause
fastboot flash system system.img_sparsechunk.1
pause
fastboot flash system system.img_sparsechunk.2
pause
fastboot flash system system.img_sparsechunk.3
pause
fastboot flash system system.img_sparsechunk.4
pause
fastboot flash system system.img_sparsechunk.5
pause
fastboot flash system_b system_b.img_sparsechunk.0
pause
fastboot flash system_b system_b.img_sparsechunk.1
pause
fastboot flash system_b system_b.img_sparsechunk.2
pause
fastboot flash system_b system_b.img_sparsechunk.3
pause
fastboot flash oem oem.img
pause
fastboot erase carrier
pause
fastboot erase cache
pause
fastboot erase userdata
pause
fastboot erase ddr
pause
fastboot reboot
That is ready to be put into a batch file to avoid errors and having the possibility to check results of every single flashing since of pause commands presence (press a key to continue to next file). Batch file has to be placed and started from same folder of fastboot & unzipped files to avoid errors.
Please note:
- I've added a fastboot devices command as first to check if your device is properly connected;
- I've used stock sequence of flashing BUT removed gpt (partitions) and bootloader for safety reasons (no need to flash them usually... and let Motorola upgrading your bootloader rarely is a good choice... )
If all flashes will go fine your device /data would be wiped (yes, again!) and phone will reboot after last command.
If something go wrong stop the sequence by CTRL+C and do not reboot your phone until you have understood/cleared/fixed what has gone wrong.
If fine, again... reboot to system and make a fast configuration (we'll wipe them in minutes... ) to check all is ok and re-enabling usb debugging is preferred.
6. INSTALL TWRP
This is a quite simple step, but you have to take a decision before you start...
I'll provide two different boot+TWRP image files as attachment to chose from (both of them realized by @joemossjr )
First one is composed by stock NPXS26 kernel and TWRP v.2 (it's a 3.1.1-0 in TWRP versions), while the second is composed by a kernel recompiled (with little modifications) from sources by joemossjr and TWRP v.3 (still a 3.1.1-0 in TWRP versions) with some little improvements (you can go to his thread for details on TWRP https://forum.xda-developers.com/z2-force/development/twrp-3-1-1-0-moto-z2-force-nash-t3687421 and to this one for details on Pantheon kernel https://forum.xda-developers.com/z2-force/development/kernel-pantheon-kernel-t3702208 ).
If you are on NXPS software version (flashed before) and want to remain "full stock" go with TWRPNPXS.zip, otherwise (you preferring newest firmware or want all newest features) go with TWRPREV3.zip.
Both files *have to be* decompressed, *can't be directly flashed* and your choice of them has to be flashed in fastboot mode with the command:
Code:
fastboot flash boot TWRPxxxx.img
where xxxx is matching your choice.
If all have gone fine, you can now reboot to recovery and make some backups if you prefer (please note you will need to place them to an sd card or to a plugged USB key, since internal memory will be fully deleted again soon...
PLEASE NOTE: during this phase still *don't enable* TWRP to Mount system as R/W ("Swipe to allow modifications for /system" message...) since it could lead to a not booting system if DM verity check is still enabled (it shouldn't since what @ChainfireXDA reported on Twitter, but it is better to be safe...).
A reboot to system to check all is still ok is preferred. If TWRP asks to install his app files on exit, *be sure* to decline/skip (ever! There is an option in TWRP to disable this request too!).
PLEASE NOTE: this way we are flashing ONLY ONE of the boot partitions with TWRP (usually boot_a) while the other (boot_b) is unaffected. This is a wanted behaviour to stay on "safe side".
PLEASE NOTE: On the linked thread @joemossjr put a flashable zip file to update it from inside TWRP itself which flash both boot_a & boot_b. So if you'll want to update to newer versions (and remain on safe side...) unzip that file too (instead to flash it in TWRP), extract boot.img contained inside and flash it with the same command indicated before.
Please note all newer versions will use Pantheon Kernel.
WARNING: If you will in future reflash kernel/TWRP to update them, you would lose both root & disabled forced encryption!!!
So, after every boot.img flashing *you will need*, before booting system, to boot TWRP and flash again SuperSU before reboot to system.
If you fail to do this you'll face bootloops and/or your /data partition will be corrupted. So a /data backup (on external storage!) before a kernel/TWRP update would be mandatory.
7. ROOT & DECRYPT DEVICE
In this step we will go to finally root the device and decrypt its /data partition. This operation *will delete all data again* on you device (downloaded files & pics too!).
Decryption of /data is needed for many reasons:
- to date TWRP is unable to work with compressed /data (and, anyway, it's ever dangerous to work with encrypted data backups/restore... )
- some advanced software you'll go to use could have issues with encrypted data
- a decrypted device is slightly faster
- you definitely will want it unencrypted... listen to me!
Since our phone will come "force encrypted" (it can't be disabled on stock fw!), we need SuperSU help on this and so we'll need to follow *at perfection* the following provided sequence!
Not all SuperSU are equals (more... they are all different! :silly so, tested working fine version to be used is this: http://download.chainfire.eu/1220/SuperSU/SR5-SuperSU-v2.82-SR5-20171001224502.zip?retrieve_file=1
If newer will be out, don't mind, you could ever upgrade it from inside a working system...
Steps are:
- boot to fastboot mode (from off, VOL DOWN + POWER)
- from fastboot mode select RECOVERY mode
- go to wipe menu and select /data FORMAT (not wipe or factory reset, FORMAT!)
- if you have placed downloaded SuperSU zip file on SDcard or USB key browse to it in TWRP Install menu (otherwise connect your phone to PC and trasfer it to internal memory and then browse for it), then Flash it.
- *do not* and I repeat it, *do NOT* clear cache/dalvik cache
- reboot to system
First boot could take a while and probably it reboots one (or two...) times, but at the end it will boot... :fingers-crossed:
You'll have to reconfigure again your system BUT this time, if all has gone fine, it's the good one, so you can do a better configuration if you want.
You will need a working Play Store for next steps, so add a data SIM and/or a wireless network and setup a Google account to enable it.
To check if all has gone fine you should have:
- a SuperSu icon into apps drawer
- on Settings - Security there should be an option to encrypt your system (DON'T chose it! :silly instead of the previous "encrypted" status..
It could be a good moment to download an useful Root check app. A good one is Root Check by JRummy Apps which is able to check Busybox & Xposed presence too (and more...).
8. BUSYBOX & XPOSED
If you have reached this point and all is fine, now it's very simple to complete.
Both Busybox & Xposed can in fact be installed from inside a working rooted system, so...
- download from Play Store BusyBox (free version) by Stephen (Stericson), open it, grant root permissions and press Install button without wait all the (unuseful) checks
- reboot
- enable in Settings - Security the "unknown sources"
- download from here https://forum.xda-developers.com/attachment.php?attachmentid=4319220&d=1509453299 latest Xposed installer/manager apk
- install it, open it and grant root
- select Xposed v.88.2 (or newer if available) for arm64 (if many options are showed be sure to select this, arm64!!!) and select Install (*NOT* via recovery... simply normal Install)
- when prompted for a reboot, accept it.
Please note first reboot could take a while and, again, it could self reboot one (or two times...). When at last it will reboot... gotcha!!! It's cigar time!!! :victory:
Well... it has been a LONG WORK to write this as simple & complete as possible. I hope to not have inserted any error and to have been enough clear on provided instructions.
If you'll find any errors please report to me for corrections.
Newer & better methods are welcome too.
If you liked this, PLEASE USE THANKS BUTTON!
EneTec
MANY THANKS TO:
@seniorstew
@joemossjr
@jhofseth
@Uzephi
for their useful linked guides and/or great development! :good:
Reserved #1.
Reserved #2.
Awesome guide! One of the most intricate guides that goes over every last detail that I've read on XDA in a long time. Thank you. ?
...
Great guide, thanks for the notes re: Xposed...I kept trying to install from TWRP (habit)
3's&7's said:
Great guide, thanks for the notes re: Xposed...I kept trying to install from TWRP (habit)
Click to expand...
Click to collapse
Our device still needs some cautions & tips...
Issue with Modem/Radio
After following your guide to the letter, my phone would not connect to a mobile network and would say "Error while searching for networks" when I tried to force it to find one. I ended up following this guide to try and get back to a working setup:
https://forum.xda-developers.com/z2...m-stock-november-hybrid-rom-t-mobile-t3712795
Unfortunately, nothing is working. Any help would be greatly appreciated.
Thanks!
-Josh-
I figured it out. Had to use the Flash ALL Package from that other post. The modem firmware is very specific.
might be this is the reason i loose 4G+ (4G instead) signal after flashing lmfao
just Wow!! What a great post!!
Damn! Why did follow this guide!? I knew I didn't need to flash anything but boot/boot_a and stay on stock FW with only TWRP from Pantheon kernel!
Now I have a Moto Z2 Force (Dual SIM, UK, retail) without wifi, mac 02:00:00:00:00:00:00:00 and it cannot switch it on!
Any one have full stock image, at least of the boot partition from Dual SIM, UK?
PS: No need to link to Factory Image Moto Z2 Force (NASH) RETAIL. both of them aren't fixing anything for me.
hashnon said:
Damn! Why did follow this guide!? I knew I didn't need to flash anything but boot/boot_a and stay on stock FW with only TWRP from Pantheon kernel!
Now I have a Moto Z2 Force (Dual SIM, UK, retail) without wifi, mac 02:00:00:00:00:00:00:00 and it cannot switch it on!
Any one have full stock image, at least of the boot partition from Dual SIM, UK?
PS: No need to link to Factory Image Moto Z2 Force (NASH) RETAIL. both of them aren't fixing anything for me.
Click to expand...
Click to collapse
Bitdefender blocked it for me for the longest time, then after reinstalling minimal ADB and Fastboot, Motorola Manager, and allowing access to Windows File Explore through Bitdefender, it worked for me; check your antivirus, hope that helps.
Blocked what? And anyway, I don't have any antivirus. There is brain and Linux for that!
hashnon said:
Blocked what? And anyway, I don't have any antivirus. There is brain and Linux for that!
Click to expand...
Click to collapse
Oh my bad, lol
Ok, fixed it my self, this: https://forum.xda-developers.com/ne...0000000000-t3257465/post65960082#post65960082 gave me general idea what to do and what to check.
hashnon said:
Ok, fixed it my self, this: https://forum.xda-developers.com/ne...0000000000-t3257465/post65960082#post65960082 gave my general idea what to do and what to check.
Click to expand...
Click to collapse
Good to hear that, I got so mad when I went in and tried rooting my Z2F without reading this guide first on the very first day that I got it. ??
Deester4x4jr said:
I figured it out. Had to use the Flash ALL Package from that other post. The modem firmware is very specific.
Click to expand...
Click to collapse
This is intended/tested only on EU/intl. XT1789-06... on what version did you applied all this?
ilovemeow said:
might be this is the reason i loose 4G+ (4G instead) signal after flashing lmfao
Click to expand...
Click to collapse
This is intended/tested only on EU/intl. XT1789-06... on what version did you applied all this?
hashnon said:
Ok, fixed it my self, this: https://forum.xda-developers.com/ne...0000000000-t3257465/post65960082#post65960082 gave me general idea what to do and what to check.
Click to expand...
Click to collapse
This is intended/tested only on EU/intl. XT1789-06... on what version did you applied all this?
How do you fix your wifi issue exactly?

Magisk 19.3 and Samsung GT-I9001 (LineageOS 14.1, TWRP 2.8.1.0) does not work

Hi,
my Samsung GT-I9001 runs with LineageOS 14.1 (Nougat 7.1.2):
https://forum.xda-developers.com/ga...opment/i9001-lineageos-galaxy-s-plus-t3793783
As recovery TWRP 2.8.1.0 (F2FS-support) is installed.
Wenn trying to install Magisk 19.3 using magisk-v19.3.zip via TWRP it does not work: Error message ""Error execute updater binary in zip" and no flash is done.
Any idea what is the reason? The TWRP 2.8.1.0 is the latest version I found for the I9001.
The I tried patching the stock-bootloader via the Magisk-Manager. The bootloader-file is a .tar-file, e.g. in
https://forum.xda-developers.com/showpost.php?p=24831012&postcount=1330.
Magisk works with .tar, too, but seems to exspect an .img-file inside. But inside the I9001-"Boot_loader.tar" is no .img-file but 3 .mbn-files and 1 .bin-file.
So I am asking for help. Is there no way using Magisk with the I9001 (and LineageOS 14.1/TWRP)?
You're not supposed to use the bootloader, but the boot image. Two very different parts of the system setup...
And since you have such an old TWRP you're going to have to use the patching method, but it is very far from certain that your device is compatible. Only way to know is to try though.
Oops. Sorry, my mistake. I am a newbie with this and until I was not aware of boot.img ... I supposed it as the "real" filename of the bootloader. And again learning something new. Thank a lot for teaching.
Fortunately I have made a backup of the stock-ROM with TWRP before flashing the ROM. In the backup I find the file boot.emmc.win. This seems to be the stock-boot.img. Is it corrcect that I only have to rename the file to boot.img?
If the I9001 is not compatible with Magisk, means patching of the boot.img would result in a not working code/boot.img (the patching-procedure itself worked w/o errors, but does thos mean, that the result is o.k.?) - is the real risk bricking the device?
That should be the boot image and it should work fine by just renaming it. But, if it's the boot image from the stock Samsung system it won't work with LineageOS. You'll find the boot image for the ROM inside the ROM zip.
If the boot image is incompatible the Manager will let you know by an error message. Save the installation log if that happens and it could possibly tell you in more detail what went wrong.
If everything goes smoothly and the Manager manages to patch the file without issue and you still end up not being able to boot your device after flashing it you can simply restore the unpatched boot image and everything will be back to normal again.
Thanks for the further explanations. But I am not sure understanding correct.
In my understanding of the Magisk-installation manual I have to use the original boot.img always, in every case.
Do I understand correct that this understanding is wrong and that I have to use for patching with the Magisk-Manager the specific boot.img of the actual running OS? So I have to extract the boot.img of the lineageos-14.1-.tar-file (or rename the boot.emmc.win from one of my later backups of the lineagos-14.1-system)?
I have tested patching meanwhile with the "original" boot.img from the old ("original") backup and also with a boot.img extracted from a complete stock-ROM I have found in the web. Magisk Manager patched both fles w/o problems.
btw: Need the patched file the name "boot.img" or doesn´t matter the ame of the patched file (when flashing with fastboot or Odin)?
Unfortunately - or fortunately - I was not able to flash the patched boot.img to the i9001:
adb can communicate with the i9001 when it is running normal (USB debug enabled) and attached via USB. But although Odin is realizing the i9001 attached in download-mode (what means that the USB-cable is working and the driver are installed) fastboot does not realize the i9001 attached in download-mode. I have tested a lot of cables, ports and USB-drivers - no success.
So I tried to flash the boot.img with Odin. For this the boot.img must be converted to a .tar- (or .tar.md5-)file. When searching for converting-tools I found the explanation how to change the output-format of the patched boot.img in Magisk-Manager to .tar. Unfortunately I do not find this option in the current/latest version of Magisk-Manager. What is wrong - is there a secret, a hidden way to activate this option or is this option available in older versions of Magisk Manager only - and if so can I use an older version only for patching and getting a .tar-boot-image-file?
What the documentation is talking about is indeed the untouched boot image of your currently running OS. Don't mix and match.
When flashing with Odin the image indeed need to be in tar-format. With the current Manager there is no option to change the output format because the Manager will take care of that itself. Feed it a tar file and it'll output a tar file. Unfortunately you'll likely get plain image files from the TWRP backups, so those files will be no good unless you convert them before patching.
But, you might not have to use Odin since you have TWRP. It can flash the patched boot image for you. No computer required...
Again thanks a lot for this teaching. I am a newbie in modifying, tuning, flashing smartphones, and although I have learned a lot in the last weeks there are yet a lot of thing I do not know.
I know that I can flash new OS as .zip-file with TWRP (and other files if the manual says that I have/can do it with TWRP ) but I did not know that I can flash with TWRP a boot.img-file. So I would like to ask for a brief guide how to do this. Or is this the same procedure as flashing any .zip-file?
Addition 1: TWRP 2.8.1.0 does not see/list the .img-Files ....
O.k., found in the web: Directly flashing .img: Version 2.8.4.0 and above ....
So I am back again where I started ... fastboot does not see the i9001 and Odin needs a .tar ...
Addition 2: In reg. of the boot.img of the actual used OS:
I have looked into the "original" flashed lineage-14.1-20180523-UNOFFICIAL-ariesve.zip and found the boot.img. But this boot.img is smaller (4.670 byte) than the boot.emmc.win of it´s backup (5.120 byte). In fact every boot.emmc.win of every TWRP-backup (doesn´t matter what OS I have tested) ist 5.120 bytes and larger than the boot.img of the .tar/.zip-file for flashing (different sizes). So if the files are not identical - how can just simply renaming the boot.emmc.win in boot.img result in a valid boot.img?
It's practically the same thing. You just have to switch to "Image" after choosing the install option and then pick what partition to flash to after selecting the file.
Didgeridoohan said:
It's practically the same thing. You just have to switch to "Image" after choosing the install option and then pick what partition to flash to after selecting the file.
Click to expand...
Click to collapse
But not in version 2.8.1.0 - and there is no newer TWRP for the i9001.
MarkFalk said:
But not in version 2.8.1.0 - and there is no newer TWRP for the i9001.
Click to expand...
Click to collapse
Yes. I'm going to forcefully introduce my palm to my face for a moment... Forgot about that tiny but crucial detail.
Just use the boot image file from the LineageOS zip. Patch it and flash the patched image to your device. If you can't get that working I'm going to have to hand this over to someone else, because I have practically zero knowledge on working with Samsung devices and their shenanigans.
Thanks. The small detail of "flashing" into the i9001 is the remaining problem.
As said fastboot does not see the i9001 in it´s download-mode although Odin sees the device and can flash e.g. the bootloader. Odin on the other hand needs a .tar-file and I do not find a way how to converting the (patched) boot.img into a .tar-file that Odin would accept as valid file.
In these cases I usually ask someone like @jenslody or @ianmacd. They usually have a lot more knowledge about Samsung stuff...
I have found a workaround:
1. Make a pure boot-backup with TWRP
2. Copy the backup-folder into/with a new name
3. Copy boot.emmc.win and boot.emmc.win.md5 from the backup to pc or root
4. Rename boot.emmc.win to boot.img
5. Patch boot.img with Magisk-Manager
6. Rename the result to boot.emmc.win
7. Copy boot.emmc.win to the new backup-folder
8. Make a RD5-hash of boot.emmc.win
9. Replace the hash in boot.emmc.win.rd5 with the new hash
10. Copy boot.emmc.win.rd5 to the new backup-folder
11. Boot into TWRP and restore boot from the new folder
It works with the i9001 and lineageOS14.1 and TWRP 2.8.1.0 and the newest Magisk, but it should work with all devices.

Magisk 20/Canary any way to adjust/sett "TARGET IMAGE" path ?

Hi there,
I'm on Redmi 7A, Pie/9, with Magisk Canary, however, cannot upgrade by patching image directly.
The manager updates to latest withOUT any problems, base magisk appeared to update OK, however, after reboot, the wifi and many other things do NOT work, and phone would eventually reboot (3-5 minutes), in an endless loop/reboot as described.
Only way around is to flash the Magisk base ZIP (say 20304) from TWRP (in recovery mode) , then phone boots OK, and wifi and all works fine!
Same thing few days later, flashed 20308 from TWRP, and it WORKED!!! whereas from Manager, it causes the wifi not work, and reboot loop...
Noticed the difference, in the (failure case) flashing from Magisk while phone is booted, the first line of work to be done says:
Code:
Target image: /dev/block/mmcblk0p53
by comparison, doing a TWRP install of the same magisk/zip file from recovery mode, showed a partition number less by ONE, i.e:
Code:
Target image: /dev/block/mmcblk0p52
This flash went OK, and phone works just fine!
If I correctly read the partition name/numbers: 52 is 'boot.img' whereas 53 is 'recovery.img' !!
In the flashing/from magisk while phone is ON, selecting all DEFAULT so:
Preserve AVB 2.0/dm-verify
Preserve force encryption
Recovery Mode
(and "Install directly (recommended)")
Also tried to DESELECT the "recovery mode", it still went after wrong partition #.. p53..
Question is there any way to tell Magisk to flash into partition p52 instead of p53? (anything in settings? config file? )
Click to expand...
Click to collapse
Got latest bits from canary bits:
https://raw.githubusercontent.com/to...y/release.json
Thanks.

Magisk v21 on android 11: bootloop at bootloader when flashing magisk patched img

I've been waited for Magisk v21 released by John Wu this morning, but I ran into some problems
What I've done
- download stock image file from Google official site
- follow the instruction given by John Wu at GitHub wiki
- run command
Code:
adb shell magisk --remove-modules
- when i flash the patched boot.img file, it stuck on the *G logo* with progress bar under it.
- After a certain period of time, it comes back to bootloader with a prompt saying: "no valid slot to boot".
What i've tried:
- redo all processes, no working
- switch active slot to both a & b, none working
- re-patch the stock boot.img file use different Magisk Manager version. The ones i tried: v8.0.0-Beta(offers Magisk v21), v8.0.0-Stable(offers Magisk v20.4), Canary version (offers Magisk Canary who claims to support android 11)
- change the command
HTML:
fastboot flash boot ***.img
to
HTML:
fastboot flash boot_a ***.img
&
HTML:
fastboot flash boot_b ***.img
then run
HTML:
fastboot reboot
. same result as said before
Basic info:
- Device: Pixel 3 (blueline), android 11 (build number RP1A.200720.009), latest android security update & Google play system update.
- Magisk: Magisk Manager v8.0.0 (released hours ago), Magisk v21 is suppose to be installed
Is patched boot.img filesize ~32 or ~64mb?
I ran into the same problem. My phone is a Pixel 2 XL running Android 11. However, I was not patient enough to wait for the "no valid slot to boot" message. After waiting for 5-10 minutes, I did a factory reset.
I followed the installation instruction that were posted by John Wu.. (As a new user, I am not allowed to post an outside link)
The displayed Magisk installation messages do not suggest a problem:
- Device platform: arm64-v8a
- Copying image to cache
- Unpacking boot image
- Checking ram disk status
- Stock boot image detected
- Patching ram disk
- Repacking boot image
***************************
Output file is written to
/storage/emulated/0/Download/magisk_patched.img
***************************
- All Done!
The boot.img and magisk_patched.img files have both a file size of 41943040 bytes. This is a different from previous Magisk version. For instance, with Magisk 20.4 and Android 10, the file sizes of boot.img and magisk_patched.img were 41943040 and 25747456, respectively. Thus, the patched file was smaller than the original.
done
dmk16 said:
Is patched boot.img filesize ~32 or ~64mb?
Click to expand...
Click to collapse
the stock & patched boot.img are both 65535KB large, which is weird and also mentioned by @red stapler
red stapler said:
I ran into the same problem. My phone is a Pixel 2 XL running Android 11. However, I was not patient enough to wait for the "no valid slot to boot" message. After waiting for 5-10 minutes, I did a factory reset.
I followed the installation instruction that were posted by John Wu.. (As a new user, I am not allowed to post an outside link)
The displayed Magisk installation messages do not suggest a problem:
- Device platform: arm64-v8a
- Copying image to cache
- Unpacking boot image
- Checking ram disk status
- Stock boot image detected
- Patching ram disk
- Repacking boot image
***************************
Output file is written to
/storage/emulated/0/Download/magisk_patched.img
***************************
- All Done!
The boot.img and magisk_patched.img files have both a file size of 41943040 bytes. This is a different from previous Magisk version. For instance, with Magisk 20.4 and Android 10, the file sizes of boot.img and magisk_patched.img were 41943040 and 25747456, respectively. Thus, the patched file was smaller than the original.
Click to expand...
Click to collapse
Seems like we're in the same boat here lol, is this enough proof for a legit bug issue to John?
red stapler said:
The boot.img and magisk_patched.img files have both a file size of 41943040 bytes. This is a different from previous Magisk version.
Click to expand...
Click to collapse
DaddyTony said:
the stock & patched boot.img are both 65535KB large, which is weird and also mentioned by @red stapler
Click to expand...
Click to collapse
The patched boot image is supposed to be the same size as the original now.
From the v21 changelog:
[MagiskBoot] Pad boot images to original size with zeros
Click to expand...
Click to collapse
nogaff said:
The patched boot image is supposed to be the same size as the original now.
From the v21 changelog:
Click to expand...
Click to collapse
Glad to hear, hope this indicates patch is successfully done?
Why not:
adb reboot bootloader
fastboot boot twrp-xxxx.img
adb push magisk-xxxx.zip /tmp
adb shell twrp install /tmp/magisk-xxxx.zip
adb reboot system
Let the magisk zip update script figure everything out...
Its what i do on Pixel 2 XL, works every time...10/11
So far, what we've seen that is causing issues with Android 11 and Magisk is usually either having incompatible modules installed (the brand new Safe Mode should take care of that, see the FAQ for details), or having TWRP installed to your device (it'll cause a conflict and the device won't boot, install the stock recovery and only use TWRP booted).
I forgot to mention that I didn't install or use a custom recovery, such as TWRP. Using the stock recovery.
73sydney said:
Why not:
adb reboot bootloader
fastboot boot twrp-xxxx.img
adb push magisk-xxxx.zip /tmp
adb shell twrp install /tmp/magisk-xxxx.zip
adb reboot system
Let the magisk zip update script figure everything out...
Its what i do on Pixel 2 XL, works every time...10/11
Click to expand...
Click to collapse
Sorry but i don't think Pixel 3 have Teamwin (TWRP) support of android 11?
Didgeridoohan said:
So far, what we've seen that is causing issues with Android 11 and Magisk is usually either having incompatible modules installed (the brand new Safe Mode should take care of that, see the FAQ for details), or having TWRP installed to your device (it'll cause a conflict and the device won't boot, install the stock recovery and only use TWRP booted).
Click to expand...
Click to collapse
I forgot to mention that i run this command before install magisk patched boot.img
Code:
adb pm shell magisk --remove-modules
I didn't have TWRP installed on my device, don't seem to have TWRP for Pixel 3 on android 11.
DaddyTony said:
Sorry but i don't think Pixel 3 have Teamwin (TWRP) support of android 11?
Click to expand...
Click to collapse
Theres no TWRP support of my Pixel 2 XL either, but it works
We just dont install it, we fastboot to it
73sydney said:
Theres no TWRP support of my Pixel 2 XL either, but it works
We just dont install it, we fastboot to it
Click to expand...
Click to collapse
Just tried boot into TWRP img, failed. It just says:
Code:
FAILED (remote: 'Error verifying the received boot.img: Invalid Parameter')
Googled it & find out TWRP's a deprecated/no longer recommended way to install Magisk. And according to John Wu's installation instruction, it is no longer supported in modern models.
Due to this reason, we no longer recommend installing Magisk through custom recoveries on modern devices.
Click to expand...
Click to collapse
BTW he also said the "patch image" method is guaranteed to work 100% lol, should we let him know hhh
--------------------
edit:
Just find out Pixel 3 (blueline) has **NO** official support of TWRP v3.4+, but Pixel 3 XL (crosshatch) has it. How ironic.
and I wonder if TWRP v3.4+ support android 11?
DaddyTony said:
Just tried boot into TWRP img, failed. It just says:
Code:
FAILED (remote: 'Error verifying the received boot.img: Invalid Parameter')
Googled it & find out TWRP's a deprecated/no longer recommended way to install Magisk. And according to John Wu's installation instruction, it is no longer supported in modern models.
BTW he also says the "patch image" method is guaranteed to work 100% lol, should we let him know hhh
Click to expand...
Click to collapse
Hmmm, disappointing
Ive literally tried the image patch method once, a lot of faffing about, I always use the TWRP method, easy peasy at least for older device
....we no longer recommend installing Magisk through custom recoveries on modern devices. The custom recovery installation method exists mostly for legacy support.
Download the Magisk installer zip
Reboot to custom recovery
Flash the zip and reboot
Check whether Magisk Manager is installed. If it isn’t installed automatically, manually install the APK.
Click to expand...
Click to collapse
Guess ill be happy to remain a legacy device user
This saved my day:
Code:
fastboot --set-active=b
You might need to use "a" instead.
In my case the kernel was loaded and started and Android startup was hanging.
I guess we have to wait until this is fixed.
Edit: Pixel 3a XL, latest Android 11
Hey all, i have a pixel 2 XL and I'm also stuck in bootloop. However i can't find how to do a factory reset. Could you help me?
polyxn said:
Hey all, i have a pixel 2 XL and I'm also stuck in bootloop. However i can't find how to do a factory reset. Could you help me?
Click to expand...
Click to collapse
Which version of Android?
Do you have TWRP installed?
If you do people have been posting that going to Advanced, then tapping Fix Bootloop may work
Otherwise find the boot image of the ROM you have installed, and flash that to the device
If youre on Android 11 on the Pixel, as i found out myself via bootloop, do NOT install TWRP, just fastboot to it to flash zips
M66B said:
This saved my day:
Code:
fastboot --set-active=b
You might need to use "a" instead.
In my case the kernel was loaded and started and Android startup was hanging.
I guess we have to wait until this is fixed.
Edit: Pixel 3a XL, latest Android 11
Click to expand...
Click to collapse
I used this command (and tried to boot in slot a), the patched img still won't boot.
Did you managed to flash Magisk with patched boot file?

[ROM][SM-T500] Samsung Galaxy Tab A7 10.4 (2020) - LineageOS 18.1

Update: March 24 2022: This ROM has been retired and a new one based on LOS 19.1 (and TWRP based on Android 11) have taken its place. New thread here: https://forum.xda-developers.com/t/...4-2020-lineageos-19-1-and-twrp-3-6-1.4421365/
---
Update 9:46am EST July 15 2021: new builds of TWRP and LineageOS with TWRP touch fixed and LOS w/ space for Gapps is now live.
WARNING: USE AT YOUR OWN RISK.
I have successfully ported TWRP and Lineage OS 18.1 to the Samsung Galaxy Tab A7 10.4 (2020), aka SM-T500. This is my first time porting TWRP or LOS, so there may be issues unknown about at this time. Thus far, the only known issue is that the touchscreen in TWRP does not work. This can be worked around by using a USB mouse and/or accessing the device via ADB.
Here are the steps to follow:
Update your device to the latest stock ROM (as of this writing) either using the built-in system updater or via Odin. You want the build that ends with "3BUF3".
Unlock device bootloader using instructions from other threads. This will wipe your device.
Boot into download mode and flash "vbmeta_disabled_R.tar" via Odin in the "Userdata" slot to disable verified boot. This will wipe your device again.
Boot device back into download mode and flash TWRP via Odin in the "AP" slot. If you boot up into the stock ROM rather than booting directly back into download mode then go through the initial setup process of the stock ROM and enable developer tools and ensure OEM Unlocking is still enabled (VaultKeeper can possibly undo OEM Unlocking if you get to the ROM but don't go into Developer Tools and view OEM Unlocking is enabled, so make sure to do this).
Boot device into TWRP (recovery mode) and format (not wipe) your data partition. Then reboot back into TWRP.
Push LineageOS (super.new.ext4.img) to device. Ideally push it to an SD card formatted with ExFat or EXT2/3/4 (FAT/FAT16/FAT32/VFAT won't work due to file-size limitations).
Install LineageOS image to "Super" partition. Make sure to select "Install from Image" in order to show .img files in the install selector screen.
(Optional) Push NikGapps Omni to your device and install the zip. Make sure you include a "nikgapps.config" file in your "/tmp" folder that is configured to install to "system" rather than "product" or "default".
Reboot to system. You should now be in LOS with Gapps.
(Optional, but recommended): Install Magisk via TWRP
(Optional, but recommended): Run fix script to fix brightness slider not working and to make Magisk work. If you didn't install Magisk but only want the brightness fix, just enter "n" when prompted in the script. To run the script:
NOTE: Script has .txt file extension to allow hosting on AFH. Remove that so it's just .sh to match the instructions below.
Download and push to device when booted into TWRP
adb push sm-t500_fixes.sh /tmp
Enter an adb shell
adb shell
Change directories and set permissions
cd /tmp
chmod +x /tmp/sm-t500_fixes.sh
Run script
/tmp/sm-t500_fixes.sh
Tips:
If you are not seeing all of your storage space in the OS on the internal flash, boot to TWRP and format data.
Flash TWRP via "AP" slot and flash VBMeta_Disabler via "Userdata" slot in Odin.
Flash LineageOS as an Image, not as a Zip.
For Gapps, use the latest NikGapps for ARM64 and Android 11/R.
For Gapps, make sure you install to the System partition and not Product. To do this you need to slightly modify a nikgapps.config file. Instructions on that can be found on the NikGapps site.
Downloads:
LineageOS 18.1 20210615 Beta 2: https://www.androidfilehost.com/?fid=14943124697586369438
TWRP 3.5.2 Beta 3: https://www.androidfilehost.com/?fid=14943124697586369439
vbmeta_disabled_R: https://www.androidfilehost.com/?fid=14943124697586369440
Fixes for brightness and Magisk (sm-t500_fixes.sh): https://www.androidfilehost.com/?fid=14943124697586369521
Known Issues:
OS-encrypted storage (Internal Data) not able to be decrypted in TWRP.
Brightness controls don't work: Fixed via "sm-t500_fixes.sh script.
TWRP touch screen doesn't work (use USB keyboard or adb). Should be fixed with TWRP Beta 3.
TWRP formatting external SD card may hardbrick device. Do not do this! Fixed with TWRP Beta 2.
Source (device tree for TWRP from my Github): https://github.com/agreenbhm/android_device_samsung_gta4lwifi
Source (kernel sources from Samsung): https://opensource.samsung.com/uploadSearch?searchValue=Sm-t500#
agreenbhm said:
I have successfully ported TWRP and Lineage OS 18.1 to the Samsung Galaxy Tab A7 10.4 (2020), aka SM-T500. This is my first time porting TWRP or LOS, so there may be issues unknown about at this time. Thus far, the only known issue is that the touchscreen in TWRP does not work. This can be worked around by using a USB mouse and/or accessing the device via ADB.
Here are the rough steps to follow:
Unlock device bootloader using instructions from other threads.
Patch stock ROM (AP) using Magisk, then flash rooted ROM. Will likely need to wipe device after this.
Boot into rooted ROM and ensure "OEM Unlocking" is still enabled in "Developer Tools".
Boot back into download mode and flash "vbmeta_disabled_R.tar" to disable verified boot.
Boot device back into rooted stock ROM to ensure things are still functional (may require a device wipe at this step).
Boot device into download mode and use ODIN to flash TWRP recovery.tar file via "AP" slot.
Boot device into TWRP to verify functionality (hold Vol-Up + Power during boot).
Access TWRP via adb using "adb shell" or with USB mouse (touch functionality currently not working).
Format data partition on device.
Via ADB shell: twrp format data
Via USB mouse: Wipe -> Advanced -> Format Data
Boot device into download mode.
Via ADB shell: twrp reboot download
Via USB mouse: Reboot -> Download
Flash LineageOS tar file via ODIN using the "AP" slot.
If device boots into TWRP after flashing LineageOS, use USB mouse to select: Reboot -> System
Device should boot and stall for ~1m at the Samsung logo screen with red text below, then should go blank and then display LineageOS boot image.
Downloads:
LineageOS 18.1 20210615 with TWRP 3.5.2: https://mega.nz/file/vMVglThZ#TepIHvdEypezq3z4S_4Lln7FRFVfC7CUjVGq3ByFb6U
TWRP 3.5.2: https://mega.nz/file/GYU1yCCQ#JsthI8BYNtfB08Pzt1eeXta2Lb1zCkUI185Zm88dEW4
vbmeta_disabled_R: https://mega.nz/file/iMFx3CQI#8cP4mPoRaQNwDATqt0vKD8wxqRWSTz1EL79U0fNpW8M
Click to expand...
Click to collapse
Great news!! But I think you need to post it in the ROMs, Kernels, Recover thread.
awesome. Will try after work. Also I think you posted in the wrong section.
Which slot to flash the vbmeta?
wizzdome said:
Which slot to flash the vbmeta?
Click to expand...
Click to collapse
AP
Thanks,
After flashing the vbmeta it booted into recovery automatically after what looked like a bootloop in progress, so I wiped with factory reset and then it rebooted fine. (still not sure exactly what the vbmeta does I was hoping it would make it so i didnt get that stupid pop up asking me to hit power button to continue booting due to it having the patched os) anyhow booted fine and twrp installed as you stated without touch screen but mouse with otg works fine. (great job so far) On to LOS... I think I should have checked oem lock before flashing LOS as when I installed I get stuck at boot screen that says oem lock is on... must have been from my factory reset... (facepalm)
Nope... Still sticking on boot with the following showing on the screen...
RPMB fuse not set
RPMB Provisioned
Current BInary: Custom (0x30f)
FRP Lock : OFF
OEM Lock : ON (U) {this was off verified before flash}
KG Status : Checking
Waranty Void : 0x1 (0xE02)
Quallcomm Secureboot : Enable
RP SWREV : B3 (1,1,1,3,1,1) k3 s3
secure download : enable
grdm status : normal (d0000501)
did : 041ce2d22dba
this is displayed in the corner on the bootscreen and looks like it belongs on the download screen, anyhow booting into twrp from this point works however factory reset fails with unable to mount key(something and key(something else) i figure i will let it sit a while as I know sometimes it just takes first boot a while to go through however it doesnt seem to be the problem. Have you had a positive install of the LOS? I am wondering if I had maybe gotten a bad copy of the file. When i go to install I get a pass in odin so not quite sure where to go from here other than back to the factory image any help to get this going would be great... I took on this task cause i needed someting to take my mind off the severely crappy week I have had... so looking forward to anything you can share here...
Actually, userdata is the slot I always use. It might work in both though.
Something to mention: there is not enough space on the /system partition to flash Gapps. I created a build that supports it (with a resized /system partition) but I couldn't get it to flash via Odin. The only way I got it to work was by flashing it via TWRP as an img file. I will be posting that soon. Unfortunately that will be the end of development for now as I hard-bricked the device and need to wait for a repair or replacement. Should be back developing in 2 weeks.
Nevermind what I said here.
jayzarry84 said:
Anyone get this to work? I just flashed the TWRP part but have not been able to get into TWRP
Click to expand...
Click to collapse
Get adb access in the OS and then run "adb reboot recovery"
agreenbhm said:
Get adb access in the OS and then run "adb reboot recovery"
Click to expand...
Click to collapse
question. I don't have an OTG cable and TWRP keeps booting. I've tried rebbot, rebbot bootloader, reboot system. any advice?
jayzarry84 said:
question. I don't have an OTG cable and TWRP keeps booting. I've tried rebbot, rebbot bootloader, reboot system. any advice?
Click to expand...
Click to collapse
You may need to get an otg cable for a USB mouse and choose "reboot system" from the gui. Alternatively, look at the /dev/block/by-name/misc partition and try blanking that out with dd. That has worked sometimes.
jayzarry84 said:
question. I don't have an OTG cable and TWRP keeps booting. I've tried rebbot, rebbot bootloader, reboot system. any advice?
Click to expand...
Click to collapse
Also, from an adb shell, try "twrp reboot". Supposedly that should boot to system, but I feel like in testing I got mixed results. According to the TWRP documentation though that should be the answer.
agreenbhm said:
Also, from an adb shell, try "twrp reboot". Supposedly that should boot to system, but I feel like in testing I got mixed results. According to the TWRP documentation though that should be the answer.
Click to expand...
Click to collapse
Not working. I'll wait for my otg cable to come in
jayzarry84 said:
Not working. I'll wait for my otg cable to come in
Click to expand...
Click to collapse
I was able to use adb to run the TWRP Format Data command and it rebooted the tablet and now LOS has booted up. I think I'm good!
Looking forward to see how this develops
Rom is fast and snappy. Brightness control does not work. I haven’t played too much because of work but that’s what I’ve found so far
Can a mod move this to the rom release section?
agreenbhm said:
Something to mention: there is not enough space on the /system partition to flash Gapps. I created a build that supports it (with a resized /system partition) but I couldn't get it to flash via Odin. The only way I got it to work was by flashing it via TWRP as an img file. I will be posting that soon. Unfortunately that will be the end of development for now as I hard-bricked the device and need to wait for a repair or replacement. Should be back developing in 2 weeks.
Click to expand...
Click to collapse
I've not been able to flash this yet but I know that the latest TWRP versions have a way to fix the system partition to accept gapps. /Wipe/Advanced check system then resize. Sometimes you have to do it more than once if it is a large gapps.
lewmur said:
I've not been able to flash this yet but I know that the latest TWRP versions have a way to fix the system partition to accept gapps. /Wipe/Advanced check system then resize. Sometimes you have to do it more than once if it is a large gapps.
Click to expand...
Click to collapse
I will look into that, but I'm not optimistic it will work. This device does not separately present the system partition, rather it uses a super partition which contains system, vendor, product, and odm. TWRP only shows me the super partition for working with. I was able to resize the system partition by expanding the Lineage image and file system on my pc to match the original stock system partition, then rebuilt the super image with the other partitions it needs.

Categories

Resources