How long does an LGUP Dump take to complete?
I did one last night. It said 30 minutes.
3.5 hours later it finished with a timeout error.
PS. Never mess with your phone after midnight!
yes, sometimes timeout error
backup dump all partitions except userdata (because userdata partitions is very large 64GB or 128GB maybe longtime or timeout error)
you can backup except userdata (if for you personal data backup use lgbridge)
Related
Last week something burnt out in my Streak, it wouldn't turn on, so I needed to send it to get repaired/replaced, as a little data insurance I took a dump of the internal SD card (just using dd in Ubuntu).
Now O2 are replacing my Streak, so I'll have a new one with a different IMEI, etc, and I don't want to open this one (I only opened the other one as it was an emergency). So I'm looking for help on restoring the backup I've taken without opening the phone, and once done, leaving it in a warranty-friendly state.
Obviously the first step is going to be rooting it, but what then? Is it simply a matter of copying all the files? Just thinking that might cause conflicts due to the new IMEI.
so i've got a similar (but reciprocal) problem... i had a malformed update.zip that pooched my internal microsd's system partition and the streak won't boot at all... I have a nandroid backup and i've pulled the internal microsd to find an empty ext filesystem that mounts just fine when I plug it into a linux laptop, but there's not a clear mapping from the system.img that I have and the contents of the accidentally wiped system partition...
SO, two things would fix this....
1. someone could send me a link to their raw 'dd' image of the system partition (~200mb)
2. or, I can keep figuring out how to use 'dd' with the system.img that I have to get the same results as the 'flash_image' tool...
would someone be so kind as to speed me along on this by giving me their system partition dump (1) or quickening my learning curve on (2) so that I can restore with the flash_image formatted nandroid dump of a working system partition???
Please, please....
Well, for those who were wondering (since fastboot resizing is not implemented yet), the procedures to resize your internal partitions are the exact same as HTC Dream with customMTD..
Just follow directions from the original idea/poster (Firerat and lbcoder): http://forum.xda-developers.com/showthread.php?t=717874
I have tested it on my rhod400 and it works, just be sure that you have the correct sizes.. if it is too large, you will be wasting valuable internal space that could be used for /data, and too small, your phone won't boot..
There is practically no chance of bricking your phone as you can always do a task29 and re-flash LK and recovery and as a final note, remember keep /cache greater than 30 mb so corruption will be last likely..
I recently had some disruptive partition troubles. I don't know how they started (must've been a bad flash, or a flash which didn't finish seeing as though i was experimenting with the leaked roms) but basically, my /cache, /system, /data, and /emmc partitions were all corrupted.
Fixing the /emmc, /cache and /system partitions was quite easy. I booted up into fastboot mode, flashed an ADB enabled recovery (the one in the Atrix Development forum works fine) and downloaded ADB.
I booted up into recovery, and in CMD i went into adb shell and used "parted /dev/block/mmcblk0p18" to get into the emmc partition, "rm 1" to remove the corrupted partition and "mkpartfs" to make a new partition as ext2, start 0, end 11.5GB (or something like that) and let it finish. Then i went into Mounts and Storage in CWM and formatted emmc. Did the same for /cache (mmcblk0p15) and /system (mmcblk0p12).
So far so good, my random reboots were fixed and my deadly FC of all apps was gone. But not for long.
I noticed after about 24 hours of normal use, i would start FC everything and multiple reboots + clearing caches (including dalvik) would fix it temporarily. This was a headache as messaging, phone and whatsapp would all crash and not recover.
I chalked this down to the /data partition (also known as /userdata, which houses the dalvik cache). I must be hitting a corrupt part of it during my daily use which messed my device up (once i hit the corrupt part, i could not do ANYTHING with the device, including just checking a partition. I would ALWAYS have to reboot at least twice to even read the partition).
I tried the same method as before (mmcblk0p16 for userdata partition) but i couldn't do it. It would always fail at around 90% and say i/o error and needed a few reboots. If i made a fat32 partition, i couldn't format over it with CWM (error near the end). Same with any kind of partition. This was the partition which couldn't be fixed...
So i decided to go all out. I knew i never flashed OTA 2.3.4 (Gingerbread), so i downloaded the Gingerbread SBF from a quick google search, despite all the warnings (i also THINK you CAN flash this SBF even though you were on OTA 2.3.4, just NOT ANYTHING LOWER SUCH AS FROYO). I booted into RSD mode and hoped for the best. Flashing went fine, but i was in a bootloop (due to data partition). Tried clearing with the stock android recovery and i would get i/o errors even though it said successfully wiped.
It was here when i got angry.
I flashed the ADB enabled recovery via fastboot and booted into it. Went into adb and parted again (first i inspected emmc partition which was mmcblk0p18). Did "print" and it said couldn't find label or something (which meant no partition table was found). ALL my partitions were missing this partition table.
So i created one.
"mklabel msdos" for emmc partition, then mkpartfs to make a primary partition, ext2, start 0, end 11.5GB" (or something like that) and let it happen.
For cache partition, i did "mklabel loop" then mkpartfs ext2, etc etc, with data i did "mklabel loop" and made a partition, same with system.
Then i tried wiping them via CWM. SUCCESS! I formatted them 5 times each just to be sure and sure enough, they were working fine now. I flashed a new ROM (couldn't risk my backup partitions having a corrupt sector or something in them) and heavily used it for a few hours. Downloaded many apps and games, did loads of texting and test calls.
No reboots. No FC, no problems for 24 hours. Hope it stays this way.
I posted this in hopes that others would find a solution with this rare problem. My data partition was the killer, no matter what, i couldn't fix it without flashing sbf. Remember, don't flash froyo sbf, only gingerbread (just to be safe).
When doing a factory reset some partitions are wiped from all their data.
How is the wipe done?
Are all flash blocks belonging to these partitions erased, or are only references cleared, meaning data could be recovered as long as not overwritten?
I'd say with some professional grade software it could be restored. Before Android 4.3 you'd have better luck as TRIM isn't built in. 4.3+ it is.
It's about a Samsung Galaxy S3 on Android 4.1.2 so Trim shouldn't be an issue unless Samsung implemented it themselves.
Though, after running two seemingly serious recovery programs (Wondershare and Remo Recover) in raw ("deep") inspection mode I don't find any of the lost 8GB of files. The recovery programs do find the files that were newly created during the factory reset so the deep inspection seems to work (I gave them a raw 11.5GB image of the data partition extracted using dd if=/dev/block/mmcblk0p16 ... so they still had to work for it).
So it looks like this is not only about lost references but lost data is at least not making it out to the dd:ed image.
This could either be because all flash blocks were actually erased during the factory reset, or it could be because unreferenced block data is not making it out through the eMMC subsystem. It would be interesting to be able to read the raw contents / erase status of the MMC flash storage like can be done with nanddump for MTD flash storage.
Anybody knows of such a tool for MMC?
Or (returning to the original question), do the above findings in fact show that a full erase has been performed? (meaning data is irrevocably lost)
In the end I traced the source code to see what is actually done at factory reset. The short story is that the device boots into recovery mode and erases volumes /cache and /data. On my device with MMC storage this means recreating the ext4 filesystem with a wipe parameter set to true. The wipe parameter will cause an ioctl(BLKSECDISCARD) on the whole block region, which will erase all blocks. Thus data is irrevocably lost.
According to this discussion http://forum.xda-developers.com/showthread.php?t=1644364&page=42 this behaviour was new from Android 4.0, so in earlier versions data may be recoverable.
Wouldn't that mean factory reset would take a lot longer?
mikewse said:
In the end I traced the source code to see what is actually done at factory reset. The short story is that the device boots into recovery mode and erases volumes /cache and /data. On my device with MMC storage this means recreating the ext4 filesystem with a wipe parameter set to true. The wipe parameter will cause an ioctl(BLKSECDISCARD) on the whole block region, which will erase all blocks. Thus data is irrevocably lost.
According to this discussion http://forum.xda-developers.com/showthread.php?t=1644364&page=42 this behaviour was new from Android 4.0, so in earlier versions data may be recoverable.
Click to expand...
Click to collapse
I'm know expert but if that was the case wouldn't a factory reset take a lot longer?
From what I read BLKSECDISCAED "Discard is voluntary. The device might ignore it silently. Also what you read back from the discarded blocks might not be zeroes — you might read back stale data or random data" from https://rwmj.wordpress.com/tag/kernel/
Doesn't that mean that if the factory reset was fast the the underlying block devices must have opted not to write all zeros so there would be stale data. Again I'm no expert.
Block erase is a native operation on flash memory. It doesn't have to iterate over bytes and "write zeroes" as you suggest and thus is very quick.
The rest of your suggestions are already answered in my previous post. If you have an Android 4.0+ device with internal MMC storage (most do), and your distribution is using the default Android MMC driver (most do), then the factory reset BLKSECDISCARD will cause a native block erase on the whole /cache and /data volumes. Check the Android source code yourself if you don't believe it.
Back in the day I had my phone encrypted with data as a ext4 partition, I switched to using f2fs for a long time.
Now that I've tried to go back to using data as a ext4 partition while booting android asks for a invalid decryption password
using a really old pin number (I've had it encrypted several times since then using f2fs with different pin numbers) from the first
time I encrypted my partition while it was ext4.
Now when ever I wipe my data partition and try and use it as ext4 while booting android asks for a decryption pin which I can enter
but then complains that the filesystem it is trying to decrypt is corrupt.
I've tried doing a data format in twrp but it automatically formats it f2fs which doesn't solve the problem since
the problem only shows up while data is formated ext4.
I've tried every piece of wisdom I can find on the internet.
factory reset,
formatting all partitions,
dd front and back of userdata and then make_ext4 on userdata,
twrp format data,
recovery --wipe_data --set_encrypted_filesystem=off (from within twrp with the partition formated ext4),
format f2fs then boot up and reset and format ext4,
etc.
How do I give data the ultimate clean slate for being formatted ext4?
Or where is the remnant of the old encryption info stored from the first time I encrypted my phone?
I can format my data partition f2fs but frankly I was a little stunned when I saw the kind of overhead that filesystem has,
its space using overhead is way more then I want to have in a filesystem, or any filesystem I've ever seen.
Also is the problem not what I think it is?
Faced the same behaviour on my xt1524. Would be interesting to know if there is a solution for this
Is there a way to generate a new encryption from within the recovery?
Since it won't boot with data formatted as ext4.
Formatting it ext4 and then putting a new valid encryption on it?
From what I've found it, if the UI to unlock the partition on boot had a cancel button the system would boot as normal.
Unfortunately there is no cancel button on the unlock encrypted partition screen on our device. =/
Tried flashing a different recovery and using it wiping tools on data.
official twrp-3.0.2-0-surnia.img.
mkfs-f2fs -t 0 /dev/block/mmcblk0p44
process ended with ERROR:255
Unable to wipe Data.
Unable to format to remove encryption.
Also data wiping on TWRP is defaulting to trying to format data as F2FS which isn't even the default,
and while the partition has been switched to ext4.
I'd like to fastboot erase userdata and then fastboot format userdata.
But its giving me this error message.
fastboot format userdata
(bootloader) has-slot:userdata: not found
Formatting is not supported for file system with type 'raw'.
I've already done a lot of looking around on this issue, I'm normally not worried about this but
formatting internal system partitions that I don't understand how its different from a standard
desktop computers layout does worry me.
Should I be doing a full wipe and format everything to stock and then back to a custom rom?
God I wish this was a desktop computer right now, wipe the hard drive and reinstall the operating system,
there is something to be said for being simple and straight forward.
WTB cellular modem support in standard operating systems, and handheld devices that
can run standard operating systems.
I'd ditch this overcomplicated vendor locked sht so fast and never look back.
Following this guide to setup a new system encryption with rom in one go from the start with data as ext4 to see if I can bypass it this way.
But I'm getting a cannot find libraries error running cryptfs format command from adb shell or twrp terminal. b(>.<)d
http://android.stackexchange.com/questions/33398/cannot-factory-reset-after-encrypting
All this because someone thought it would be a great idea to take off the cancel button on data decryption
during boot.
This is why god invented beer and soaking you're brain in alcohol.
Damn been at this thing all day and still no luck.
Can I smoke the whole userdata partition with DD without bricking the phone?
In fact what can I effectively zero on a android phone without bricking it?
Am I miss reading this problem? Is the new inbuilt ext4 encryption (ext4 filesystem now has built in encryption support on newer kernels) support assumed to be on?
Never mind not as solved as I thought, But I just found another way to have my partition set to F2FS with letting me know. (^.^)
God this illustrates why formatting utilities that take shortcuts and 'ghetto erase' stuff are bad.
*Edited*
Default filesystem from the factory was F2FS (I have a bad memory : ) looks like it doesn't support putting data on Ext4.
Editing this post because I did a lot of post updates on what I was trouble shooting, but that might have
pissed people off because it does 'bump' the thread.
Sigh I'm throwing in the towel and formatting F2FS and moving on, F2FS is a one way door one which you never get back to ext4 from. > : (
Or ext4 formatting utilities suck balls and don't do their jobs.
Format all partitions to f2fs reboot to recovery again and format system and cache to ext4 now make a factory reset and reboot.