[Q] Issues with Signing Android Factory Images, ROMs and OTA Files. - OS Porting

I am doing R&D on FOTA(Firmware Update Over the Air) using Nexus 7-Wifi(grouper). For which I followed the following steps.
1. Downloaded the android source from source.android.com for v 4.2.2_r1 and v 4.3_r1
2. Downloaded the binaries for grouper, extract it to my source folder.
3. Then I compiled the source code using following commands.
i. source build/envsetup.sh
ii. lunch full_grouper-userdebug
iii. make -j8 dist
4. After few tries, I had success in compiling the source for Nexus 7(grouper).
5. I got following files in $out/source_4.2.2/dist folder
-----------------------------------------------
adb*
android-common-carousel.jar
android-common.jar
android-info.txt
android-support-v13.jar
android-support-v4.jar
android-support-v7-gridlayout.jar
build.prop
com.android.nfc_extras.jar
fastboot*
full_grouper-apps-eng.root.zip
full_grouper-emulator-eng.root.zip
full_grouper-img-eng.root.zip
full_grouper-ota-eng.root.zip
full_grouper-symbols-eng.root.zip
full_grouper-target_files-eng.root.zip
gpl_source.tgz
guava.jar
installed-files.txt
jsr305.jar
mkbootfs*
mkbootimg*
mkyaffs2image*
mp4parser.jar
package-stats.txt
ramdisk.img
signapk.jar
vendor_owner_info.txt
-----------------------------------------------
6. Then I generated my own keys using /development/tools/make_key tool for media, testkey, releasekey, shared, platform.
Assume my keys are locate at /keys folder.
7. Then I created a signed target zip file using following command.
/source/build/tools/releasetools/sign_target_files_apks -v -p ../host/linux-x86 -d /keys full_grouper-target_files-eng.root.zip signed_target_files.zip
8. From signed target zip file I create
/source/build/tools/releasetools/img_from_target_files -v -p ../host/linux-x86 signed_target_files.zip signed_img_from_target_files.zip
9. Then I flashed the signed_img_from_target_files.zip using fastboot command using the following script:
----------------------------------------------------------------------
fastboot oem unlock
fastboot erase boot
fastboot erase cache
fastboot erase recovery
fastboot erase system
fastboot erase userdata
fastboot reboot-bootloader
sleep 10
fastboot -w update signed_img_from_target_files.zip
----------------------------------------------------------------------
10. The device gets flashed well and is working, but I am getting an log while flashing in which it is unable to find boot.sig, system.sig and recovery.sig
11. Now the otacerts.zip file contains a testkey which is not the one that I signed it with.
file located at "/system/etc/security/otacerts.zip" on device.
12. Now since the otacerts.zip is signed with the default key it gives a mismatch error which I tried to flash an OTA update which is signed by the my custom key.
Now my doubt is:
How can I add boot.sig, recovery.sig and system.sig to signed_img_from_target_files.zip?
Is there anything I am doing wrong?
Does the recovery checks the current ROM keys from "/system/etc/security/otacerts.zip"?
What is the correct procedure to sign the OTA update?

