hello
I am looking for update.pkg for the dell venue. my phone it bricked, and to fix it i need the update.pkg.
thanks
I am having the same problem, please update i\us if you find a problem please
I really hope that XDA community will help us in here.I bought the Dell Venue from HongKong, and this happened straight after I came back to US. The bad part, dell has no idea about what I am talking about. The product does not exist to them, and I can no longer return it back to HongKong, so I ended up with a 500$ piece of brick.
An Advice: Never buy a Dell Product, EVER!
Help will be really appreciated from the smart XDA community.
abdallh7,
Where did you buy it from?
If it is sold in your country, can you call local dell in your country? Dell India, and Dell HongKong should have this file.
nounousomes said:
abdallh7,
Where did you buy it from?
If it is sold in your country, can you call local dell in your country? Dell India, and Dell HongKong should have this file.
Click to expand...
Click to collapse
I am in the UAE but i bought the phone from Hongkong ?
please any way to get the files?
dell is not a bed company, and the phone is not bricked. It is only a file the bring the phone back to life.
thanks
I don't think Dell has rolled out any updates for the Venue other than what ships on it, so finding an update.pkg is going to be difficult. I have a Venue, so if you tell me what file you hosed, I can at least extract that file(s) for you, and perhaps someone smarter than me can make an update.zip that will replace that file for you.
Root
Has anyone been able to root their Venue? I received mine today and I'm looking for a way to root it. I tried SuperOneClickv1.6.1-ShortFuse that has several versions and none of them has worked. I get the following:
Killing ADB Server...
OK
Starting ADB Server...
* daemon not running. starting it now on port 5037 *
* daemon started successfully *
OK
Waiting for device...
OK
Pushing psneuter...
2363 KB/s (585731 bytes in 0.242s)
OK
chmod psneuter...
OK
Running psneuter...
OK
***IF IT KEEPS LOOPING, TRY DISABLING USB DEBUGGING NOW***
Killing ADB Server...
OK
Starting ADB Server...
* daemon not running. starting it now on port 5037 *
* daemon started successfully *
OK
Waiting for device...
OK
Running psneuter...
FAILED
Any help would be much appreciated.
abdallh7 said:
I am in the UAE but i bought the phone from Hongkong ?
please any way to get the files?
dell is not a bed company, and the phone is not bricked. It is only a file the bring the phone back to life.
thanks
Click to expand...
Click to collapse
abdallh7,
this is the same exact case for me. Could you get a contact with Dell HongKong?
I tried calling them, but they told me that my device is out of warranty based on my service tag: 6VSPHN2 because the shop I bought it from seems to be did not register the purchase with Dell. I have never heard of this before, but seems Dell is really missing stuff up.
My dell venue version is: GTOUB1A130211
What is your dell Venue version and Service tag? Can you call Dell HongKong to get any information for the device? Do you want me to call dell Hong Kong for you?
I hope Dell will be helping us with this.
ebaul said:
Has anyone been able to root their Venue? I received mine today and I'm looking for a way to root it. I tried SuperOneClickv1.6.1-ShortFuse that has several versions and none of them has worked. I get the following:
Killing ADB Server...
OK
Starting ADB Server...
* daemon not running. starting it now on port 5037 *
* daemon started successfully *
OK
Waiting for device...
OK
Pushing psneuter...
2363 KB/s (585731 bytes in 0.242s)
OK
chmod psneuter...
OK
Running psneuter...
OK
***IF IT KEEPS LOOPING, TRY DISABLING USB DEBUGGING NOW***
Killing ADB Server...
OK
Starting ADB Server...
* daemon not running. starting it now on port 5037 *
* daemon started successfully *
OK
Waiting for device...
OK
Running psneuter...
FAILED
Any help would be much appreciated.
Click to expand...
Click to collapse
Please do not root it right now as you can totally destroy it.
calebm said:
I don't think Dell has rolled out any updates for the Venue other than what ships on it, so finding an update.pkg is going to be difficult. I have a Venue, so if you tell me what file you hosed, I can at least extract that file(s) for you, and perhaps someone smarter than me can make an update.zip that will replace that file for you.
Click to expand...
Click to collapse
Thank you for your offer. I hope some one from the smart coder up here could help us to provide us with instructions on how to do it.
I will also try to search for instructions.
Thank you for your help.
calebm said:
I don't think Dell has rolled out any updates for the Venue other than what ships on it, so finding an update.pkg is going to be difficult. I have a Venue, so if you tell me what file you hosed, I can at least extract that file(s) for you, and perhaps someone smarter than me can make an update.zip that will replace that file for you.
Click to expand...
Click to collapse
anyone with a new Venue
please try..
adb pull /system
thanks
for any devs that may be interested...
please post Dell Venue full system dump to be pulled apart and modded and help us restore our Venue
Thanks.
Posted this in the other thread already, but in case it is missed, here is the link to the system dump again...
http://rapidshare.com/files/447206989/venuedump.zip
nounousomes said:
Please do not root it right now as you can totally destroy it.
Click to expand...
Click to collapse
Wrong, rooted it and it's working fine. I am able to install apps that require root access without issues.
ebaul said:
Wrong, rooted it and it's working fine. I am able to install apps that require root access without issues.
Click to expand...
Click to collapse
I totally understand, ebaul, the problem is when you change any of the frameworks can easily render the device useless. The problem is not the rooting, the problem is it can help you screw up the device. If you can help us to find the update.pkg or a way to help us this will be great, as this can represent a point to go back.
Any help is seriously appreciated.
Isn't it located on the SD like the streak? I thought they had the Update.pkg on the SD. I find it foolish to not include a way to recover the system. I contacted Dell Support and complaint about the Venue looping and not been able to access it, requested the location to download the software but all they said is send it back for a replacement. I'm not having issues with mine, I just wanted to see if they give up the location of this file which I'm sure they do have but no luck. Sorry
nounousomes said:
I totally understand, ebaul, the problem is when you change any of the frameworks can easily render the device useless. The problem is not the rooting, the problem is it can help you screw up the device. If you can help us to find the update.pkg or a way to help us this will be great, as this can represent a point to go back.
Any help is seriously appreciated.
Click to expand...
Click to collapse
ebaul said:
Isn't it located on the SD like the streak? I thought they had the Update.pkg on the SD. I find it foolish to not include a way to recover the system. I contacted Dell Support and complaint about the Venue looping and not been able to access it, requested the location to download the software but all they said is send it back for a replacement. I'm not having issues with mine, I just wanted to see if they give up the location of this file which I'm sure they do have but no luck. Sorry
Click to expand...
Click to collapse
Thank you so much for your help, I could not return mine as I purchased it
From HK.
Thank you for sensere trial to help, dell tech support is a shame. They told me that they are seaching for the file themselves!!!!!
Sent from my HTC Vision using XDA App
ebaul said:
Isn't it located on the SD like the streak? I thought they had the Update.pkg on the SD. I find it foolish to not include a way to recover the system. I contacted Dell Support and complaint about the Venue looping and not been able to access it, requested the location to download the software but all they said is send it back for a replacement. I'm not having issues with mine, I just wanted to see if they give up the location of this file which I'm sure they do have but no luck. Sorry
Click to expand...
Click to collapse
ebaul,
I am sorry, but can you help us in getting the partition images:
adb shell
su
cat /proc/partitions
you can saw all the partitions, which will look like this:
137 1 256 bml1
137 2 1280 bml2
137 3 512 bml3
137 4 8192 bml4
137 5 7680 bml5
137 6 225280 bml6
137 7 207360 bml7
137 8 38912 bml8
137 9 7168 bml9
137 10 16384 bml10
138 4 4352 stl4
138 6 217600 stl6
138 7 200192 stl7
138 8 34816 stl8
use dd copy rom to sdcard
dd if=/dev/block/bml1 of=/sdcard/bml1.img
dd if=/dev/block/bml2 of=/sdcard/bml2.img
dd if=/dev/block/bml3 of=/sdcard/bml3.img
dd if=/dev/block/bml4 of=/sdcard/bml4.img
dd if=/dev/block/bml5 of=/sdcard/bml5.img
dd if=/dev/block/bml6 of=/sdcard/bml6.img
dd if=/dev/block/bml7 of=/sdcard/bml7.img
dd if=/dev/block/bml8 of=/sdcard/bml8.img
dd if=/dev/block/bml9 of=/sdcard/bml9.img
dd if=/dev/block/bml10 of=/sdcard/bml10.img
dd if=/dev/block/stl4 of=/sdcard/stl4.img
dd if=/dev/block/stl6 of=/sdcard/stl6.img
dd if=/dev/block/st7 of=/sdcard/stl7.img
dd if=/dev/block/stl8 of=/sdcard/stl8.img
I hope you can zip all of them in one file and upload it for us.
I will try to restore using fastboot
Ok. Working on this now, let's see if it works
nounousomes said:
ebaul,
I am sorry, but can you help us in getting the partition images:
adb shell
su
cat /proc/partitions
you can saw all the partitions, which will look like this:
137 1 256 bml1
137 2 1280 bml2
137 3 512 bml3
137 4 8192 bml4
137 5 7680 bml5
137 6 225280 bml6
137 7 207360 bml7
137 8 38912 bml8
137 9 7168 bml9
137 10 16384 bml10
138 4 4352 stl4
138 6 217600 stl6
138 7 200192 stl7
138 8 34816 stl8
use dd copy rom to sdcard
dd if=/dev/block/bml1 of=/sdcard/bml1.img
dd if=/dev/block/bml2 of=/sdcard/bml2.img
dd if=/dev/block/bml3 of=/sdcard/bml3.img
dd if=/dev/block/bml4 of=/sdcard/bml4.img
dd if=/dev/block/bml5 of=/sdcard/bml5.img
dd if=/dev/block/bml6 of=/sdcard/bml6.img
dd if=/dev/block/bml7 of=/sdcard/bml7.img
dd if=/dev/block/bml8 of=/sdcard/bml8.img
dd if=/dev/block/bml9 of=/sdcard/bml9.img
dd if=/dev/block/bml10 of=/sdcard/bml10.img
dd if=/dev/block/stl4 of=/sdcard/stl4.img
dd if=/dev/block/stl6 of=/sdcard/stl6.img
dd if=/dev/block/st7 of=/sdcard/stl7.img
dd if=/dev/block/stl8 of=/sdcard/stl8.img
I hope you can zip all of them in one file and upload it for us.
I will try to restore using fastboot
Click to expand...
Click to collapse
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Is this what you need??? or do you need a picture of each partition? I'm not good with this android stuff, but if you walk me through it I can do it.
nounousomes said:
ebaul,
I am sorry, but can you help us in getting the partition images:
adb shell
su
cat /proc/partitions
you can saw all the partitions, which will look like this:
137 1 256 bml1
137 2 1280 bml2
137 3 512 bml3
137 4 8192 bml4
137 5 7680 bml5
137 6 225280 bml6
137 7 207360 bml7
137 8 38912 bml8
137 9 7168 bml9
137 10 16384 bml10
138 4 4352 stl4
138 6 217600 stl6
138 7 200192 stl7
138 8 34816 stl8
use dd copy rom to sdcard
dd if=/dev/block/bml1 of=/sdcard/bml1.img
dd if=/dev/block/bml2 of=/sdcard/bml2.img
dd if=/dev/block/bml3 of=/sdcard/bml3.img
dd if=/dev/block/bml4 of=/sdcard/bml4.img
dd if=/dev/block/bml5 of=/sdcard/bml5.img
dd if=/dev/block/bml6 of=/sdcard/bml6.img
dd if=/dev/block/bml7 of=/sdcard/bml7.img
dd if=/dev/block/bml8 of=/sdcard/bml8.img
dd if=/dev/block/bml9 of=/sdcard/bml9.img
dd if=/dev/block/bml10 of=/sdcard/bml10.img
dd if=/dev/block/stl4 of=/sdcard/stl4.img
dd if=/dev/block/stl6 of=/sdcard/stl6.img
dd if=/dev/block/st7 of=/sdcard/stl7.img
dd if=/dev/block/stl8 of=/sdcard/stl8.img
I hope you can zip all of them in one file and upload it for us.
I will try to restore using fastboot
Click to expand...
Click to collapse
I think is broken:
nounousomes said:
ebaul,
I am sorry, but can you help us in getting the partition images:
adb shell
su
cat /proc/partitions
you can saw all the partitions, which will look like this:
137 1 256 bml1
137 2 1280 bml2
137 3 512 bml3
137 4 8192 bml4
137 5 7680 bml5
137 6 225280 bml6
137 7 207360 bml7
137 8 38912 bml8
137 9 7168 bml9
137 10 16384 bml10
138 4 4352 stl4
138 6 217600 stl6
138 7 200192 stl7
138 8 34816 stl8
use dd copy rom to sdcard
dd if=/dev/block/bml1 of=/sdcard/bml1.img
dd if=/dev/block/bml2 of=/sdcard/bml2.img
dd if=/dev/block/bml3 of=/sdcard/bml3.img
dd if=/dev/block/bml4 of=/sdcard/bml4.img
dd if=/dev/block/bml5 of=/sdcard/bml5.img
dd if=/dev/block/bml6 of=/sdcard/bml6.img
dd if=/dev/block/bml7 of=/sdcard/bml7.img
dd if=/dev/block/bml8 of=/sdcard/bml8.img
dd if=/dev/block/bml9 of=/sdcard/bml9.img
dd if=/dev/block/bml10 of=/sdcard/bml10.img
dd if=/dev/block/stl4 of=/sdcard/stl4.img
dd if=/dev/block/stl6 of=/sdcard/stl6.img
dd if=/dev/block/st7 of=/sdcard/stl7.img
dd if=/dev/block/stl8 of=/sdcard/stl8.img
I hope you can zip all of them in one file and upload it for us.
I will try to restore using fastboot
Click to expand...
Click to collapse
Related
first and formost special thanks CastleBravo,without whos testing and help in this thread,for DNA. he asked all the right questions,and gave others all the right answers while i was at work and couldnt respond. also to treadwayj,who dumped mmcblk0p3 from his still locked phone for comparison,providing valuable confirmation.
with m7,this is just one way to skin the cat. you can also use the revone tool to change back to *locked*
use clockwork recovery it did not work for me using twrp. agaion, if you want to flash these zips,do now use twrp.
i happened across this thread inthe gsm evo 3d forum: http://forum.xda-developers.com/showthread.php?t=1970252 and found it to work on the rezound,inc 4g,sensation 4g,cdma evo 3d,MT4GS,Amaze 4g,one s,droid DNA,m7,and prolly several others.
this does NOT mean you can unlock your bootloader without going thru htcdev. all this means,is that if your bootloader is unlocked after s-off,you can get rid of the relocked watermark and get back to 100% locked prior to s-on for legitimate warranty purposes.
ive always been unlocked. for S&Gs,i dumped mmcblk0p3 and found the described "HTCU" at 0x8404. changed it to 0x00000000 and voila! back to locked
afterward,relfashed my origianl mmcblk0p3,wich brought me back to unlocked with no getting or flashing tokens.
this is NOT a patched or hex edited hboot.again,this is ONLY to get back your original ***locked*** status.
*this is for s-off phones only
2 ways to do it:
1)old school
this assumes you to have drivers,adb/fastboot,a hex editor,a fair understanding about what youre doing,and the ability to follow directions on the linked thread
Code:
Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.
C:\Users\Scott>[COLOR="Red"]cd c:\mini-adb_vigor[/COLOR]
c:\mini-adb_vigor>[COLOR="red"]adb devices[/COLOR]
* daemon not running. starting it now *
* daemon started successfully *
List of devices attached
HTxxxxxxxxxx device
c:\mini-adb_vigor>[COLOR="Red"]adb shell[/COLOR]
[email protected]:/ $ [COLOR="red"]su[/COLOR]
su
[email protected]:/ # [COLOR="red"]dd if=/dev/block/mmcblk0p3 of=/sdcard2/mmcblk0p3[/COLOR]
dd if=/dev/block/mmcblk0p3 of=/sdcard2/mmcblk0p3
64734+0 records in
64734+0 records out
33143808 bytes transferred in 9.519 secs (3481858 bytes/sec)
[email protected]:/ # [COLOR="red"]exit[/COLOR]
exit
[email protected]:/ $ [COLOR="red"]exit[/COLOR]
exit
c:\mini-adb_vigor>[COLOR="red"]adb pull /sdcard2/mmcblk0p3[/COLOR]
2292 KB/s (33143808 bytes in 14.116s)
[COLOR="Blue"]*modify mmcblk0p3 with a hex editor[/COLOR]
c:\mini-adb_vigor>[COLOR="Red"]adb push mmcblk0p3mod /sdcard2/mmcblk0p3mod[/COLOR]
2478 KB/s (33143808 bytes in 13.059s)
c:\mini-adb_vigor>[COLOR="red"]adb shell[/COLOR]
[email protected]:/ $ [COLOR="red"]su[/COLOR]
su
[email protected]:/ # [COLOR="red"]dd if=/sdcard2/mmcblk0p3mod of=/dev/block/mmcblk0p3[/COLOR]
dd if=/sdcard2/mmcblk0p3mod of=/dev/block/mmcblk0p3
64734+0 records in
64734+0 records out
33143808 bytes transferred in 18.937 secs (1750214 bytes/sec)
[email protected]:/ #[COLOR="red"] exit[/COLOR]
exit
[email protected]:/ $ [COLOR="red"]exit[/COLOR]
exit
c:\mini-adb_vigor>[COLOR="red"]adb reboot bootloader[/COLOR]
c:\mini-adb_vigor>
2)noob friendly
-download the appropriate zips,place on sd card.
-boot to recoverywipe cache/dalvik
-flash in recovery. i recomend to run query first,to make sure its working. tested on my personal m7_u,and m7_ul, one s,amaze,jetstream,rezound,inc) 4g,sensation,MT4GS,and gsm evo 3d. tested by castlebravo on DNA.
query:query_bootloader.zip
query_bootloader.zip f335f78f9f46469c823da0c671026de5
unlock:unlock_bootloader.zip
unlock_bootloader.zip f335f78f9f46469c823da0c671026de5
lock:lock_bootloader.zip
lock_bootloader.zip f335f78f9f46469c823da0c671026de5
a little bit of explanation. yes,the md5s are all the same. its the same file,just named differently. the script behaves based on the name of the zip. i knew if i only included 1 download and instructed folks to change the name there would be confusion,so this is my attempt to keep it simple. feel free to download one file and just change the name to make the other zips.
it also works to make your phone relocked if for some reason you want it that way(rename relock_bootloader.zip). i didnt include a zip for that because i figued there would be no demand.
before:
after:
sure,i could have easily faked the above photos,but i dint.
again,all credit goes to s trace on the above thread,be sure to click the thanks button on his post. all i did was remove the device check per his instruction. DO NOT flash on other devices without checking for the proper location of the lock flag first.
DISCLAIMER:this is not my work. i have tested it on my own device,but use it at your own risk. if it melts your phone into a lil pile of goo,its not my fault.
enjoy
special thanks
-BC for originally dumping mmcblk0p3 for me to know this was worth exploring for dna
-CastleBravo for testing and suport on the original test thread,as well as the pics you see here
-treadwayj for dumping mmcblk0p3 from his still locked phone.
-brian for unlocking his bootloader,then dumping mmcblock0p3 to make sure it would work for cdma evo3d phones too
-brian and donb for fearless testing of the zip files on evo3d cdma
This is only for the flags, correct? It won't turn S-ON, will it? I'm not sure how thorough the T-mobile folks check to see if you've rooted your phone or not. Mine says locked but I have S-OFF so i can still do as I please with the phone. NINJA!
silentcovenant said:
This is only for the flags, correct? It won't turn S-ON, will it? I'm not sure how thorough the T-mobile folks check to see if you've rooted your phone or not. Mine says locked but I have S-OFF so i can still do as I please with the phone. NINJA!
Click to expand...
Click to collapse
It will lock the bootloader again, but that doesn't matter now that we have S-OFF.
I just used revone's guide for resetting the flag from "Relocked" to "Locked".
Lafenear said:
It will lock the bootloader again, but that doesn't matter now that we have S-OFF.
I just used revone's guide for resetting the flag from "Relocked" to "Locked".
Click to expand...
Click to collapse
Okay, yeah, me too.. I'm having a lot of issues with getting AOSP ROMs to work with my phone, I'm starting to think the phone is defective. I can't imagine what would be going wrong, though. What would I tell T-Mobile if/when I take the phone to them, I just want another HTC One that works with my flashing habit.
Also, anyone know how to reflash the stock recovery? I notice someone posted the .img file of it
silentcovenant said:
Okay, yeah, me too.. I'm having a lot of issues with getting AOSP ROMs to work with my phone, I'm starting to think the phone is defective. I can't imagine what would be going wrong, though. What would I tell T-Mobile if/when I take the phone to them, I just want another HTC One that works with my flashing habit.
Also, anyone know how to reflash the stock recovery? I notice someone posted the .img file of it
Click to expand...
Click to collapse
you should be able to just flash it in fastboot
Sent from my HTC One using xda premium
Can you actually S-ON again? Don't need to but just curious!
meleelord said:
Can you actually S-ON again? Don't need to but just curious!
Click to expand...
Click to collapse
http://androidforums.com/showthread.php?p=5918438
Sent from my ADR6425LVW using Tapatalk 2
Any Cherry Mobile Cruize/GFIVE G95 user here ?
I have accidently overwritten the /dev/block/mmcblk0p16 block, which is 'dt-blob'. Without it phone's touchscreen and buttons dont work.
Can you please take a backup of your mmcblk0p16 block and upload it ? it'd be great help.
The process would be,
adb shell
su
dd if=/dev/block/mmcblk0p16 of=/sdcard/block16.img
now please upload the /sdcard/block16.img to the web.
I am attempting to apply a new system.img file to an Android tablet and it always results in a soft brick/bootloop.
The tablet being used is a TerraPad 1004, running android 5.1.1 (MTK8735). I have been given special access to the image files by the manufacturer, who have provided everything I need to update the tablet using SP Flash Tool (5.164 on Windows 10). If I flash the files as they were provided it all works fine and the tablet boots up perfectly. If I unpack/mount/repack the system.img and then try flashing it I get stuck either on the boot screen or get the dead android image (only get this I make the system.img file too big when repacking it). Please note, despite unpacking/mounting/repacking I made no changes to the system image, so in theory it should be the same as the originally provided system.img file.
I am doing the unpack/mount/repack on Ubuntu 16.04 (64 bit - have tried 32 bit and 12.04) VM (using Virtual Box).
The commands I am using are:
Unpack: simg2img system.img system.raw
Mount: sudo mount -t ext4 -o loop system.raw system/
Repack: make_ext4fs -s -l 1617722231 -S file_contexts -a system newsystem.img /home/ubuntu/mhh/Terra1004/system
The file size specified for make_ext4fs has been arrived at via trial and error as all the means I have seen of calculating (e.g blocks x block size) result in a file that is significantly bigger then the original system.img file (resulting in dead android when flashed to tablet). The current size specified results in an image file that has the same number of blocks as the original file but is 24 bytes bigger than the original (this img results in getting stuck on the very first boot splash screen).
I have tried flashing the image via fastboot (fastboot flash system system.img) and get "FAILED (remote: failed to get download permission for partition 'system')".
I am working with the manufacturer to resolve this issue but I am getting very little back from them.
I am getting quite desperate to resolve this as my business relies on my ability to amend the system.img (and other files) to bespoke the tablet to my own product.
I am really at the limit of my understanding on what I am talking about when it comes to modding tablets - I do it as a necessity rather than a hobby, so please excuse any incorrectly used terminology.
All help/suggestions welcome. Please let me know if you need any further information.
Thanks in advance.
KGMARSCH said:
I am attempting to apply a new system.img file to an Android tablet and it always results in a soft brick/bootloop.
The tablet being used is a TerraPad 1004, running android 5.1.1 (MTK8735). I have been given special access to the image files by the manufacturer, who have provided everything I need to update the tablet using SP Flash Tool (5.164 on Windows 10). If I flash the files as they were provided it all works fine and the tablet boots up perfectly. If I unpack/mount/repack the system.img and then try flashing it I get stuck either on the boot screen or get the dead android image (only get this I make the system.img file too big when repacking it). Please note, despite unpacking/mounting/repacking I made no changes to the system image, so in theory it should be the same as the originally provided system.img file.
I am doing the unpack/mount/repack on Ubuntu 16.04 (64 bit - have tried 32 bit and 12.04) VM (using Virtual Box).
The commands I am using are:
Unpack: simg2img system.img system.raw
Mount: sudo mount -t ext4 -o loop system.raw system/
Repack: make_ext4fs -s -l 1617722231 -S file_contexts -a system newsystem.img /home/ubuntu/mhh/Terra1004/system
The file size specified for make_ext4fs has been arrived at via trial and error as all the means I have seen of calculating (e.g blocks x block size) result in a file that is significantly bigger then the original system.img file (resulting in dead android when flashed to tablet). The current size specified results in an image file that has the same number of blocks as the original file but is 24 bytes bigger than the original (this img results in getting stuck on the very first boot splash screen).
I have tried flashing the image via fastboot (fastboot flash system system.img) and get "FAILED (remote: failed to get download permission for partition 'system')".
I am working with the manufacturer to resolve this issue but I am getting very little back from them.
I am getting quite desperate to resolve this as my business relies on my ability to amend the system.img (and other files) to bespoke the tablet to my own product.
I am really at the limit of my understanding on what I am talking about when it comes to modding tablets - I do it as a necessity rather than a hobby, so please excuse any incorrectly used terminology.
All help/suggestions welcome. Please let me know if you need any further information.
Thanks in advance.
Click to expand...
Click to collapse
Try flashing system.img without modifying it
Sent from my GT-S7580 using Tapatalk
DodoGTA said:
Try flashing system.img without modifying it
Sent from my GT-S7580 using Tapatalk
Click to expand...
Click to collapse
I've done that. The system.img file as provided by the manufacturer works fine. It fails as soon as I unpack/repack it, even without making any modifications to it.
KGMARSCH said:
I've done that. The system.img file as provided by the manufacturer works fine. It fails as soon as I unpack/repack it, even without making any modifications to it.
Click to expand...
Click to collapse
What's the size of unmodified system.img (in bytes)?
Sent from my GT-S7580 using Tapatalk
DodoGTA said:
What's the size of unmodified system.img (in bytes)?
Sent from my GT-S7580 using Tapatalk
Click to expand...
Click to collapse
Using Ubuntu stat command on system.img (the original untouched image), it reports:
Size: 929,933,912
Blocks: 1,816,288
IO Block: 4,096
Inode: 1,863,406
Doing the same on the repacked newsystem.img I get:
Size: 929,933,936
Blocks: 1,816,288
IO Block: 4,096
Inode: 1,983,804
This is the closest I can get the size of newsystem.img to be to system.img (24 bytes difference).
The permissions on both are the same (0770).
DodoGTA said:
Try flashing system.img without modifying it
Sent from my GT-S7580 using Tapatalk
Click to expand...
Click to collapse
Just realised that I may have misunderstood your comment. I have previously tried flashing the original system.img using the SP Flash Tool and that works fine. However, in case you meant flashing it via fastboot, I have just tried this and I get the same "failed to get download permission for partition 'system'" error, even with the original system.img.
KGMARSCH said:
Using Ubuntu stat command on system.img (the original untouched image), it reports:
Size: 929,933,912
Blocks: 1,816,288
IO Block: 4,096
Inode: 1,863,406
Doing the same on the repacked newsystem.img I get:
Size: 929,933,936
Blocks: 1,816,288
IO Block: 4,096
Inode: 1,983,804
This is the closest I can get the size of newsystem.img to be to system.img (24 bytes difference).
The permissions on both are the same (0770).
Click to expand...
Click to collapse
Can you run this command on a tablet you talked about in this thread (with a terminal emulator app):
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
and post the output of it?
Sent from my GT-S7580 using Tapatalk
DodoGTA said:
Can you run this command on a tablet you talked about in this thread (with a terminal emulator app):
and post the output of it?
Sent from my GT-S7580 using Tapatalk
Click to expand...
Click to collapse
Here is the output from cat partitions, cat partinfo and cat emmc:
[email protected]_PAD_1004:/proc $ cat partitions
cat partitions
major minor #blocks name
254 0 483328 zram0
7 0 1254 loop0
179 0 15267840 mmcblk0
179 1 3072 mmcblk0p1
179 2 5120 mmcblk0p2
179 3 10240 mmcblk0p3
179 4 10240 mmcblk0p4
179 5 512 mmcblk0p5
179 6 512 mmcblk0p6
179 7 16384 mmcblk0p7
179 8 16384 mmcblk0p8
179 9 8192 mmcblk0p9
179 10 10240 mmcblk0p10
179 11 512 mmcblk0p11
179 12 2048 mmcblk0p12
179 13 6144 mmcblk0p13
179 14 8192 mmcblk0p14
179 15 5120 mmcblk0p15
179 16 5120 mmcblk0p16
179 17 1024 mmcblk0p17
179 18 32768 mmcblk0p18
179 19 37888 mmcblk0p19
179 20 1572864 mmcblk0p20
179 21 409600 mmcblk0p21
179 22 13088256 mmcblk0p22
179 23 16384 mmcblk0p23
179 96 4096 mmcblk0rpmb
179 64 4096 mmcblk0boot1
179 32 4096 mmcblk0boot0
[email protected]_PAD_1004:/proc $ cat partinfo
cat partinfo
Name Start Size
pgpt 0x0000000000000000 0x0000000000080000
proinfo 0x0000000000080000 0x0000000000300000
nvram 0x0000000000380000 0x0000000000500000
protect1 0x0000000000880000 0x0000000000a00000
protect2 0x0000000001280000 0x0000000000a00000
lk 0x0000000001c80000 0x0000000000080000
para 0x0000000001d00000 0x0000000000080000
boot 0x0000000001d80000 0x0000000001000000
recovery 0x0000000002d80000 0x0000000001000000
logo 0x0000000003d80000 0x0000000000800000
expdb 0x0000000004580000 0x0000000000a00000
seccfg 0x0000000004f80000 0x0000000000080000
oemkeystore 0x0000000005000000 0x0000000000200000
secro 0x0000000005200000 0x0000000000600000
keystore 0x0000000005800000 0x0000000000800000
tee1 0x0000000006000000 0x0000000000500000
tee2 0x0000000006500000 0x0000000000500000
frp 0x0000000006a00000 0x0000000000100000
nvdata 0x0000000006b00000 0x0000000002000000
metadata 0x0000000008b00000 0x0000000002500000
system 0x000000000b000000 0x0000000060000000
cache 0x000000006b000000 0x0000000019000000
userdata 0x0000000084000000 0x000000031ed80000
flashinfo 0x00000003a2d80000 0x0000000001000000
sgpt 0x00000003a3d80000 0x0000000000080000
[email protected]_PAD_1004:/proc $ cat emmc
cat emmc
partno: start_sect nr_sects partition_name
emmc_p1: 00000400 00001800 "proinfo"
emmc_p2: 00001c00 00002800 "nvram"
emmc_p3: 00004400 00005000 "protect1"
emmc_p4: 00009400 00005000 "protect2"
emmc_p5: 0000e400 00000400 "lk"
emmc_p6: 0000e800 00000400 "para"
emmc_p7: 0000ec00 00008000 "boot"
emmc_p8: 00016c00 00008000 "recovery"
emmc_p9: 0001ec00 00004000 "logo"
emmc_p10: 00022c00 00005000 "expdb"
emmc_p11: 00027c00 00000400 "seccfg"
emmc_p12: 00028000 00001000 "oemkeystore"
emmc_p13: 00029000 00003000 "secro"
emmc_p14: 0002c000 00004000 "keystore"
emmc_p15: 00030000 00002800 "tee1"
emmc_p16: 00032800 00002800 "tee2"
emmc_p17: 00035000 00000800 "frp"
emmc_p18: 00035800 00010000 "nvdata"
emmc_p19: 00045800 00012800 "metadata"
emmc_p20: 00058000 00300000 "system"
emmc_p21: 00358000 000c8000 "cache"
emmc_p22: 00420000 018f6c00 "userdata"
emmc_p23: 01d16c00 00008000 "flashinfo"
[email protected]_PAD_1004:/proc $
DodoGTA said:
Can you run this command on a tablet you talked about in this thread (with a terminal emulator app):
and post the output of it?
Sent from my GT-S7580 using Tapatalk
Click to expand...
Click to collapse
I've got ahead of you I think. I have amended the file size in the make_ext4fs command to make it the same as the partition (1572864 x 1024 = 1610612736). I have flashed the resultant image and it now boots up.
I would swear that I tried this, but then again I have tried so many things over the last couple of weeks
You are my hero and have saved me sooooooo much stress - I honestly thought I'd have to shut down business until this was resolved.
KGMARSCH said:
I've got ahead of you I think. I have amended the file size in the make_ext4fs command to make it the same as the partition (1572864 x 1024 = 1610612736). I have flashed the resultant image and it now boots up.
I would swear that I tried this, but then again I have tried so many things over the last couple of weeks
You are my hero and have saved me sooooooo much stress - I honestly thought I'd have to shut down business until this was resolved.
Click to expand...
Click to collapse
I meant to say this solution
Sent from my GT-S7580 using Tapatalk
DodoGTA said:
I meant to say this solution
Sent from my GT-S7580 using Tapatalk
Click to expand...
Click to collapse
I don't really know what the forum etiquette is but thanks very much for your help. I was rapidly running out of stock of the previous tablet model from the manufacturer and was starting to worry that I wouldn't have a replacement ready in time - now I can get on with making the required amends.
Sometimes you just need someone from the outside to have a look!
Many thanks, Kevin
KGMARSCH said:
I am attempting to apply a new system.img file to an Android tablet and it always results in a soft brick/bootloop.
The tablet being used is a TerraPad 1004, running android 5.1.1 (MTK8735). I have been given special access to the image files by the manufacturer, who have provided everything I need to update the tablet using SP Flash Tool (5.164 on Windows 10). If I flash the files as they were provided it all works fine and the tablet boots up perfectly. If I unpack/mount/repack the system.img and then try flashing it I get stuck either on the boot screen or get the dead android image (only get this I make the system.img file too big when repacking it). Please note, despite unpacking/mounting/repacking I made no changes to the system image, so in theory it should be the same as the originally provided system.img file.
I am doing the unpack/mount/repack on Ubuntu 16.04 (64 bit - have tried 32 bit and 12.04) VM (using Virtual Box).
The commands I am using are:
Unpack: simg2img system.img system.raw
Mount: sudo mount -t ext4 -o loop system.raw system/
Repack: make_ext4fs -s -l 1617722231 -S file_contexts -a system newsystem.img /home/ubuntu/mhh/Terra1004/system
The file size specified for make_ext4fs has been arrived at via trial and error as all the means I have seen of calculating (e.g blocks x block size) result in a file that is significantly bigger then the original system.img file (resulting in dead android when flashed to tablet). The current size specified results in an image file that has the same number of blocks as the original file but is 24 bytes bigger than the original (this img results in getting stuck on the very first boot splash screen).
I have tried flashing the image via fastboot (fastboot flash system system.img) and get "FAILED (remote: failed to get download permission for partition 'system')".
I am working with the manufacturer to resolve this issue but I am getting very little back from them.
I am getting quite desperate to resolve this as my business relies on my ability to amend the system.img (and other files) to bespoke the tablet to my own product.
I am really at the limit of my understanding on what I am talking about when it comes to modding tablets - I do it as a necessity rather than a hobby, so please excuse any incorrectly used terminology.
All help/suggestions welcome. Please let me know if you need any further information.
Thanks in advance.
Click to expand...
Click to collapse
Why not try it like this
This is how I do it
use simg2img
simg2img system.img system_mod.img
mount it
mount -t ext4 -o loop system_mod.img /data/mountpoint
Make your modifications and unmount it
use img2simg
img2simg system_mod.img system.img
I don't think you can mount an img for what your trying to do you can use dd though its like flashing it
dd if=/system.img of=/mountpoint
Sent from my SM-J320P using Tapatalk
rick.wardenburg said:
Why not try it like this
This is how I do it
use simg2img
simg2img system.img system_mod.img
mount it
mount -t ext4 -o loop system_mod.img /data/mountpoint
Make your modifications and unmount it
use img2simg
img2simg system_mod.img system.img
I don't think you can mount an img for what your trying to do you can use dd though its like flashing it
dd if=/system.img of=/mountpoint
Sent from my SM-J320P using Tapatalk
Click to expand...
Click to collapse
Thanks for replying. I've now solved this (with help from DodoGTA). Turns out I had to be very specific (to the byte) with the file size in the make_ext4fs command. Previous tablets I've updated weren't as stringent with the files size (I think they were always defaulted to 500M) but this one is. I took the file size from the system partition size on the tablet (x 1024 to get it into bytes) and it worked (although I could have sworn I'd already tried this). I've now made amends to the system.img and they are taking affect. Thanks anyway.
Same issue as OP
Hey guys I could really use some help. I have MTK device with manufacturer permission to modify firmware. I unpack and repack system.img with no changes, and phone stuck on boot. I can cat partitions, but not partinfo or emmc. Any suggestions would be great as I'm super frustrated and running out of ideas.
scott.fallick said:
Hey guys I could really use some help. I have MTK device with manufacturer permission to modify firmware. I unpack and repack system.img with no changes, and phone stuck on boot. I can cat partitions, but not partinfo or emmc. Any suggestions would be great as I'm super frustrated and running out of ideas.
Click to expand...
Click to collapse
Hi Scott,
If your problem is the same as the one I had then it will be to do with the size you are specifying when repacking the system image.
I was able to work out the size that I required from "cat partitions" (take the size shown for the system partition and multiply it by 1024 to get the value you should use).
The problem you may have is being able to identify which is the system partition. Without being able to see either the partinfo or emmc you may not be able to do this easily, in which case I would recommend a process of elimination. Start with the largest number shown on in the "cat partitions" list and work your why down until you get a value that works. Not the quickest way to do it but the best I can offer you. If you can post the output from "cat partitions" I may be able to make an educated guess which is the system.
Sorry I can't be of more help.
KGMARSCH said:
Hi Scott,
If your problem is the same as the one I had then it will be to do with the size you are specifying when repacking the system image.
I was able to work out the size that I required from "cat partitions" (take the size shown for the system partition and multiply it by 1024 to get the value you should use).
The problem you may have is being able to identify which is the system partition. Without being able to see either the partinfo or emmc you may not be able to do this easily, in which case I would recommend a process of elimination. Start with the largest number shown on in the "cat partitions" list and work your why down until you get a value that works. Not the quickest way to do it but the best I can offer you. If you can post the output from "cat partitions" I may be able to make an educated guess which is the system.
Sorry I can't be of more help.
Click to expand...
Click to collapse
So I believe I'm using the correct size, I was able to determine the name for system using an apk. However, this may sound weird, but it seems my system.img is on a ZRAM partition.
scott.fallick said:
So I believe I'm using the correct size, I was able to determine the name for system using an apk. However, this may sound weird, but it seems my system.img is on a ZRAM partition.
Click to expand...
Click to collapse
I think I am at the limit of my knowledge here. I know enough to be able to make changes to one specific model of tablet. Anything outside of the process that I use for modifying that tablet and I'm not much help I'm afraid. Sorry.
I hope someone else is able to help you.
Kevin
KGMARSCH said:
Hi Scott,
If your problem is the same as the one I had then it will be to do with the size you are specifying when repacking the system image. I was able to work out the size that I required from "cat partitions" (take the size shown for the system partition and multiply it by 1024 to get the value you should use).
.
Click to expand...
Click to collapse
I have the same issue. Seem to have to almost hit super lucky with my make_ext4fs command on nougat based system.img files, where I seem to have gotten one mbuild working but then nothing!. I am in bootloop hell!! However your solution seems like the answer for me. Forgive me for being a little slow on the uptake here, can you explain how you CAT on the device to get the partition sizes and can you take us through the method a little more step by step? I just lost you on that small point.
Just the bit about getting the partition size you then multiply by 1024 to get the final value you use in the make_ext4fs command?
Cheers
OK, so I answered my own question here: https://forum.xda-developers.com/showthread.php?t=2450045
I'm a Windows dude so LINUX commands are not my forte!!
davek17 said:
OK, so I answered my own question here: https://forum.xda-developers.com/showthread.php?t=2450045
I'm a Windows dude so LINUX commands are not my forte!!
Click to expand...
Click to collapse
Well still not resolved actually. For some reason make_ext4fs is now building 44.9MB system.img files that are empty when upacked. Maybe my LINUX VM has gotten corrupted.
Also I think this could be to do with dm-verity too. Despite not seeing any errors when I build the system.img again it boots, runs normally but anything to do with Google apps fail. E.G. Google play stops running, chrome just doesn't want to load. Rest of device seems to work OK though!! Anyone shed any light on that
Well , I found a python script that can make the gpt.bin(or partitions.bin) file I need to make gpt partition table.
Just Need someone who have well working device and a computer running linux.
I last the script end of this tread.
Would Anyone like to give me a lift?
How To:
1. You should have a well-working htc desire 610/612 phone.(ROOTED)
2..Download that script named mkpartition0_bin.py I last at end.
3.Connect your phone, make sure you have adb (android-tools) running corrctly.
4.cd to your work directory and type:
Code:
python ./mkpartition0_bin.py
Then you'll find it at your device's sdcard root dir.
Some issues:
1.I found error when I running this script:
Code:
[[email protected] create]$ ./mkpartition0_bin.py
1+0 records in
1+0 records out
512 bytes transferred in 0.001 secs (512000 bytes/sec)
Traceback (most recent call last):
File "./mkpartition0_bin.py", line 54, in <module>
mbr()
File "./mkpartition0_bin.py", line 17, in mbr
partition = dict(zip(('boot', 'id', 'start', 'size'), unpack('4I', buf)))
struct.error: unpack requires a string argument of length 16
2.Another Issue is that this script requires device is rooted.
But I think sometimes it isn't touchable.
Code:
dd if=/dev/block/mmcblk0 of=/cache/partition0.bin bs=512 count=1
dd: /dev/block/mmcblk0: Permission denied
ANYWAY, Thank for all.
==============================================================
Hi guys.
I've got a hard brick with my htc Desire 612 , which I think is same as 610.
1. I got the "cat /proc/xxx" info with a thread I found in XDA ( I left it here).
2. I have got Qualcomm .mbn files :
mprg8x26.mbn, prog_firehose_8x26.mbn
and so on.
left this thread.
3.I would use QFIL but less rawprogram0.xml and patch0.xml.
I found I can get them two with partition.xml and ptool.py .
So , I just need to create a partition.xml with this tread :
https://androidforums.com/threads/guide-how-to-create-partition-xml-gpt.1125433/
But when I unpacked the rom.zip from RUU , USING THIS TOOL :
https://forum.xda-developers.com/chef-central/android/tool-universal-htc-ruu-rom-decryption-t3382928
I CANNOT Found the gpt_main_xx.img , which is a gpt partition table I need to create partition.xml .
Here are my files you guys might need.
contents:
create.zip:
partition.xml (template)
partitions table.txt (Info)
PartitioningTool.py (This script parses "partition.xml" and creates numerous output files specifically, partition.bin, rawprogram.xml)
Partition_xml-Generator-Spreadsheet.ods (sheet to generate partition.xml from gpt.bin)
THANKS ALL!
There are some posts on how to root the Xiaomi Redmi 9 (Galahad/Lancelot) phone, but since they have lots of "don't know" phrases (or files of unknown origin), I've managed to do the whole process from scratch.
Lancelot or Galahad
Basically, the codename for Xiaomi Redmi 9 phone is Lancelot. But when you get shell via ADB, you will see Galahad. This can cause lots of confusion because you may think that Galahad and Lancelot are two different phones. In reality they're the same phone. Moreover, the specs of the Xiaomi Redmi 9 says that the phone has a MT6769T SoC (the info comes from the phone's /proc/cpuinfo). But it looks like the official ROM, TWRP, even CPU-Z treats the phone as if it had the MT6768 SoC. So keep that in mind when you look for some info concerning the phone.
The phone was bought in Europe/Poland last year (the black Friday, 2020) from the official source. Here's some more info:
Code:
galahad:/ # getprop | grep -i model
[ro.product.model]: [M2004J19C]
[ro.product.odm.model]: [M2004J19C]
[ro.product.product.model]: [M2004J19C]
[ro.product.system.model]: [M2004J19C]
[ro.product.vendor.model]: [M2004J19C]
galahad:/ # getprop | grep -i ro.build.version.
[ro.build.version.base_os]: [Redmi/galahad_eea/galahad:10/QP1A.190711.020/V12.0.0.1.QJCEUXM:user/release-keys]
[ro.build.version.incremental]: [V12.0.1.0.QJCEUXM]
[ro.build.version.security_patch]: [2021-01-05]
galahad:/ # getprop | grep -i baseband
[gsm.version.baseband]: [MOLY.LR12A.R3.MP.V98.P75,MOLY.LR12A.R3.MP.V98.P75]
[ro.baseband]: [unknown]
[vendor.gsm.project.baseband]: [HUAQIN_Q0MP1_MT6769_SP(LWCTG_CUSTOM)]
$ fastboot getvar all
...
(bootloader) product: lancelot
...
(bootloader) version-baseband: MOLY.LR12A.R3.MP.V98.P75
(bootloader) version-bootloader: lancelot-2b1e22f-20201123162228-2021011
(bootloader) version-preloader:
(bootloader) version: 0.5
...
The bootloader unlock
Before you even start thinking of flashing the TWRP image to the Xiaomi Redmi 9 (Galahad/Lancelot) phone, you have to unlock it's bootloader first. It's a straightforward operation, but you need some proper tools to achieve that. If you're using windows, use Mi Unlock, if you're on linux, use xiaomitool. I'm a linux user so I can't help with this process those of you who use windows. If you're going to use xiaomitool, there's a bug in the current version (20.7.28 beta), and you have to patch the source yourself to make it work again. It's not hard. There's an article step by step how to do it. It's in Polish, but all the necessary commands are included so you can just ctrl+c and ctrl+v.
When you unlock the bootloader, you can flash the TWRP image, so make sure you have the following in the Developer options:
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
The TWRP image
There are some prebuilt TWRP images in the wild, but I wanted source of the files, and I couldn't get any. But I've managed to target this device tree. I attached the twrp-recovery.img (64MiB) file in this post. It looks like the TWRP image built from that source has everything that's needed, so you won't really have to build it yourself. If you want to build the TWRP image yourself from the provided source, you have to go through setting up the android build environment.
Flashing the TWRP image
When you have the TWRP image, you can flash it to the Xiaomi Redmi 9 (Galahad/Lancelot) phone using fastboot. On Debian, you just install the fastboot package. To flash the TWRP image, turn off you phone, turn it on using volumeDown+power, plug the phone via USB to your desktop/laptop and issue the following command:
Code:
$ fastboot flash recovery twrp-recovery.img
Remember one thing. This flashing has only a temporary effect. When you boot the device in a normal mode, the recovery partition will be automatically regenerated and flashed by your phone. So when you issue the command above, boot to recovery via:
Code:
$ fastboot reboot recovery
After you boot into TWRP recovery, it will ask for password. This is the password that you use to unlock your phone's lock screen.
Backup the phone's flash
The temporary TWRP recovery is needed to take the backup of the whole phone's flash. The only partition that has been changed is the recovery partition. Other partitions are intact. In this way, you can backup partitions that hold IMEI, WiFi/BT MACs, and other important stuff. If something goes wrong, you can restore the phone to it's default state (after unlocking) using fastboot and the partition images.
To make the backup of the whole phone's flash, use the following command:
Code:
$ adb pull /dev/block/mmcblk0 mmcblk0.img
This command is issued from your desktop/laptop computer, and not from the phone. Of course you could just use the dd command and backup the flash to the external SD card, but my external SD was only 32G, and the phone's flash is 64G. Besides it's better to store the phone's flash on your computer for future use.
The process of taking a backup is rather slow. It took around 2h (14M/s). After it finishes, you can check whether everything with the image is OK by looking into the image using the gdisk tool:
Code:
$ adb pull /dev/block/mmcblk0 mmcblk0.img
/dev/block/mmcblk0: 1 file pulled. 14.0 MB/s (62537072640 bytes in 4266.682s)
# gdisk -l /media/Zami/mmcblk0.img
GPT fdisk (gdisk) version 1.0.7
Partition table scan:
MBR: protective
BSD: not present
APM: not present
GPT: present
Found valid GPT with protective MBR; using GPT.
Disk /media/Zami/mmcblk0.img: 122142720 sectors, 58.2 GiB
Sector size (logical): 512 bytes
Disk identifier (GUID): 00000000-0000-0000-0000-000000000000
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 122142686
Partitions will be aligned on 16-sector boundaries
Total free space is 61 sectors (30.5 KiB)
Number Start (sector) End (sector) Size Code Name
1 64 131135 64.0 MiB 0700 recovery
2 131136 132159 512.0 KiB 0700 misc
3 132160 133183 512.0 KiB 0700 para
4 133184 174143 20.0 MiB 0700 expdb
5 174144 176191 1024.0 KiB 0700 frp
6 176192 192575 8.0 MiB 0700 vbmeta
7 192576 208959 8.0 MiB 0700 vbmeta_system
8 208960 225343 8.0 MiB 0700 vbmeta_vendor
9 225344 271631 22.6 MiB 0700 md_udc
10 271632 337167 32.0 MiB 0700 metadata
11 337168 402703 32.0 MiB 0700 nvcfg
12 402704 533775 64.0 MiB 0700 nvdata
13 533776 632079 48.0 MiB 0700 persist
14 632080 730383 48.0 MiB 0700 persistbak
15 730384 746767 8.0 MiB 0700 protect1
16 746768 770047 11.4 MiB 0700 protect2
17 770048 786431 8.0 MiB 0700 seccfg
18 786432 790527 2.0 MiB 0700 sec1
19 790528 796671 3.0 MiB 0700 proinfo
20 796672 797695 512.0 KiB 0700 efuse
21 797696 850943 26.0 MiB 0700 boot_para
22 850944 982015 64.0 MiB 0700 nvram
23 982016 998399 8.0 MiB 0700 logo
24 998400 1260543 128.0 MiB 0700 md1img
25 1260544 1262591 1024.0 KiB 0700 spmfw
26 1262592 1274879 6.0 MiB 0700 scp1
27 1274880 1287167 6.0 MiB 0700 scp2
28 1287168 1289215 1024.0 KiB 0700 sspm_1
29 1289216 1291263 1024.0 KiB 0700 sspm_2
30 1291264 1324031 16.0 MiB 0700 gz1
31 1324032 1356799 16.0 MiB 0700 gz2
32 1356800 1360895 2.0 MiB 0700 lk
33 1360896 1364991 2.0 MiB 0700 lk2
34 1364992 1496063 64.0 MiB 0700 boot
35 1496064 1528831 16.0 MiB 0700 dtbo
36 1528832 1539071 5.0 MiB 0700 tee1
37 1539072 1549311 5.0 MiB 0700 tee2
38 1549312 1582079 16.0 MiB 0700 gsort
39 1582080 1844223 128.0 MiB 0700 minidump
40 1844224 2630655 384.0 MiB 0700 exaid
41 2630656 4727807 1024.0 MiB 0700 cust
42 4727808 4744191 8.0 MiB 0700 devinfo
43 4744192 4767743 11.5 MiB 0700 ffu
44 4767744 19447807 7.0 GiB 0700 super
45 19447808 20332543 432.0 MiB 0700 cache
46 20332544 122021823 48.5 GiB 0700 userdata
47 122021824 122109887 43.0 MiB 0700 otp
48 122109888 122142655 16.0 MiB 0700 flashinfo
As you can see, there's the whole flash layout with all the partitions in their stock state (except for the recovery partition, of course). If something goes wrong, you can extract the individual partition by mounting the image on a linux system in the following way:
Code:
# losetup /dev/loop5 /media/Zami/mmcblk0.img
# losetup -a
/dev/loop5: [64769]:12 (/media/Zami/mmcblk0.img)
The above command uses the /dev/loop5 device to mount the image. Since the image has many partitions, the corresponding devices will be created for each partition, which looks like this:
Code:
# ls -al /dev/loop5*
brw-rw---- 1 root disk 7, 320 2021-08-29 02:54:11 /dev/loop5
brw-rw---- 1 root disk 7, 321 2021-08-29 02:54:11 /dev/loop5p1
brw-rw---- 1 root disk 7, 330 2021-08-29 02:54:11 /dev/loop5p10
brw-rw---- 1 root disk 7, 331 2021-08-29 02:54:11 /dev/loop5p11
brw-rw---- 1 root disk 7, 332 2021-08-29 02:54:11 /dev/loop5p12
brw-rw---- 1 root disk 7, 333 2021-08-29 02:54:11 /dev/loop5p13
brw-rw---- 1 root disk 7, 334 2021-08-29 02:54:11 /dev/loop5p14
brw-rw---- 1 root disk 7, 335 2021-08-29 02:54:11 /dev/loop5p15
brw-rw---- 1 root disk 7, 336 2021-08-29 02:54:11 /dev/loop5p16
brw-rw---- 1 root disk 7, 337 2021-08-29 02:54:11 /dev/loop5p17
brw-rw---- 1 root disk 7, 338 2021-08-29 02:54:11 /dev/loop5p18
brw-rw---- 1 root disk 7, 339 2021-08-29 02:54:11 /dev/loop5p19
brw-rw---- 1 root disk 7, 322 2021-08-29 02:54:11 /dev/loop5p2
brw-rw---- 1 root disk 7, 340 2021-08-29 02:54:11 /dev/loop5p20
brw-rw---- 1 root disk 7, 341 2021-08-29 02:54:11 /dev/loop5p21
brw-rw---- 1 root disk 7, 342 2021-08-29 02:54:11 /dev/loop5p22
brw-rw---- 1 root disk 7, 343 2021-08-29 02:54:11 /dev/loop5p23
brw-rw---- 1 root disk 7, 344 2021-08-29 02:54:11 /dev/loop5p24
brw-rw---- 1 root disk 7, 345 2021-08-29 02:54:11 /dev/loop5p25
brw-rw---- 1 root disk 7, 346 2021-08-29 02:54:11 /dev/loop5p26
brw-rw---- 1 root disk 7, 347 2021-08-29 02:54:11 /dev/loop5p27
brw-rw---- 1 root disk 7, 348 2021-08-29 02:54:11 /dev/loop5p28
brw-rw---- 1 root disk 7, 349 2021-08-29 02:54:11 /dev/loop5p29
brw-rw---- 1 root disk 7, 323 2021-08-29 02:54:11 /dev/loop5p3
brw-rw---- 1 root disk 7, 350 2021-08-29 02:54:11 /dev/loop5p30
brw-rw---- 1 root disk 7, 351 2021-08-29 02:54:11 /dev/loop5p31
brw-rw---- 1 root disk 7, 352 2021-08-29 02:54:11 /dev/loop5p32
brw-rw---- 1 root disk 7, 353 2021-08-29 02:54:11 /dev/loop5p33
brw-rw---- 1 root disk 7, 354 2021-08-29 02:54:11 /dev/loop5p34
brw-rw---- 1 root disk 7, 355 2021-08-29 02:54:11 /dev/loop5p35
brw-rw---- 1 root disk 7, 356 2021-08-29 02:54:11 /dev/loop5p36
brw-rw---- 1 root disk 7, 357 2021-08-29 02:54:11 /dev/loop5p37
brw-rw---- 1 root disk 7, 358 2021-08-29 02:54:11 /dev/loop5p38
brw-rw---- 1 root disk 7, 359 2021-08-29 02:54:11 /dev/loop5p39
brw-rw---- 1 root disk 7, 324 2021-08-29 02:54:11 /dev/loop5p4
brw-rw---- 1 root disk 7, 360 2021-08-29 02:54:11 /dev/loop5p40
brw-rw---- 1 root disk 7, 361 2021-08-29 02:54:11 /dev/loop5p41
brw-rw---- 1 root disk 7, 362 2021-08-29 02:54:11 /dev/loop5p42
brw-rw---- 1 root disk 7, 363 2021-08-29 02:54:11 /dev/loop5p43
brw-rw---- 1 root disk 7, 364 2021-08-29 02:54:11 /dev/loop5p44
brw-rw---- 1 root disk 7, 365 2021-08-29 02:54:11 /dev/loop5p45
brw-rw---- 1 root disk 7, 366 2021-08-29 02:54:11 /dev/loop5p46
brw-rw---- 1 root disk 7, 367 2021-08-29 02:54:11 /dev/loop5p47
brw-rw---- 1 root disk 7, 368 2021-08-29 02:54:11 /dev/loop5p48
brw-rw---- 1 root disk 7, 325 2021-08-29 02:54:11 /dev/loop5p5
brw-rw---- 1 root disk 7, 326 2021-08-29 02:54:11 /dev/loop5p6
brw-rw---- 1 root disk 7, 327 2021-08-29 02:54:11 /dev/loop5p7
brw-rw---- 1 root disk 7, 328 2021-08-29 02:54:11 /dev/loop5p8
brw-rw---- 1 root disk 7, 329 2021-08-29 02:54:11 /dev/loop5p9
To extract some partition (for instance the stock boot), use the following command:
Code:
# dd if=/dev/loop5p34 of=./34-stock-boot.img
Extracting any of the partitions from the backup creates a file that can be flashed via fastboot or directly via dd from TWRP recovery. So as long as fastboot (or TWRP recovery) works and you are able to switch to that mode, you shouldn't brick the phone for good. All the bricks should be only temporary and they go away when you flash the stock partitions to the changed ones. So pay attention what changes you commit to the phone's flash.
The Magisk app and a bootloop
To sum up, we have a backup of the phone's flash on our computer, we have flashed a temp TWRP image to the recovery partition, and we are booted in the TWRP recovery mode. Now it's time to flash Magisk and get root on our Xiaomi Redmi 9 (Galahad/Lancelot) phone.
But not so fast. If you just flashed the Magisk apk file using TWRP, you will get a bootloop. This is because of the Android Verified Boot mechanism, which still works even after you unlock the phone. You can read about this AVB mechanism more here. Basically it's all about the boot partition hashes (and possibly other partition hashes as well) which are allowed by manufacturer of the phone to be valid. So only those boot images that have valid hashes can be used in the boot process of the device. Flashing Magisk changes the boot partition, and in this way the hash of the boot partition changes. So, when you try to boot the phone after you flashed Magisk from the TWRP recovery, it will bootloop. Also you will loose access to the recovery partition, so you won't be able to revert the change you did when you flashed the Magisk app. The only way to restore the phone in such state is to flash the stock boot partition. That's why you should make the phone's whole flash backup. I include the stock boot partition here for those who didn't have the backup, but pay attention that this boot image is for Android10/MIUI12 (see the specs above), and I don't know what will happen if you use the image with different software/firmware/ROM.
Install the Magisk app
To avoid the unpleasant bootloop situation after flashing the Magisk app, you have to deactivate the AVB mechanism. You do this by flashing the stock vbmeta partition using fastboot, i.e. the following command:
Code:
# dd if=/dev/loop5p6 of=./6-stock-vbmeta.img
$ fastboot --disable-verity --disable-verification flash vbmeta 6-stock-vbmeta.img
You can proceed with flashing the Magisk app only after you disable the AVB mechanism.
If your phone restored the stock recovery, flash once again the TWRP recovery, and boot into the recovery mode. Download the most recent Magisk app, currently Magisk-v23.0.apk. Yes, I know it's an APK file, and yes, you have to flash the APK file via TWRP recovery. You're going to see some messages about repacking the stock boot and flashing it.
This is the step when the phone stops rewriting the custom recovery partition. So, after installing the Magisk app, the TWRP recovery will be persistent, and you won't have to flash it again.
After flashing the APK file, you have to boot to the phone's OS in order to finish installing Magisk (the OS part/app). You'll be prompted to do this step, so follow what it says and ultimatelly you get the Magisk installed:
SafetyNet
The next thing is to open the Magisk App. After this, check the SafetyNet. It should fail. Go to the options and "Hide the Magisk app". You also have to activate MagiskHide. After this, check the SafetyNet again. It should pass now.
So now you have the root access on your Xiaomi Redmi 9 (Galahad/Lancelot) and also it passes the SafetyNet.
This HOWTO should work for the Xiaomi Redmi 9 (Galahad/Lancelot) phones, but I'm not sure whether I forgot to mention about something. Anyways, if you have any questions, or something doesn't work, ask.
Wow,realy great guide,good written and all infos are there,not bad!!!Cheers!!!
I fixed some spelling mistakes, now it should be easier to read.
Thanks a lot for this great guide.
Small problem here though ;-)
Entering
$ fastboot reboot recovery
leads to:
fastboot: usage: unknown reboot target recovery
Looking at fastboot --help there is no such parameter. Either bootloader or emergency (the latter doesn't work)
Thanks in advance - Chris
It works just fine with my phone:
Code:
$ fastboot reboot recovery
Rebooting into recovery OKAY [ 0.001s]
Finished. Total time: 0.252s
Maybe you need a newer version of the tool?
morfikov said:
It works just fine with my phone:
Code:
$ fastboot reboot recovery
Rebooting into recovery OKAY [ 0.001s]
Finished. Total time: 0.252s
Maybe you need a newer version of the tool?
Click to expand...
Click to collapse
Thank you, morfikov - that was it. Mine was nearly 12 years old :-D
Everyone else facing this issue: latest SDK Platform Tools always under https://developer.android.com/studio/releases/platform-tools
Thanks again for your fabulous guide!
Great guide! I even managed to compile latest TWRP from the devicetree you linked. The only thing that I would add is that I had to use losetup -fP <name>.img. The "P" flag forces the loop device to display partitions and "f" just takes the first available device. As for magisk, I had to use the Didgeridoohan's MagiskHide Props Config module in order to pass CTS check. I just had to "Force BASIC key attestation" using the default value "galahad". I suspect that has to do with the fact that i'm running latest EEA rom (Android 11), other than that I use the same phone - European version bought in Poland
morfikov said:
The process of taking a backup is rather slow. It took around 2h (14M/s)
Click to expand...
Click to collapse
You might have been using a USB 2.0 port.
It is advised that you use a USB 3.x Port. Throughput here was: 146.5 MB/s. It took around 10-15 Minutes.
Maybe you want to put that advise in your guide..
Another tipp which makes the the deavtivation of the AVB mechanism and flashing the stock vbmeta partition using fastbootmuch easier, fast - and also suitable to Windows machines. It takes all together only 2-3 minutes then:
When you're in TWRP after the first flash, instead of pulling the complete image of your Redmi 9 (which is not bad at all, but the image is not loadable under Win machines), you use the means of TWRP:
In TWRP you enter the section "Backup"
There you select the storage "Micro SD card"
In the list of partitions to be backed up ONLY select "vbmeta". It's only 8 MB. (This only takes a few seconds and requires not more than 9MB on your SD card ;-) )
Then "Swipe to Backup"
After that you stay in TWRP
Then you copy the tiny backup to your adb/fastboot folder on the PC (as you're in TWRP, you have full access):
Copy from your phone the files from Redmi's "External_SD/TWRP/BACKUPS/Redmi_9/<current date/time/ID>" to your adb/fastboot folder on the PC:
vbmeta.emmc.win
vbmeta.emmc.win.sha2
(recovery.log is not needed, it only contains the console output)
Within TWRP go back to the main menu and select "Reboot" and select "Fastboot"
The Smartphone reboots into TWRP / Fastboot mode
Now from the PC you turn the the AVB mechanism off by flashing:
$ fastboot --disable-verity --disable-verification flash vbmeta vbmeta.emmc.win
Now you continue with the guide above - reflashing TWRP & booting in Recovery:
$ fastboot flash recovery twrp-recovery.img
$ fastboot reboot recovery
In TWRP back again, now flash Magisk-vXY.Z.apk and reboot to System after that (to clean Cache & Dalvik is not a bad idea).
The flash of TWRP is now permanent (can be entered anytime from device off --> Press and hold Power and Volume up buttons)
It's weird that windows still can't mount such images.
Any tip for me?
I have J19AG (lancelot at first). The problem is that I can't fix broken Google Play Protect on other roms than EEA. This phone came with EEA rom which had GPP. Then I unlocked bootloader and flashed non EEA rom. I have tried TR, ID, IN, RU fastboot roms but none worked with GPP.
Im now on ID rom and trying to fix it using Magisk modules to change props. But neither galahad or lancelot worked for Force Basic Key attestation. After changing galahad to lancelot my base_os prop is empty. Magisk CTS check is still failed.
Code:
[ro.build.version.all_codenames]: [REL]
[ro.build.version.base_os]: []
[ro.build.version.codename]: [REL]
[ro.build.version.incremental]: [V12.0.3.0.QJCIDXM]
I would suggest you to restore the phone stock state with fastboot ROM. You can find some here:
Download: MIUI 12 stable update rolling out to several Xiaomi, Redmi and POCO devices
MIUI 12 stable builds have begun rolling out to several Xiaomi, Redmi, and POCO devices. Head on over for Recovery ROM and Fastboot ROM download links!
www.xda-developers.com
No I do not want this.
I asked some certain question.
I know exactly what I'm doing and have skills for that.
My goal was to have galahad with rom other than EEA with Google Play protect on.
Currently only EEA <-> Galahad is possible. ID, TW, TR rom have no Google Play protect when unlocked or locked bootloader on galahad (Redmi 9 with NFC).
The trick is to fix Google Play protect with Magisk and TWRP. But above methods didnt work for me.
I have no knowledge on this subject, so I can't help you with this.
Hello.
I'm having a problem using the losetup command. After using
sudo losetup /dev/loop3 mmcblk0.img
and checking out the partitions created with
[I]ls -al /dev/loop3*[/I]
I only get ...
brw-rw---- 1 root disk 7, 3 d’oct. 16 10:40 /dev/loop
When checking mmcblk0.img with command
[I]gdisk -l mmcblk0.img[/I]
I get the same as you.
I understand that losetup doesn't create the partitions other than one so I can't extract anyone in particular. Am I doing something wrong. I'm using an updated Ubuntu 20.04.
Thanks for your help.
Use:
Code:
# modprobe -r loop
# modprobe loop max_part=64
morfikov said:
Use:
Code:
# modprobe -r loop
# modprobe loop max_part=64
Click to expand...
Click to collapse
After using the first command I get
modprobe: FATAL: Module loop is builtin.
The second one doesn't display anything.
Then again when using ls -al /dev/loop3* I get
brw-rw---- 1 root disk 7, 3 d’oct. 16 10:40 /dev/loop3
Then edit the kernel cmd line in grub bootloader (or whatever ubuntu is using) and add to it loop.max_part=64 and restart the system.
morfikov said:
Then edit the kernel cmd line in grub bootloader (or whatever ubuntu is using) and add to it loop.max_part=64 and restart the system.
Click to expand...
Click to collapse
Thanks again. I'm still trying. In Ubuntu it's different and after doing it it didn't work (and somehow I broke the OS and had to reinstall it).
I think I will try to do it in a virtualised Debian system.
lotiopep said:
Thanks again. I'm still trying. In Ubuntu it's different and after doing it it didn't work (and somehow I broke the OS and had to reinstall it).
I think I will try to do it in a virtualised Debian system.
Click to expand...
Click to collapse
Finally it worked! Thanks!