Related
So far I have tested redbend_ua for backup purposes, and got the bml7 and bml8 partitions backed up, and tested just restoring the bml8 partition with the clockwork recovery that is being tested on the epic. The utility did write the image / partition correctly (afaik) and rebooted the phone upon completion. The phone booted correctly to android, but then upon another reboot to test recovery, it just boot loops, even a normal boot and trying to get to the downloader mode.
This utility seems to work and do what it was meant to, but i would not use this tool without knowledge of what you are doing. On that note, i will not post a link to the tool, just as a safeguard, for now at least.
it is known to work on bml7 (the kernel partition).
for the last few fays ive been trying to gather information regarding flashing an entire rom (all the partitions resides in an odin update file) using redbend_ua only, but i couldn't get a clear understanding of what todo with the two cache.rfs & dbdata.rfs files (each located on both the PDA and the CSC files). also, repartitioning the disk is also needed when flashing a new rom, so i need to recognize the new partition table layout (which i assume resides in the .pit file).
as for now, its only a lot of assumptions for me. they only confirmation i could get was from here: hxxp://forum.xda-developers.com/wiki/index.php?title=Samsung_Galaxy_S
z4ziggy said:
it is known to work on bml7 (the kernel partition).
for the last few fays ive been trying to gather information regarding flashing an entire rom (all the partitions resides in an odin update file) using redbend_ua only, but i couldn't get a clear understanding of what todo with the two cache.rfs & dbdata.rfs files (each located on both the PDA and the CSC files). also, repartitioning the disk is also needed when flashing a new rom, so i need to recognize the new partition table layout (which i assume resides in the .pit file).
as for now, its only a lot of assumptions for me. they only confirmation i could get was from here: hxxp://forum.xda-developers.com/wiki/index.php?title=Samsung_Galaxy_S
Click to expand...
Click to collapse
Both cache and dbdata can largely be ignored; I actually had to nuke my /dbdata partition earlier due to something I did. It gets rebuilt on boot, it's just a SQLite store for the applications and on most Android phones resides within /data. No idea why Samsung felt it necessary to separate this partition.
if this is so, and both cache.rfs & dbdata.rfs can be ignored, then updating an entire rom using redbend_ua from within update.zip is possible (right now the project-voodoo is using the redbend_ua method to flash kernel only from within update.zip file, but the idea is the same).
i think we need to get some more confirmation before actually testing this because failure on flashing the rom will break the phone... and no one wants to have that
z4ziggy said:
if this is so, and both cache.rfs & dbdata.rfs can be ignored, then updating an entire rom using redbend_ua from within update.zip is possible (right now the project-voodoo is using the redbend_ua method to flash kernel only from within update.zip file, but the idea is the same).
i think we need to get some more confirmation before actually testing this because failure on flashing the rom will break the phone... and no one wants to have that
Click to expand...
Click to collapse
I did some more testing and can confirm that cache and dbdata can both be empty on boot.
this is excellent news!
i will work later today on a template for update.zip using redbend_ua and post here for reference.
also, a thought came to mind - what is the difference between redbend_ua and dd? if all redbend_ua does is dumping data from/to a partition, then it is simply a dd replacement. isn't it?
z4ziggy said:
this is excellent news!
i will work later today on a template for update.zip using redbend_ua and post here for reference.
also, a thought came to mind - what is the difference between redbend_ua and dd? if all redbend_ua does is dumping data from/to a partition, then it is simply a dd replacement. isn't it?
Click to expand...
Click to collapse
If you currently have redbend_ua on your device, could i get you to dump /dev/block/BML7 to /sdcard/recovery.bin and upload it / link it? i need it
fallingup said:
If you currently have redbend_ua on your device, could i get you to dump /dev/block/BML7 to /sdcard/recovery.bin and upload it / link it? i need it
Click to expand...
Click to collapse
Yeah.. I could've used that yesterday too.. I ended up swapping out my device this morning.
Sounds like some progress is being made. Very good to hear confirmation on cache and dbdata
i actually got it working now, after my brick anyways. Now i need to find the verizon dump not a USC dump
fallingup said:
i actually got it working now, after my brick anyways. Now i need to find the verizon dump not a USC dump
Click to expand...
Click to collapse
Glad to hear it.. I was getting seg-faults trying to mount /system .
Is there a way to Backup and Restore Original Shipped Firmware? Is we have Norton Ghost for Android then it will be good...
The purpose is to claim the phone for warranty, after flashed with customized firmware. The phone's hardware might go fault.
Well as a previous sgs user I know that the best way is to have root on ur device then u can access cwm to create a complete image (backup) of ur current os.
I don't know if there is a better way of doing so
Cheers
Sent from my GT-I9100 using Tapatalk
A lot of branded roms are posted in the Branded rom post in dev section .
jje
For an own backup, exactely as you bought the phone, here's what I did:
- flash an insecure kernel (stock kernels are available for all FWs, so restoring original stock kernel is easy)
- apply root
- dump all important partitions:
Code:
dd if=/dev/block/mmcblk0p1 of=/sdcard/p1-EFS.img bs=4096
dd if=/dev/block/mmcblk0p4 of=/sdcard/p4-PARAM.img bs=4096
dd if=/dev/block/mmcblk0p5 of=/sdcard/p5-KERNEL.img bs=4096
dd if=/dev/block/mmcblk0p8 of=/sdcard/p8-MODEM.img bs=4096
dd if=/dev/block/mmcblk0p9 of=/sdcard/p9-FACTORYFS.img bs=4096
dd if=/dev/block/mmcblk0p12 of=/sdcard/p12-HIDDEN.img bs=4096
As a more easy/convinient alternative you could flash a kernel with a custom recovery (like CF-Root, containing CWM recovery) and use the Nandroid backup feature from the recovery menu - but those root-kernels usually perform a few more changes on the /system partition, so I did my "initial stock backup" just using an insecure kernel and root applied.
HellcatDroid said:
For an own backup, exactely as you bought the phone, here's what I did:
- flash an insecure kernel (stock kernels are available for all FWs, so restoring original stock kernel is easy)
- apply root
- dump all important partitions:
Code:
dd if=/dev/block/mmcblk0p1 of=/sdcard/p1-EFS.img bs=4096
dd if=/dev/block/mmcblk0p4 of=/sdcard/p4-PARAM.img bs=4096
dd if=/dev/block/mmcblk0p5 of=/sdcard/p5-KERNEL.img bs=4096
dd if=/dev/block/mmcblk0p8 of=/sdcard/p8-MODEM.img bs=4096
dd if=/dev/block/mmcblk0p9 of=/sdcard/p9-FACTORYFS.img bs=4096
dd if=/dev/block/mmcblk0p12 of=/sdcard/p12-HIDDEN.img bs=4096
As a more easy/convinient alternative you could flash a kernel with a custom recovery (like CF-Root, containing CWM recovery) and use the Nandroid backup feature from the recovery menu - but those root-kernels usually perform a few more changes on the /system partition, so I did my "initial stock backup" just using an insecure kernel and root applied.
Click to expand...
Click to collapse
Thanks for the advice! I have a question regarding Nandroid and CWM. Restoring the image made with Nandroid is easy enough, but won't the carrier/Samsung detect that a custom recovery (CWM) has been installed and consider it voiding the warranty regardless of the stock ROM being on the device?
Thanks in advance.
techjunkieza said:
Restoring the image made with Nandroid is easy enough, but won't the carrier/Samsung detect that a custom recovery (CWM) has been installed and consider it voiding the warranty regardless of the stock ROM being on the device?
Click to expand...
Click to collapse
After restoring a stock backup via a custom recovery/nandroid, just flash a stock kernel afterwards with Odin as well.
That will restore kernel and the recovery back to stock too.
All that is then left from a rooting is two files and a few symlinks hidden in /system/xbin - unlikely they'll go and check that IMO.
HellcatDroid said:
After restoring a stock backup via a custom recovery/nandroid, just flash a stock kernel afterwards with Odin as well.
That will restore kernel and the recovery back to stock too.
All that is then left from a rooting is two files and a few symlinks hidden in /system/xbin - unlikely they'll go and check that IMO.
Click to expand...
Click to collapse
Thanks dude. I was wondering how it is done. I did not know that flashing a stock kernel will make the recovery mode default as well. I'm new to Android so please forgive the noob questions. Surely there should be a list of files in a thread somewhere which indicates which files are modified when rooting the phone?
So I take it by restoring the original ROM, flashing a stock kernel (if you have a custom recovery mode or root access), removing the files and symlinks and resetting the ROM counter that the phone will be "stock" again?
techjunkieza said:
Thanks dude. I was wondering how it is done. I did not know that flashing a stock kernel will make the recovery mode default as well. I'm new to Android so please forgive the noob questions.
Click to expand...
Click to collapse
He, I had to learn all this myself recently, the SGS2 is my first Android device as well
For the SGS2 the recovery mode is part of the main kernel (partition), so flashing a stock kernel replaces that as well.
AFAIK this a unique Samy thing, on the other Android devices the recovery actually resides on its own partition.
techjunkieza said:
Surely there should be a list of files in a thread somewhere which indicates which files are modified when rooting the phone?
So I take it by restoring the original ROM, flashing a stock kernel (if you have a custom recovery mode or root access), removing the files and symlinks and resetting the ROM counter that the phone will be "stock" again?
Click to expand...
Click to collapse
Depending on how you rooted it's just /system/xbin/su that gets replaced and /system/xbin/busybox that gets added.
Then all the symlinks busybox installs - not sure if busybox has an "uninstall" option to remove them, if not just dump all symlinks in /system/xbin, on stock FWs there are none in this dir.
HellcatDroid said:
He, I had to learn all this myself recently, the SGS2 is my first Android device as well
For the SGS2 the recovery mode is part of the main kernel (partition), so flashing a stock kernel replaces that as well.
AFAIK this a unique Samy thing, on the other Android devices the recovery actually resides on its own partition.
Click to expand...
Click to collapse
Thanks a lot for the advice. I see many people asking the same questions but no one really gives them answers. I'm guessing it's betterfor it to be on two different partitions in terms of coupling. For noobs, the Samsung way is easier.
HellcatDroid said:
Depending on how you rooted it's just /system/xbin/su that gets replaced and /system/xbin/busybox that gets added.
Then all the symlinks busybox installs - not sure if busybox has an "uninstall" option to remove them, if not just dump all symlinks in /system/xbin, on stock FWs there are none in this dir.
Click to expand...
Click to collapse
Great. Thanks. I would like to know what Android does on a low level in order to gain root access. I'm going to research that a bit.
Thanks very much for the info!
techjunkieza said:
I would like to know what Android does on a low level in order to gain root access. I'm going to research that a bit.
Click to expand...
Click to collapse
Well, once one knows what happens it's not that much magic that happens.
Basically, the stock su gets replaced with a custom one that actually has a way of allowing other user (IDs) to run as root, Superuser.apk is installed to maintain su's database of allowed (and disallowed) user IDs and last not least busybox is installed to gain some shell commands not available (or limited) on stock.
All that is done via an adb daemon (already) running with root perms - that's what the insecure kernels do, they simply let the adbd run with root perms (so the above things can be done).
Each app running has it's unique, own user ID it's running with, so root access/permissions can easiely be maintained that way.
I hope that was what you wanted to know
HellcatDroid said:
Well, once one knows what happens it's not that much magic that happens.
Basically, the stock su gets replaced with a custom one that actually has a way of allowing other user (IDs) to run as root, Superuser.apk is installed to maintain su's database of allowed (and disallowed) user IDs and last not least busybox is installed to gain some shell commands not available (or limited) on stock.
All that is done via an adb daemon (already) running with root perms - that's what the insecure kernels do, they simply let the adbd run with root perms (so the above things can be done).
Each app running has it's unique, own user ID it's running with, so root access/permissions can easiely be maintained that way.
I hope that was what you wanted to know
Click to expand...
Click to collapse
Basically, yes! You definitely deserve a thanks for all of this. I was looking for information of what you just described but couldn't find anything. Shot dude!
how to reset counter without the USB jig ?
You don't.
Best you can do is getting rid of the triangle by flashing a stock kernel, but to reset the counter you really need the USB jig.
Great post! I cannot find a clear answer to these questions as well:
1. What is the location of the so called "boot loader" and how to make a backup? On Intel architecture it's on the first few sectors of the disk block device.
2. What is the location of the "ODIN mode/Download mode" application and how to make a backup? I suspect it may be in some read only memory and there is nothing to backup?
3. What is the location of the partition table? How to backup?
I want to understand the real/core/linux/android way of doing these, not just blindly running arbitrary tools.
Thanks in advance.
HellcatDroid said:
You don't.
Best you can do is getting rid of the triangle by flashing a stock kernel, but to reset the counter you really need the USB jig.
Click to expand...
Click to collapse
You can try this
http://forum.xda-developers.com/showthread.php?t=1494114
I already did it on my SII running ICS 4.0.3, worked great!..., but..., read the thread and cross your fingers...
gingingingin said:
1. What is the location of the so called "boot loader" and how to make a backup? On Intel architecture it's on the first few sectors of the disk block device.
2. What is the location of the "ODIN mode/Download mode" application and how to make a backup? I suspect it may be in some read only memory and there is nothing to backup?
3. What is the location of the partition table? How to backup?
Click to expand...
Click to collapse
1, 2 and 3: they are outside of the normal partitioned space / on hidden partiions (the bootloader partition is visible in ICS though) and you should not touch them.
Backing them up is useless as when the bootloaders are corrupted/broken, you'll have no way to restore them anyways as no bootloader == no boot to run anything, hence no restoring.
One is advised to leave them alone and not touch them - usually you can't access them anyways.
2: "Download Mode" is part of the secondary bootloader (partitions /dev/block/mmcblk0p2 and mmcblk0p3).
Hence the inability to access Download Mode when the bootloaders are broken.
Does it mean that "Download Mode" can be corrupt by overwriting this secondary bootloader? What about the the primary one? Is this a sure way for "hard bricking"? I was always wondering is there a way to completely lock yourself out of SGS2, but could not get a conclusive answer in the forum. Or you can recover from any failure by having any single piece backed up?
What do update packages mean when they contain a bootloader update - is it primary or secondary bootloader, or both?
You didn't say about the location of the partition table, although it's quite often part of the updates to have a PIT file with a new layout?
And last but not least, what is the basic sequence to recover from a partition based raw backup, like the one we're discussing in the thread?
Regards,
Anton
I know this has been posted but since it was long ago and *nobody replied*, here it is:
There are no FULL rom for the 4.0US. Of course you can use the bootloaders from the international version and the factory image that has been posted here, but both don't go without issues. The only stock image we have is the kernel from package2.3.5.
So to fix those issues, I am asking if one of you with stock rom could be so kind as to post a factory.rfs file and (this is including everybody) the other files (sbl, param, boot etc)
I don't think it matters if it is rooted or not (factory.rfs), I am looking at something that is *fully* functional. I'll provide you with tutorials, just ask for it
Thank you!
I'll be happy to post it but where do I look for the files so I can post it. And fyi I am running root stock atm
Sent from my YP-G70 using xda premium
Ben456 said:
I know this has been posted but since it was long ago and *nobody replied*, here it is:
There are no FULL rom for the 4.0US. Of course you can use the bootloaders from the international version and the factory image that has been posted here, but both don't go without issues. The only stock image we have is the kernel from package2.3.5.
So to fix those issues, I am asking if one of you with stock rom could be so kind as to post a factory.rfs file and (this is including everybody) the other files (sbl, param, boot etc)
I don't think it matters if it is rooted or not (factory.rfs), I am looking at something that is *fully* functional. I'll provide you with tutorials, just ask for it
Thank you!
Click to expand...
Click to collapse
You have a US YP-G1 no? You can make a dump of your partitions to make a recovery solution!
Ok, first, I was wrong, you have to be rooted. Then, either from adb from your computer or from a terminal emulator in your device, you have to type:
dd if=/dev/block/stl9 of=/sdcard/factoryfs.rfs bs=4096
No personal data is on this backup. This file can be flashed with heimdall so you can stop there or if you have linux, you can make a tar+md5 file to flash wth odin:
tar -H ustar -c factoryfs.rfs > package_name.tar
md5sum -t package_name.tar >> package_name.tar
mv package_name.tar package_name.tar.md5
if you don't have linux, just post factoryfs.rfs and i'll make it to a tar file.
Note: There may be other ways to do a an image without being rooted, I'll check if you are not rooted.
A HUGE THANKS!!
You have a US YP-G1 no? You can make a dump of your partitions to make a recovery solution!
Click to expand...
Click to collapse
No I can't since I have flashed my device with package2.3.5.tar that was posted here some time ago, which is the only working image we have to date, but there are some issues with this. I also can't post my boot loaders since I have flashed them with the international version. They work, but I can't enter recovery mode or download mode without a jig or access to an adb shell. All those flashes were made in the process of unbricking my device.
Hi Ben,
I had made a backup of my ROM before trying to install Steve's kernel. I used the same 'dd' command you mention in your instructions. The kernel install went OK, but when I ran CWM backup, I got into a boot loop and had to restore to the package_us2.3.5.tar.md5 that's been circulated around. This was a few weeks ago.
I've tried using the steps to run tar and md5sum on two separate Linux installs using my backup and have created what appears to be a valid .tar.md5 file, according to ODIN. But when I try to flash the .tar.md5 file, it passes MD5 checksum OK, ODIN reports NAND write start, but then fails immediately and I'm left with having to reflash package_us2.3.5.tar.md5 to get it to work again. Looking at my factory.rfs binary and comparing it to the factory.rfs in package_us2.3.5.tar.md5 seems to indicate that it's mostly similar, but there are binary differences. Headers look similar though.
So I'm not sure what I've done wrong in either (a) creating the backup image, or (b) creating the .tar.md5 file, or (c) flashing the .tar.md5 file. But the net result is that it won't flash successfully. So I don't think sharing my factory.rfs as it is will help you.
Here are some tips that my help troubleshoot issues.
1. The MD5 sum part is not neccessary, you can just put the factoryfs.rfs in a tarball and flash it.
2. You can loop mount a factoryfs.rfs in linux by creating an empty dir and running "mount -o loop -t auto factoryfs.rfs empty_dir"
3. It should be possible to reverse the dd command to restore the partition. ie "dd if=/sdcard/factoryfs.rfs of=/dev/block/stl9 bs=4096" (if I were going to do this I would use adb in recovery mode and root is required )
4. If you have a CWM backup, you should be able to to pull files out of the backup if you need to restore files manually. Files should be located on external sdcard in "clockworkmod/backup/"somedatestuff"/system.rfs.tar
It seems to me that what Ben456 wrote up there should have worked. Hope this helps.
I just learned how to dump my factoryfs.rfs file. This is dumped from my brand new Samsung Galaxy Player 4.0 (YP-G1CWY/XAA) right after I opened it from the box. It should be 100% clean.
I uploaded it here. Let me know if it works.
http://www.sendspace.com/file/6fzfdg
Here is the recovery rom I just uploaded. I really hope this works.
http://www.sendspace.com/file/1y2ogi
I created a thread for it here.
Hi everyone,
I made this guide for users of a Galaxy Player 4.0 USA or INTL who want to get backups of every partition in case they completely brick their device. This will be very useful if you have somehow screwed up your partitions beyond just /system, which is what most ROMs only include. It even backs up /efs, which contains the serial numbers unique to every player and other things that even complete restore ROMs and nandroid backups don't include. It's also good to just have a backup of your partitions stored somewhere safe, because you never know when you might need them. Also, if you're reverting from CM7 (the second release or later) you will need to use this with a PIT file because CM7 uses MTD partitions. Basically, flashing this backup will allow you to completely return to how your device was before, including all your personal data and apps. Hopefully soon we'll begin to have less "bricked my player help" threads clogging up the General (and sometimes Dev) sections. Enjoy
This backup does not back up bootloaders, which can increase your chances of a hard-brick and are almost never needed. Also, this is for the YP-G1 / Player 4.0 USA or INTL only, not for 5.0 users.
Disclaimer: I am not responsible for your device if anything happens blah blah blah
*Pre-requisites*
- Rooted device or ROM
- Busybox (Most rooted ROMs have this, but you can still download Busybox Installer from the Play Store and update to the latest busybox version just to make sure)
- ADB properly set up
- Some space on your internal SD card (about 1-2 GBs should be fine)
- Player set to "USB Debugging Mode" found in Settings
Alright, let's begin. First we will need to make a dump of every partition on the device. However, dumping the PIT is not needed because Adamoutler has a thread with a master list of PITs. Open a Command Prompt (or Terminal if you're using Linux), make sure your device is connected and type:
Code:
adb remount
adb shell
su
Now, to back up EFS:
Code:
dd if=/dev/block/stl3 of=/sdcard/efs.rfs bs=4096
PARAM
Code:
dd if=/dev/block/stl6 of=/sdcard/param.lfs bs=4096
KERNEL
Code:
dd if=/dev/block/bml7 of=/sdcard/zImage bs=4096
SYSTEM
Code:
dd if=/dev/block/stl9 of=/sdcard/factoryfs.rfs bs=4096
DBDATA
Code:
dd if=/dev/block/stl10 of=/sdcard/dbdata.rfs bs=4096
CACHE
Code:
dd if=/dev/block/stl11 of=/sdcard/cache.rfs bs=4096
DATA (Optional if you want your apps)
Code:
tar -czvf /sdcard/data.tar.gz /data
You can exit out of the current window and open a new one once all the processes above are completed.
Now to pull all of the backups to your computer:
Code:
adb remount
adb pull /sdcard/efs.rfs
adb pull /sdcard/param.lfs
adb pull /sdcard/zImage
adb pull /sdcard/factoryfs.rfs
adb pull /sdcard/dbdata.rfs
adb pull /sdcard/cache.rfs
adb pull /sdcard/data.tar.gz
I recommend keeping these files in a safe place on your hard drive for when you need to use them. Feel free to delete them from your player now to save space.
How to Flash
First grab the correct PIT for your device here
For Heimdall, just load the PIT, click "Re-Partition", and select the correct files for each partition. Then click flash.
For ODIN, you have to tar the files together first.
Using Cygwin or Terminal, browse to the directory where all your backup files are. Then, type in:
Code:
tar -H ustar -c efs.rfs param.lfs zImage factoryfs.rfs dbdata.rfs cache.rfs > backup_package.tar
Now load the PIT, click "Re-Partition", and under the PDA section browse to your backup_package.tar (or whatever you named it to). Click flash.
After it is done flashing, here's how to restore your apps. Open Terminal or Command Prompt to the directory of data.tar.gz on your computer:
Code:
adb remount
adb push data.tar.gz /sdcard/
adb shell su -c "tar -zxvf /sdcard/data.tar.gz"
And you're done! If all goes well you should have completely restored your device, with a perfectly safe method and no bootloaders! I hope that this will be helpful to people.
Reserved for future use....
I did this, and i believe that AdamOutlers .pit is what messed up my device. Can you please give me a copy of your or another copy?
Tcollins412 said:
I did this, and i believe that AdamOutlers .pit is what messed up my device. Can you please give me a copy of your or another copy?
Click to expand...
Click to collapse
AdamOutler's pit is not messed up... I used it to repartition my player and it worked perfectly with the right partitions.
Sent using Tapatalk
when i tried it, it messed up my player. do you know how i could fix it?
Hey klin1344, not sure if you still watch this thread, but I was wondering if anyone has had success using heimdall 1.3.2 with the 4.0? I see it says it broke compatibility with some devices.
iJimaniac said:
Hey klin1344, not sure if you still watch this thread, but I was wondering if anyone has had success using heimdall 1.3.2 with the 4.0? I see it says it broke compatibility with some devices.
Click to expand...
Click to collapse
No problem for me
i wanted to use this method to backup my /efs (like daniel advicd me to do ) but i cant seem to do it. It says Can't open 'sdcard/efs.rfs': Read only file system
pls answer
crancpiti said:
i wanted to use this method to backup my /efs (like daniel advicd me to do ) but i cant seem to do it. It says Can't open 'sdcard/efs.rfs': Read only file system
pls answer
Click to expand...
Click to collapse
You have to be rooted to do this.
Sent from my A500 using xda app-developers app
klin1344 said:
You have to be rooted to do this.
Sent from my A500 using xda app-developers app
Click to expand...
Click to collapse
i think either i hadnt BuSY box installed(my device was rooted before) or it was bcause i connected my device to the PC / i mounted my sdcards
now i have a efs.rfs file and that should do it i hope
thanks . i have problem with heimdall to download my wifi 4 int PIt file
is there any ADB command for downloading pit file from device?
aminking2005 said:
thanks . i have problem with heimdall to download my wifi 4 int PIt file
is there any ADB command for downloading pit file from device?
Click to expand...
Click to collapse
I do remember that there is the dd command from the adb shell in order to get your pit, but it's not the recommended way to get it.
You can download the pit files right here:
http://forum.xda-developers.com/showthread.php?t=1531850
zaclimon said:
I do remember that there is the dd command from the adb shell in order to get your pit, but it's not the recommended way to get it.
You can download the pit files right here:
http://forum.xda-developers.com/showthread.php?t=1531850
Click to expand...
Click to collapse
most pit file are represented for wifi4 8GB . but mine is 16GB.
so im not sure about pit files in forum.
if i install a custom rom and it faild can i recover my yp-g1 by having above backups?
aminking2005 said:
most pit file are represented for wifi4 8GB . but mine is 16GB.
so im not sure about pit files in forum.
if i install a custom rom and it faild can i recover my yp-g1 by having above backups?
Click to expand...
Click to collapse
Sorry for the long reply time, and yeah you should be able to restore with those backups.
Envoyé de mon Nexus 4 en utilisant Tapatalk
I got an EFS.tar backup
I got Odin
I got Heimdall
I got YP-G1 stock.tar.md5
I just don't know how put it all together.
Back on GB roms, I would just wipe everything via CWM, use Odin to flash stock, and then wipe once again.
But this is ICS. Surely it's different, right?
I wrote out instructions in either the LinICS or the Nebula thread (I can't remember it was several weeks ago), also the files are in the Restore to stock thread from Zaclimon. you gonna have some issues in that your efs backup is an efs.tar instead of an efs.rfs
Oh!
I also have a cwm recovery image of stock, if that matters at all
Doesn't seem like a quick restore job either though
theplasmastorm said:
Oh!
I also have a cwm recovery image of stock, if that matters at all
Doesn't seem like a quick restore job either though
Click to expand...
Click to collapse
IT DOESN'T, when you go to LinICS or any of the CM9 ROMs your player is converted from RFS partitions to MTD ones and you HAVE TO use HEIMDALL with a PIT file to reparttion the player back to RFS as you flash the stock ROM.
Totally lost on what to do. I don't know where to begin or anything. I need someone to hold my hand step by step like a baby.
I've read the recovery thread and did some searches around the place, but I don't really understand a thing. I have a US YP-G1
Alright after some fiddling around I got back to stock but the usual blank efs issues are there. I still don't understand how to restore my efs.tar. Could someone help me please?
I also can't mount efs and have no idea what to do with the blankefs.img in the recovery thread
Okay after some more fiddling around I was able to restore my EFS. The efs bugs are still there though so I'm suspecting that the automatic backup that CM9 did is utterly useless and I lost my efs forever. Well I guess I'm going back to linaro <_<
theplasmastorm said:
Okay after some more fiddling around I was able to restore my EFS. The efs bugs are still there though so I'm suspecting that the automatic backup that CM9 did is utterly useless and I lost my efs forever. Well I guess I'm going back to linaro <_<
Click to expand...
Click to collapse
Did you have content on your efs.tar?
Yes my efs.tar has stuff in it
What I did was...
wipe data
restore stock via heimdall. add in blankefs.img in the efs spot.
flashed terra via odin
went to cwm recovery. got on adb shell
cd /efs
ls -l. nothing was in it except what blankefs did
tar -x -f /sdcard/efs.tar
ls -l. tar successfully extracted
got off adb shell and restarted the player
the efs issues still presist
so then i got on adb shell again and checked the efs folder and everything was still there
So I don't know
theplasmastorm said:
Yes my efs.tar has stuff in it
What I did was...
wipe data
restore stock via heimdall. add in blankefs.img in the efs spot.
flashed terra via odin
went to cwm recovery. got on adb shell
cd /efs
ls -l. nothing was in it except what blankefs did
tar -x -f /sdcard/efs.tar
ls -l. tar successfully extracted
got off adb shell and restarted the player
the efs issues still presist
so then i got on adb shell again and checked the efs folder and everything was still there
So I don't know
Click to expand...
Click to collapse
one thing that works, atleast the method I used to solve it, once you've copied the contents back into the EFS folder on the player, then flash the Dream Ultra ROM from CWM, then after booting the ROM up shutdown and wipe data/factory reset, then use Odin to flash the stock GB.tar through odin.
Roms at these links.
http://forum.xda-developers.com/showthread.php?t=1719685&highlight=dream+ultra
http://forum.xda-developers.com/showthread.php?t=1512331&highlight=stock+rooted+4+0
Oh snap that worked. Aroma installer to the rescue.
theplasmastorm said:
Oh snap that worked. Aroma installer to the rescue.
Click to expand...
Click to collapse
Now make a a proper EFS.rfs backup using the method described here http://forum.xda-developers.com/showthread.php?t=1632376&highlight=efs+backup that way next time you need to revert back from an ICS ROM you can flash the efs.rfs to the efs section instead of the blankefs.img and not have to go through this again.
FYI the method listed can be done on the player using terminal emulator just go into it and type su to gain superuser then type the the part for making an efs backup and your done, then copy that file to your PC.
Well when I first flashed linaro there was no mention of efs backup or anything in the topic post and that is why I got in the predicament in the first place.
And then when I watched your vid on how to flash it there was no mention of efs backup either.
Well all that is in the past. I know better now.
I already made a backup as soon as I got back to stock
theplasmastorm said:
Well when I first flashed linaro there was no mention of efs backup or anything in the topic post and that is why I got in the predicament in the first place.
And then when I watched your vid on how to flash it there was no mention of efs backup either.
Well all that is in the past. I know better now.
I already made a backup as soon as I got back to stock
Click to expand...
Click to collapse
Sorry, it was in my older videos that I did, forgot to mention it in that one, guess I'm not the only one to goof up if it's not in the OP either.
theplasmastorm said:
Yes my efs.tar has stuff in it
What I did was...
wipe data
restore stock via heimdall. add in blankefs.img in the efs spot.
flashed terra via odin
went to cwm recovery. got on adb shell
cd /efs
ls -l. nothing was in it except what blankefs did
tar -x -f /sdcard/efs.tar
ls -l. tar successfully extracted
got off adb shell and restarted the player
the efs issues still presist
so then i got on adb shell again and checked the efs folder and everything was still there
So I don't know
Click to expand...
Click to collapse
Whenever I try to do these steps before flashing dream ultra rom it tells me "tar not found" I have a efs.tar on my sd card for certain.