The instructions for Lineage OS don't seem to tally up with my Recovery menu (Team Win on the latest version 3.5.1_9-0) :
"2. Now, use the volume buttons to select “Advanced”, and then “Enable ADB”."
There's no option to enable ADB in the advanced menu,
"3. Now tap Factory Reset, then Format data / factory reset....."
There's no Factory Reset option
"5. On the device, select “Apply Update”...."
There is no apply update option.
Am I missing something simple?
replicon1 said:
The instructions for Lineage OS don't seem to tally up with my Recovery menu (Team Win on the latest version 3.5.1_9-0) :
"2. Now, use the volume buttons to select “Advanced”, and then “Enable ADB”."
There's no option to enable ADB in the advanced menu,
"3. Now tap Factory Reset, then Format data / factory reset....."
There's no Factory Reset option
"5. On the device, select “Apply Update”...."
There is no apply update option.
Am I missing something simple?
Click to expand...
Click to collapse
Yes you are. These are totally different recoveries so they look different.
TWRP menu vs Lineage menu.
2) If I'm not mistaken, adb should be turned on by default in twrp.
3) In twrp you find this on the "wipe" button
5) In twrp the apply update functionality should be under "advanced". Else, you could just adb push your file to your device and install via the "install" buttton.
User699 said:
Yes you are. These are totally different recoveries so they look different.
TWRP menu vs Lineage menu.
2) If I'm not mistaken, adb should be turned on by default in twrp.
3) In twrp you find this on the "wipe" button
5) In twrp the apply update functionality should be under "advanced". Else, you could just adb push your file to your device and install via the "install" buttton.
Click to expand...
Click to collapse
Thanks, I was starting to lose the will to live.
replicon1 said:
Thanks, I was starting to lose the will to live.
Click to expand...
Click to collapse
No need to. Hope you'll be fine!
Managed to get Lineage installed but I don't seem to be able to install MindTheGapps. Error states "Could not mount /mnt/system Aborting". I've tried searching for this issue but it I can't find a solution. Now it won't boot to Lineage. Should I wipe it and start again?
replicon1 said:
Managed to get Lineage installed but I don't seem to be able to install MindTheGapps. Error states "Could not mount /mnt/system Aborting". I've tried searching for this issue but it I can't find a solution. Now it won't boot to Lineage. Should I wipe it and start again?
Click to expand...
Click to collapse
You could try wiping it.
I didn't flash gapps, but as far as I know it should be flashed before booting into the OS for the first time.
replicon1 said:
Managed to get Lineage installed but I don't seem to be able to install MindTheGapps. Error states "Could not mount /mnt/system Aborting". I've tried searching for this issue but it I can't find a solution. Now it won't boot to Lineage. Should I wipe it and start again?
Click to expand...
Click to collapse
Any progress with installing MindTheGapps?
I got the same error message about not being able to mount system with my LG G2.
nexus212 said:
Any progress with installing MindTheGapps?
I got the same error message about not being able to mount system with my LG G2.
Click to expand...
Click to collapse
Do you have twrp or stock-lineageos-recovery installed?
If it cannot mount it, something isn't working as it's supposed to.
Can you try this from within your recovery?:
Code:
mkdir /tmp/system_b
Here I'm creating a mount point for my system_b (I have system a and b due to a a-b partitioned device) in the tmp folder.
Code:
mount /dev/block/by-name/system_b /tmp/system_b
I am mounting my system_b partition on the previously created mounting point.
Your system partition might be at a slightly different place somewhere in /dev/block/.
Code:
ls /tmp/system_b/
Just listing the content of system_b.
Spoiler: You should get an output similar to this one
Code:
acct default.prop init.zygote32.rc res
apex dev init.zygote64_32.rc sbin
bin dsp lost+found sdcard
bt_firmware etc mnt storage
bugreports firmware odm sys
cache init oem system
charger init.environ.rc persist tmp
config init.rc postinstall ueventd.rc
d init.recovery.qcom.rc proc vendor
data init.usb.configfs.rc product verity_key
debug_ramdisk init.usb.rc product_services
Code:
umount /tmp/system_b/
Unmount the system_b partition from that mounting point we created earlier, since it's not needed anymore.
Code:
rmdir /tymp/system_b/
Remove system_b directory we created at the beginning since we don't need it anymore.
Please note that I'm using 'rmdir' instead of 'rm -R' because 'rmdir' will fail if /tmp/system_b/ isn't empty (preventing you to accidentally delete your system partition).
If that works for you (especially the mounting part), then your recovery should be able to do it itself too.
Yes, I had(/have?) twrp installed and with that it didn't worked. Yesterday I pinned it down to the installation script not being able to find the system block by adding some additional ui_prints.
But today I followed upgrade instructions (https://wiki.lineageos.org/devices/d802/upgrade) again with installed LOS 18.1 image and somehow my device booted into lineageos-recovery instead of twrp and I was able to fully install LOS 18.1 (again, just to be save) and MTGapps.
Although my issue accidentally fixed itself, thank you for you attempt to help!
replicon1 said:
Managed to get Lineage installed but I don't seem to be able to install MindTheGapps. Error states "Could not mount /mnt/system Aborting". I've tried searching for this issue but it I can't find a solution. Now it won't boot to Lineage. Should I wipe it and start again?
Click to expand...
Click to collapse
try this twrp,it should be able to install MindTheGapps.
Any chance to get this modified twrp for herolte?
replicon1 said:
Managed to get Lineage installed but I don't seem to be able to install MindTheGapps. Error states "Could not mount /mnt/system Aborting". I've tried searching for this issue but it I can't find a solution. Now it won't boot to Lineage. Should I wipe it and start again?
Click to expand...
Click to collapse
I recently ran into this issue. In my case, it was due to /etc/recovery.fstab using tabs, while MindTheGapps was expecting spaces. I filed a merge request here, but you can try making the change yourself by editing META-INF/com/google/android/update-binary in the MindTheGapps zip file.
rkjnsn said:
I recently ran into this issue. In my case, it was due to /etc/recovery.fstab using tabs, while MindTheGapps was expecting spaces. I filed a merge request here, but you can try making the change yourself by editing META-INF/com/google/android/update-binary in the MindTheGapps zip file.
Click to expand...
Click to collapse
I got the same error. According to your hint, I tried to change the line in "update-binary": Unzipping all files, changing the file's content, zipping again, installing. Now I'm said the zip in invalid: "Invalid zip file format"
Can you please let me/us know how to zip a file TWRP accepts for installing?
was having issues installing gapps and searches brought me here, tomintpe i would avoid regenerating the zip file and just add the edited file back to the zip... Am working on that myself.... if i get it to work will attempt to attach the file
Okay, this was tested on a samsung galaxy s2 gt-i9100, this was going into the MindTheGapps-11.0.0-arm-20210412_124103 package for a lineage os 18.1 install. So, make sure this applies to you before you copy/paste anything ok?
The issue was the line "grep -v "^#" /etc/recovery.fstab | grep " $1 " | tail -n1 | tr -s ' ' | cut -d' ' -f1"
which i replaced with "grep -v "^#" /etc/fstab | grep "$1" | sed 's/ */!/g' | cut -d'!' -f1"
Am using sed to replace whitespace with !'s (unsure why cut -d' ' didn't work but, it didnt) and also looking at /etc/fstab instead of recovery although recovery would have probably worked fine.
Thanks for the answers so far.
When I want to update the original zip file with the edited "update.binary" I wonder how to get the file into the right directory in the zip file. A simple
Code:
zip MindTheGapps-11.0.0-arm64-20210412_124247.zip update-binary
just adds the new file to the archive's main directory.
How do I get the updated file where its belong to in the zip without newly building the zip file?
Ok, I found out myself how to update the zip file using the flag -u with the same directory structure.
But changing the "update-binary" 's line 44 into "grep -v "^#" /etc/fstab | grep "$1" | sed 's/ */!/g' | cut -d'!' -f1" or "grep -v "^#" /etc/recovery.fstab | grep "[[:blank:]]$1[[:blank:]]" | tail -n1 | tr -s [:blank:] ' ' | cut -d' ' -f1" does not help. I still get the TWRP error "Could not mount /mnt/system Aborting".
get_block_for_mount_point() {
#grep -v "^#" /etc/recovery.fstab | grep " $1 " | tail -n1 | tr -s ' ' | cut -d' ' -f1
grep -v "^#" /etc/recovery.fstab | grep "$1" | tail -n1 | rev | cut -f1 | rev
}
semellle said:
get_block_for_mount_point() {
#grep -v "^#" /etc/recovery.fstab | grep " $1 " | tail -n1 | tr -s ' ' | cut -d' ' -f1
grep -v "^#" /etc/recovery.fstab | grep "$1" | tail -n1 | rev | cut -f1 | rev
}
Click to expand...
Click to collapse
No, same error message.
You need to test the command with adb shell.
Can you send me the content of your : /etc/recovery.fstab
Or just past the result of this cmd:
grep system /etc/recovery.fstab
Related
What is the most reliable recovery currently? I'm using twrp at the moment. It's probably an older version so I'm curious what is recommended before i update it.
Sent from my Kindle Fire using Tapatalk 2
pwned3 said:
What is the most reliable recovery currently? I'm using twrp at the moment. It's probably an older version so I'm curious what is recommended before i update it.
Sent from my Kindle Fire using Tapatalk 2
Click to expand...
Click to collapse
My suggestion would be for you to stay with TWRP. Version 2.1.1 is the latest.
kinfauns said:
My suggestion would be for you to stay with TWRP. Version 2.1.1 is the latest.
Click to expand...
Click to collapse
I agree
Sent from my Galaxy Nexus using XDA
pwned3 said:
What is the most reliable recovery currently? I'm using twrp at the moment. It's probably an older version so I'm curious what is recommended before i update it.
Click to expand...
Click to collapse
You already know that TWRP is intuitive and easy to use. I'm using TWRP 2.1.1 and I have used recovery many times when trying out new ROM builds. Occassionally with 2.1.1 I find that the operation that you want to do just fails with either an error outright or will fail during the recovery process. It even failed on me once while creating a backup. I didn't pay much attention to the backup output log text once and I did want to recover that backup and could not due to an image file being zero bytes in size. I have my own app and data backup script that I wrote that keeps me current so recovery in such a failed case is simply flashing a new ROM and executing my recovery script; couldn't be simpler.
If you pay attention to TWRP's output and not just make an assumption that the backup or recovery succeeded then you can just repeat the operation until it's successful. This is rare but has happened to me more than once but even with that issue, I still like TWRP 2.1.1 (plus my own app backup script).
I'll include my app backup and recovery script here in case others can find it useful (I make no claims that will work to your liking however or that it will even work for you)
rebaseline.sh
Code:
#!/system/xbin/bash
cd /sdcard/BACKUP/
for i in `/system/bin/pm list packages -3 -f`
do
read junk apk pkg <<< =`echo $i | sed -e 's/[=:]/ /g'`
echo "Processing $pkg..."
echo " backing up $apk..."
cp $apk baseline/
touch /sdcard/BACKUP/baseline/`basename $apk`
echo " backing up data..."
busybox tar czf /sdcard/BACKUP/baseline/$pkg.tar.gz --exclude lib --exclude cache /data/data/$pkg 2>/dev/null
done
echo "Processing accounts..."
echo " backing up data..."
busybox tar czf /sdcard/BACKUP/baseline/accounts.tar.gz /data/system/accounts.db 2>/dev/null
Here is my recovery script:
restore-from-baseline.sh
Code:
#!/system/xbin/bash
cd /sdcard/BACKUP
pm set-install-location 1
chmod 777 /data/data
for i in baseline/*apk
do
X=${i/-[0-9].apk}
Y=`basename $i`
Y=${Y/-[0-9].apk}
echo $X
pm install -r $i
# Find out what the new app ID is for the package
OWNER=`/system/bin/ls -l /data/data | grep $Y | awk '{print $3;}'`
echo $OWNER
# Restore data as the app owner ID
chmod 777 /data/data/$Y
su --command "tar xvf /sdcard/BACKUP/$X.tar.gz -C /" $OWNER
echo "tar rc=$?"
chmod 751 /data/data/$Y
echo
done
chmod 771 /data/data
echo "Restoring accounts.db - reboot will be required"
tar xvf /sdcard/BACKUP/baseline/accounts.tar.gz -C /
There is one limitation that I haven't worked into the script yet. Any time there is an app update you will see a duplicate app in the baseline folder differentiated by -1 or -2. Before recovery you can just get rid of the oldest version of the apk file; the data is always current.
I'm sure that there are a lot of apps that this script would not work with but it does work very well with mine and cuts down recovery to a minute or two. I don't use Titanium Backup myself.
I've been sticking with TWRP 2.1.1, simply because I really like how it can compress backups, meaning more space for music and videos. Haven't had any issues with it, but I do prefer the look of CWRecovery, particularly Hashcode's latest release.
Hi all folks,
I have some question about the stock android system in this specific box and the format of the dumped partition.
Try to explain, I'm using rkflashtool to interact with the memory of the RK3188
This is the output of the command
rkflashtool r 0 1 | head -n 11
-------------------------------------------------------------------------------------------------
CMDLINE:console=ttyFIQ0 androidboot.console=ttyFIQ0
init=/init initrd=0x62000000,0x00800000 mtdparts=rk29xxnand:
[email protected](misc),
[email protected](kernel),
[email protected](boot),
[email protected](recovery),
[email protected](backup),
[email protected](cache),
[email protected](userdata),
[email protected](kpanic),
[email protected](system),
[email protected](user)
-------------------------------------------------------------------------------------------------
I guess the boot partition is something linke that:
+-------+ <--- 0x00019fe0
| boot |
+-------+ <----0x00012000
With this command i'm able to dump the entrie boot partition on my linux box in a file named b00t.img :
rkflashtool r 0x12000 0x8000 > b00t.img
Now, i have find out that with the tool rkunpack (or simply with dd) i'm able to unpack this b00t.img. The output are two file:
b00t.img-raw
b00t.img-symbol
The first file is no more than a gzip compressed data file, I'm able to extract the data in a directory with this command:
gunzip < ../b00t.img-raw | sudo cpio -i --make-directories
Now in this dir I have all the files of the / partition. I can modify for example the /init.rc.
I want to repack the entrie b00t.img in order to flash it again on the device.
NB:
In this thread this guys work at something like my problem...
http://www.freaktab.com/showthread....-Tricks-by-Finless&p=4055&viewfull=1#post4055
The difference is that they work on a different partition layout, and the rkunpack of dumped boot.img return they only boot.img-raw.
Obviously I've already tried to repack the modified directory in this two ways:
mkcramfs myboot myboot-temp.img
kcrc myboot-temp.img customboot.img
or
find . ! -name "."| sort | cpio -oa -H newc | gzip -n > ../newboot.gz
kcrc newboot.gz customboot.img
Neither of these leads to obtain a file large enough to fit the boot partition on the deivice, that I want fill with:
rkflashtool w 0x12000 0x8000 < modifiedb00t.img
Has anyone ever worked with rk3188? Any idea?
Thanks in advance.
Anyone?
I have substratum working on 2 other modded moto devices but can't get it to work on this XT1952-4. I am running Descendant-4.0.1_a64_ab Pie. The substratum version is one thousand twenty two. My device is successfuly rooted using @Spaceminer modded phh root. I have Magisk on the other 2 devices. If anyone has any ideas on this I would appreciate it. Thanks
Motomizer said:
I have substratum working on 2 other modded moto devices but can't get it to work on this XT1952-4. I am running Descendant-4.0.1_a64_ab Pie. The substratum version is one thousand twenty two. My device is successfuly rooted using @Spaceminer modded phh root. I have Magisk on the other 2 devices. If anyone has any ideas on this I would appreciate it. Thanks
Click to expand...
Click to collapse
I think that I have a solution if you can run a command from termux or adb for me.
Code:
ls /system/bin | grep .sh
Give me the output of that. I'll probably need you to send me a file afterwards, but I need to get the name of it first. I'll recognize it when I see it. If you get a special character error, drop the dot off of sh.
Wow, I wasn't expecting the legend himself replying. I don't have termux so I will get on the computer and do adb
It says cannot access '/system/bin'
I installed termux and got the following result:
crash_dump32
lshal
phh-on-boot.sh
rw-system.sh
twrp.sh
Motomizer said:
I installed termux and got the following result:
crash_dump32
lshal
phh-on-boot.sh
rw-system.sh
twrp.sh
Click to expand...
Click to collapse
Rename phh-on-boot.sh to phh-on-boot.txt and send it to me. Use the paperclip to attach it. Use a root explorer to copy it to your sdcard first. Or from termux...
Code:
su
cp /system/bin/phh-on-boot.sh /sdcard/phh-on-boot.sh
You can also concatenate it and pipe the output to a text file like this...
Code:
su
cat /system/bin/phh-on-boot.sh > /sdcard/phh-on-boot.txt
Spaceminer said:
Rename phh-on-boot.sh to phh-on-boot.txt and send it to me. Use the paperclip to attach it. Use a root explorer to copy it to your sdcard first. Or from termux...
Code:
su
cp /system/bin/phh-on-boot.sh /sdcard/phh-on-boot.sh
You can also concatenate it and pipe the output to a text file like this...
Code:
su
cat /system/bin/phh-on-boot.sh > /sdcard/phh-on-boot.txt
Click to expand...
Click to collapse
Ok, I copied and renamed the file easily with a file manager. I can't find a paperclip symbol anywhere to attach it. Is there a post quota to allow attachments?
Motomizer said:
Ok, I copied and renamed the file easily with a file manager. I can't find a paperclip symbol anywhere to attach it. Is there a post quota to allow attachments?
Click to expand...
Click to collapse
I believe there is a quota. 10 if I'm not mistaken. Just use the code button "#" and paste the text of it in a reply.
Spaceminer said:
I believe there is a quota. 10 if I'm not mistaken. Just use the code button "#" and paste the text of it in a reply.
Click to expand...
Click to collapse
[#!/system/bin/sh
[ "$(getprop vold.decrypt)" = "trigger_restart_min_framework" ] && exit 0
if [ -f /vendor/bin/mtkmal ];then
if [ "$(getprop persist.mtk_ims_support)" = 1 ] || [ "$(getprop persist.mtk_epdg_support)" = 1 ];then
setprop persist.mtk_ims_support 0
setprop persist.mtk_epdg_support 0
reboot
fi
fi
#Clear looping services
sleep 30
getprop | \
grep restarting | \
sed -nE -e 's/\[([^]]*).*/\1/g' -e 's/init.svc.(.*)/\1/p' |
while read -r svc ;do
setprop ctl.stop "$svc"
done
if grep -qF android.hardware.boot /vendor/manifest.xml || grep -qF android.hardware.boot /vendor/etc/vintf/manifest.xml ;then
bootctl mark-boot-successful
fi
]
Motomizer said:
[#!/system/bin/sh
[ "$(getprop vold.decrypt)" = "trigger_restart_min_framework" ] && exit 0
if [ -f /vendor/bin/mtkmal ];then
if [ "$(getprop persist.mtk_ims_support)" = 1 ] || [ "$(getprop persist.mtk_epdg_support)" = 1 ];then
setprop persist.mtk_ims_support 0
setprop persist.mtk_epdg_support 0
reboot
fi
fi
#Clear looping services
sleep 30
getprop | \
grep restarting | \
sed -nE -e 's/\[([^]]*).*/\1/g' -e 's/init.svc.(.*)/\1/p' |
while read -r svc ;do
setprop ctl.stop "$svc"
done
if grep -qF android.hardware.boot /vendor/manifest.xml || grep -qF android.hardware.boot /vendor/etc/vintf/manifest.xml ;then
bootctl mark-boot-successful
fi
]
Click to expand...
Click to collapse
Try this and see if it works. Place the file on your internal storage, then open up termux and run the following commands.
Code:
mount -o remount,rw /
mv /sdcard/phh-on-boot.txt /sdcard/phh-on-boot.sh
cp -f /sdcard/phh-on-boot.sh /system/bin
chmod 0755 /system/bin/phh-on-boot.sh
reboot
After rebooting, see if substratum will work.
For future reference, the code brackets work like so on XDA...
Code:
The text goes here...[/CODE ← Close this with another bracket. "]"
[CODE]The text goes here...
The bracket was closed, so now it looks different.
This helps formatting when working with scripts.
Spaceminer said:
Try this and see if it works. Place the file on your internal storage, then open up termux and run the following commands.
Code:
mount -o remount,rw /
mv /sdcard/phh-on-boot.txt /sdcard/phh-on-boot.sh
cp -f /sdcard/phh-on-boot.sh /system/bin
chmod 0755 /system/bin/phh-on-boot.sh
reboot
After rebooting, see if substratum will work.
For future reference, the code brackets work like so on XDA...
Code:
The text goes here...[/CODE ← Close this with another bracket. "]"
[CODE]The text goes here...
The bracket was closed, so now it looks different.
This helps formatting when working with scripts.
Click to expand...
Click to collapse
I knew that file I sent you didn't look right, but didn't know how to fix it. Thanks for the code bracket lesson and your patience. Unfortunately the code you had me run in termux didn't get substratum working. So you know, when I first ran into problems on this g7 play I copied the substratum apk over to my z play to see if the package was corrupt but it works fine there. Same with the themes.
Motomizer said:
I knew that file I sent you didn't look right, but didn't know how to fix it. Thanks for the code bracket lesson and your patience. Unfortunately the code you had me run in termux didn't get substratum working. So you know, when I first ran into problems on this g7 play I copied the substratum apk over to my z play to see if the package was corrupt but it works fine there. Same with the themes.
Click to expand...
Click to collapse
Can you check the build number on substratum? Find it in your app list and check near the bottom of it's info. Should look something like the attached screenshot. I'll see what I can dig up about it.
Spaceminer said:
Can you check the build number on substratum? Find it in your app list and check near the bottom of it's info. Should look something like the attached screenshot. I'll see what I can dig up about it.
Click to expand...
Click to collapse
I was trying to send a screenshot of the app info but I guess I can't do that yet, either. Next to the i in a circle at the bottom it reads:
version one thousand twenty two
They spell it out instead of using numerical digits. I have seen it like that even on older versions.
There is more information at ApkMirror. It's even compatible with Android 10. I didn't know that.
@Spaceminer
Could it be that Descendant-4.0.1_a64_ab Pie doesn't have OMS support? I did a full xda search on that and got no results. When I have time I will install another gsi rom and see what happens.
Motomizer said:
@Spaceminer
Could it be that Descendant-4.0.1_a64_ab Pie doesn't have OMS support? I did a full xda search on that and got no results. When I have time I will install another gsi rom and see what happens.
Click to expand...
Click to collapse
It's been quite awhile since I've tested descendant. That could be the case but I doubt it. OMS should be baked into the source code. I have been wrong before though. I'll see what I can find about that.
Spaceminer said:
It's been quite awhile since I've tested descendant. That could be the case but I doubt it. OMS should be baked into the source code. I have been wrong before though. I'll see what I can find about that.
Click to expand...
Click to collapse
I was just at the descendant telegram group and asked about OMS support. Dil3mma4 himself answered and said that they never really cared about substratum, nor do they now.
Motomizer said:
I was just at the descendant telegram group and asked about OMS support. Dil3mma4 himself answered and said that they never really cared about substratum, nor do they now.
Click to expand...
Click to collapse
I think this is the answer. It looks like it's unsupported.
The battery of a rooted, UsUed LG G4 running LineageOS 14.1 was accidentally allowed to drain to zero. After re-charging above 50%, the device failed to boot. The LOS boot screen "bubble on a string" animation would continue indefinitely.
The phone still booted to TWRP, download mode, and fastboot mode.
Originally, it was suspected that this was ILAPO. However, this suspicion was incorrect.
After extensive work creating a boot sector that would allow logging and a ton of help from @steadfasterX, it was discovered that various files in /data/system had been corrupted and had sizes of zero. Android would try to read values from these files, fail, and repeat.
First, a full TWRP backup of the phone was made and copied off-device. Then, I made a second backup of /data/system. Next, I deleted the following zero-byte files from /data/system using TWRP (or ADB after launching TWRP).
packages.list
packages.xml
profiles.xml
netpolicy.xml
notification_policy.xml
If this doesn't work, I would have considered deleting other zero-byte files in /data/system. I used "ls -laS" to get a size-ordered list of files in my current directory.
After a reboot, android re-created the files and booted to the lockscreen.
All of the apps in /data/data had already been cleared. Otherwise, Android would probably have choked on the differences between the user IDs that it wanted to assign to apps and the ownership of the various app folders.
The following links suggest ways to restore some apps from previously created backups
GitHub - joshuabragge/twrp-manual-restore: Automate individual app restores from an android TWRP backup
Automate individual app restores from an android TWRP backup - GitHub - joshuabragge/twrp-manual-restore: Automate individual app restores from an android TWRP backup
github.com
https://www.semipol.de/posts/2016/07/android-manually-restoring-apps-from-a-twrp-backup/
(Permanent archive: https://web.archive.org/web/2019083.../android-restoring-apps-from-twrp-backup.html)
There is no warranty on this solution. It was a makeshift effort created by an amateur. If you choose to duplicate it, you do so at your own risk. You may permanently destroy your phone.
Old post below:
I'm trying to understand whether a particular G4 (H815) has ILAPO. Its been sneezing, has a sore throat, and now can't taste anything^H^H oops, I mean:
- Previously, the phone would get hot during use.
- The phone has been UsUed.
- The battery was accidentally allowed to discharge to zero.
- After the battery was recharged, the phone was unable to boot past the Lineageos "bubble on a string" animation. The animation simply continues forever.
- The phone can boot to TWRP, fasboot, download mode, etc.
Attempts to fix:
- Tried renaming /sdcard/Android to /sdcard/Android.old but this had no effect.
- Tried clearing cache and dalvik cache but this had no effect
- (NEW) Tried attaching to computer and launching "adb logcat" during animation. Device is never found. If I remember correctly, "USB debugging" was off when the device died. (ADB does work in TWRP.)
- (NEW) Tried creating a custom 4-core (2 core for boot) boot image using the instructions here https://forum.xda-developers.com/t/...tom-x-cores-boot-image-ilapo-tempfix.3718389/ and used "fastboot flash boot boot.img" to flash it. This doesn't seem to work.
-- If I reboot into TWRP after a long period of waiting for the lineageos splash screen, I get a CPU temperature of 46 C. I don't know what temperature was generated in the same situation the modified boot image was installed.
Most of the info on ILAPO suggests that phones with it can't get past the LG logo. That is not the case here. Is this ILAPO or something different? Does anyone have ideas as to what might be an appropriate fix?
Is it possible to retrieve boot logs using TWRP in order to figure out when/where/why the boot hangs?
electricfield said:
I'm trying to understand whether a particular G4 (H815) has ILAPO. Its been sneezing, has a sore throat, and now can't taste anything^H^H oops, I mean:
- Previously, the phone would get hot during use.
- The phone has been UsUed.
- The battery was accidentally allowed to discharge to zero.
- After the battery was recharged, the phone was unable to boot past the Lineageos "bubble on a string" animation. The animation simply continues forever.
- The phone can boot to TWRP, fasboot, download mode, etc.
Attempts to fix:
- Tried renaming /sdcard/Android to /sdcard/Android.old but this had no effect.
- Tried clearing cache and dalvik cache but this had no effect
- (NEW) Tried attaching to computer and launching "adb logcat" during animation. Device is never found. If I remember correctly, "USB debugging" was off when the device died. (ADB does work in TWRP.)
- (NEW) Tried creating a custom 4-core (2 core for boot) boot image using the instructions here https://forum.xda-developers.com/t/...tom-x-cores-boot-image-ilapo-tempfix.3718389/ and used "fastboot flash boot boot.img" to flash it. This doesn't seem to work.
-- If I reboot into TWRP after a long period of waiting for the lineageos splash screen, I get a CPU temperature of 46 C. I don't know what temperature was generated in the same situation the modified boot image was installed.
Most of the info on ILAPO suggests that phones with it can't get past the LG logo. That is not the case here. Is this ILAPO or something different? Does anyone have ideas as to what might be an appropriate fix?
Is it possible to retrieve boot logs using TWRP in order to figure out when/where/why the boot hangs?
Click to expand...
Click to collapse
Sounds like the ilapo. Is the battery charged now? I don't know which LOS version you have installed but if you use mine:
follow FAQ #7 of my LOS thread
steadfasterX said:
Sounds like the ilapo. Is the battery charged now? I don't know which LOS version you have installed but if you use mine:
follow FAQ #7 of my LOS thread
Click to expand...
Click to collapse
Thank you for your reply. You seem to know more about G4 issues than anyone. I really appreciate your help.
The battery is charged now.
Unfortunately, I am using the microg version of LOS 14.1, rather than your 16.0.
I tried following the instructions in your FAQ #7, but I can't do step 1 (boot android). The only way for me to exit the bootloop is by removing the battery. There is no "debug" in /cache after I mount cache in TWRP.
I also looked at FAQ #1. ADB never finishes waiting for the device. In fact "lsusb" doesn't show the phone during OS boot (ADB is fine when TWRP is loaded).
Any other ideas?
electricfield said:
Thank you for your reply. You seem to know more about G4 issues than anyone. I really appreciate your help.
The battery is charged now.
Unfortunately, I am using the microg version of LOS 14.1, rather than your 16.0.
I tried following the instructions in your FAQ #7, but I can't do step 1 (boot android). The only way for me to exit the bootloop is by removing the battery. There is no "debug" in /cache after I mount cache in TWRP.
I also looked at FAQ #1. ADB never finishes waiting for the device. In fact "lsusb" doesn't show the phone during OS boot (ADB is fine when TWRP is loaded).
Any other ideas?
Click to expand...
Click to collapse
As written in my mentioned FAQ taken battery out is needed in your case. Step 2 iirc.
If you dont use my LOS then no way. The cache/debug is something I've added and no one else has.
Option1:
You can just flash my LOS 16 or /e/ ROM (take a full backup before in TWRP) and use that for debugging your current issue. Why using microg btw? /e/ is great
Option2:
The other option would be pulling the boot img of your current LOS (in TWRP: adb pull /dev/block/bootdevice/by-name/boot ) and rebuilding it as insecure (i.e. usb debug on and adb root ) but if you never did that before it it will be hard i guess. AiK might work here or using mAid which includes bootimgtool.
Option3:
Also you can attach that boot img here and if i ever find the time i can do option2 for you but don't expext that this happens soon .
Thank you again for your help.
I'm a little afraid that installing a new & different ROM will increase the level of complexity. I'll do it if I must, though.
I started looking at option #2. Retrieving the boot image was fine, but unpacking presents a problem.
$ ./unpack-bootimg.sh boot.img.original
Found a secondary file after the ramdisk image. According to the spec (mkbootimg.h) this file can exist, but this script is not designed to deal with this scenario.
Is there a guide anywhere?
electricfield said:
Thank you again for your help.
I'm a little afraid that installing a new & different ROM will increase the level of complexity. I'll do it if I must, though.
I started looking at option #2. Retrieving the boot image was fine, but unpacking presents a problem.
$ ./unpack-bootimg.sh boot.img.original
Found a secondary file after the ramdisk image. According to the spec (mkbootimg.h) this file can exist, but this script is not designed to deal with this scenario.
Is there a guide anywhere?
Click to expand...
Click to collapse
thousands.. But the problem is that our device is sensitive when it comes to packaging the boot.img again. Bootimgtool is working in 9 of 10 times though.
Boot mAid . Open a terminal. Type bootimgtool --help .important is to use "-v qcom". Then extract the ramdisk with gzip and cpio, then modding the default.prop to make it insecure , then using gzip and cpio again to rebuild the ramdisk, finally using bootimgtool to construct the boot.img again. Sounds harder than it is but i have no access to my pc until monday so i cannot give all the needed cmds atm. There are plenty of guides out there and tools ofc which allow unpack,repack etc. That's why i mentioned AIK which does exactly the above but it fails sometimes to build a correct working boot.img.
So my suggestion is try your luck with one of the tools or wait until I've access to my pc. Consider joining my TG group then for easier support (see my sig)
steadfasterX said:
thousands.. But the problem is that our device is sensitive when it comes to packaging the boot.img again. Bootimgtool is working in 9 of 10 times though.
Boot mAid . Open a terminal. Type bootimgtool --help .important is to use "-v qcom". Then extract the ramdisk with gzip and cpio, then modding the default.prop to make it insecure , then using gzip and cpio again to rebuild the ramdisk, finally using bootimgtool to construct the boot.img again. Sounds harder than it is but i have no access to my pc until monday so i cannot give all the needed cmds atm. There are plenty of guides out there and tools ofc which allow unpack,repack etc. That's why i mentioned AIK which does exactly the above but it fails sometimes to build a correct working boot.img.
So my suggestion is try your luck with one of the tools or wait until I've access to my pc. Consider joining my TG group then for easier support (see my sig)
Click to expand...
Click to collapse
Thank you once again. I'm really impressed by how much help you have been able to give so far.
Unfortunately, I have no phone with which to join the Telegram group.
I made the modified boot image, but adb is still unable to speak to the phone during boot. I note that lsusb does not show the phone during boot -- maybe the system hangs before USB is activated. However, I could have made the boot image incorrectly.
Here is what I did:
[[email protected] extract]$ bootimgtool -i boot
Image size: 41943040
Page size: 4096
Kernel size: 22456976
Ramdisk size: 1672742
Second stage size: 0
Device tree size: 0
Kernel load address: 0x00008000
Ramdisk load address: 0x01000000
Second stage load address: 0x00f00000
Device tree load address: 0x00000000
Tags load address: 0x00000100
Product name:
Command line: maxcpus=4 boot_cpus=0-1 console=ttyHSL0,115200,n8 androidboot.console=ttyHSL0 androidboot.hardware=qcom user_debug=31 ehci-hcd.park=3 lpm_levels.sleep_disabled=1 msm_rtb.filter=0x37 boot_cpus=0-1 buildvariant=userdebug
[[email protected] extract]$ bootimgtool -x boot -v qcom
[[email protected] extract]$ gunzip ramdisk
[[email protected] ex]$ cpio -i < ../ramdisk
In default.prop, I changed:
ro.adb.secure=0
ro.secure=0
security.perf_harden=0
ro.debuggable=0
persist.sys.usb.config=mtp,adb
In default.prop, I added:
persist.service.adb.enable=1
persist.service.debuggable=1
[[email protected] ex]$ find > /tmp/filelist
[[email protected] ex]$ cpio -o < /tmp/filelist > ../ramdisk.modified
This produces
-rw-r--r-- 1 android users 4166400 Jan 2 17:29 ramdisk.gunzip.original
-rw-r--r-- 1 android users 4162048 Jan 2 17:31 ramdisk.modified
-rw-r--r-- 1 android users 1672742 Jan 2 17:16 ramdisk.img.original
I don't understand why the "modified" gunzipped file is slightly smaller than the original.
[[email protected] extract]$ mv ramdisk.modified.gz ramdisk.img
[[email protected] extract]$ cp boot boot.original
[[email protected] extract]$ bootimgtool -v qcom -c boot
Overwrite 'boot'? [y/N] y
-rw-r--r-- 1 android users 25370624 Jan 2 17:38 boot
-rw-r--r-- 1 android users 41943040 Jan 2 17:37 boot.original
I am wary because I don't understand why the new file is so much smaller than the original. However, I decided to proceed. Uploaded modified boot to /sdcard/boot.modified
Inside adb:
/dev/block/platform/soc.0/f9824900.sdhci/by-name # ls -al boot
lrwxrwxrwx 1 root root 21 Jan 1 04:16 boot -> /dev/block/mmcblk0p38
/dev/block/platform/soc.0/f9824900.sdhci/by-name # cp /sdcard/boot.modified /dev/block/mmcblk0p38
Plugged in device. On computer "adb wait-for-device". Reboot device.
Unfortunately, no action from adb.
electricfield said:
Thank you once again. I'm really impressed by how much help you have been able to give so far.
Unfortunately, I have no phone with which to join the Telegram group.
I made the modified boot image, but adb is still unable to speak to the phone during boot. I note that lsusb does not show the phone during boot -- maybe the system hangs before USB is activated. However, I could have made the boot image incorrectly.
Here is what I did:
[[email protected] extract]$ bootimgtool -i boot
Image size: 41943040
Page size: 4096
Kernel size: 22456976
Ramdisk size: 1672742
Second stage size: 0
Device tree size: 0
Kernel load address: 0x00008000
Ramdisk load address: 0x01000000
Second stage load address: 0x00f00000
Device tree load address: 0x00000000
Tags load address: 0x00000100
Product name:
Command line: maxcpus=4 boot_cpus=0-1 console=ttyHSL0,115200,n8 androidboot.console=ttyHSL0 androidboot.hardware=qcom user_debug=31 ehci-hcd.park=3 lpm_levels.sleep_disabled=1 msm_rtb.filter=0x37 boot_cpus=0-1 buildvariant=userdebug
[[email protected] extract]$ bootimgtool -x boot -v qcom
[[email protected] extract]$ gunzip ramdisk
[[email protected] ex]$ cpio -i < ../ramdisk
In default.prop, I changed:
ro.adb.secure=0
ro.secure=0
security.perf_harden=0
ro.debuggable=0
persist.sys.usb.config=mtp,adb
In default.prop, I added:
persist.service.adb.enable=1
persist.service.debuggable=1
[[email protected] ex]$ find > /tmp/filelist
[[email protected] ex]$ cpio -o < /tmp/filelist > ../ramdisk.modified
This produces
-rw-r--r-- 1 android users 4166400 Jan 2 17:29 ramdisk.gunzip.original
-rw-r--r-- 1 android users 4162048 Jan 2 17:31 ramdisk.modified
-rw-r--r-- 1 android users 1672742 Jan 2 17:16 ramdisk.img.original
I don't understand why the "modified" gunzipped file is slightly smaller than the original.
[[email protected] extract]$ mv ramdisk.modified.gz ramdisk.img
[[email protected] extract]$ cp boot boot.original
[[email protected] extract]$ bootimgtool -v qcom -c boot
Overwrite 'boot'? [y/N] y
-rw-r--r-- 1 android users 25370624 Jan 2 17:38 boot
-rw-r--r-- 1 android users 41943040 Jan 2 17:37 boot.original
I am wary because I don't understand why the new file is so much smaller than the original. However, I decided to proceed. Uploaded modified boot to /sdcard/boot.modified
Inside adb:
/dev/block/platform/soc.0/f9824900.sdhci/by-name # ls -al boot
lrwxrwxrwx 1 root root 21 Jan 1 04:16 boot -> /dev/block/mmcblk0p38
/dev/block/platform/soc.0/f9824900.sdhci/by-name # cp /sdcard/boot.modified /dev/block/mmcblk0p38
Plugged in device. On computer "adb wait-for-device". Reboot device.
Unfortunately, no action from adb.
Click to expand...
Click to collapse
Ok i haven't followed every step bc I'm in half sleep mode already but you did one step wrong : you cant use cp like you did to copy the boot img. Either use the IMG button within TWRP flash menu or use fastboot flash boot boot.img to actually flash the modded boot img
Thank you, once again.
I think that something must be wrong with the boot image.
After "fastboot flash boot boot.modified", I get a blue light. The screen is blank with a cursor in the upper-left hand corner.
"fastboot flash boot boot.original" restores it to its previous state. i.e., it gets to the first lineageos splash screen bubble.
I'm suspicious of the difference between the file sizes of the original and modified boot images.
electricfield said:
Thank you, once again.
I think that something must be wrong with the boot image.
After "fastboot flash boot boot.modified", I get a blue light. The screen is blank with a cursor in the upper-left hand corner.
"fastboot flash boot boot.original" restores it to its previous state. i.e., it gets to the first lineageos splash screen bubble.
I'm suspicious of the difference between the file sizes of the original and modified boot images.
Click to expand...
Click to collapse
Ignore the size diff. That's bc of diff compressing tools but does not matter. Your cpio cmd is unusual . Cpio has switches to create directories and that is not used in yours above . Thats likely the reason why it does not boot at all. Again sorry that i can't help better atm but without my pc..
Thanks.
I changed the ramdisk extraction command to:
gzip -dc ../ramdisk.img | cpio -imd
and the creation command to:
find . ! -name . | LC_ALL=C sort | cpio -o -H newc -R root:root | gzip > ../new-boot.img-ramdisk.gz
Bootimgtool then produced a boot image that booted. After fastboot flash, the device is in the same state as before (splash screen).
Unfortunately, "adb wait-for-device" produces nothing. "lsusb" does not show the phone.
Can you confirm the lines to change in default.prop?
In default.prop, I changed:
ro.adb.secure=0
ro.secure=0
security.perf_harden=0
ro.debuggable=0
persist.sys.usb.config=mtp,adb
I added:
persist.service.adb.enable=1
persist.service.debuggable=1
electricfield said:
Thanks.
I changed the ramdisk extraction command to:
gzip -dc ../ramdisk.img | cpio -imd
and the creation command to:
find . ! -name . | LC_ALL=C sort | cpio -o -H newc -R root:root | gzip > ../new-boot.img-ramdisk.gz
Bootimgtool then produced a boot image that booted. After fastboot flash, the device is in the same state as before (splash screen).
Unfortunately, "adb wait-for-device" produces nothing. "lsusb" does not show the phone.
Can you confirm the lines to change in default.prop?
In default.prop, I changed:
ro.adb.secure=0
ro.secure=0
security.perf_harden=0
ro.debuggable=0
persist.sys.usb.config=mtp,adb
I added:
persist.service.adb.enable=1
persist.service.debuggable=1
Click to expand...
Click to collapse
ro.debuggable=1 is better (allows adb root)
security.perf_harden shouldn't be added (or.changed if it was there)
Rest looks ok. At least as long as you really changed these values directly or added them at the top (ro. values can be set only once)
Otherwise you should wait until tomorrow then i can share a 100% working way
electricfield said:
Thanks.
I changed the ramdisk extraction command to:
gzip -dc ../ramdisk.img | cpio -imd
and the creation command to:
find . ! -name . | LC_ALL=C sort | cpio -o -H newc -R root:root | gzip > ../new-boot.img-ramdisk.gz
Bootimgtool then produced a boot image that booted. After fastboot flash, the device is in the same state as before (splash screen).
Unfortunately, "adb wait-for-device" produces nothing. "lsusb" does not show the phone.
Can you confirm the lines to change in default.prop?
In default.prop, I changed:
ro.adb.secure=0
ro.secure=0
security.perf_harden=0
ro.debuggable=0
persist.sys.usb.config=mtp,adb
I added:
persist.service.adb.enable=1
persist.service.debuggable=1
Click to expand...
Click to collapse
Oh wait! Pls share the bootimgtool command you are using to create the new boot.img
Thank you, again.
The bootimgtool command is the same one as I used before (no change). Before running it, I renamed the new ramdisk to ramdisk.img.
bootimgtool -v qcom -c boot.modified3
Followed by bringing the phone into fastboot mode and running
fastboot flash boot boot.modified3
The phone boots to the lineageos splash screen but no response to "adb wait-for-device".
I'll try ro.debuggable=1 and get rid of security.perf_harden in a few minutes, but I wonder if they are unlikely to change anything given that the device does not show up in (linux) lsusb.
electricfield said:
Thank you, again.
The bootimgtool command is the same one as I used before (no change). Before running it, I renamed the new ramdisk to ramdisk.img.
bootimgtool -v qcom -c boot.modified3
Followed by bringing the phone into fastboot mode and running
fastboot flash boot boot.modified3
The phone boots to the lineageos splash screen but no response to "adb wait-for-device".
I'll try ro.debuggable=1 and get rid of security.perf_harden in a few minutes, but I wonder if they are unlikely to change anything given that the device does not show up in (linux) lsusb.
Click to expand...
Click to collapse
That wont change anything if adb does not come up. Just for completeness.
Ok so if you renamed it to ramdisk.img then all.good that was the thing i had in mind (that you didn't and not.used the -r switch). Well ok then without my pc the only thing i can think of might be the USB cable but thats very unlikely
Thanks again for your help.
The boot image that was flashed is definitely the correct one. I extracted it to another folder and checked it before flashing.
I re-made the boot image, but the result is the same (no adb, no device in lsusb).
What "-r switch" are you referring to in your previous message?
The USB cable works fine for ADB in TWRP, so I doubt it is the problem.
electricfield said:
Thanks again for your help.
The boot image that was flashed is definitely the correct one. I extracted it to another folder and checked it before flashing.
I re-made the boot image, but the result is the same (no adb, no device in lsusb).
What "-r switch" are you referring to in your previous message?
The USB cable works fine for ADB in TWRP, so I doubt it is the problem.
Click to expand...
Click to collapse
The -r (iirc) switch was related to bootimgtool. That way you can choose your newly created ramdisk.img but when you renamed it to ramdisk.img it works without.
Thanks.
I would deeply appreciate if you were able to guide me in making the boot image correctly when you have your computer on Monday.
On the other hand, if this method won't work, its best if I know that so that I can try the next thing....
electricfield said:
Thanks.
I would deeply appreciate if you were able to guide me in making the boot image correctly when you have your computer on Monday.
On the other hand, if this method won't work, its best if I know that so that I can try the next thing....
Click to expand...
Click to collapse
ok here you go, this must be added /changed in default.prop:
Code:
ro.adb.secure=0
ro.secure=0
ro.debuggable=1
persist.service.adb.enable=1
persist.service.debuggable=1
persist.sys.usb.config=adb
thumbs pressed
Thank you.
I rebuilt the boot image with these entries, but "adb wait-for-device" still does not work during boot.
Any other ideas?
Hey folks! I unlocked my FireTV stick and was able to install TWRP following the amazing guide by @k4y0z (https://forum.xda-developers.com/t/unlock-root-twrp-unbrick-fire-tv-stick-2nd-gen-tank.3907002/).
I can boot into TWRP just OK.
I am using adb shell to issue TWRP commands. (I don't have an OTG cable with power input).
I began by flashing stock ROMs by @0815hoffi from here (https://forum.xda-developers.com/t/...-7-ota-zip-launcher-replacement-root.4155489/).
Then I tried installing pre-rooted images by @rbox (https://forum.xda-developers.com/t/fire-tv-stick-2-tank-prerooted-stock-images-5-2-7-3_r1.3912271/) along with magisk.
Here are the general steps I followed while flashing these images :
1. wiping everything. I suspect my first issue here :
Code:
$ adb shell
$ twrp wipe cache
$ twrp wipe data
$ twrp wipe dalvik
$ twrp wipe /system
~ # twrp wipe cache
Formatting Cache using make_ext4fs...
Failed to mount '/cache' (No such device)
Done processing script file
Click to expand...
Click to collapse
~ # twrp wipe /system
Formatting System using make_ext4fs...
Failed to mount '/system' (No such device)
Done processing script file
Click to expand...
Click to collapse
~ # mount /cache
mount: mounting /dev/block/mmcblk0p12 on /cache failed: No such device
Click to expand...
Click to collapse
~ # stat /dev/block/mmcblk0p12
File: '/dev/block/mmcblk0p12'
Size: 0 Blocks: 0 IO Block: 4096 block special file
Device: ch/12d Inode: 5332 Links: 1 Device type: b3,c
Access: (0600/brw-------) Uid: ( 0/ root) Gid: ( 0/ root)
__bionic_open_tzdata: couldn't find any tzdata when looking for localtime!
__bionic_open_tzdata: couldn't find any tzdata when looking for GMT!
__bionic_open_tzdata: couldn't find any tzdata when looking for posixrules!
Access: 2010-01-01 00:17:58.000000000
Modify: 2010-01-01 00:17:57.000000000
Change: 2010-01-01 00:17:57.000000000
Click to expand...
Click to collapse
2. push images to /sdcard
Code:
$ adb push update-kindle-full_tank-288.6.6.4_user_664657620.bin /sdcard/firm.zip
update-kindle-full_tank-288.6.6.4_user... 6.1 MB/s (532252995 bytes in 83.009s)
3. Install image
adb shell
~ # twrp install /sdcard/firm.zip
Installing zip file '/sdcard/firm.zip'
Checking for Digest file...
Skipping Digest check: no Digest file found
[amonet] Remove boot patch...
[amonet] OK
Patching system image unconditionally...
Copying preloader_prod.img to boot partition 0 for secure device...
script succeeded: result was [][amonet] Install boot patch...
[amonet] OK
[amonet] Install recovery patch...
[amonet] ALREADY_INSTALLED
Done processing script file
Click to expand...
Click to collapse
4. `adb shell reboot`
They all install just OK. But in all cases, every time I do `reboot` in `adb shell` after `adb install` commands, it boots and gets stuck on 'fireTV Stick' logo.
At first I thought maybe it takes time to boot for first time, but I let it go for as long as half an hour and still no good.
I tried wiping cache and dalvik before rebooting too, no avail (had same could not mount /cache prompt).
I am pretty sure I am doing something stupid, I'd really appreciate any help. I'll be happy if I get it back to a working state, I do not really need root. This all started because the stick went into bootloop outta nowhere. My initial finding pointed at a failed update, see :
https://twitter.com/i/web/status/1393963756426698756
Maybe try with 5.2.7.7
ftvs2k-5.2.7.7
MediaFire is a simple to use free service that lets you put all your photos, documents, music, and video in a single place so you can access them anywhere and share them everywhere.
www.mediafire.com
0815hoffi said:
Maybe try with 5.2.7.7
ftvs2k-5.2.7.7
MediaFire is a simple to use free service that lets you put all your photos, documents, music, and video in a single place so you can access them anywhere and share them everywhere.
www.mediafire.com
Click to expand...
Click to collapse
Thanks @0815hoffi , that's actually the very first image I tried with from your thread.
Looking back, I think there's something wrong with my partitions.
If I see logs of other people from these threads, it says
script succeeded: result was [ALL DONE][amonet] Install boot patch...
Click to expand...
Click to collapse
Whereas for me, it says
script succeeded: result was [][amonet] Install boot patch...
Click to expand...
Click to collapse
This may mean that my flash is not successful, right? It's same everytime I flash.
I wonder, is there a way to bring everything to a clean state?
Given your expertise in amonet, @k4y0z from the thread and this comment, do you have a suspicion of what could be going wrong?
It looks like like it indeed were messed up partitions. My initial plan was to flash GPT fix in DL mode (by @k4y0z : link). But I thought might as well play with few things if am anyway going to re-do everything.
I started by going deleting directories manually (e.g. `rm -rf /system`). My plan was to manually flash each partition through fastboot.
Before that I attempted
Code:
fastboot format all
and received a bunch of errors, specifically
Code:
Formatting is not supported for file system with type ''.
Though format didn't work, I decided to wipe anyway
Code:
fastboot -w
It finished with few errors, but looked like it created those directories which I deleted earlier. So I rebooted to TWRP and did
Code:
twrp wipe data
Re-flashed @0815hoffi 's image and luckily it booted into "Optimising storage" screen. Post boot-up it appears to be working OK so far. Had an issue with wifi, but restart fixed it.
tl;dr
Code:
rm -rf /cache
rm -rf /data/dalvik
rm -rf /system
fastboot format userdata # errors
fastboot -w # completed but some errors
twrp wipe data
twrp install <img.zip>
reboot
EDIT : Looks like @Sus_i and @racega went through a similar journey and ended up with a similar fix. Good to know the fix is reproducible. Here's their posts : https://forum.xda-developers.com/t/...ck-2nd-gen-tank.3907002/page-61#post-83031003
saurabhshri said:
It looks like like it indeed were messed up partitions. My initial plan was to flash GPT fix in DL mode (by @k4y0z : link). But I thought might as well play with few things if am anyway going to re-do everything.
I started by going deleting directories manually (e.g. `rm -rf /system`). My plan was to manually flash each partition through fastboot.
Before that I attempted
Code:
fastboot format all
and received a bunch of errors, specifically
Code:
Formatting is not supported for file system with type ''.
Though format didn't work, I decided to wipe anyway
Code:
fastboot -w
It finished with few errors, but looked like it created those directories which I deleted earlier. So I rebooted to TWRP and did
Code:
twrp wipe data
Re-flashed @0815hoffi 's image and luckily it booted into "Optimising storage" screen. Post boot-up it appears to be working OK so far. Had an issue with wifi, but restart fixed it.
tl;dr
Code:
rm -rf /cache
rm -rf /data/dalvik
rm -rf /system
fastboot format userdata # errors
fastboot -w # completed but some errors
twrp wipe data
twrp install <img.zip>
reboot
EDIT : Looks like @Sus_i and @racega went through a similar journey and ended up with a similar fix. Good to know the fix is reproducible. Here's their posts : https://forum.xda-developers.com/t/...ck-2nd-gen-tank.3907002/page-61#post-83031003
Click to expand...
Click to collapse
Usually when this corrupted partitions happen you may try the command:
fastboot format userdata
followed by :
adb shell
(to call twrp#)
Then :
twrp wipe data
twrp wipe system
twrp wipe cache
twrp wipe dalvik
Then adb push the rom, gapps/magisk to /sdcard
twrp install nameofyourrom.zip
twrp install gappsxx.zip
Let it boot once and go back and update magisk via recovery.
(adb reboot recovery once permissions set or use powermenu little vic apk for quickness)
Another method I found which works good with fireos is :
When faced with corrupted/encrypted partition issues and/or unable to mount/format data issues
goto advanced wipe
select change file system
change it to EXT2
it will format data and data should appear become mount
hit back and change to EXT4 Filesystem again.
Then push rom and any other zips etc to /sdcard and install in usual way.
Good you got it working
Regards
Thank you for writing this down @Bertonumber1, I am sure it'll be very helpful to people who will encounter such situation in future.
Bertonumber1 said:
select change file system
change it to EXT2
it will format data and data should appear become mount
hit back and change to EXT4 Filesystem again.
Click to expand...
Click to collapse
I sincerely wish I could have done this. But I don't have an OTG with power input and deliveries are closed due to the pandemic. I was issuing TWRP commands through adb. I'll keep this in mind for future!
Thanks!
saurabhshri said:
Thank you for writing this down @Bertonumber1, I am sure it'll be very helpful to people who will encounter such situation in future.
I sincerely wish I could have done this. But I don't have an OTG with power input and deliveries are closed due to the pandemic. I was issuing TWRP commands through adb. I'll keep this in mind for future!
Thanks!
Click to expand...
Click to collapse
Ah I see, I'm sure the twrp can be commanded to repair change file systems. However, you are correct it is much easier via otg mouse or keyboard.
Regards