This thread will be a compilation of findings and references along the way as we make attempts to modify and hack our Nook Tablets. If you would like to add anything, please post it and I can compile into the OP posts. This is beyond rooting and bootloader bypass/bootstrap (for the most part), there are separate threads for those.
This will be for posting what certain files are found to do or involve, and which files to STAY AWAY FROM to prevent bootloops and forced recovery, and other findings that will help others to avoid issues or save time by learning from our discoveries. As we get CWM and the ability to replace entire ROMs, some of those risks will go away.
We are the Pioneers of the Nook Tablet, lets document our findings to keep track of them and to help others who will be making the NT an even better tablet.
Again, this is not to duplicate what is going on in the Dev Progress threads, but to help compile all of the scattered findings to compliment those threads.
System Recovery (Factory Restore):
There has been some question about the factory restore as to whether it just wipes data or does a complete /system restore as well.
There are two different modes of restore that can kick in, if you bork the system files or need to force a complete restore, you can do so.
Data only wipe:
The fastest and best way to get to this is to hold down the "n" button while powering on the tablet. This will wipe your side loaded or installed apps as well. If something gets messed up on your tablet and is forced into a recovery, this is the default recovery that will kick in after about 8 failed boot attempts.
Full system restore:
If your tablet continues to have failed boots after initiating the data wipe restore, it will force into a complete restore without even asking. First it will do the data wipe like normal, followed by a restore of factory software. Once done, your Nook Tablet will be restored to the way it was the first time you powered it on.
I have been able to force the full restore by powering off repeatedly during the data wipe. Once you see the restore kick in without giving the usual prompt to hit "n" or home to continue, just let it run and the complete restore will run.
Partition Files and Information:
"Factory" partition, this is where the factory restore pulls the files from (ROM, etc)
/dev/block/platform/mmci-omap-hs.1/mmcblk0p7 or /dev/block/platform/mmci-omap-hs.1/by-name/factory
DOWNLOAD ZIP FILE OF FACTORY PARTITION FILES HERE - There appears to be a Recovery image and boot image in this as well
I did try to alter the factory.zip rom file by not disturbing it's signature. I then mounted the factory partition and added the modded factory.zip
I forced a full restore but about 1/4 of the way into the factory software restore it aborted and told me to reboot. It did not install the modded rom files. So it checks beyond just the signature on the rom file, maybe md5 checks.
Working on other partitions and will add those as done....
Recovery Partition
/dev/block/platform/mmci-omap-hs.1/mmcblk0p3 or /dev/block/platform/mmci-omap-hs.1/by-name/recovery
Boot Partition
/dev/block/platform/mmci-omap-hs.1/mmcblk0p4 or /dev/block/platform/mmci-omap-hs.1/by-name/boot
Reserved.....
In trying to add new library files to /system/lib, I will get FC errors when testing changes and in reviewing the logcat, it is as if the files does not exist. The error will say the lib file is not found. Permissions are correct, and a full reboot has been done as well. I ran into a similar problem where an FC error was looking for a java class, and when the APK was decompiled, it was right there in the location it was suppoed to be.
I found a file, /system/manifest that has a list of the libs and framework files, along with a long code. Does anyone know what this is? It appears the ROM has a manifest of what is supposed to be in place, and if it falls outside of that it gets ignored. Editing this manaifest could be a critical piece at this point in doing some serious modifications.
There are also a couple of manifest files in the root (/) path as well.
Anyone familiar with this and can expand further?
Here is a few lines from the Manifest files.
/system/lib/libstagefright.so:99208dff1b94c6955e72abdfc8bc70fc020a113a
/system/lib/libsqlite_jni.so:df4a43e08d9a2c02aaed47ccbecba6be3d4b3e33
/system/lib/libsmapi.so:6c4761d3bbc3c18fa11d1d59ea7ae295d0874752
/system/lib/libsensorservice.so:654b3d705b4220441d819f337eef201d979a0003
/system/framework/com.bn.service.devicemanager.jar:144dfb6833f4ddf52bdd4f5cabf163aaf4724252
/system/framework/com.bn.app.deviceinfo.jar:9256951bbfe5126e54dade8d5ef3878ae0a05f20
/system/framework/services.jar:51c05355e9165b5683f0b40106e70fdfd7be41aa
/system/framework/pm.jar:0bc6fe41c40dc6205bac73443d0c771d9fa718e5
/system/framework/framework.jar:0f5b44a0c264061c5ba6efb9f04112fe752dea38
/system/lib/libstdc++.so:bd50887222d9a03ed683bcc94525b32b1405c0a7
I'd guess that's the MD5 sum of each file. Perhaps file integrity is confirmed by calculatung the current sum and comparing it to the stored value in this file. Any files you update in your image, consider calculating the new checksum and putting it here next to the right file?
Sent from my BNTV250 using Tapatalk
t-r-i-c-k said:
I'd guess that's the MD5 sum of each file. Perhaps file integrity is confirmed by calculatung the current sum and comparing it to the stored value in this file. Any files you update in your image, consider calculating the new checksum and putting it here next to the right file?
Sent from my BNTV250 using Tapatalk
Click to expand...
Click to collapse
That is what I was thinking, and hoping but wanted to confirm. Thanks !
Related
I recently tried a new ROM and made a Rom Manager recovery restore file prior to changing. Things didn't work out as well as I had hoped and when attempting to restore, it fails at the checking MD5 sum process.
Any way to work around this? I really would like to restore to the previous ROM without starting over.
Anybody? I am not quite sure how the restore file can be created on this phone and then not pass verification?
Any ideas or am I stuck starting over?
sandiegopaneraiguy said:
Anybody? I am not quite sure how the restore file can be created on this phone and then not pass verification?
Any ideas or am I stuck starting over?
Click to expand...
Click to collapse
depending on the type of file format used to backup, the restoring could be done manually but a changed md5sum generally means the files are not the same as the original. this could result in corruption and generally it isnt recommended to restore corrupted files as you run the risk of nothing working.
if you're still wanting to proceeding with attempting to restore files which are different than the original and could be corrupted, off the top of my head, you can probably dd the .img files back and untar the .tar files back.
i would suggest starting over and perhaps copying the backup files over to your desktop instead of only leaving on the sdard. this should help ensure at least one of the copies maintains their integrity.
hope that helps!
You can boot into recovery, and run nandroid via adb shell command line, no md5 checksum file needed. Now if the image is bad, you of course get bad results, but if the checksum is just hosed for some reason, it will work fine.
Put the .win files for the partitions you want to restore in /sdacrd
then issue the command "tar xvpf /sdcard/data.win" or "tar xvpf /sdcard/system.win" from the adb shell while in /data or /system respectively. .win files are what TWRP creates for backups.
I had this happen with TWRP 1.01 or 1.02 once on a good backup that passed the checksum tests when I backed it up.
I was testing the reliability of the TWRP package's nandroid and first one failed.
Once I moved to the newer version, I've not had that issue.
Hi guys,
I'm at my wit's end with this one.
I have a 1.2GB data.img file created with Clockworkmod Recovery backup. I believe it was one of the older versions, in the 3.x.x.x range. When this was created I had plenty of space available on the SD and the MD5 was created successfully.
I have had no luck restoring this with any version of CWM. Restoring simply results in a system that won't boot; I am presented with either a black screen or a boot-loop. I have since learned that this is because my backup has too many files. Apparently CWM is hard-coded to restore a maximum of 10,000 files and will not restore anything past that point. I found a thread where someone had edited the source code to increase this limit to 50,000, compiled and flashed it, then successfully restored their backup. Aside from the initial editing, I would not know where to start to do this for my phone (SGS2)
Furthermore, I cannot extract the contents with unyaffs.exe for Windows. When I try to do this, it extracts a small portion of files (around 170MB), then exits with the following report :
Code:
read image file
: Bad file descriptor
read image file
: Bad file descriptor
I have since learnt that this is due to NTFS limitations with the length of pathnames. 'No problem' I think, and decide to install Ubuntu 11.10 so that I can use the linux version of unyaffs to extract the full thing without these limitations.
After a bit of messing around, I successfully compile the unyaffs source (I'm no expert in these matters). I then attempt to extract data.img and after a short while processing I get another error! :
Code:
Segmentation fault
Out of interest, I checked how much data had been extracted and got 9,544 items, totalling 204.2 MB. So I'm roughly 1 GB down.
Please help, you might not believe the hours I've spent to get to this stage and I still can't get all of my data back. I need my contacts (Google didn't back them up apparently), messages, app data and anything else I can get my hands on. If there's a better utility I can use for extracting, or perhaps a modified version of CWM I can flash onto my SGS2 so that I can restore the backup properly, I'm all ears.
Look forward to any responses and thanks in advance.
Just to update, I have now tried ext2explore on Windows 7, as well as yaffs2 explorer on Android. Both will open the .img file but display a blank window.
Exploit: Modify System Files w/o Flashing Boot Partition​
Background
One of the serious inconveniences of the stock Nook Tablet firmware is the inability to copy & paste in text fields. I hacked together a solution (see this thread) that requires replacing the file /system/framework/framework.jar. However, when I did replaced that file, my tablet no longer boots.
It turns out that there are two files in the ramdisk that specify (what I assume to be) checksums of system files: /manifest00 and /manifest01. B&N has added a "feature" to the /init process that checks if system files on disk match the checksums in /manifest00 and /manifest01, and will crash the system if it finds a discrepancy, resulting in a boot loop.
/manifest00 and /manifest01 cover essentially all of the system files that one would be interested to modify, including my /system/framework/framework.jar. It is possible to get around this by using a ramdisk that has an empty /manifest00 and /manifest01, because /init only checks files with a checksum listed in /manifest00 and /manifest01, and will happily ignore everything else. But this would require me to flash a new boot partition, and since the NT has a locked bootloader, I would have to use bauwks's 2nduboot or Cyanoboot.
In essence, B & N is quite clever:
1. To modify system files (/system), you need to modify the boot partition (/manifest00 and /manifest01).
2. To modify the boot partition, you need to modify the boot loader.
3. The bootloader is locked.
Of course, with bauwks's 2nduboot hack, 3 is no longer an obstacle, but I would still rather not flash and damage my boot partition, having almost bricked my tablet once by doing so.
Exploit
I studied the /manifest00 and /manifest01 in the 1.4.2 ROM on my NT 8GB and compared them with /init.rc and /init.omap4430.rc, and discovered that /init.omap4430.rc starts /system/bin/uim-sysfs with root permissions at boot, but /system/bin/uim-sysfs does not actually exist. In addition, /system/bin/uim-sysfs is not in /manifest00 or /manifest01, and is thus not verified by /init.
Upon further testing, /system/bin/uim-sysfs is run after /init checks the checksums of system files, which means that /system/bin/uim-sysfs can modify /system as it wishes, with the caveat that it must restore its modifications before a reboot lest /init catches it at it.
So I placed a shell script at /system/bin/uim-sysfs that replaces /system/framework/framework.jar with my custom build, restarts the zygote process, and restores the stock /system/framework/framework.jar. I'm now able to use copy & paste on my Nook Tablet
If anyone's interested, you can check out the uim-sysfs script I'm using for the copy & paste hack in the linked file in this thread.
Interesting and very useful for stock users. Well done!
~ Veronica
Stop it, BN. Stop it.
/init.omap4430.rc starts /system/bin/uim-sysfs with root permissions at boot, but /system/bin/uim-sysfs does not actually exist!
Click to expand...
Click to collapse
Interesting find. What is BN thinking with this manifest checking stuff. BN, just stop it. Seriously. Stop it.
Stop it, BN.
FWIW, uim-sysfs is the no-longer-used userspace side of the "shared transport" wireless daemon stuff (the other side is called "kim" in the kernel) that's used for bluetooth, FM, and gps on the 1271... it's used in CM7/CM9 (backported from 2.6.35 to 2.6.32) for nookcolor to make bluetooth work.
BN likely just modified TI's stock init.omap3.rc and left lines like the uim service as-is. Running this non-existent file as root is kinda a "security" hole, IMO, assuming the manifest verification was supposed to be some kind of security. Remove this, there will doubtlessly be other examples of the same thing.
All that said, is this script, which is replacing system files on-the-fly any more "safe" than just replacing the boot partition in the first place? Add CyanoBoot, shift current boot.img contents 512 bytes. Done.
Nice discovery tho.
fattire said:
All that said, is this script, which is replacing system files on-the-fly any more "safe" than just replacing the boot partition in the first place? Add CyanoBoot, shift current boot.img contents 512 bytes. Done.
Click to expand...
Click to collapse
Well, the only real difference for me is what happens when you screw something up. When I screwed up /system, I could always use the "8 failed reboots" method to go back to stock /system. When I screwed up my boot partition, I almost bricked my tablet and there was no way of getting back to the factory restore interface.
In addition, it's also really, really easy for development because we'd be working with simple files, not images. For my copy & paste hack, I was editing /system/bin/uim-sysfs directly on the tablet using a text editor. Boot images are much harder to work with.
The last advantage is that it's a lot less intrusive. There's no scary flashing going on here; just drop a file in /system/bin/ and you're set.
care to share the files?
jichuan89 said:
Exploit: Modify System Files w/o Flashing Boot Partition​
Background
One of the serious inconveniences of the stock Nook Tablet firmware is the inability to copy & paste in text fields. I hacked together a solution (will post details later) that requires replacing the file /system/framework/framework.jar. However, when I did replaced that file, my tablet no longer boots.
It turns out that there are two files in the ramdisk that specify (what I assume to be) checksums of system files: /manifest00 and /manifest01. B&N has added a "feature" to the /init process that checks if system files on disk match the checksums in /manifest00 and /manifest01, and will crash the system if it finds a discrepancy, resulting in a boot loop.
/manifest00 and /manifest01 cover essentially all of the system files that one would be interested to modify, including my /system/framework/framework.jar. It is possible to get around this by using a ramdisk that has an empty /manifest00 and /manifest01, because /init only checks files with a checksum listed in /manifest00 and /manifest01, and will happily ignore everything else. But this would require me to flash a new boot partition, and since the NT has a locked bootloader, I would have to use bauwks's 2nduboot or Cyanoboot.
In essence, B & N is quite clever:
1. To modify system files (/system), you need to modify the boot partition (/manifest00 and /manifest01).
2. To modify the boot partition, you need to modify the boot loader.
3. The bootloader is locked.
Of course, with bauwks's 2nduboot hack, 3 is no longer an obstacle, but I would still rather not flash and damage my boot partition.
Exploit
I studied the /manifest00 and /manifest01 in the 1.4.2 ROM on my NT 8GB and compared them with /init.rc and /init.omap4430.rc, and discovered that /init.omap4430.rc starts /system/bin/uim-sysfs with root permissions at boot, but /system/bin/uim-sysfs does not actually exist. In addition, /system/bin/uim-sysfs is not in /manifest00 or /manifest01, and is thus not verified by /init.
Upon further testing, /system/bin/uim-sysfs is run after /init checks the checksums of system files, which means that /system/bin/uim-sysfs can modify /system as it wishes, with the caveat that it must restore its modifications before a reboot lest /init catches it at it.
So I placed a shell script at /system/bin/uim-sysfs that replaces /system/framework/framework.jar with my custom build, restarts the zygote process, and restores the stock /system/framework/framework.jar. I'm now able to use copy & paste on my Nook Tablet
Click to expand...
Click to collapse
would be nice if you can share some files
MikeCh said:
would be nice if you can share some files
Click to expand...
Click to collapse
If you're interested in copy & paste, I've now posted instructions at http://forum.xda-developers.com/showthread.php?t=1534757
jichuan89 said:
Well, the only real difference for me is what happens when you screw something up. When I screwed up /system, I could always use the "8 failed reboots" method to go back to stock /system. When I screwed up my boot partition, I almost bricked my tablet and there was no way of getting back to the factory restore interface.
Click to expand...
Click to collapse
Well, "bricking" in the classic sense of creating a permanently damaged system is a bit difficult-- you can always boot from SD card and reflash from CWM, right?
In addition, it's also really, really easy for development because we'd be working with simple files, not images. For my copy & paste hack, I was editing /system/bin/uim-sysfs directly on the tablet using a text editor. Boot images are much harder to work with.
Click to expand...
Click to collapse
do you mean for the developer or end user?
The last advantage is that it's a lot less intrusive. There's no scary flashing going on here; just drop a file in /system/bin/ and you're set.
Click to expand...
Click to collapse
but aren't you still moving framework files around "on the fly"?
Well, in any event it was a good observation that can be used for all kinds of purposes-- rooting, running background processes, etc. You could even drop a cwm recovery binary in there to instantly turn stock into cwm I bet...
fattire said:
Well, "bricking" in the classic sense of creating a permanently damaged system is a bit difficult-- you can always boot from SD card and reflash from CWM, right?
Click to expand...
Click to collapse
True.
fattire said:
do you mean for the developer or end user?
Click to expand...
Click to collapse
I guess that's personal preference more than anything else. Please disregard.
fattire said:
but aren't you still moving framework files around "on the fly"?
Click to expand...
Click to collapse
Yes - but the process is automated by the script in uim-sysfs. From the user's perspective it's just copying a file to /system/bin say using ES File Explorer, rather than burning an image to an SD card and booting from it which appears to scare/confuse a lot of people. Also they wouldn't need a computer or a card reader or a spare SD card or a USB cable or any special software on their computer.
CWM 5.8.0.9 for Huawei MediaPad
WARNING !!! DON'T FORMAT AND DON'T WIPE PARTITIONS USING THESE CWM !
I don't know how much this CWM version improves over the existing one by segler11.
However these build were more aimed at compiling and testing the new kernel sources.
I have tested compiling with both arm-eabi-4.4.0 and arm-eabi-4.4.3 with success on Ubuntu 10.04.
This is experimental, however with the new kernel sources it will just be a matter of time.
I have compiled the kernel included in this CWM recovery image but I didn't recompile the complete image.
I took as base Pyramid CWM 5.8.0.9 and I replaced the files from those found on a stock C232B005 kernel.
As the default build configuration I have used the /proc/config.gz of a C232B005 running kernel.
I have tested this CWM to be able to backup these partitions (I have not tested "restore" yet, just checked the tar archives):
boot.img - 12.582.912 (match 12Mb)
recovery.img - 16.777.216 (match 16Mb)
data.ext4.tar
cache.ext4.tar
system.ext4.tar
custom.ext4.tar
as you can see my hand tweaks to "recovery" require the name of "cust" partition to be "custom" instead but I believe this is a no issue while you backup and restore with the same CWM. Suggestions welcome.
BUGS:
data & time on archives are wrong
mount USB storage does not work
adb not enabled in recovery mode
Formats and Wipes do not work don't use them
The "busybox hwclock" applet doesn't work to set the hardware clock of our device.
The "adb shell" is not active while in CWM recovery, I don't know why and this was my objective so if you have suggestion please help.
As usual flash both "recovery" and "recovery2" partitions using "fastboot" and one of the attached CWM recovery:
Code:
fastboot flash recovery recovery-5.8.0.9-HWMOD-eabi-4.4.3.img
fastboot flash recovery2 recovery-5.8.0.9-HWMOD-eabi-4.4.3.img
fastboot reboot
WARNING !!! DON'T FORMAT AND DON'T WIPE PARTITIONS USING THESE CWM !
.:HWMOD:.
.
Reserved CWM HWMOD
This version seemed to work better for me.Tnx dude!
john9 said:
This version seemed to work better for me.Tnx dude!
Click to expand...
Click to collapse
Thank you for trying it.
Remember to absolutely avoid formatting or wiping partitions.
If you need to format/wipe do it ONLY after reinstalling the original "recovery.img" in both "recovery" and "recovery2" partitions and then reset the device from:
"Settings -> Backup and reset -> Factory reset"
ATTENTION !!! You can safely do a wipe or factory reset only after reinstalling the original recovery image.
Sorry for insisting but I don't want to create problems on users devices and I know those operations will create problems.
.:HWMOD:.
Just a note: I used your 4.4.3 version to try making a nandroid backup last night. Good news and bad news.
This morning I inspected the result using the app Nandroid Browser.
Good: Your CWM does successfully backup /data/data. The other CWM that had been posted here did not do so properly.
Bad: Your CWM also backs up the entire internal SD storage contents inside the folder /data/share. It is customary *not* to include this in a nandroid backup because a) you don't want to inflate the file size unnecessarily, and b) you don't want to overwrite the internal SD on a restore.
Idea: After you fix it, and until you manage to get ADB over USB working, maybe you could add a menu option to make a separate backup archive of internal SD to external SD. This would allow a route to save the internal storage if the device becomes unbootable and requires a data wipe.
cmstlist said:
Just a note: I used your 4.4.3 version to try making a nandroid backup last night. Good news and bad news.
This morning I inspected the result using the app Nandroid Browser.
Good: Your CWM does successfully backup /data/data. The other CWM that had been posted here did not do so properly.
Bad: Your CWM also backs up the entire internal SD storage contents inside the folder /data/share. It is customary *not* to include this in a nandroid backup because a) you don't want to inflate the file size unnecessarily, and b) you don't want to overwrite the internal SD on a restore.
Idea: After you fix it, and until you manage to get ADB over USB working, maybe you could add a menu option to make a separate backup archive of internal SD to external SD. This would allow a route to save the internal storage if the device becomes unbootable and requires a data wipe.
Click to expand...
Click to collapse
Thank you for trying it. I wanted to compile/test a kernel with new sources in a CWM.
Yes, in our device the internal memory "/mnt/sdcard" is also mapped under "/data/share".
Unfortunately I don't have the skills (yet) to build a complete recovery image from scratch,
so what I did was just compiling the kernel part of the recovery image, using the new sources.
Then I simply hex tweaked the "recovery" executable of a 5.8.0.9 Pyramid CWM (HTC Sensation).
So, in conclusion, I have no control over what is copied during the backup process of those partitions.
Though I could control which partition is processed by removing them from "fstab", but there is no gain into it.
We will have to wait somebody with the specific knowledge, or maybe I will have some time to learn once I return from holidays.
.:HWMOD:.
Today i have builded bootable CWM 5.5.0.4 from sources, so now we can adjust all what we need
after_silence said:
Today i have builded bootable CWM 5.5.0.4 from sources, so now we can adjust all what we need
Click to expand...
Click to collapse
well done
HI, can anyone share buckup from working device created by CWM.?
Thanks to all.
Hi,
Is it possible to flash update zips from this CWM recovery (like Beats Audio which is in flashable zip format)?
I don't want to use it for backup-recovery.
...and how about doing wipe cache and wipe dalvik cache?
.dredd. said:
Hi,
Is it possible to flash update zips from this CWM recovery (like Beats Audio which is in flashable zip format)?
I don't want to use it for backup-recovery.
...and how about doing wipe cache and wipe dalvik cache?
Click to expand...
Click to collapse
Haven't tried installing a ".zip" archive from CWM but it should work.
Avoid "wiping" and/or "formatting" partitions, they will be messed up.
hwmod said:
Haven't tried installing a ".zip" archive from CWM but it should work.
Avoid "wiping" and/or "formatting" partitions, they will be messed up.
Click to expand...
Click to collapse
The main reason for use of CWM would be to have the possibility of flashing update zips from CWM... but I am afraid of messing up my device... to understand: no problem if I have to reflash the rom but I would not want to cause mistake which could be repaired only by service.
fastboot is always available if something goes wrong and if you flash cwm you wont be able to install official roms because cwm will overwrite stock recovery
so i was stupid and wiped data and cache - then remembered that it said not to - how do i fix this paperweight? i tried fastbooting all the usual partitions (system, boot, userdata, cache, etc) but still nothing - i can get to fastboot but i cant flash any dload updates. any suggestions are greatly appreciated.
flash stock recovery (2 files) from zipped rom via fastboot and then you should be able to flash stock rom
flashed three different stock recoveries to recovery and recovery2 - still only get the media pad logo twice (flashed androidani intl rom before bricking) cant boot to recovery - think the partition table is screwed. is there a way to create partitions from fastboot, and if so, still would be nice to know the names of the partitions to flash as referenced in tmo stock thread.
byt3b0mb said:
flashed three different stock recoveries to recovery and recovery2 - still only get the media pad logo twice (flashed androidani intl rom before bricking) cant boot to recovery - think the partition table is screwed. is there a way to create partitions from fastboot, and if so, still would be nice to know the names of the partitions to flash as referenced in tmo stock thread.
Click to expand...
Click to collapse
The time needed to reformat and rewrite all the firmware partitions (the first time) will be between 10-15 minutes.
Be patient and give enough time to the device to execute all the needed processes.
When the device finally boot it need to completely regenerate dalvik-cache (the first time).
So try again as instructed above, rewrite "BOTH" partitions named "recovery" and "recovery2", both using the same "recovery.img" file found in the latest stock Huawei firmware.
Now extract the stock Huawei firmware archive on your PC and copy the "dload" folder on an empty formatted SDCard, then insert the SDCard in the MediaPad reboot it and wait until success or failure message.
If you wiped partitions you will have to wait more time (20-30m). It may be that after waiting a while a message about "Encryption not possible" could appear, just say no to encryption and let it reset the device.
It already happened to some of us so hope you are also able to recover your tablet.
thanks i will give it a shot - while it is rewriting partitions, should it be on the huawei logo? or should i see the android / gears turning?
byt3b0mb said:
thanks i will give it a shot - while it is rewriting partitions, should it be on the huawei logo? or should i see the android / gears turning?
Click to expand...
Click to collapse
First time restoration takes time on both moments during the 1st Huawei log and even during animation.
Trying to recover a partition that was wiped takes much longer for the OS to show the error.
When I tried wiping "data" and rebooted the device I recall I went for a long walk and when I returned the device was showing the "Encryption failure / Reset" message (about half an hour later).
So I can only suggest that when you retry you wait at least that amount of time (30 min.) with charger connected, whatever happens leave it alone until it display or ask you do something. Let me know if it works when you have tried.
Download links do not work for me. Can you upload in mediafire please?
Hi folks,
The adventures continue. I've been trying to restore my Safestrap backup for ages, and no matter what I try, I continue to get
Code:
Error restoring /data!
at the conclusion of the restoration. I can restore via Fastboot to stock, but no matter what I can't get my full backup restored successfully. Generally unless I restore to stock factory the system ends up in a kind of broken state where there are apps that are installed but have file size 0B, and don't run.
The final error in the recovery log is
Code:
tar: seek failure: Value too large for defined data type
Error while restoring /data!
Of course the first thing I thought was that the backup was corrupt, but it extracts completely fine with plain ole' tar on my Linux laptop.
I have:
Updated Safestrap to 2.11 for Droid Razr
Updated BusyBox via Stericson's BusyBox updater app from Google Play
Attempted restore again after those two steps
Wiped /data and restored to Factory via both Fastboot flash through Matt's Utility and Motorola Recovery menu
Attempted to split the data.ext3.tar file into two, one with my apps directory, one without (since that way, both files are below 2 GB). The first file, the one with the apps directory removed, restored fine. The second one, consisting of just the apps directory, did not (with the same error). It might be a moot point anyway since I think Safestrap formats the partitions before restoring, so it wouldn't "recombine" them anyway.
Bought the XDADevelopers Android Hackers' Toolkit from the bookstore. Haven't finished reading it yet, but hopefully it will give me some ideas.
So I can get access to what my apps directory should look like (I can extract it locally here on my laptop) but I can't get Safestrap to extract it all at once to the correct partition on my phone.
I'm currently almost out of ideas. It seems this is a common problem and that newer versions of CWM Recovery split the tars so to avoid the file size limit imposed by BusyBox, if I'm interpreting what I've read correctly. This might be the case with the newer Safestrap but it doesn't help my old backup, unless I can split it in a way that Safestrap expects and will deal with (is this possible?)
Given that I have the actual files that should be on the phone, and that my phone is rooted, would it make sense to simply attempt to extract the apps-only tar overtop of the apps directory? Would the files be locked when the phone was on normally?
Could this still be a free space issue? Currently I'm showing 1.7 GB free after the latest failed restore. One would think if it was a disk space issue, it would show 0 B free, right? To test this, would it hurt to delete the files in the safestrap directory (i.e. orig and safe, containing a data.ext3.tar in each of about 2.2 GB) since Safestrap is currently in unsafe mode right now anyway?
Also, is there anything I can do to help here? I know C and C++; while I'm not a low-level hardware hacker by any means (I'm a professional web developer) this issue has bugged me enough that I want to try to fix it. I know that Safestrap is on Github but I'm not really sure where to start.
Do you have any other suggestions for ways to get my Safestrap-generated nandroid backup of my data correctly restored to my phone?
Please let me know if I did something wrong in asking this question; I tried to do as much research as I could beforehand. If I haven't done enough, I would appreciate a point in the right direction.
Or maybe the post was too long and drawn out, so I'll try to compact it here.
My phone won't restore a successful Safestrap backup that is 2.2 GB in size. The backup (a tar file) extracts fine on my PC. I'm getting "error restoring /data!". It seems to be the same issue others have had with restoring a CWM backup over 2 GB.
Would it make sense to simply attempt to extract the apps-only tar overtop of the apps directory, or would the files be locked when the phone was on normally?
Could this still be a free space issue?
Do you have any other suggestions for ways to get my Safestrap-generated nandroid backup of my data correctly restored to my phone?
Edit: Could the tar be converted to an image file to be flashed to the data partition with Fastboot?
Final bump. Anyone? Anyone? Bueler?
Is it safe to just grab a root shell through ADB, push the tar containing the apps, and extract over top of my phone's existing apps directory, while the phone is running? Are there risks associated with this?
Edit: Alternatively, is there a native Android GNU tar binary available anywhere, or instructions for cross-compiling one, since this seems to be a problem with BusyBox?
...Answering my own question, apparently yes. I'm going to try replacing the tar symlink to BusyBox with this native version and try again tonight, I'll let you know how it goes.
I had the same problem and the tar from your link worked for me for a 4GB tar extract. Thanks for your tip!