i am posting this reply just for people who are looking for help too,
you need to explicitly define "BUILD_SECURE := true" in your device make file so that android/build/core/Makefile will use device/*/$(TARGET_DEVICE)/releasekey.x509.pem for OTA_PUBLIC_KEYS

Related

[dev]How to Un/Re/Pack a Boot.blob and unyaff a boot.img

Technically i have to give credit to scott crossler
www.scottsroms.com
for showing me the method
and then i came upon turges
faq
Thanks Turge and Scott and whomever created these blobpacktools
but since i keep getting pms
and im sure you do to
scott
Here are the steps for repacking the boot.img. Some involve running the commands via cygwin, others involve running them via the Windows Command Prompt.
The instructions for installing cygwin, extracting and repacking the boot.img were found here: http://www.freeyourandroid.com/guide...ot-img-windows
Once you have setup cygwin, extract the attached files in a folder under your "home" folder in cygwin.
Also unzip blob tools into the same folder as your boot.blob
1.
Code:
copy boot.blob to the same folder and run the following via
the Windows Command Prompt to extract the boot.img from the boot.blob:
BlobUnpack.exe boot.blob
ren boot.blob.LNX boot.img
which will create boot.img
2.
Code:
From the cygwin bash terminal window,
switch to the same folder and run the following
to extract the ramdisk from the boot.img:
./extractboot boot.img
You now have an out/ramdisk folder
that contains the files you want to edit.
3.
Code:
Once done, repack the ramdisk and kernel into boot_new.img
with the following command (via cygwin once again):
./packboot
4.
Code:
then from the Command Prompt repack boot_new.img
into boot2.blob using the following:
blobpack -s boot2.blob LNX boot_new.img
5.
Code:
You can now flash the boot.blob to the staging
partition via a command in updater-script:
Code:
package_extract_file("/boot.blob", "/dev/block/mmcblk0p4");
or by using adb while in recovery/android:
Code:
dd if=/sdcard/boot2.blob of=/dev/block/mmcblk0p4
Lastly the rundown is like this
if you want to take a ota blob
and extract the contents for a raw base
and a raw kernel
1
take the ota and extract the blob file and place
in your folder with blobtools
2. then run
Code:
blobunpack.exe blob
Which now creates
Blob.APP =System.img (can be renamed system.img and unyaffed in the kitchen)or straight cygwin
Blob.sos=Recovery Img
Blob.Ebt=Bootloader information
Blob.Lnx=kernel (can also just be renamed boot.img and unyaffed in kitchen)
Blob.pt=Partition info
so to repack lets say your custom remade image
and your custom kernel
and a recovery of your choice
run
Code:
blobpack.exe -s blob lnx boot.img sos twrp.blob app system.img
then simply take the blob replace in the ota file
and flash in recovery
and it should flash a rom packed as a blob
Hi!
...also you can flash the new boot.blob via fastboot mode
>fastboot-i 0x0B05 flash boot boot.blob
:good:
Call me stupid, but what does repacking the boot.img do? I never pm'ed you, but what would we gain from this. a lil lost
unpacking a boot.img allows you to take a stock already built kernel
and make specific changes to the ramdisk
more specifically
default.prop
can make kernel insecure
debuggable
bootanimation enabled
blah blah blah
and init.rc
but also
cardhu
and goldfish.rc
and init.trace
and init.usb
then repacked and good to flash
seanzscreams said:
Lastly the rundown is like this
if you want to take a ota blob
and extract the contents for a raw base
and a raw kernel
1
take the ota and extract the blob file and place
in your folder with blobtools
2. then run
Code:
blobunpack.exe blob
Which now creates
Blob.APP =System.img (can be renamed system.img and unyaffed in the kitchen)or straight cygwin
Blob.sos=Recovery Img
Blob.Ebt=Bootloader information
Blob.Lnx=kernel (can also just be renamed boot.img and unyaffed in kitchen)
Blob.pt=Partition info
so to repack lets say your custom remade image
and your custom kernel
and a recovery of your choice
run
Code:
blobpack.exe -s blob lnx boot.img sos twrp.blob app system.img
then simply take the blob replace in the ota file
and flash in recovery
and it should flash a rom packed as a blob
Click to expand...
Click to collapse
Hi!
For a linux (Ubuntu) machine you can easily unpack blob.APP
> sudo mkdir mnt
> sudo mount -o loop blob.APP mnt
- now in your mnt directory , you will have /system ! :good:
Hi,
My TF300tl can't unlock bootloader. so can I use this way to pack custom ROM ( cm11, liplop...) as official ROM to flash for my tablet ?
konnichiwa said:
Hi,
My TF300tl can't unlock bootloader. so can I use this way to pack custom ROM ( cm11, liplop...) as official ROM to flash for my tablet ?
Click to expand...
Click to collapse
I wouldn't think so, as the ROM would have to be signed to be official

Setting up a self-signed (restrictive) recovery for self-signed ROMs

Has anyone installed self signed ROMs using the method described in this blog http://mjg59.dreamwidth.org/31765.html? The goal is to install a self signed image that allows you to only install images signed by a key you generate yourself to avoid the giant security hole caused by custom recoveries that don't check signatures.
Here's the overview :
First: Unlock your bootloader. /data will be wiped.
Second: Get a copy of the stock recovery.img for your device.
Third: Grab mkbootimg from here and build it. Run unpackbootimg against recovery.img.
Fourth: Generate some keys. Get this script and run it.
Fifth: zcat recovery.img-ramdisk.gz | cpio -id to extract your recovery image ramdisk. Do this in an otherwise empty directory.
Sixth: Get DumpPublicKey.java from here and run it against the .x509.pem file generated in step 4. Replace /res/keys from the recover image ramdisk with the output. Include the "v2" bit at the beginning.
Seventh: Repack the ramdisk image (find . | cpio -o -H newc | gzip > ../recovery.img-ramdisk.gz) and rebuild recovery.img with mkbootimg.
Eighth: Write the new recovery image to your device
Ninth: Get signapk from here and build it. Run it against the ROM you want to sign, using the keys you generated earlier. Make sure you use the -w option to sign the whole zip rather than signing individual files.
Tenth: Relock your bootloader
Eleventh: Boot into recovery mode and sideload your newly signed image.
Click to expand...
Click to collapse
I have the 8" Tab (SM-T310) and want to try it. Anyone know if there's an official source of stock recovery images? I have the 4.4.2 update.zip from an OTA update I never installed (my tablet's still on stock 4.2.2), can the recovery somehow be extracted from that? Since I'm still on 4.2.2, I don't need to unlock the bootloader, right? Can I use Heimdall to put the new recovery on the tab?
Here's my step by step if anyone else is crazy enough to try this.
First: Unlock your bootloader. /data will be wiped.
Click to expand...
Click to collapse
Skipped so far, running 4.2.2 which from what I've been reading I think isn't locked.
Second: Get a copy of the stock recovery.img for your device.
Click to expand...
Click to collapse
Grabbed the update from Kies (on Windows VM):
Agreed to Kies update when I plugged in the tablet.
Watched my temp folder (from windows search bar enter %temp%) until tmp*.tmp.zipfolder showed up (wait for tmp*.tmp file to download and get converted to a zip, then it unzips into zipfolder automatically), unplugged the tablet immediately as it booted into download mode, copied tmp*.tmp.zipfolder somewhere else (desktop) before Kies cancelled the update process and deleted the temp files.
Third: Grab mkbootimg from here and build it. Run unpackbootimg against recovery.img.
Click to expand...
Click to collapse
Source is on github: osm0sis/mkbootimg From here on I'm using linux.
cd into mkbootimg folder and run "make"
run
Code:
./unpackbootimg -i recovery.img -o rec
(rec is the folder I unpacked to, make the folder first or it'll segfault)
Fourth: Generate some keys. Get this script and run it.
Click to expand...
Click to collapse
Saved script (posted below, can't post links yet...) to "make_key.sh", then
Code:
chmod +x make_key.sh
to make it executable.
Ran script, usage: /make_key.sh <name> <subject> [<keytype>]
subject must be in the format "/C=GB/ST=London/L=London/O=Global Security/OU=IT Department/CN=example.com" (look up "Create CSR using OpenSSL Without Prompt (Non-Interactive)" for what all that means)
Fifth: zcat recovery.img-ramdisk.gz | cpio -id to extract your recovery image ramdisk. Do this in an otherwise empty directory.
Click to expand...
Click to collapse
Make a directory, cd into it, run
Code:
zcat recovery.img-ramdisk.gz | cpio -id
with recovery.img-ramdisk.gz pointing to where your file is (mine was ../recovery.img-ramdisk.gz).
Sixth: Get DumpPublicKey.java from here and run it against the .x509.pem file generated in step 4. Replace /res/keys from the recover image ramdisk with the output. Include the "v2" bit at the beginning.
Click to expand...
Click to collapse
Not sure why he's using a different DumpPublicKey.java than the one that's in the mkbootimg git... but it's in the "libmincrypt/tools/DumpPublicKey.java" that was in the mkbootimg git, I didn't see any differences using diff.
Running
Code:
javac DumpPublicKey.java
tells me I need BouncyCastleProvider. And now I'm stuck.
Downloaded the Bouncy Castle jar and put it in the same folder as DumpPublicKey.java and ran
Code:
javac -cp bcprov-jdk15on-152.jar DumpPublicKey.java
echo "Main-Class: DumpPublicKey" > manifest.txt
jar cvfm DumpPublicKey.jar manifest.txt DumpPublicKey.java
Then running
Code:
java com.android.dumpkey.DumpPublicKey
gave me various class not found errors and I ended up with a file structure like this trying to make it find the bouncy castle. Annnnnd I'm stuck.
.
├── bcprov-jdk15on-152.jar
├── com
│** └── android
│**** └── dumpkey
│****** ├── bcprov-jdk15on-152.jar
│****** ├── DumpPublicKey.class
│****** ├── DumpPublicKey.jar
│****** ├── DumpPublicKey.java
│****** └── manifest.txt
├── DumpPublicKey.class
├── DumpPublicKey.java
└── manifest.txt
I obviously don't know how to java at all.... any suggestions?
I just needed to put the "-cp" in the java command as well as the javac command.
Code:
java -cp .:./bcprov-jdk15on-152.jar com.android.dumpkey.DumpPublicKey
The full command is
Code:
java -cp .:./bcprov-jdk15on-152.jar com.android.dumpkey.DumpPublicKey /path/to/key.x509.pem > keys
After deleting stuff and testing, I found I only needed files in these locations:
.
├── bcprov-jdk15on-152.jar
├── com
│** └── android
│** └── dumpkey
│** ├── DumpPublicKey.class
│** └── DumpPublicKey.jar
├── DumpPublicKey.java
└── manifest.txt
Then I replaced the "/res/keys" file with the "keys" file I just made.
Seventh: Repack the ramdisk image (find . | cpio -o -H newc | gzip > ../recovery.img-ramdisk.gz) and rebuild recovery.img with mkbootimg.
Click to expand...
Click to collapse
From the folder that the ramdisk image was extracted into, run
Code:
find . | cpio -o -H newc | gzip > ../recovery.img-ramdisk.gz
mkbootimg needs offsets that were printed when I ran unpackbootimg:
BOARD_KERNEL_CMDLINE
BOARD_KERNEL_BASE 10000000
BOARD_NAME
BOARD_PAGE_SIZE 2048
BOARD_KERNEL_OFFSET 00008000
BOARD_RAMDISK_OFFSET 01000000
BOARD_TAGS_OFFSET 00000100
Still in the folder where I unpacked the recovery image (mkbootimg is one directory up)
Code:
../mkbootimg --kernel recovery.img-zImage --ramdisk recovery.img-ramdisk.gz --base 10000000 --pagesize 2048 --kernel_offset 00008000 --ramdisk_offset 01000000 --tags_offset 00000100 -o newrecovery.img
Eighth: Write the new recovery image to your device
Click to expand...
Click to collapse
This thread says Heimdall 1.4.0 works for T31x: http://forum.xda-developers.com/showthread.php?t=2522091
Oh how nice, Heimdall 1.4.1 is in my package manager.
Connect device and restart in download mode (held the "HOME" button, "Volume Down" and "Power" all at the same time (for about 5 seconds). Hit the "Volume Up" to enter download mode when prompted.)
Code:
sudo heimdall flash --verbose --no-reboot --RECOVERY recovery.img
Ninth: Get signapk from here and build it. Run it against the ROM you want to sign, using the keys you generated earlier. Make sure you use the -w option to sign the whole zip rather than signing individual files.
Click to expand...
Click to collapse
signapk is on github in android/platform_build/tools. And it gives more bouncy castle errors. Put bcpkix-jdk15on-152.jar and bcprov-jdk15on-152.jar in the signapk folder and run
Code:
javac -cp .:./bcprov-jdk15on-152.jar:./bcpkix-jdk15on-152.jar SignApk.java
echo "Main-Class: SignApk" > manifest.txt
jar cvfm SignApk.jar manifest.txt SignApk.java
make directory com/android/signapk/ and move in all the *.class files and the SignApk.jar
Code:
java -cp .:./bcprov-jdk15on-152.jar:./bcpkix-jdk15on-152.jar com.android.signapk.SignApk /path/to/key.x509.pem /path/to/key.pk8 ../original.zip ../signed.zip
I just replaced the recovery in the OTA with the recovery with my keys from earlier, then rezipped it before signing. And after starting sideloading I noticed I left the "-w" option off the signing command, so I made another file with "-w".
Sideloaded with:
Code:
adb reboot recovery
(then volume down to select apply update from ADB)
adb sideload signed.zip
Then saw:
loading: 'update.zip'
sending: 'update.zip' <completion percent>
(might have to do some adb stopping/starting or adb usb beforehand to make it work, I was getting "error: closed" at first. If it just sits on "loading" something's wrong, as I found out last night when I waited hours for "loading" to turn into something else.)
After the file finished uploading, In terminal I got the response "* failed to write data 'protocol fault (couldn't read status): Success' *"
And on the device I got (for a few seconds before it showed only the sad robot on its back). Then after a couple minutes it rebooted back into recovery.
E: Footer is wrong
E: Footer is wrong
E: Signature verification failed
Installation aborted
So I tried again, but this time selected the option to wipe the cache before adb sideload. Then I tried again, using the update.zip that I forgot to add the "-w" option when signing. So far all fails.
I have no idea if the issue is how the recovery was flashed or what, so I'm doing it manual...
Code:
adb shell
su
#first backup current recovery
dd if=/dev/block/mmcblk0p10 of=/sdcard/recoverybk.img
adb pull /sdcard/recoverybk.img
# now push and dd my signed recovery
adb push /sdcard/recovery.img
dd if=/sdcard/recovery.img of=/dev/block/mmcblk0p10
And still having the same signature verification issue.
Edit: I went back and unpacked the recovery I pulled off the device (unpackbootimg), and it looks like somehow I managed to run mkbootimg with the old ramdisk image.
New problem with the new recovery: "E:failed to load keys". Maybe it had something to do with using ec keys just for funsies. So I remade the keys with the default, redumped into the ramdisk image, rebuild/reflashed recovery, resigned the update.zip. Now it's back to the "footer is wrong, signature verification failed" error.
But this is still trying to use the OTA 4.4.something update, not a full ROM. What's it do with Cyanogen?
First attempt: Download Cyanogen and sideload it (unmodified)
E:failed to verify whole-file signature
E:signature verification failed
Ok, expected behavior, it's not signed with my keys.
Attempt 2: sign Cyanogen with my keys and sideload it
Install from ADB complete!! Success!!
@user0002,
great thread! have you considered assembling a toolkit/suite for this process?
Thanks.
m
moonbutt74 said:
@user0002,
great thread! have you considered assembling a toolkit/suite for this process?
Thanks.
m
Click to expand...
Click to collapse
Hmmm... that's a good idea.

How to flash my custom Android binary from AOSP source code?

Hello, I'm working on a project with Pixel XL so, I'm trying to build Android source code and flash its output on my Pixel XL.
But there are some problems during flashing the img files.
This is my history how I have done so far.
1. Downloaded Android source code from AOSP home page and built it successfully. My build commands are:
Code:
$ source build/envsetup.sh
$ lunch aosp_arm64-eng
$ make -j8
and the output is:
Code:
[email protected]:~/AOSP/out/target/product/generic_arm64$ ls
android-info.txt build_fingerprint.txt cache.img current_build_config.mk dex_bootjars installed-files.json module-info.json obj_arm ramdisk.img root system userdata.img
boot.img cache clean_steps.mk data
2. I tried to flash the img files onto the device:
Code:
$ fastboot flash system system.img
$ fastboot flash boot boot.img
$ fastboot flash cache cache.img
However, it seems that Pixel XL does not have cache partition so that the last command failed.
3. After I executed above commands, I rebooted the device and it trapped in boot loop:
warning for bootloader unlock -> Google logo -> warning for bootloader unlock -> ...(repeat) -> enter recovery mode and stay in the mode for a while(about 5 min) -> warning for bootloader unlock -> ...(repeat)
What did I do in wrong way? I just built Android source for eng binary because I need root privilege.
And How can I build and flash Android source code for eng binary?
Please give me any small clue to resolve it.
Thanks!

Pre Rooted PATCHED_BOOT.IMG (10.0.4) for Magisk Root

Original tutorial located at https://forum.xda-developers.com/oneplus-7t/how-to/guide-how-to-root-oneplus-7t-twrp-t3979307
Hello all. Just providing this file for convenience. All credit goes to original author of the guides. This file is a pre-rooted, magisk patched boot.img for firmware version 10.0.4. Use this boot.img for flashing/booting if you are on version 10.0.4 and want to have root using magisk.
!!!I AM NOT RESPONSIBLE FOR ANY DAMAGE DONE TO YOUR DEVICE. USE COMMON SINCE AND YOU WILL BE OK!!​
STEP 1 - Put phone into fastboot mode
Code:
adb reboot fastboot
STEP 2 - Boot the patched boot.img. Download here
Code:
fastboot boot patched_boot_10.0.4.img
STEP 3 - Backup current boot.img. Open an adb shell and find which block device contains your boot partition and then using dd, make a copy of it.
Open ADB Shell
Code:
adb shell
then
Code:
su
Find boot partition
Code:
ls -lah /dev/block/bootdevice/by-name | grep -i boot
You will see something like this as output:
boot_a -> /dev/block/sde11
boot_b -> /dev/block/sde38
Make copy of boot partition(s)
Code:
dd if=/dev/sde11 of=/sdcard/boot_backup.img
DO THIS FOR BOTH BOOT PARTITIONS, LABEL ACCORDINGLY. JUST IN CASE!
Backup boot.img file(s) to PC
FROM YOUR PC, OPEN COMMAND PROMPT AND DO FOR BOTH IMAGES.
Code:
adb pull /sdcard/boot_backup.img
STEP 4 - Install magisk manager
Get magisk manager APK from here. Download the app-release.apk and install on phone.
Code:
adb install app-release.apk
STEP 5 - Open magisk manager and select Install -> Direct Install.
After you have completed the above steps, if everything worked correctly, and you followed the steps with common sense, everything should be good to go.
The download link is not working. Do you still have a patched 10.0.4 boot image?

Looking to hire tech $upport for Moto G7 Play --> /e/ Project Conversion

Money. $$$$$$$$$$$$$$$$$$$$$$
I need HELP in de-soft-bricking my Moto Play G7 and installing the /e/ project (or perhaps other Linux-based build), and I am willing to PAY for tech support to walk me through it (ideally via Skype or Zoom platform). Here are a few more specifics:
I bought a used Moto G7 Play that was updated by a developer from Android 9 to Android 10. I followed tutorials to unlock the phone and install TWRP via ADB but ran into problems, as far as I can tell, due to the Motorola A-B slot issue (it says "No bootable A/B slot, failed to boot Linux, falling back to fastboot" when I try to reboot). I can no longer recover the phone to Android or reset it to "factory" settings via the bare-bones Android and Motorola phone menus, but I remain able to issue commands via ADB / USB and also navigate to the G7's bootloader menus by using the buttons on the side of the phone. As for my PC platforms, I am running Win 10 (with ADB) but I also have Ubuntu running (so I could format SD cards to ext4 if that would help), and I have Android studio installed (not as if I know what to do with it), if that would be of any help. As far as I can tell, ADB and the Motorola USB drivers are working fine, and I USUALLY get positive indication when I type "adb devices", and I can always get the phone to acknowledge that the USB is connected/disconnected.
I don't know if this will help, but as I try to do the ADB sideload for copy-partitions.zip, this is where things don't work, as my Moto G7 play screen says:
Finding update package…
Opening update package…
Verifying update package…
E:footer is wrong
Update package verification too 0.2 s (result 1).
E: Signature verification failed
E: error:21
Installation aborted.
From there, it seems I can't go on to flash the TWRP image. Any ideas how I can work past these problems? Let me know how I can contact you via the forum and we can work $omething out. I'm guessing that this is a fast fix for someone who knows what they are doing. I'm sick of google and don't want to accept defeat! Thanks, -Andrew
Try the motorola rescue assistant
When it not workling download for your device the firmware
Instead of flashing TWRP, have you tried just booting TWRP w/o flashing?
fastboot boot twrp.img
I ran into some problems with my Moto G7 Play; I didn't softbrick it, but several things fought back, so I'll pass along what may get you back on track. First of all, I cannot use Linux to connect via fastboot, so I had to use a Mac, you can use your Windows box. Secondly, TWRP does not officially have a version for the G7 Play. I used an unofficial one from an XDA forum member HERE. It only offers a black screen unless you flash dtmo.img. I didn't want to flash dtmo.img, so I just used the black screen and used adb commands to install Lineage (and /e/) via TWRP command line.
The steps are pulled from another XDA posting showing how to use TWRP command line:
1. Connect the phone in fastboot mode to the PC, run fastboot devices to make sure it is connected.
2. Type: fastboot set_active b
Then: fastboot boot <your_recovery.img>, e.g. fastboot boot twrp.img
<phone will reboot, the screen will be black>
<wait to Windows new device sound>
3. Type: adb shell
twrp wipe cache << will not work on Moto G7 Play, but won't hurt anything.
twrp wipe dalvik
twrp wipe system
twrp wipe data <- NOW YOUR DATA WILL BE REMOVED, SO MAKE A BACKUP BEFORE!
twrp sideload
adb sideload <location_of_your_ROM.zip>, e.g. adb sideload C:\lineage-xyz.zip
IF THE TWRP commands do not work and hang saying something about "starting TWRP", I discovered by looking at the log in /tmp that /sdcard is encrypted. You will need to unencrypt /sdcard and I'm not sure how to do that without recovery; I'm sure there is way, though.
If I were you, I would see if you can flash LineageOS (or lineageOS + microG) with this method to get your phone back working, then you can move on to /e/. Note that if this works, you will have a recovery program available (the standard Lineage recovery), which has some basic tools. You CAN ONLY load Lineage-signed roms with this recovery. So if you want to switch from lineage to /e/ or to lineage+microG, you will need to use the twrp method above to switch to the other rom. Then you can use the lineage or /e/ recovery to install lineage or /e/ updates from the same publisher.
Also, if you install stock lineage, don't use a bleeding edge version. Pick one from mid-October so if you decide to switch to /e/ or Lineage+microG you will not be downgrading because they don't make nightly builds. It probably won't hurt since downgrading a week probably has few changes, but just in case.
Hope this helps.
maw1 said:
Try the motorola rescue assistant
When it not workling download for your device the firmware
Click to expand...
Click to collapse
I tried the Motorola Device Manager tool. Not sure if I made a good backup to begin with, and now I try to open the tool it doesn't seem to do anything.
xtermmin said:
Instead of flashing TWRP, have you tried just booting TWRP w/o flashing?
fastboot boot twrp.img
Click to expand...
Click to collapse
Tried that... It says it FAILED.
C:\adb>fastboot boot twrp.img
downloading 'boot.img'...
OKAY [ 0.427s]
booting...
FAILED (remote failure)
finished. total time: 1.054s
Exinu said:
I ran into some problems with my Moto G7 Play; I didn't softbrick it, but several things fought back, so I'll pass along what may get you back on track. First of all, I cannot use Linux to connect via fastboot, so I had to use a Mac, you can use your Windows box. Secondly, TWRP does not officially have a version for the G7 Play. I used an unofficial one from an XDA forum member HERE. It only offers a black screen unless you flash dtmo.img. I didn't want to flash dtmo.img, so I just used the black screen and used adb commands to install Lineage (and /e/) via TWRP command line.
The steps are pulled from another XDA posting showing how to use TWRP command line:
1. Connect the phone in fastboot mode to the PC, run fastboot devices to make sure it is connected.
2. Type: fastboot set_active b
Then: fastboot boot <your_recovery.img>, e.g. fastboot boot twrp.img
<phone will reboot, the screen will be black>
<wait to Windows new device sound>
3. Type: adb shell
twrp wipe cache << will not work on Moto G7 Play, but won't hurt anything.
twrp wipe dalvik
twrp wipe system
twrp wipe data <- NOW YOUR DATA WILL BE REMOVED, SO MAKE A BACKUP BEFORE!
twrp sideload
adb sideload <location_of_your_ROM.zip>, e.g. adb sideload C:\lineage-xyz.zip
IF THE TWRP commands do not work and hang saying something about "starting TWRP", I discovered by looking at the log in /tmp that /sdcard is encrypted. You will need to unencrypt /sdcard and I'm not sure how to do that without recovery; I'm sure there is way, though.
If I were you, I would see if you can flash LineageOS (or lineageOS + microG) with this method to get your phone back working, then you can move on to /e/. Note that if this works, you will have a recovery program available (the standard Lineage recovery), which has some basic tools. You CAN ONLY load Lineage-signed roms with this recovery. So if you want to switch from lineage to /e/ or to lineage+microG, you will need to use the twrp method above to switch to the other rom. Then you can use the lineage or /e/ recovery to install lineage or /e/ updates from the same publisher.
Also, if you install stock lineage, don't use a bleeding edge version. Pick one from mid-October so if you decide to switch to /e/ or Lineage+microG you will not be downgrading because they don't make nightly builds. It probably won't hurt since downgrading a week probably has few changes, but just in case.
Hope this helps.
Click to expand...
Click to collapse
Thanks for the effort, Exinu, but it seems to not fully recognize the command or is looking for another flag or operand. The "set_active b" command that you proposed just results in making a list like for a "help" or unspecified command. As you can see below, I tried other variations of the command after I tried searching out more details. I also tried "fastboot set_active=b" and it does the same thing with the listing. I'm assuming that it's not accepting this command. I did try the twrp-dirtyport image as well, but as you can see below, that created an error as well:
C:\adb>fastboot --set_active b
fastboot: unknown option -- set_active
C:\adb>fastboot --set-active=b
fastboot: unknown option -- set-active=b
C:\adb>fastboot set_active b
usage: fastboot [ <option> ] <command>
commands:
update <filename> reflash device from update.zip
flashall flash boot, system, vendor and if found,
recovery
flash <partition> [ <filename> ] write a file to a flash partition
flashing lock locks the device. Prevents flashing partitions
flashing unlock unlocks the device. Allows user to flash any partition except the ones that are related to bootloader
flashing lock_critical Prevents flashing bootloader related partitions
flashing unlock_critical Enables flashing bootloader related partitions
flashing get_unlock_ability Queries bootloader to see if the device is unlocked
erase <partition> erase a flash partition
format[:[<fs type>][:[<size>]] <partition> format a flash partition.
Can override the fs type and/or
size the bootloader reports.
getvar <variable> display a bootloader variable
boot <kernel> [ <ramdisk> ] download and boot kernel
flash:raw boot <kernel> [ <ramdisk> ] create bootimage and flash it
devices list all connected devices
continue continue with autoboot
reboot [bootloader] reboot device, optionally into bootloader
reboot-bootloader reboot device into bootloader
help show this help message
options:
-w erase userdata and cache (and format
if supported by partition type)
-u do not first erase partition before
formatting
-s <specific device> specify device serial number
or path to device port
-l with "devices", lists device paths
-p <product> specify product name
-c <cmdline> override kernel commandline
-i <vendor id> specify a custom USB vendor id
-b <base_addr> specify a custom kernel base address.
default: 0x10000000
-n <page size> specify the nand page size.
default: 2048
-S <size>[K|M|G] automatically sparse files greater
than size. 0 to disable
C:\adb>​
I did try the next step with the dirtyboot but that seem to have failed as well.
C:\adb>fastboot boot twrp-dirtyport-g7play.img
downloading 'boot.img'...
OKAY [ 0.570s]
booting...
FAILED (status read failed (Too many links))
finished. total time: 1.566s​
On my phone on the "Bootloader logs" screen, it said (before I began)
Start Up Failed:​Your device didn't stat up successfully.
Use the Software Repair Assistant on computer to repair your device.
Connect your device to your computer to get
the Software Repair Assistant.
AP Fastboot Flash Mode (Secure)
No bootable A/B slot
Failed to boot Linux, falling back to fastboot
Fastboot Reason: Fall-through from normal boot mode
USB Connected​
I then typed fastboot devices from my windows C:\ADB prompt and it showed me it was connected.
After running the stuff mentioned above, it said:
cmd: download:01348000
cmd: boot
Incomplete boot image for booting.
I disconnected and reconnect the USB and then I tried the fastloading of the dirtyport image again. The screen went blank and said the same stuff again with no bootable A/B slot, which leaves me to believe this is where my problem starts.
Any other ideas?
Any ideas
I think you may have several issues that need to be fixed one step at a time. First, I think you have an old fastboot if it doesn't recognize the set_active command. Go to this link: https://developer.android.com/studio/ and scroll down to the section labeled "Command Line tools only" and download the command line tools. Make sure you are in that directory in Windows so you are running the newer version and not the old version installed. If you run "fastboot --help" you should see set_active as an option.
Next, where did you get the TWRP? Go to the link I provided, which has a (black screen) TWRP that I have used and it works. Start from there and see how things proceed.
Exinu said:
I think you may have several issues that need to be fixed one step at a time. First, I think you have an old fastboot if it doesn't recognize the set_active command. Go to this link: https://developer.android.com/studio/ and scroll down to the section labeled "Command Line tools only" and download the command line tools. Make sure you are in that directory in Windows so you are running the newer version and not the old version installed. If you run "fastboot --help" you should see set_active as an option.
Next, where did you get the TWRP? Go to the link I provided, which has a (black screen) TWRP that I have used and it works. Start from there and see how things proceed.
Click to expand...
Click to collapse
I got the TWRP from the link that you provided. As for running "fastboot --help", I did not see the "set_active" flag listed as an option (results pasted below). I also tried to download the command line tools as suggested, but not positive as to which directory they are to reside in, or which of the files I should launch. I unzipped the commandlinetools directory (in my adb directory) and tried running the sdkmanager.bat batch file which was nested in one of the subdirectories (it briefly opened and flashed a window but seemed to do nothing more). Not sure if this matters, but I also have android studio installed, although I am not sure how or where the "set_active" command comes from. I tried downloading windows latest PowerShell, and have also tried CMD as adminstrator. From my searching, I see people using "--set-active" with android commands as well, but I really don't know if this is a MS/DOS based command that is used for controlling drives and partitions on the Windows system, or if it's an adhock SDK - Linux add-on command of sorts. I can't seem to find much info on the command.
This is how it reads:
PS C:\adb> fastboot --help
usage: fastboot [ <option> ] <command>
commands:
update <filename> reflash device from update.zip
flashall flash boot, system, vendor and if found,
recovery
flash <partition> [ <filename> ] write a file to a flash partition
flashing lock locks the device. Prevents flashing
partitions
flashing unlock unlocks the device. Allows user to
flash any partition except the ones that are related to bootloader
flashing lock_critical Prevents flashing bootloader related
partitions
flashing unlock_critical Enables flashing bootloader related
partitions
flashing get_unlock_ability Queries bootloader to see if the device is unlocked
erase <partition> erase a flash partition
format[:[<fs type>][:[<size>]] <partition> format a flash partition.
Can override the fs type and/or
size the bootloader reports.
getvar <variable> display a bootloader variable
boot <kernel> [ <ramdisk> ] download and boot kernel
flash:raw boot <kernel> [ <ramdisk> ] create bootimage and flash it
devices list all connected devices
continue continue with autoboot
reboot [bootloader] reboot device, optionally into bootloader
reboot-bootloader reboot device into bootloader
help show this help message
options:
-w erase userdata and cache (and format
if supported by partition type)
-u do not first erase partition before
formatting
-s <specific device> specify device serial number
or path to device port
-l with "devices", lists device paths
-p <product> specify product name
-c <cmdline> override kernel commandline
-i <vendor id> specify a custom USB vendor id
-b <base_addr> specify a custom kernel base address.
default: 0x10000000
-n <page size> specify the nand page size.
default: 2048
-S <size>[K|M|G] automatically sparse files greater
than size. 0 to disable
PS C:\adb>​
PS C:\adb> set_active
set_active : The term 'set_active' is not recognized as the name of a cmdlet, function, script file, or operable
program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.
At line:1 char:1
+ set_active
+ ~~~~~~~~~~
+ CategoryInfo : ObjectNotFound: (set_active:String) [], CommandNotFoundException
+ FullyQualifiedErrorId : CommandNotFoundException
Any other ideas?
The command-line tools download should not require any installation; at least, the Mac version did not. Unzip the file to your desktop. Then open a command prompt which should open in c:\Users\your_user . Enter "cd Desktop" to change to the Desktop folder, then cd <foldername> to change into the folder you unzipped the files into. Windows will sometimes unzip a folder into a second folder, so you may need to cd <foldername> once more. In any case, enter "dir" to make sure you see files like fastboot.exe, adb.exe, etc.
In Windows, when you type a command it will first look to your current directory and run the exe file that exists there, if it exists. If it does not, then it starts looking for the command in your %PATH% environment variable. That's why you need to "cd" to the tools directory: when you run "fastboot", you want it to run fastboot.exe in that directory, and not the old fastboot.exe that is installed somewhere on your system.
It sounds like you haven't worked with the command line much; I suggest you go through some tutorials on basic command line usage for both Windows and Linux; it will make tinkering with computers and phones much easier. And set_active is not a DOS/Windows command, it is parameter you are passing to fastboot.exe to tell it what action you want it to do; it just also calls these actions "commands". So when you typed c:>set_active, you told Windows to find a file called set_active.exe and run it. That file does does not exist, so it did not work.
Quick note: the Unix command line will not run a command from the current directory for multiuser security reasons; you need to specify the current directory (dot) and a slash on the command like this: ./fastboot
This will also work with DOS/Windows, but usually the backslash is used instead of the forward slash, for very old historical reasons.
Exinu said:
The command-line tools download should not require any installation; at least, the Mac version did not. Unzip the file to your desktop. Then open a command prompt which should open in c:\Users\your_user . Enter "cd Desktop" to change to the Desktop folder, then cd <foldername> to change into the folder you unzipped the files into. Windows will sometimes unzip a folder into a second folder, so you may need to cd <foldername> once more. In any case, enter "dir" to make sure you see files like fastboot.exe, adb.exe, etc.
In Windows, when you type a command it will first look to your current directory and run the exe file that exists there, if it exists. If it does not, then it starts looking for the command in your %PATH% environment variable. That's why you need to "cd" to the tools directory: when you run "fastboot", you want it to run fastboot.exe in that directory, and not the old fastboot.exe that is installed somewhere on your system.
It sounds like you haven't worked with the command line much; I suggest you go through some tutorials on basic command line usage for both Windows and Linux; it will make tinkering with computers and phones much easier. And set_active is not a DOS/Windows command, it is parameter you are passing to fastboot.exe to tell it what action you want it to do; it just also calls these actions "commands". So when you typed c:>set_active, you told Windows to find a file called set_active.exe and run it. That file does does not exist, so it did not work.
Quick note: the Unix command line will not run a command from the current directory for multiuser security reasons; you need to specify the current directory (dot) and a slash on the command like this: ./fastboot
This will also work with DOS/Windows, but usually the backslash is used instead of the forward slash, for very old historical reasons.
Click to expand...
Click to collapse
Exinu, thanks for your continued assistance. As it turns out the fastboot/adb version I was using didn't include the "set_active" command (I don't think it was a path problem as I was always typing commands from the in directory where the ADB software was downloaded). As I had tried to follow a number of different tutorials of the course of several weeks, some for the G7 play, and perhaps some for the G7 and others generic, I think the place on the web that I went for the original ADB package (or the ADB version) was the problem. I also found another copy of ADB on my drive (downloaded weeks ago) that was titled "Minimal ADB and Fastboot", and as it turns out, that version DID support the set_active operand (from the fastboot --help command). So, I was able to return to your initial directions to set the active partion to b as initially instructed (see below, but the phone also shows that the set_active:b command seemed to process without error). However, I was not able to do the next step of flashing the TWRP. I tried the TWRP version you suggested and linked to (the dirtyport version) and then also the "channel" version, which I understand to be designed for the G7 play, unlike the "river" version. In either case (dirtyport or channel) I get a new/different "usage: unknown command" error, as seen in text pasted below:
C:\Program Files (x86)\Minimal ADB and Fastboot>fastboot set_active b
Setting current slot to 'b'...
OKAY [ 0.176s]
finished. total time: 0.178s
C:\Program Files (x86)\Minimal ADB and Fastboot>dir
Volume in drive C has no label.
Volume Serial Number is EC2B-BC54
Directory of C:\Program Files (x86)\Minimal ADB and Fastboot
2020-11-27 01:42 PM <DIR> .
2020-11-27 01:42 PM <DIR> ..
2018-01-11 06:53 PM 1,784,320 adb.exe
2018-01-11 06:53 PM 97,792 AdbWinApi.dll
2018-01-11 06:53 PM 62,976 AdbWinUsbApi.dll
2015-08-09 01:50 PM 29,882 cmd-here.exe
2018-01-11 06:53 PM 853,504 fastboot.exe
2020-08-17 02:31 AM 1,456,678 logo.bin
2020-08-15 11:25 PM 27,848,704 twrp
2020-09-03 02:52 AM 27,133,952 twrp-dirtyport-g7play.img
2020-08-16 01:12 AM 17,307,289 twrp-installer-3.4.0-0-river.zip
2020-11-17 04:21 AM 23,298,048 twrp-moto-g7-play-channel-android-10.img
2020-08-15 11:25 PM 27,848,704 twrp.img
2020-11-27 01:27 PM 5,004 unins000.dat
2020-11-27 01:26 PM 717,985 unins000.exe
13 File(s) 128,444,838 bytes
2 Dir(s) 28,010,246,144 bytes free
C:\Program Files (x86)\Minimal ADB and Fastboot>fastboot twrp-dirtyport-g7play.img
fastboot: usage: unknown command twrp-dirtyport-g7play.img
Granted, I'm not a command line expert, but I have been playing with computers since the TRS-80 and the C64 and Apple IIe, and 8086 DOS stuff, and used to do QBasic programming as a kid, so in most cases, I can usually navigate myself through some hairy computer instructions to do whatever I need to do, unless the instructions themselves are hairy. I find that the Android Dev forums are predicated upon some knowledge of those platforms and are a rude awakening for those unfamiliar with the development history and architecture. Obviously, I'm going to extremes to try to de-google an Android phone (frankly I would be happier if there was more stuff on the market that already was preinstalled), as this google censorship and proposed contract tracing stuff is just getting out of hand and going too far... so this is my way of fighting back. I'd rather know nothing about ADB, but here I am.
Is there any chance you know how or why I am getting the "fastboot: usage: unknown command twrp..." error above, or how I can resolve it?
You are getting close. Your fastboot entry is a little off. It should be >fastboot boot <filename.img>. If the twrp img file is not in the current directory, you will need to provide the full path.
Exinu said:
You are getting close. Your fastboot entry is a little off. It should be >fastboot boot <filename.img>. If the twrp img file is not in the current directory, you will need to provide the full path.
Click to expand...
Click to collapse
OK, so that was a head-slapping "duh" moment on my end (using fastboot filename.img instead of fastboot boot filename.img). However, now that I've entered the right command I'm still having problems. As you indicate in your post above, the "fastboot boot" command did initiate the sequence, and the screen did go black, however, one of the screens that it went to only said "bad key" at the upper left hand corner.
C:\Program Files (x86)\Minimal ADB and Fastboot>fastboot boot twrp-dirtyport-g7play.img
downloading 'boot.img'...
OKAY [ 0.575s]
booting...
FAILED (status read failed (Too many links))
finished. total time: 1.580s​
As for my phone screen, it goes black and cycles saying "bad key" a few times, and after a few attempts it reverts to the Bootload logs screen, giving the same message it did that I started with.
Start Up Failed​
Your device didn't start up successfully.
Use the Software Repair Assistant on computer
to repair your device.
Connect you device to your computer to get
the Software Repair Assistant. ​AP Fastboot Flash Mode (Secure)
No bootable A/B slot
Failed to boot Linux, falling back to fastboot
Fastboot Reason: Fall-through from normal boot mode
USB Connected​
Exinu said:
You are getting close. Your fastboot entry is a little off. It should be >fastboot boot <filename.img>. If the twrp img file is not in the current directory, you will need to provide the full path.
Click to expand...
Click to collapse
OK, I after the "dirtyport" image didn't work, I went out on a limb and tried to flash a different img file, (first doing the set_active b command), typing:
C:\Program Files (x86)\Minimal ADB and Fastboot>fastboot boot twrp-moto-g7-play-channel-android-10.img
downloading 'boot.img'...
OKAY [ 0.496s]
booting...
OKAY [ 0.178s]
finished. total time: 0.679s​It briefly flashed the Moto screen and then went black. After this, with the black screen, it seemed like it was able to the "adb shell" command, although it seemed to not be able to take the TWRP commands:
C:\Program Files (x86)\Minimal ADB and Fastboot>adb shell
* daemon not running; starting now at tcp:5037
* daemon started successfully
channel:/ # twrp wipe cache
Unable to find partition for path '/cache'
Done processing script file
channel:/ # twrp wipe dalvik
Failed to mount '/data' (Invalid argument)
Done processing script file
channel:/ # twrp wipe system
E:Error with wipe command value: 'system'
Done processing script file
channel:/ # twrp wipe data
Failed to mount '/data' (Invalid argument)
Done processing script file
channel:/ # twrp sideload
C:\Program Files (x86)\Minimal ADB and Fastboot>adb sideload lineage-17.1-20201129-nightly-channel-signed.zip
Total xfer: 1.00x​
After this point it went back to the "bad key" and return to the Bootloger logs screen.
I'm assuming at this point if there is a failure in the TWRP command sequence (as suggested above) I shouldn't expect the latter commands to work. I also attempted to use the moto g7's built-in recovery menu that is available from pushing and holding the power and upper volume button. When I tried to "apply update from ADB" using the phone to initiate the effort, and then typed, C:\Program Files (x86)\Minimal ADB and Fastboot>adb sideload lineage-17.1-20201129-nightly-channel-signed.zip, the phone screen read as follows:
Supported APR: 3
Stopping adbd...
Now send the package you want to apply to the device with the "adb sideload ,filename"...
Finding update package...
Opening update package...
Verifying update package...
E: failed to verify whole-file signature Update package verification took 45.2 s (result 1).
E: Signature verification failed
E: error: 21
Installation aborted. ​
Exinu said:
You are getting close. Your fastboot entry is a little off. It should be >fastboot boot <filename.img>. If the twrp img file is not in the current directory, you will need to provide the full path.
Click to expand...
Click to collapse
Even though I was getting errors after the "WIPE" command, it seems like the adb shell is bringing about a linux-esque terminal of the channel image and I can see the files/directories. Using the LS command it seems that the folders you are mentioned are empty, with the exception that there is no "dalvik" directory:
C:\Program Files (x86)\Minimal ADB and Fastboot>adb shell
channel:/ # twrp
TWRP openrecoveryscript command line tool, TWRP version 3.3.1-0
Allows command line usage of TWRP via openrecoveryscript commands.
Some common commands include:
install /path/to/update.zip
backup <SDCRBAEM> [backupname]
restore <SDCRBAEM> [backupname]
wipe <partition name>
sideload
set <variable> [value]
decrypt <password>
remountrw
fixperms
mount <path>
unmount <path>
print <value>
mkdir <directory>
reboot [recovery|poweroff|bootloader|download|edl]
See more documentation at https://twrp.me/faq/openrecoveryscript.html
channel:/ # ls
acct config etc init.rc init.recovery.usb.rc persist plat_service_contexts res sideload tmp vendor_file_contexts vndservice_contexts
bin d external_sd init.recovery.hlthchrg.rc license plat_file_contexts postinstall root storage twres vendor_hwservice_contexts
bugreports data file_contexts.bin init.recovery.mksh.rc mnt plat_hwservice_contexts proc sbin sys ueventd.rc vendor_property_contexts
cache default.prop firmware init.recovery.qcom.rc odm plat_property_contexts product sdcard system usb_otg vendor_seapp_contexts
charger dev init init.recovery.service.rc oem plat_seapp_contexts prop.default sepolicy system_root vendor vendor_service_contexts​
Here are the directory contents:
channel:/ # cd data
channel:/data # ls
channel:/data # cd /
channel:/ # cd cache
channel:/cache # ls
channel:/cache # cd /
channel:/ # cd system
channel:/system # ls
channel:/system # cd /
channel:/ # cd dalvik
/sbin/sh: cd: /dalvik: No such file or directory​
When you went into recovery mode, was it Motorola's stock recovery or LineageOS's recovery (with the Lineage logo (the three circles))?
In any case, at least you have a working recovery. Error 21 simply means that the signature is on the firmware file is not what it was expecting. If you have a Motorola recovery, then it expects a Motorola-signed firmware. If it is the Lineage recovery, then it will only flash Lineage-signed firmware.
Your TWRP sideload command sure looks like it worked when it loaded the firmware, but if it had worked, you would have LineageOS recovery and it would say current slot: a. I don't remember if the stock Motorola recovery displays the current slot. When you tell fastboot to set_active b, it sets the current slot to b and then when you install the firmware it installs the firmware to slot a.
Exinu said:
When you went into recovery mode, was it Motorola's stock recovery or LineageOS's recovery (with the Lineage logo (the three circles))?
In any case, at least you have a working recovery. Error 21 simply means that the signature is on the firmware file is not what it was expecting. If you have a Motorola recovery, then it expects a Motorola-signed firmware. If it is the Lineage recovery, then it will only flash Lineage-signed firmware.
Your TWRP sideload command sure looks like it worked when it loaded the firmware, but if it had worked, you would have LineageOS recovery and it would say current slot: a. I don't remember if the stock Motorola recovery displays the current slot. When you tell fastboot to set_active b, it sets the current slot to b and then when you install the firmware it installs the firmware to slot a.
Click to expand...
Click to collapse
Exinu,
It looks like the fastboot set_active b command worked, in that my phone acknowledged it did, and the command prompt seemed to indicate the same. As for the phone screen, the Moto splash screen that flashed quickly (probably less than 1 second) did not have any hint of Lineage logo. I tried repeating the process and saw the logo a total of 3x. It was the C:\Program Files (x86)\Minimal ADB and Fastboot>fastboot boot twrp-moto-g7-play-channel-android-10.img command that got me there (the "dirtyport" image you suggested didn't work) and it was before the attempt to flash the lineage image.
However, as for the ADB SHELL commands that you recommended, it didn't seem like they were doing what one might expect. Subsequent to the attempted TWRP commands in the shell, I tried to sideload the lineage system but it would not take, saying "bad key" on the upper LH side of the screen.
Is it possible that prior image flashing attempts have left some incompatible clutter on my phone (perhaps visible by means of exploring other folders or folder names via the ADB SHELL)? I've been working with Raspberry PI's and PC based OMV / Nextcloud servers in recent months and perceive that new installs seem inclined to revert to old files on occasion if not thoroughly formatted.
One thing I forgot to mention: since you are installing Lineage, you can use the Lineage recovery to install it. TWRP is only necessary for /e/ or other roms that do not have their own recovery. Try "fastboot boot" but specify the lineage recovery file.
Also, now that I review things again, I may have used this TWRP instead of the "dirty port" version. I don't know if it will make a difference, but it might be worth a try. Sorry, I guess I have too many irons in the fire right now and got it mixed up. Scroll down to abou t the third or forth comment and there is a google drive link. You just need the recovery.img. Do not flash the dtmo.img, just fastboot/boot the recovery image: https://forum.xda-developers.com/t/...y-custom-recovery-kernel-source-code.3933680/

Categories

Resources