Related
So, I bought a g2x ,Rooted with a flashed rom (not sure which) .
Would have random reboots one day battery died and it never woke up after.
I used to be able to get into cwm (v. 3.0.5 flashed) Now it just hangs at the LG logo and does nothing. I tried calling the guy who sold it to me to get some info of Recoverys and roms he doesn't answer.
1. A custom Recovery was flashed, but don't know which and how it was flashed.
2. A Custom rom was flashed but don't know which.
3. It will connect to my win7 pc and shows up in Device manager. (Battery out, vol up + vol dwn)
4. NVflash finds it, but never succeeds.
5. One-click finds it, but never succeeds.
Ive tried using NVflash, followed the instructions : Battery out, hold down vol up + dwn, plug in usb, run command. It loads Fastboot, then thedownload of the bootloader is sucessfull but just hangs there never send the img file. Then it just gives NV error. One-click does the same no matter what recovery I try to flash, ext or int.
When I was able to get into Recovery I would give error about not eing able to mount cache and such, even when I tried to go back to a stock rom. Now I'm not bale to get into any Recovery, Vol dwn + Pwr. Only LG logo.
What I think I need is to Repair the internal Memory and partitions. From ADB, only problem is I can't turn the phone one to get my pc to recognize and install the adb drivers.
Any help would be great!
NO HELP ?
Hi, I'm pretty new myself to the g2x device. However, I'm able to install recovery and flashed to a different custom ROM before. so I have some experience in this area. When reading your post, I'm not fully understanding what you're saying. Are you able to turn the phone on at all? Or you stuck at the LG logo?
Are the battery able to charge with the phone off? Just to be sure we have to isolate the battery to determine whether it is the problem. Is there anyone around you that have the g2x. The problem I think is that your phone is unable to install the driver into your computer. You need to use someone device to install the NV driver. Once you install the NV driver.
Attempt to turn it on first. If it still won't boot. Then we can try to reflash the Recovery to the 4.02. If you able to do all this and get to the recovery screen, then I think we are set... The goal is to get to the recovery screen.
I hope this help...But anything more technical, we have to wait for others to help..Best of luck
I'm not exactly new either, I've used NVflash at least once before to flash a recovery onto a Streak. I've rooted and Flashed recovery to a few MYtouch4g's.
But this G2X is just proving to be a problem.
To answer some of your questions.
When The phone does power on, it just hangs at the LG screen.
I tested the voltage of the battery with a meter and shows 3.8-3.7 volts of power, and is able to light a tiny light bulb. I also checked the charging port and power is running to the prongs which would touch the battery to charge. I did put the battery into another G2X and it worked. I no longer have access to the other G2X so do further testing.
I was and can still get the PC to recognize the phone via battery out, Vol up + Vol dwn & connect usb wire. PC recognizes beeps and phone shows up in device manager as "Android usb recovery mode" or something simular. So the APX driver is installed
When I try to NVflash (while keeping vol up + vol dwn) CWM 4 or Stock recovery its the same result, Loads bootloader and just hangs until it spits out an NV error (i'll post the result). (S/W Upgrade screen does show up on phone)
I cannot boot into any recovery via holding Vol dwn + Pwr.
Ieven tried the One-click recovery, no go, errors out.
I did find a Zip file with a recovery which is supposed to load the phone the factory supposed to format partitions and load original files. Uses NVflash, its just a bat file which runs the NVflash commands. found here. But this loads some files then when it gets to the formating partition it errors out. i'll post what it does. link > android.modaco.com/content/lg-optimus-2x-2x-modaco-com/335474/25-mar-nvflash-stock-rom-release-v10b-dated-1300166062-15-03-2011/
Code:
C:\Users\Alan\Desktop\recover>.\nvflash.exe --bct E1108_Hynix_512MB_H8TBR00U0MLR
-0DM_300MHz_final_emmc_x8.bct --setbct --odmdata 0xC8000 --configfile android_fa
stboot_emmc_full.cfg --create --bl fastboot.bin --go
Nvflash started
rcm version 0X20001
System Information:
chip name: unknown
chip id: 0x20 major: 1 minor: 3
chip sku: 0xf
chip uid: 0x02804081423f7117
macrovision: disabled
hdcp: enabled
sbk burned: false
dk burned: false
boot device: emmc
operating mode: 3
device config strap: 0
device config fuse: 17
sdram config strap: 0
sending file: E1108_Hynix_512MB_H8TBR00U0MLR-0DM_300MHz_final_emmc_x8.bct
- 4080/4080 bytes sent
E1108_Hynix_512MB_H8TBR00U0MLR-0DM_300MHz_final_emmc_x8.bct sent successfully
odm data: 0xc8000
downloading bootloader -- load address: 0x108000 entry point: 0x108000
sending file: fastboot.bin
/ 1024992/1024992 bytes sent
fastboot.bin sent successfully
waiting for bootloader to initialize
bootloader downloaded successfully
setting device: 2 3
creating partition: BCT
creating partition: PT
creating partition: EBT
creating partition: MBR
creating partition: APP
creating partition: CAC
creating partition: MSC
creating partition: EB1
creating partition: LNX
creating partition: EB2
creating partition: DRM
creating partition: EB3
creating partition: SOS
creating partition: EB4
creating partition: UDA
creating partition: EB5
creating partition: UDB
Formatting partition 2 BCT please wait.. |
I think what needs to be done is to fix the internal partition I think they got damaged somehow?
Wow, you doing really good. Unfortunately, I think this problem is out of my league. The worst you can do is call T-mobile. Tell them your device is defective and they can send you a new one. But since your phone is rooted, if they found out then we can run into some problem. Most likely they will charge you 99 dollars for damaging the phone. I hope you'll find a way to fix your device because the G2x rock...
PS: I think the previous might have flash a lg optimus 2x Rom, which could explain why the phone is damage...If your phone is in fact a Optimus 2x and we flash the wrong recovery, that could also explain why we can't install the recovery...
android.modaco.com/content/lg-optimus-2x-2x-modaco-com/335474/25-mar-nvflash-stock-rom-release-v10b-dated-1300166062-15-03-2011/
WARNING: This can destory your internalSD card partitions. If it's not broke don't fix it!
ALL COMMANDS ARE IN RED
I am not responsible for any damage you do to your phone.
I did this same thing to my phone... I was still able to get into recovery though. You can repair the internal partitions through ADB if you can still get into recovery.
Steps to recreate partitions.
Boot into recovery
from your PC open cmd prompt
change to your ADB directory
run adb shell
fdisk -H 1 /dev/block/mmcblk0
once in the fdisk of ../mmcblk0 you might as well delete all the partitions if you believe that they are corrupted
d
1
repeat for partition 2-8
one all of your partitions are gone you now have a blank internal SD and will need to execute the following to restore all the proper partition sizes
Partition 1
n
p
1
First Cylinder start 129
First Cylinder stop 55168
We will repeat this for partitions 2 and 3
Partition 2
n
p
2
Start 55169
Stop 63360
Partition 3
n
p
3
Start 63361
Stop 63616
On to partition 4 which will be extended (this is the last partion you will choose primary or extended)
Partition 4
n
e
4
Start 63617
Stop 975424
Now onto partition 4-8 which are automatically selected as logicall partions (no option is given)
Partition 5
n
Start 63681
Stop 64704
Partition 6
n
Start 64769
Stop 65088
Partition 7
n
Start 65153
Stop 261760
Partition 8
n
Start 261825
Stop 975424
Once you have done this the partitions are ready to be written to the internalSD
I would recommend choosing the command p to verify that all of your start and stop blocks are correct.
From this point you have the option to either quit without saving changes or to write the partition table itself. Once you are sure that you have entered all of your partitions correctly you can choose the command w
At this point you have recreated all the partitions on your InternalSD card. If you have a nandroid backup at this point you should be able to restore it without a problem once you copy it over to the internal or external (depending on which CWR you are running).
If I've forgotten any steps please feel free to comment and include them.
Thanks to TeamWhiskey for helping me resolve this issue when I had it...
casper200519 said:
WARNING: This can destory your internalSD card partitions. If it's not broke don't fix it!
ALL COMMANDS ARE IN RED
I am not responsible for any damage you do to your phone.
I did this same thing to my phone... I was still able to get into recovery though. You can repair the internal partitions through ADB if you can still get into recovery.
Steps to recreate partitions.
Boot into recovery
from your PC open cmd prompt
change to your ADB directory
run adb shell
fdisk -h 1 /dev/block/mmcblk0
once in the fdisk of ../mmcblk0 you might as well delete all the partitions if you believe that they are corrupted
d
1
repeat for partition 2-8
one all of your partitions are gone you now have a blank internal SD and will need to execute the following to restore all the proper partition sizes
Partition 1
n
p
1
First Cylinder start 129
First Cylinder stop 55168
We will repeat this for partitions 2 and 3
Partition 2
n
p
2
Start 55169
Stop 63360
Partition 3
n
p
3
Start 63361
Stop 63616
On to partition 4 which will be extended (this is the last partion you will choose primary or extended)
Partition 4
n
e
4
Start 63617
Stop 975424
Now onto partition 4-8 which are automatically selected as logicall partions (no option is given)
Partition 5
n
Start 63681
Stop 64704
Partition 6
n
Start 64769
Stop 65088
Partition 7
n
Start 65153
Stop 261760
Partition 8
n
Start 261825
Stop 975424
Once you have done this the partitions are ready to be written to the internalSD
I would recommend choosing the command p to verify that all of your start and stop blocks are correct.
From this point you have the option to either quit without saving changes or to write the partition table itself. Once you are sure that you have entered all of your partitions correctly you can choose the command w
At this point you have recreated all the partitions on your InternalSD card. If you have a nandroid backup at this point you should be able to restore it without a problem once you copy it over to the internal or external (depending on which CWR you are running).
If I've forgotten any steps please feel free to comment and include them.
Thanks to TeamWhiskey for helping me resolve this issue when I had it...
Click to expand...
Click to collapse
Can you help me with a video easier to work !!!!!!!! hopefully my phone will return to stock
I love you. Thanks for putting up the instructions.
chulun9999 said:
Can you help me with a video easier to work !!!!!!!! hopefully my phone will return to stock
Click to expand...
Click to collapse
I will try to get some video on it when I get time... If you get stuck on any of the instructions just ask and I'll check back often to try to help
casper200519 said:
I will try to get some video on it when I get time... If you get stuck on any of the instructions just ask and I'll check back often to try to help
Click to expand...
Click to collapse
you can guide me. I really do not understand to be able to work with it. I do not know where to start
downloading bootloader -- load address: 0x108000 entry point: 0x108000
sending file: fastboot.bin
/ 1024992/1024992 bytes sent
fastboot.bin sent successfully
waiting for bootloader to initialize
bootloader downloaded successfully
failed executing command 14 NvError 0x120000
command failure: partition download failed
chulun9999 said:
you can guide me. I really do not understand to be able to work with it. I do not know where to start
downloading bootloader -- load address: 0x108000 entry point: 0x108000
sending file: fastboot.bin
/ 1024992/1024992 bytes sent
fastboot.bin sent successfully
waiting for bootloader to initialize
bootloader downloaded successfully
failed executing command 14 NvError 0x120000
command failure: partition download failed
Click to expand...
Click to collapse
The how-to that I wrote is on recreating the partitions... I understand your error is with allowing nvflash to create them. Are you still trying to put an O2x image on a G2x?
casper200519 said:
The how-to that I wrote is on recreating the partitions... I understand your error is with allowing nvflash to create them. Are you still trying to put an O2x image on a G2x?
Click to expand...
Click to collapse
yes . i try to put an O2x image on a G2x . and now it happen this status . how do i repair my mistake .please help me
I am experiencing the same issue. Any luck resolving this????
I have CWM as my recovery system... So I cannot use ADB -- it won't connect.
Any ideas???
crosses fingers and prays
hope someone figures this out soon, i have been in many weird spots but none more than this g2x, it always worked fine and one day after reinstalling the cm7 nightly it never booted, just the LG boot screen and no more! windows even recognizes the phone but as fastboot only, NV flash says it worked but i never get further than LG screen, CLK Recovery wont pop up! hope someone solves this cus i love this phone!!
tylermauthe said:
I am experiencing the same issue. Any luck resolving this????
I have CWM as my recovery system... So I cannot use ADB -- it won't connect.
Any ideas???
Click to expand...
Click to collapse
ADB works in cwr recovery.if you find my other post labeled [REF]Repair internal SD in the dev area it has some q&a from others
Sent from my LG-P999 using XDA Premium App
Sorry for reviving this post!
This has been so helpful!
My phone was not able to boot in normal mode, but only in CWM! Thanks KAsp3rd!
need help with lg p999
hey am new here but am having the same problem and i need som help because i accedentaly used usde an nvflash tool for a lg p990 on my lg p999 and now am having problems with my baseband, sim,audio and my ime # is gone but the phone works but those are the problems that am having. so if any 1 help please assist
after using factory rest in the system settings menu,I found my device not starting.then I went into the cwm,i found that i could not mount /data or do anything else to the data folder.it looks like the /data folder has gone...
then i went to the fastboot menu,and did the following commands:
E:\A701\CWM-recovery_A70x>fastboot flash data recovery.img
sending 'data' (6144 KB)...
OKAY [ 2.169s]
writing 'data'...
FAILED (remote: (00030003))
finished. total time: 3.261s
E:\A701\CWM-recovery_A70x>fastboot flash userdata recovery.img
sending 'userdata' (6144 KB)...
OKAY [ 2.036s]
writing 'userdata'...
OKAY [ 1.712s]
finished. total time: 4.356s
E:\A701\CWM-recovery_A70x>fastboot flash system recovery.img
sending system' (6144 KB)...
OKAY [ 2.535s]
writing 'system'...
OKAY [ 1.902s]
finished. total time: 4.437s
then i went to the cwm menu,the /system folder could not be mounting,either.
I wonder if there are raw image,just like system.img or data img could do solve the problem.I reflashed the bootloader but it's still not mailfunctioning.do i have to flash the pit partition file or sth else?
and i see this in the nexus 7 forum:
recovery.fstab
/sdcard vfat /dev/block/sda1
/system ext4 /dev/block/platform/sdhci-tegra.3/by-name/APP
/cache ext4 /dev/block/platform/sdhci-tegra.3/by-name/CAC
/data ext4 /dev/block/platform/sdhci-tegra.3/by-name/UDA length=-32768
/misc emmc /dev/block/platform/sdhci-tegra.3/by-name/MSC
/boot emmc /dev/block/platform/sdhci-tegra.3/by-name/LNX
/recovery emmc /dev/block/platform/sdhci-tegra.3/by-name/SOS
/staging emmc /dev/block/platform/sdhci-tegra.3/by-name/USP
fstab.grouper
# Android fstab file.
#<src> <mnt_point> <type> <mnt_flags> <fs_mgr_flags>
# The filesystem that contains the filesystem checker binary (typically /system) cannot
# specify MF_CHECK, and must come before any filesystems that do specify MF_CHECK
/dev/block/platform/sdhci-tegra.3/by-name/APP /system ext4 ro wait
/dev/block/platform/sdhci-tegra.3/by-name/CAC /cache ext4 noatime,nosuid,nodev,nomblk_io_submit,errors=panic wait
/dev/block/platform/sdhci-tegra.3/by-name/UDA /data ext4 noatime,nosuid,nodev,nomblk_io_submit,errors=panic wait,encryptable=/dev/block/platform/sdhci-tegra.3/by-name/MDA
at here:http://forum.xda-developers.com/showthread.php?t=1742416
and I don't now how and where to flash this....
at least,we know one thing....do not use factory rest...
goddamn cwm
lsnc said:
after using factory rest in the system settings menu,I found my device not starting.then I went into the cwm,i found that i could not mount /data or do anything else to the data folder.it looks like the /data folder has gone...
then i went to the fastboot menu,and did the following commands:
E:\A701\CWM-recovery_A70x>fastboot flash data recovery.img
sending 'data' (6144 KB)...
OKAY [ 2.169s]
writing 'data'...
FAILED (remote: (00030003))
finished. total time: 3.261s
E:\A701\CWM-recovery_A70x>fastboot flash userdata recovery.img
sending 'userdata' (6144 KB)...
OKAY [ 2.036s]
writing 'userdata'...
OKAY [ 1.712s]
finished. total time: 4.356s
E:\A701\CWM-recovery_A70x>fastboot flash system recovery.img
sending system' (6144 KB)...
OKAY [ 2.535s]
writing 'system'...
OKAY [ 1.902s]
finished. total time: 4.437s
then i went to the cwm menu,the /system folder could not be mounting,either.
I wonder if there are raw image,just like system.img or data img could do solve the problem.I reflashed the bootloader but it's still not mailfunctioning.do i have to flash the pit partition file or sth else?
and i see this in the nexus 7 forum:
recovery.fstab
/sdcard vfat /dev/block/sda1
/system ext4 /dev/block/platform/sdhci-tegra.3/by-name/APP
/cache ext4 /dev/block/platform/sdhci-tegra.3/by-name/CAC
/data ext4 /dev/block/platform/sdhci-tegra.3/by-name/UDA length=-32768
/misc emmc /dev/block/platform/sdhci-tegra.3/by-name/MSC
/boot emmc /dev/block/platform/sdhci-tegra.3/by-name/LNX
/recovery emmc /dev/block/platform/sdhci-tegra.3/by-name/SOS
/staging emmc /dev/block/platform/sdhci-tegra.3/by-name/USP
fstab.grouper
# Android fstab file.
#<src> <mnt_point> <type> <mnt_flags> <fs_mgr_flags>
# The filesystem that contains the filesystem checker binary (typically /system) cannot
# specify MF_CHECK, and must come before any filesystems that do specify MF_CHECK
/dev/block/platform/sdhci-tegra.3/by-name/APP /system ext4 ro wait
/dev/block/platform/sdhci-tegra.3/by-name/CAC /cache ext4 noatime,nosuid,nodev,nomblk_io_submit,errors=panic wait
/dev/block/platform/sdhci-tegra.3/by-name/UDA /data ext4 noatime,nosuid,nodev,nomblk_io_submit,errors=panic wait,encryptable=/dev/block/platform/sdhci-tegra.3/by-name/MDA
at here:http://forum.xda-developers.com/showthread.php?t=1742416
and I don't now how and where to flash this....
at least,we know one thing....do not use factory rest...
Click to expand...
Click to collapse
Now I know,it's because of the goddamn CWM in the development ,that's a dangerous thing and not perfect at all,could do harm to our devices.
lsnc said:
Now I know,it's because of the *^*%*(% CWM in the development ,that's a dangerous thing and not perfect at all,could do harm to our devices.
Click to expand...
Click to collapse
Yes, this is the price we pay when we mess with things. Although, if the Dev "doesn't" own the specific device, it would be better to at least have "1" laboratory rat to test the recovery before putting it public.
Would have avoided a lot of bricked tabs.
Oh well, Acer Service Center.....
Hopefully, I can get with one of the recovery devs from the 500 forums, and maybe (if and when I get my tab back) we can work on a functioning recovery. Would also be nice to have a better bootloader with full fastboot from the start.
MD
been a laboratory rat...
Moscow Desire said:
Yes, this is the price we pay when we mess with things. Although, if the Dev "doesn't" own the specific device, it would be better to at least have "1" laboratory rat to test the recovery before putting it public.
Would have avoided a lot of bricked tabs.
Oh well, Acer Service Center.....
Hopefully, I can get with one of the recovery devs from the 500 forums, and maybe (if and when I get my tab back) we can work on a functioning recovery. Would also be nice to have a better bootloader with full fastboot from the start.
MD
Click to expand...
Click to collapse
but there is a proble that i'm in china,the device is not for sale publicly...seems,i can only wait for the nvflash or wait for the openning sales in china...
Moscow Desire said:
Yes, this is the price we pay when we mess with things. Although, if the Dev "doesn't" own the specific device, it would be better to at least have "1" laboratory rat to test the recovery before putting it public.
Would have avoided a lot of bricked tabs.
Oh well, Acer Service Center.....
Hopefully, I can get with one of the recovery devs from the 500 forums, and maybe (if and when I get my tab back) we can work on a functioning recovery. Would also be nice to have a better bootloader with full fastboot from the start.
MD
Click to expand...
Click to collapse
If you find a stock recovery for the A700, let me know! I flashed the CWMR on my A700, but I haven't used CWMR on it (thankfully), and I want to get the stock recovery back to make sure no issues pop up. Thanks in advance!
1
californiarailroader said:
If you find a stock recovery for the A700, let me know! I flashed the CWMR on my A700, but I haven't used CWMR on it (thankfully), and I want to get the stock recovery back to make sure no issues pop up. Thanks in advance!
Click to expand...
Click to collapse
edit this file in the update package updater-script
delete the first and the third comand.then bring it back to replace the orginal file of the update package.
then reflash.
and everything goes back.u need to reroot.
Can those with A700 units, especially ones that partially bricked, run the following from a command line?
Code:
cat /sys/class/block/mmcblk0/device/name
And then
Code:
cat /sys/class/block/mmcblk0/device/cid
Or run Chainfire's "Got Brickbug" app from the Galaxy Note forums?
http://forum.xda-developers.com/showthread.php?t=1693704
These symptoms sound a lot like "Samsung Superbrick". While this isn't a Samsung device, Samsung ships their flash chips to many companies other than Samsung. For example, about half of Kindle Fires manufactured have defective M8G2FA chips.
Hi
Here are the results
Code:
[email protected]:/ $ cat /sys/class/block/mmcblk0/device/name
MBG8FA
[email protected]:/ $ cat /sys/class/block/mmcblk0/device/cid
1501004d424738464121bd1b68e9ae00
Gotbrickbug says the chip is unknonwn.
Sent from my A700 using xda premium
laloutre said:
Hi
Here are the results
Code:
[email protected]:/ $ cat /sys/class/block/mmcblk0/device/name
MBG8FA
[email protected]:/ $ cat /sys/class/block/mmcblk0/device/cid
1501004d424738464121bd1b68e9ae00
Gotbrickbug says the chip is unknonwn.
Sent from my A700 using xda premium
Click to expand...
Click to collapse
That is an unknown chip, HOWEVER it is a Samsung chip. Is your device a 32GB by any chance?
M8G2FA = 8GB
MAG4FA = 16GB
MBG8FA = ???
fwrev is 0x21, which is also unknown - but most likely all A700 units have the same fwrev. Not all may have Samsung chips.
Bad news: Anyone who suffered damage is hosed. This damage is unrepairable.
Good news: It is possible to protect against damage. If recovery is built with BOARD_SUPPRESS_EMMC_WIPE it will be safe, although you need to be careful about update-zips in firmware releases that can still do damage even with a safe recovery.
It is also possible to render a kernel safe if you have kernel source code by removing MMC_CAP_ERASE from the relevant driver in drivers/mmc/host/ - For example on Samsung Exynos based phones it is mshci.c, on Qualcomm-based ones it is msm_sdcc.c - not sure about these Acers.
Yep it is a 32G
I forgot to mention i am not affected as I didn't wipe or flash anything after installing CWM.
I guess i'm gonna stick on this stock rom for a while.
By the way thanks for looking at this issues I've been reading the great work you did for the Galaxy Note !
Sent from my A700 using xda premium
Thanks for this important info. I also have 32G in my tab. It is running on stock 1.055 (EMEA_DE), has CWM 6.0.1.0 from pawitp and is not rooted yet. I also didn't mess around so my tab is not bricked. I followed (and read ) your link to Chainfire's Brickbug (didn't install it) and also followed his link about the backround and used the cat-command from there (without su). Got this result
Code:
[email protected]:/sys/class/block/mmcblk0/device $ cat name hwrev fwrev manfid oemi
d date type serial cid
MBG8FA
0x0
0x0
0x000015
0x0100
10/2011
MMC
0x180690d8
1501004d424738464121180690d8ae00
As you can see, same chip but different cid and fwrev. My A700 was manufactured in June 2012 (may be of interest).
lsnc used the older ZeroNull CWM for erasing which is why he had the issues with factory resets, the new CWM 6.0.1.0 doesn't have these problems !
The next builds of CM and recovery will no longer send the problematic erase command to the mmc and should be more safe.
pawitp said:
The next builds of CM and recovery will no longer send the problematic erase command to the mmc and should be more safe.
Click to expand...
Click to collapse
hi, can u plz help build the new CWM for A510, there're also many bricked A510 need to rescue:crying:
jokerzlh said:
hi, can u plz help build the new CWM for A510, there're also many bricked A510 need to rescue:crying:
Click to expand...
Click to collapse
Unfortunately, it's intended to prevent new devices from being bricked, not rescue old devices. And I want to focus on the devices that I do have, some 510 developer can take the kernel/device source I've posted and compile a version for A510.
pawitp said:
Unfortunately, it's intended to prevent new devices from being bricked, not rescue old devices. And I want to focus on the devices that I do have, some 510 developer can take the kernel/device source I've posted and compile a version for A510.
Click to expand...
Click to collapse
I have no way, so i install the new A700 CWM 6.01.1, luckily that i can enter it, but the screen become very abnormal.
I chose to install update.zip, then i saw a abnormal picture and no progress bar. I wait for 10 minutes but it only hang there.
Then i chose to factory reset, 'cos i can't c any progress text, so i didn't know what happened, but it back to munue after a while.
If the factory reset success, my bricked A510 maybe work! ( the 5.8.5 CWM kill my tab when i use the factory reset )
so i reboot my device but it also hang in 'iconia tab' Logo :crying:
thx anyway!
I'd like to note that the first time I did a factory reset from CWM update 1, my Wi-Fi went all wonky. It would scan fine, then would act as if there was little to no signal upon trying to connect. I ended up flashing to EMEA_CUS1 to get everything going again.
Just wanted to let people know.
Sent from my A700 using XDA Premium HD app
jokerzlh said:
I have no way, so i install the new A700 CWM 6.01.1, luckily that i can enter it, but the screen become very abnormal.
I chose to install update.zip, then i saw a abnormal picture and no progress bar. I wait for 10 minutes but it only hang there.
Then i chose to factory reset, 'cos i can't c any progress text, so i didn't know what happened, but it back to munue after a while.
If the factory reset success, my bricked A510 maybe work! ( the 5.8.5 CWM kill my tab when i use the factory reset )
so i reboot my device but it also hang in 'iconia tab' Logo :crying:
thx anyway!
Click to expand...
Click to collapse
never a good idea to flash a recovery from a different device...
Last night I started to run e2fsck on my /data partition to do a bit of investigation to see if had any corruption (again)
Anyway I unmounted /data in TWRP and went to the terminal and issued the following command:
e2fsck -fvyD /dev/block/mmcblk0p8
12 hours later and it was still running mainly reporting "Clone multiply-claimed blocks? Yes" Yes is because I have y flag turned on to answer yes to all questions.
So I killed it as it has never run this long before (previously 3 hours max).
I then formatted data which I thought would make it unnecessary and ran the command again after unmounting data and it is doing the same thing.....
Why?
Code:
.
.
.
(
inode
#
869248
. mod time
Sat Aug 25 18:23:27 2012
)
Clone multiply-claimed blocks? Yes
It appears to be doing this for many (if not all) inodes
Over and over.
This makes it seem like my /data partition is very corrupted and also Aug 25 is when I bought the device in 2012 so it has gone right back to the start.
I suspect it is somehow related to turning data journaling off whilst testing hunds kernels.
What is the definitive command to ensure data journaling is on please?
sbdags said:
I then formatted data which I thought would make it unnecessary and ran the command again after unmounting data and it is doing the same thing.....
Click to expand...
Click to collapse
That's strange - after formatting a partition, e2fsck must run in seconds and without errors, and it should definitely not bring up anything related to the old data. How did you format it?
_that said:
That's strange - after formatting a partition, e2fsck must run in seconds and without errors, and it should definitely not bring up anything related to the old data. How did you format it?
Click to expand...
Click to collapse
I formatted it using the big format data button in TWRP but yes I agree it doesn't appear to have done what would call a format? Maybe the equivalent of a quick format? How do I properly format the mmcblk0p8 partition?
If I just issue e2fsck -n /dev/block/mmcblk0p8 it comes back with clean. It is only when I force a scan that it finds all these errors.
Just reformatted and run again and it is dong the same again. ??
Btw what is the command to turn data journaling on? Or once formatted does journaling reset itself?
sbdags said:
Just reformatted and run again and it is dong the same again. ??
Btw what is the command to turn data journaling on? Or once formatted does journaling reset itself?
Click to expand...
Click to collapse
Can you find the following line in your recovery log? This would be the command that TWRP used to format.
Code:
make_ext4fs command:
Normally, formatting ext4 with default options enables the journal.
_that said:
Can you find the following line in your recovery log? This would be the command that TWRP used to format.
Code:
make_ext4fs command:
Normally, formatting ext4 with default options enables the journal.
Click to expand...
Click to collapse
It reports the following:
Code:
make_ext4fs -l -16384 -a /data /dev/block/mmcblk0p8
sbdags said:
It reports the following:
Code:
make_ext4fs -l -16384 -a /data /dev/block/mmcblk0p8
Click to expand...
Click to collapse
Looks plausible. And look what I've found:
http://sourceforge.net/p/e2fsprogs/bugs/292/
You could try running the make_ext4fs command manually with the "-w" (wipe) option added - if I understand the code correctly, that should issue discard requests for all blocks, similar to fstrim.
sbdags said:
I formatted it using the big format data button in TWRP but yes I agree it doesn't appear to have done what would call a format? Maybe the equivalent of a quick format? How do I properly format the mmcblk0p8 partition?
If I just issue e2fsck -n /dev/block/mmcblk0p8 it comes back with clean. It is only when I force a scan that it finds all these errors.
Just reformatted and run again and it is dong the same again. ??
Btw what is the command to turn data journaling on? Or once formatted does journaling reset itself?
Click to expand...
Click to collapse
I mentioned this during the fiasco we had in the cromi thread awhile back, but I think it got lost in the rush of comments, let me know if you get it fixed, would love to be able to complete a check.
faustus1005 said:
I mentioned this during the fiasco we had in the cromi thread awhile back, but I think it got lost in the rush of comments, let me know if you get it fixed, would love to be able to complete a check.
Click to expand...
Click to collapse
Yeah something is not quite right with running fsck on the TF700. Oddly on my prime it runs without issue. I wonder if Asus has changed the way inodes are mapped. I know Samsung do this. I wonder if contributes to any lag as well?
_that said:
Looks plausible. And look what I've found:
http://sourceforge.net/p/e2fsprogs/bugs/292/
You could try running the make_ext4fs command manually with the "-w" (wipe) option added - if I understand the code correctly, that should issue discard requests for all blocks, similar to fstrim.
Click to expand...
Click to collapse
Let me do another backup and try the -w command as well. It's quite frustrating as I wonder if being able to run fsck correctly would help solve some of the lag issues we see.
_that said:
Looks plausible. And look what I've found:
http://sourceforge.net/p/e2fsprogs/bugs/292/
You could try running the make_ext4fs command manually with the "-w" (wipe) option added - if I understand the code correctly, that should issue discard requests for all blocks, similar to fstrim.
Click to expand...
Click to collapse
Adding the -w command fixed it (I think) e2fsk now completes in about a minute with no errors
Problem is now when I check if data journaling is on with a mount command there is no indication that it is - how to turn it off?
This is the command issued that turned it off I believe it's the "-O" that turns the journaling off:
Code:
run_program("/tmp/tune2fs.ext4", "-O", "^has_journal", "-c", "1", "-i", "1d", "-m", "0", "-o", "^journal_data_writeback", "/dev/block/mmcblk0p8");
is it as easy as issuing the same command without the "-O", "^has_journal" to get it back on?
OK I found some info looks like I need to issue this command in the installer?
Code:
run_program("/tmp/tune2fs.ext4", "-O", "+has_journal", "-c", "5", "-i", "5d", "-m", "0", "-o", "^journal_data_ordered", "/dev/block/mmcblk0p8");
I'll try that out now
Thanks for all the help @_that - I'm slowly getting there I think. :good:
sbdags said:
Last night I started to run e2fsck on my /data partition to do a bit of investigation to see if had any corruption (again)
Anyway I unmounted /data in TWRP and went to the terminal and issued the following command:
e2fsck -fvyD /dev/block/mmcblk0p8
12 hours later and it was still running mainly reporting "Clone multiply-claimed blocks? Yes" Yes is because I have y flag turned on to answer yes to all questions.
So I killed it as it has never run this long before (previously 3 hours max).
I then formatted data which I thought would make it unnecessary and ran the command again after unmounting data and it is doing the same thing.....
Why?
Code:
.
.
.
(
inode
#
869248
. mod time
Sat Aug 25 18:23:27 2012
)
Clone multiply-claimed blocks? Yes
It appears to be doing this for many (if not all) inodes
Over and over.
This makes it seem like my /data partition is very corrupted and also Aug 25 is when I bought the device in 2012 so it has gone right back to the start.
I suspect it is somehow related to turning data journaling off whilst testing hunds kernels.
What is the definitive command to ensure data journaling is on please?
Click to expand...
Click to collapse
You can try this.
tune2fs -l /dev/block/mmcblk0p8
You should see your system mounting has a "has_journal".
If it is not there, then your journal is off.
To turn it on.
tune2fs -O +has_journal /dev/block/mmcblk0p8
You should use the data_write for your journal to improve performance.
If you do a clean installation for your rom, the e2fsck should run less than a minute if you have a minimal apps installed. However, if you restore a nandroid backup for your system, it will take forever even though you don't have any app. I don't know why it does that with the nandroid backup..
I think that when you use e2fsck with a nandroid restore from your backup, the e2fsck is trying to convert your ext4 system to ext3 system.. It is just my guess. Maybe you and _that can figure why it does that.. Good luck...:fingers-crossed:
LetMeKnow said:
You can try this.
tune2fs -l /dev/block/mmcblk0p8
You should see your system mounting has a "has_journal".
If it is not there, then your journal is off.
To turn it on.
tune2fs -O +has_journal /dev/block/mmcblk0p8
You should use the data_write for your journal to improve performance.
If you do a clean installation for your rom, the e2fsck should run less than a minute if you have a minimal apps installed. However, if you restore a nandroid backup for your system, it will take forever even though you don't have any app. I don't know why it does that with the nandroid backup..
I think that when you use e2fsck with a nandroid restore from your backup, the e2fsck is trying to convert your ext4 system to ext3 system.. It is just my guess. Maybe you and _that can figure why it does that.. Good luck...:fingers-crossed:
Click to expand...
Click to collapse
Interesting, however, restored a nandroid and reran e2fsck and it finished in 30 secs with no errors Installed my ROM and ran it again and same again so it seems my problems are resolved for now
Thanks for the tips on data journaling.
BTW can you reup or send me the latest ET please - ready and confident to test it again now
sbdags said:
Interesting, however, restored a nandroid and reran e2fsck and it finished in 30 secs with no errors Installed my ROM and ran it again and same again so it seems my problems are resolved for now
Thanks for the tips on data journaling.
BTW can you reup or send me the latest ET please - ready and confident to test it again now
Click to expand...
Click to collapse
Haha, I found out that when I restore a good backup from nandroid and have more than 50% of problem with e2fsck.
I am still on a business trip. Let see if my thumb drive has the latest ET. Otherwise, I have it on my personal laptop at home. I will let you know in bit..
Hey guys i have an n8010. When samsung released the leak fw for the 8000 I installed it. It worked pretty well. A few months ago an official update came for the 8010 but im using the 8000 bootloader i cannot install it Is that any solution for recovering the old bootloader? I've tried a lot of thing to solve it but none of them was successful. I've tried this method: http://forum.xda-developers.com/galaxy-note-10-1/help/recovering-n8010-leaked-locked-n8000-t2802516 and a lot of custom roms but i always have a same crash after using it for about 2 days. It says System UIDs Inconsistent, UIDs on the system are inconsistent you need to wipe your data partition or your device will be unstable. And if i press "I'm felling lucky" every app crashes touchwiz ,android everything.
Please help me to solve my problem
kataik95 said:
Hey guys i have an n8010. When samsung released the leak fw for the 8000 I installed it. It worked pretty well. A few months ago an official update came for the 8010 but im using the 8000 bootloader i cannot install it Is that any solution for recovering the old bootloader? I've tried a lot of thing to solve it but none of them was successful. I've tried this method: http://forum.xda-developers.com/galaxy-note-10-1/help/recovering-n8010-leaked-locked-n8000-t2802516 and a lot of custom roms but i always have a same crash after using it for about 2 days. It says System UIDs Inconsistent, UIDs on the system are inconsistent you need to wipe your data partition or your device will be unstable. And if i press "I'm felling lucky" every app crashes touchwiz ,android everything.
Please help me to solve my problem
Click to expand...
Click to collapse
I think your Stuck with the bootloader..
The issue about im feeling lucky thing... I think you have malware on your device... Never heard of or seen nothing like that
hi,
this is my backup of the jb bootloader for the n8013 [n801x]
http://d-h.st/users/moonbutt74/?fld_id=39849#files
cwm flashable
m
moonbutt74 said:
hi,
this is my backup of the jb bootloader for the n8013 [n801x]
http://d-h.st/users/moonbutt74/?fld_id=39849#files
cwm flashable
m
Click to expand...
Click to collapse
Thanks man i havent tried it yet but i hope it will help
Sent from my SM-G900F using XDA Free mobile app
Hi, well I have the n8010 model.
and while you install the version of n8000 leak.
so my bootloader remained in n8000.
and then, after much, I put the rom gnabo v6.
and a few days ago, my note I do not step beyond the samsung logo, stayed stagnant.
try putting on the rom again, but not carrying anything.
I made full format from the recovery of the internal sdcard.
did wipes and try to flash the rom, but not!
I went back to install the 4.4 leak of n8000, but nothing.
and I get the error: failed mount / efs (invalid argument)
that I can do? please help.
sorry for my English, I'm from mexico
FGM 11 said:
Hi, well I have the n8010 model.
and while you install the version of n8000 leak.
so my bootloader remained in n8000.
and then, after much, I put the rom gnabo v6.
and a few days ago, my note I do not step beyond the samsung logo, stayed stagnant.
try putting on the rom again, but not carrying anything.
I made full format from the recovery of the internal sdcard.
did wipes and try to flash the rom, but not!
I went back to install the 4.4 leak of n8000, but nothing.
and I get the error: failed mount / efs (invalid argument)
that I can do? please help.
sorry for my English, I'm from mexico
Click to expand...
Click to collapse
I tried everything but nothing helped. And now i have the same efs problem like you. I hope that somebody can help us
This worked for the galaxy tab 3 10.1
okay,
a while back i helped a user with a similar problem. this was my approach HOWEVER, the following conditions
must be met first.
1 you are able to boot into recovery and maintain normal operation including adb root shell access
2 you are able to charge your tab from a powered off state, mostly to see if you charging animation shows.
that means your kernel is intact-ish
3 you can boot into odin mode.
assuming the partion layouts for your respective devices match the red highlighted sections of this output from parted.
Code:
[email protected]:/ # parted /dev/block/mmcblk0
GNU Parted 1.8.8.1.179-aef3
Using /dev/block/mmcblk0
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) print all
print all
Model: MMC MAG2GA (sd/mmc)
Disk /dev/block/mmcblk0: 15.8GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Number Start End Size File system Name Flags
[COLOR="Red"] 1 4194kB 8389kB 4194kB BOTA0
2 8389kB 12.6MB 4194kB BOTA1
3 12.6MB 33.6MB 21.0MB ext4 EFS
4 33.6MB 41.9MB 8389kB PARAM[/COLOR]
5 41.9MB 50.3MB 8389kB BOOT
6 50.3MB 58.7MB 8389kB RECOVERY
7 58.7MB 92.3MB 33.6MB RADIO
8 92.3MB 931MB 839MB ext4 CACHE
9 931MB 2399MB 1468MB ext4 SYSTEM
10 2399MB 2923MB 524MB ext4 HIDDEN
11 2923MB 2932MB 8389kB OTA
12 2932MB 15.8GB 12.8GB ext4 USERDATA
(parted)
AND provided you can get someone competent with access to the respective models to open a root shell
on device or through adb and run the following command,
Code:
[COLOR="Red"]dd if=/dev/block/mmcblk0 of=/sdcard/fix.img bs=1 count=35221668[/COLOR]
AND zip the output fix.img and post it, again for the respective devices.
THEN you can through adb,
adb push fix.img /sdcard/
or
adb push fix.img /sdcard
or
adb push fix.img /data/media/0/
or
adb push fix.img /data/media/0
you can then navigate TO the directory you pushed the image to and execute the following
dd if=fix.img of=/dev/block/mmcblk0
the above approach worked for me in helping another user with a like device.
you assume the same risk you took previously to achieve the state your device is in now.
NOTE- count=35221668 is a hair under the actual end of /efs . you may need to adjust through param and into boot maybe
half way , but then you can just reflash kernel or then do a proper odin flash of stock. the fix.img will NOT be odin flashable.
m
partitions
moonbutt74 said:
okay,
a while back i helped a user with a similar problem. this was my approach HOWEVER, the following conditions
must be met first.
1 you are able to boot into recovery and maintain normal operation including adb root shell access
2 you are able to charge your tab from a powered off state, mostly to see if you charging animation shows.
that means your kernel is intact-ish
3 you can boot into odin mode.
assuming the partion layouts for your respective devices match the red highlighted sections of this output from parted.
Code:
[email protected]:/ # parted /dev/block/mmcblk0
GNU Parted 1.8.8.1.179-aef3
Using /dev/block/mmcblk0
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) print all
print all
Model: MMC MAG2GA (sd/mmc)
Disk /dev/block/mmcblk0: 15.8GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Number Start End Size File system Name Flags
[COLOR="Red"] 1 4194kB 8389kB 4194kB BOTA0
2 8389kB 12.6MB 4194kB BOTA1
3 12.6MB 33.6MB 21.0MB ext4 EFS
4 33.6MB 41.9MB 8389kB PARAM[/COLOR]
5 41.9MB 50.3MB 8389kB BOOT
6 50.3MB 58.7MB 8389kB RECOVERY
7 58.7MB 92.3MB 33.6MB RADIO
8 92.3MB 931MB 839MB ext4 CACHE
9 931MB 2399MB 1468MB ext4 SYSTEM
10 2399MB 2923MB 524MB ext4 HIDDEN
11 2923MB 2932MB 8389kB OTA
12 2932MB 15.8GB 12.8GB ext4 USERDATA
(parted)
AND provided you can get someone competent with access to the respective models to open a root shell
on device or through adb and run the following command,
Code:
[COLOR="Red"]dd if=/dev/block/mmcblk0 of=/sdcard/fix.img bs=1 count=35221668[/COLOR]
AND zip the output fix.img and post it, again for the respective devices.
THEN you can through adb,
adb push fix.img /sdcard/
or
adb push fix.img /sdcard
or
adb push fix.img /data/media/0/
or
adb push fix.img /data/media/0
you can then navigate TO the directory you pushed the image to and execute the following
dd if=fix.img of=/dev/block/mmcblk0
the above approach worked for me in helping another user with a like device.
you assume the same risk you took previously to achieve the state your device is in now.
NOTE- count=35221668 is a hair under the actual end of /efs . you may need to adjust through param and into boot maybe
half way , but then you can just reflash kernel or then do a proper odin flash of stock. the fix.img will NOT be odin flashable.
m
Click to expand...
Click to collapse
Well this is how my partitions look like: http://kepfeltoltes.hu/view/140928/partitions2_www.kepfeltoltes.hu_.png
Instructions Matter
kataik95 said:
Well this is how my partitions look like: http://kepfeltoltes.hu/view/140928/partitions2_www.kepfeltoltes.hu_.png
Click to expand...
Click to collapse
K,
i must stress the need for you to follow instructions, hear me out, I am operating on the assumption that you are
an experienced android user.
1 the archive with the bootloader data i provided was a cwm flashable zip file. to attempt a flashing of that file itself
or the img files contained within in any other fashion has likely made your problem worse. i also stated as per the
name of the file that it is for the n8013. it is good to hear that you have made some progress however instructions
are important because,
2 though you have succeeded in using parted through adb you have provided the wrong information.
instead of
parted /dev/block/mmcblk0p8
please run
parted /dev/block/mmcblk0
then at the (parted) prompt running print all wil return the correct information.
I mean the above in the best way, as well to stress the importance of doing these things correctly
to avoid a true hard-bricking of your device. You will need to go hat in hand and request an experienced/competent
user/developer pull the needed data from their device as stated in my previous post.
it is likely that the data pulled from my device may work, but that your device afterwards will register as an n8013.
please re-execute parted through adb as instructed for the needed information and we can move foward from there.
m
moonbutt74 said:
K,
i must stress the need for you to follow instructions, hear me out, I am operating on the assumption that you are
an experienced android user.
1 the archive with the bootloader data i provided was a cwm flashable zip file. to attempt a flashing of that file itself
or the img files contained within in any other fashion has likely made your problem worse. i also stated as per the
name of the file that it is for the n8013. it is good to hear that you have made some progress however instructions
are important because,
2 though you have succeeded in using parted through adb you have provided the wrong information.
instead of
parted /dev/block/mmcblk0p8
please run
parted /dev/block/mmcblk0
then at the (parted) prompt running print all wil return the correct information.
I mean the above in the best way, as well to stress the importance of doing these things correctly
to avoid a true hard-bricking of your device. You will need to go hat in hand and request an experienced/competent
user/developer pull the needed data from their device as stated in my previous post.
it is likely that the data pulled from my device may work, but that your device afterwards will register as an n8013.
please re-execute parted through adb as instructed for the needed information and we can move foward from there.
m
Click to expand...
Click to collapse
Thanks for all the help you gave me but I decided to take my tab to a service, they probably make it work
kataik95 said:
Thanks for all the help you gave me but I decided to take my tab to a service, they probably make it work
Click to expand...
Click to collapse
Sure, no problem. Hope everything works out. :good:
m
moonbutt74 said:
Sure, no problem. Hope everything works out. :good:
m
Click to expand...
Click to collapse
Imagine after 2 services where the could't fix I took to a 3rd. They could fix it so it works its on 4.0.4 in some kind of factory mode (strange). I can not quit from this mode and odin not works as well. In the recovery it says efs is invaild. What is that fw?
Lanchon REPIT: The In-Device Data-Sparing Repartitioning Tool For Android
REPIT is a simple, safe, device-only, data-sparing, and easily portable repartitioning tool for Android devices:
device-only: just flash a zip file in recovery to repartition the device.
simple: rename the zip file before flashing to configure your choice of partition sizes, file systems, wipes, etc.
safe:
a correctly ported REPIT can never hard-brick your device.
before starting, REPIT checks for the existence of all the tools that will be needed for the task at hand, verifies that the current partition layout passes several sanity checks, checks and fixes all the involved file systems, and verifies that the new partition layout will meet its sanity checks too. REPIT performs a dry-run of the complete repartitioning process to detect possible problems early on.
if REPIT fails, it will nonetheless try to restore your device to a working in-between state.
my estimate is that around 1000 users have already repartitioned with REPIT with no incidents of data loss, boot loops or soft bricks (2016-04).
easily portable: a simple configuration file is all that is needed to port REPIT to a new device.
Documentation (HELL YEAH, read this!) -> HERE
Downloads -> HERE
this is a user discussion thread. post here for general discussion and user support.
for official support create a Github issue, but only of you have read the docs.
new versions will not be announced here.
please 'watch' the Github project to receive notifications.
special thanks to the.gangster.
XDA:DevDB Information
Lanchon REPIT, Tool/Utility for all devices (see above for details)
Contributors
Lanchon
Source Code: https://github.com/Lanchon/REPIT
Version Information
Status: Stable
Created 2016-04-13
Last Updated 2019-06-07
Reserved
Reserved
Good to have a place again to discuss issues or simple questions.
Great tool, that meanwhile left its corner where it grew up (the Galaxy S2 - i9100), meanwhile supporting a growing number of devices.
RELEASES AND CHANGELOG
the.gangster said:
Good to have a place again to discuss issues or simple questions.
Great tool, that meanwhile left its corner where it grew up (the Galaxy S2 - i9100), meanwhile supporting a growing number of devices.
@Lanchon
you accidently linked the downloads to your flashize github instead of the Repit one.
Click to expand...
Click to collapse
lol thanks, mucho copy/pasta, fixed!
Thanks so much!
Perfect tool, used this evening on a old but still used I9100!
Tried this on a n7000 recently, tried to resize cache, which didn't work, saw partition structure with modem after cache, and understand your concerns in the comments. I imagine the we could so some experiments like you are doing for the Honor 4, however I'm not at the stage where I want to volunteer my device as potential sacrifice.
A question on "wipe", how sure are we that "wipe" actually wipes, ie is all the previous data non-recoverable down to a block level?
Does the wipe trigger some type of NAND erase cycle? This would be problematic on n7000 given the hard brick issues with NAND firmware there, and on the n7000 IIRC the ioctl() is filtered and purposely ignored, maybe this is also an issue with i9100? I don't recall.
If I have a used ext4 parition, and then format & wipe it then I think a fstrim happens. If I then change it to vfat, and dd the partition, am I able to recover blocks from the original ext4 partition, or does the trim cause the nand to regard the blocks as empty and return 0x0000000 or 0x11111111 or something deterministic?
I'm looking for a wipe that actually wipes, ext4 and vfat, rather then my current solution which is to dd if=/dev/zero of=/path, which is slow and is difficult to get a progress report, as kill -USR1 is a PITA.
samarium said:
Tried this on a n7000 recently, tried to resize cache, which didn't work, saw partition structure with modem after cache, and understand your concerns in the comments. I imagine the we could so some experiments like you are doing for the Honor 4, however I'm not at the stage where I want to volunteer my device as potential sacrifice.
A question on "wipe", how sure are we that "wipe" actually wipes, ie is all the previous data non-recoverable down to a block level?
Does the wipe trigger some type of NAND erase cycle? This would be problematic on n7000 given the hard brick issues with NAND firmware there, and on the n7000 IIRC the ioctl() is filtered and purposely ignored, maybe this is also an issue with i9100? I don't recall.
If I have a used ext4 parition, and then format & wipe it then I think a fstrim happens. If I then change it to vfat, and dd the partition, am I able to recover blocks from the original ext4 partition, or does the trim cause the nand to regard the blocks as empty and return 0x0000000 or 0x11111111 or something deterministic?
I'm looking for a wipe that actually wipes, ext4 and vfat, rather then my current solution which is to dd if=/dev/zero of=/path, which is slow and is difficult to get a progress report, as kill -USR1 is a PITA.
Click to expand...
Click to collapse
hi,
well, it's not that it didn't work lol! cache was intentionally left out of the resizable set. you've seen the comments and the 4X discussion so you know exactly why.
i wouldn't do the experiments anyway. in the Honor there is something useful to be gained: 1 extra GB to a 4GB /data, which is a lot. in the S2 cache is 100MB. cache is unused nowadays, so the only logical thing to do is shrink it. plus you want something left, like 32MB. so we will risk devices for 68MB? not on my watch
secure wipe is a very complex issue and there's an awful big can of worms there, believe me. it'll try to paint a picture.
ssds have a bunch of 'trim' commands. there's ERASE and DISCARD, and later TRIM was added, all with slightly different semantics. ans they all come in standard and secure flavors. most recently you can come across the standard non-queued commands or the new queued variants.
the non-secure flavored commands are performance-oriented: they are hints to help the ssd. the drive can ignore them if it wants. it can ignore requests for short ranges but honor requests for large extents, or whatever.
more recently devices can implement DRAT and RZAT (deterministic read after trim and read zero after trim), ending the previous non-deterministic behavior. take a look:
http://www.t13.org/documents/uploadeddocuments/docs2010/e09158r2-trim_clarifications.pdf
but there are a million bugs in ssd firmware so linux blacklists broken functionality. like RZAT in many drives (you can google it), even if the drive says it supports it.
in any case RZAT drives just alter the FTL (flash translation layer) structures to unmap the block, they don't erase flash, so your data is typically still there but normally inaccessible. and there is probably even a history of previous snapshots of the block, not just the latest.
that's where the secure commands enter the picture: supposedly the firmware must actually erase from flash all copies of the targeted blocks. in reality, firmwares are so buggy i wouldn't trust them for that, except maybe if the drive is intel brand.
back to the real world... the exynos:
>Does the wipe trigger some type of NAND erase cycle? This would be problematic on n7000 given the hard brick issues with NAND firmware there, and on the n7000 IIRC the ioctl() is filtered and purposely ignored, maybe this is also an issue with i9100? I don't recall.
you are living in the past. more than two years ago i started arguing that non-secure trim commands should in all probability work fine and could be used to speed up the S2 family. rationale is complex but you can google my threads about it. no-one listened so 2 years ago i learned to build kernels and did some tests with volunteers and began publishing trimming kernels (google i9100 trim for a bit of history). finally in 2016 trim was finally added to official CM 13, 12.1 and 11.
you could be trimming your device without knowing: if you are using recent official CM, you are already trimming. many other kernels switched to trim too.
but... in the S2, secure trim kills the eMMC, so only non-secure variants are issued by trim kernels. secure erase is not a possibility.
i don't know if the eMMC is RZAT, but i wouldn't trust the firmware anyway. if you want to wipe, dd is your best option. but don't use zeros!!! some ssd's compress data. use a pseudo random stream instead. after all, non-secure trim is not very different from a write, in the best case, so just write for safety and be done with it.
yes, dd won't wipe reserved blocks. no way to do that except:
-MAYBE... an eMMC full reset (including bootloader) by resizing the boot partitions (google) which is very dangerous and can easily hard brick the device.
-putting a power drill to you beloved S2
regarding what repit does:
-it trims only if the kernel has trim enabled.
-and it trims only ext4 partitions.
thanks!
Thanks for the detailed reply.
I'm currently using i9100 CM12.1 & n7000 CM13/Nightowl, and have been trimming vfat partitions.
Now you remind me, I do recall reading threads about trim safe a while ago, but I think I was more irritated at the time by the seemingly random kernel crashes & process terminations that eventually were tracked down to kernel interrupt fp register save/restore, and went down the Sony path for a while while the n7000 was unusable. Amusingly, the n7000 now has CM13, while the Sony Z Ultra is languishing and isn't looking good for CM13 at the moment.
While I agree that for general SSDs, zero blocks could be compressed, and blocks could be deduped, do you really think this is happening in n7000/i9100 emmc? I dont expect so, seems they seem too old. I agree that a /dev/urandom would be a better if= than /dev/zero for dd, however this is going to use much more power, and I'm usually wiping a phone with limited time and power.
I'm not trying to protect from something as serious as direct flash chip access, just want to be reasonably sure that whatever was on the phone has been overwritten and is not easily available to standard and even mildly esoteric extraction methods.
samarium said:
Thanks for the detailed reply.
I'm currently using i9100 CM12.1 & n7000 CM13/Nightowl, and have been trimming vfat partitions.
Now you remind me, I do recall reading threads about trim safe a while ago, but I think I was more irritated at the time by the seemingly random kernel crashes & process terminations that eventually were tracked down to kernel interrupt fp register save/restore, and went down the Sony path for a while while the n7000 was unusable. Amusingly, the n7000 now has CM13, while the Sony Z Ultra is languishing and isn't looking good for CM13 at the moment.
While I agree that for general SSDs, zero blocks could be compressed, and blocks could be deduped, do you really think this is happening in n7000/i9100 emmc? I dont expect so, seems they seem too old. I agree that a /dev/urandom would be a better if= than /dev/zero for dd, however this is going to use much more power, and I'm usually wiping a phone with limited time and power.
I'm not trying to protect from something as serious as direct flash chip access, just want to be reasonably sure that whatever was on the phone has been overwritten and is not easily available to standard and even mildly esoteric extraction methods.
Click to expand...
Click to collapse
ok. then i would format in ext4 and trim. you can use repit for doing both in a single shot, but you need a trimming kernel. take a dd snapshot of one or a couple of short pieces of the partition, both before and after the operation. compare them and post here, i'd surely like to know .
but... keep in mind that there are several different emmcs out there in the S2s, so you'd need to validate for each one. which reminds me, also post your device emmc IDs! use the eMMC brickbug check app for instance.
regarding the /dev/urandom vs /dev/zero thing, i'm not religious, i don't hold unwarranted beliefs about what i don't know. i investigate, i have no gut feelings on stuff
but if you want to know: i'm a bit obsessive, i certainly would have done at least something if i was coding the FTL, even if it is old. if your design is RZAT, the least you can do is trim the block instead of writing it when data is all zeros. you may think this would slow the emmc down, but this can be implemented in pseudo-zero time: writing usually entails generating some kind of checksum of the data. so note the magic checksum that corresponds to an all-zero block, and only if the checksum of the data being written matches the magic, actually check for all-zero data before writing. of course this can be 'attacked' by intentionally generating checksum collisions but who cares. the time saved by not garbage collecting, not using a free block, and not writing the block with all-zeros certainly pays for the checksum comparison against the magic value. also note that straight brute force comparison of all blocks is mostly ok too, as most written blocks will fail early anyway (ie, after one or a couple of bytes).
of course The One True Solution(R) is to encrypt the phone before using it...... assuming that you can actually wipe the key when you need to lol. ideally the key is in a separate hardware keystore adept at wiping keys. but on the S2 it just in the same eMMC . so this is a bit like explaining where the universe came from by saying that god created it, and then conveniently forget to explain where did god come from lol.
the power drill solution still mostly works on the S2 though
Pls help
##################################
Lanchon REPIT
A Data-Sparing Repartitioning Tool
Version: 2016-04-15
Device: i9100
Copyright 2016, Lanchon (GPLv3)
####################################
===== PRELIMINARY CHECKS =====
info: valid package names: <prefix>[-(system|data|sdcard|preload)=<conf>]...<suffix>
info: valid partition <conf> values: [<size-in-GiB>|same|min|max][+[keep|wipe][+[ext4|vfat|f2fs|swap|raw]]]
----- DEFAULTS -----
system = size:same + content:keep + fs:ext4
data = size:same + content:keep + fs:ext4
sdcard = size:same + content:keep + fs:vfat
preload = size:same + content:keep + fs:ext4
info: parsing package name
----- CONFIGURATION -----
system = size:1.0 + content:keep + fs:ext4
data = size:6 + content:keep + fs:ext4
sdcard = size:max + content:keep + fs:vfat
preload = size:min + content:keep + fs:ext4
info: disabling swap
BusyBox v1.22.1 bionic (2016-01-10 12:49 +0530) multi-call binary.
Usage: dirname FILENAME
Strip non-directory suffix from FILENAME
info: copying package to '/tmp'
cp: '/tmp/lanchon-repit-20160415-system=1.0-data=6-sdcard=max-preload=min wipe-i9100.zip' and '/tmp/lanchon-repit-20160415-system=1.0-data=6-sdcard=max-preload=min wipe-i9100.zip' are the same file
[ERROR 1]
Whats wrong
just change your current directory to /tmp and try to flash it again from there. (all within the recovery)
Lanchon said:
ok. then i would format in ext4 and trim. you can use repit for doing both in a single shot, but you need a trimming kernel. take a dd snapshot of one or a couple of short pieces of the partition, both before and after the operation. compare them and post here, i'd surely like to know .
but... keep in mind that there are several different emmcs out there in the S2s, so you'd need to validate for each one. which reminds me, also post your device emmc IDs! use the eMMC brickbug check app for instance.
regarding the /dev/urandom vs /dev/zero thing, i'm not religious, i don't hold unwarranted beliefs about what i don't know. i investigate, i have no gut feelings on stuff
Click to expand...
Click to collapse
bauner produced a new n7000 IsoRec with TWRP + OTG which I wanted, so while I was installing I tested a few things.
I generated a block binary file with each of the 1kB blocks annotated for the 200MB n7000 cache partition, and dd'd the file to the cache partition prior to each mkfs.
Code:
$ cat blocknull.pl
#!/usr/bin/perl
use strict;
my $count = $ARGV[0];
$count = 1 if $count == 0;
$count *= 1024 if $ARGV[0] =~ /M$/;
$count *= 1024 * 1024 if $ARGV[0] =~ /G$/;
for (my $i = 1; $i <= $count; $i++)
{
printf "\nBLOCK %10d kB %6d MB %2d GB BLOCK\n", $i, $i / 1024, $i / 1024 / 1024;
print chr(0) x (1024-43);
}
$
Code:
BLOCK 1 kB 0 MB 0 GB BLOCK
...
BLOCK 204800 kB 200 MB 0 GB BLOCK
Then operated on both vfat and ext4 file systems to determine which of the 204800 block signatures where remaining after various operations.
Code:
# tr -d '\0' < /dev/block/mmcblk0p7 | grep BLOCK.*BLOCK > cache.x.y.desc
...
# wc -l cache.?.?.*
204800 cache.1.1.dd
201632 cache.1.2.mkfs.fat32
197041 cache.1.3.copyfile
204800 cache.2.1.dd
0 cache.2.2.mkfs.ext4
204800 cache.3.1.dd
197380 cache.3.2.mkfs.ext4.twrp
60 cache.3.3.fstrim
60 cache.3.4.copyfile
#
So as expected vfat format doesn't change the underlying data returned, it just gets changed as it is used, as show by the signature counts on cache.1.*
ext4 is more interesting, as I tried a manual mke2fs -t ext4 for cache.2.* and TWRP wipe ext4 for cache.3.*. The TWRP wipe is not using secure discard as can be seen from recovery.log, but things are largely back on track after the first fstrim except for a hole from 131081 kB to 131125 kB.
Code:
recovery.log:
warning: wipe_block_device: Wipe via secure discard suppressed due to bug in EMMC firmware
Maybe more interesting is that even though it seems manual mke2fs -t ext4 does a wipe, when I do a fstrim is still says 180MB trimmed, which I don't expect, some inconsistency in fs metadata setup in mkfs maybe? Doesn't matter to me, 1 or 2 wipes, but seems I will be using mke2fs -t ext4 via terminal and then using TWRP wipe/format as required.
FYI, EMMC IDs PNG attached.
samarium said:
bauner produced a new n7000 IsoRec with TWRP + OTG which I wanted, so while I was installing I tested a few things.
I generated a block binary file with each of the 1kB blocks annotated for the 200MB n7000 cache partition, and dd'd the file to the cache partition prior to each mkfs.
Code:
$ cat blocknull.pl
#!/usr/bin/perl
use strict;
my $count = $ARGV[0];
$count = 1 if $count == 0;
$count *= 1024 if $ARGV[0] =~ /M$/;
$count *= 1024 * 1024 if $ARGV[0] =~ /G$/;
for (my $i = 1; $i <= $count; $i++)
{
printf "\nBLOCK %10d kB %6d MB %2d GB BLOCK\n", $i, $i / 1024, $i / 1024 / 1024;
print chr(0) x (1024-43);
}
$
Code:
BLOCK 1 kB 0 MB 0 GB BLOCK
...
BLOCK 204800 kB 200 MB 0 GB BLOCK
Then operated on both vfat and ext4 file systems to determine which of the 204800 block signatures where remaining after various operations.
Code:
# tr -d '\0' < /dev/block/mmcblk0p7 | grep BLOCK.*BLOCK > cache.x.y.desc
...
# wc -l cache.?.?.*
204800 cache.1.1.dd
201632 cache.1.2.mkfs.fat32
197041 cache.1.3.copyfile
204800 cache.2.1.dd
0 cache.2.2.mkfs.ext4
204800 cache.3.1.dd
197380 cache.3.2.mkfs.ext4.twrp
60 cache.3.3.fstrim
60 cache.3.4.copyfile
#
So as expected vfat format doesn't change the underlying data returned, it just gets changed as it is used, as show by the signature counts on cache.1.*
ext4 is more interesting, as I tried a manual mke2fs -t ext4 for cache.2.* and TWRP wipe ext4 for cache.3.*. The TWRP wipe is not using secure discard as can be seen from recovery.log, but things are largely back on track after the first fstrim except for a hole from 131081 kB to 131125 kB.
Code:
recovery.log:
warning: wipe_block_device: Wipe via secure discard suppressed due to bug in EMMC firmware
Maybe more interesting is that even though it seems manual mke2fs -t ext4 does a wipe, when I do a fstrim is still says 180MB trimmed, which I don't expect, some inconsistency in fs metadata setup in mkfs maybe? Doesn't matter to me, 1 or 2 wipes, but seems I will be using mke2fs -t ext4 via terminal and then using TWRP wipe/format as required.
FYI, EMMC IDs PNG attached.
Click to expand...
Click to collapse
>it seems manual mke2fs -t ext4 does a wipe
it shouldn't. mke2fs -i thought- doesn't trim unless invoked with a specific option. repit invokes with the flag:
https://github.com/Lanchon/REPIT/blob/master/repit-fs-ext4.sh#L51
as to the question of why your markers were cleared anyway, i've no answer.
>even though it seems manual mke2fs -t ext4 does a wipe, when I do a fstrim is still says 180MB trimmed
some kernels inform the newly trimmed space: if you run trim twice you'll get "0 bytes trimmed" the second time.
other kernels (like CM's i9100) always inform (and presumably trim) the full partition free space, so 180MB is ok. if you run trim twice you'll get the same number of bytes both times.
>things are largely back on track after the first fstrim except for a hole from 131081 kB to 131125 kB.
here are some candidate causes:
a) ext4 fs is based on 'blocks' with each block being a constant number of sectors. it makes sense that fstrim should work on whole blocks. also, when ext4 writes a 'short block', ie one not completely filled with data, some sectors and the end of the block might remain unused. it makes sense for ext4 not to write these sectors at all. but the complete block will be marked as used given that the block is the granularity for that, so no sector in the block will be trimmed by fstrim. so some pre-format data might survive in these short blocks after fstrim by this mechanism, which could explain what you observed.
b) another cause could be that the emmc might ignore trim requests for spans shorter than some size or for misaligned spans (remember that erases are performed in large chunks) giving rise to the observed data survival. when formatting no data survives because partitions are position- and size-aligned to 1MB or 4MB, which might be enough to guarantee trim. (i find this explanation unlikely, but who knows.)
about repit:
repit formats and trims ext4 and f2fs in a single operation.
to wipe /data a single repit should be enough:
-data=+wipe
to wipe /sdcard you can take advantage of repit's capability to convert file systems and do two repits:
-sdcard=+wipe+ext4
-sdcard=+wipe
an idea that comes out of this is that repit could temporarily format in ext4 before formatting in other modes that do not support format-time trimming, such as when wiping vfat and swap. this would make the above 2 steps unnecessary.
darkz16 said:
[...]
info: disabling swap
BusyBox v1.22.1 bionic (2016-01-10 12:49 +0530) multi-call binary.
Usage: dirname FILENAME
Strip non-directory suffix from FILENAME
info: copying package to '/tmp'
cp: '/tmp/lanchon-repit-20160415-system=1.0-data=6-sdcard=max-preload=min wipe-i9100.zip' and '/tmp/lanchon-repit-20160415-system=1.0-data=6-sdcard=max-preload=min wipe-i9100.zip' are the same file
[ERROR 1]
Click to expand...
Click to collapse
this is very interesting.
the relevant lines are these:
https://github.com/Lanchon/REPIT/blob/master/repit.sh#L318-L322
Code:
if [ -f "$packageName" ]; then
if [ "$(dirname $(readlink -f "$packageName"))" != "/tmp" ]; then
info "copying package to '/tmp'"
cp -f "$packageName" "/tmp/"
hint="this package copied itself to '/tmp'; please run it again from there"
the line:
if [ -f "$packageName" ]; then
assures that the file $packageName exists.
but these logfile lines:
Code:
BusyBox v1.22.1 bionic (2016-01-10 12:49 +0530) multi-call binary.
Usage: dirname FILENAME
Strip non-directory suffix from FILENAME
are proof that 'dirname' is being invoked without argument, which means that 'readlink -f "$packageName"' produced an error!
how can 'readlink -f <file>' (which means 'canonicalize') give an error when invoked on an existing file is beyond me. it looks like your implementation of 'readlink' is broken.
what exact recovery are you using? who made it or where is it being distributed?
EDIT:
btw there is a quoting error in the code here but it shouldn't affect this. the line should be:
if [ "$(dirname "$(readlink -f "$packageName")")" != "/tmp" ]; then
darkz16 said:
[...]
cp: '/tmp/lanchon-repit-20160415-system=1.0-data=6-sdcard=max-preload=min wipe-i9100.zip' and '/tmp/lanchon-repit-20160415-system=1.0-data=6-sdcard=max-preload=min wipe-i9100.zip' are the same file
[ERROR 1]
Whats wrong
Click to expand...
Click to collapse
so i committed what i think is a fix for this problem that i cant reproduce:
https://github.com/Lanchon/REPIT/commit/c7bc3655acc89ee554d1dafe09c7bb9948483c03
and attached is build for you to try.
IMPORTANT: EXTRACT THE ZIP FIRST, DONT JUST FLASH IT!
Lanchon said:
so i committed what i think is a fix for this problem that i cant reproduce:
https://github.com/Lanchon/REPIT/commit/c7bc3655acc89ee554d1dafe09c7bb9948483c03
and attached is build for you to try.
IMPORTANT: EXTRACT THE ZIP FIRST, DONT JUST FLASH IT!
Click to expand...
Click to collapse
Hi Lanchon.
I'm installed this zip but i have the same problem.
I'm copy, before zipping the achive, on the \tmp directory of emmc
What have i do wrong?.
Thanks.
chapito said:
Hi Lanchon.
I'm installed this zip but i have the same problem.
I'm copy, before zipping the achive, on the \tmp directory of emmc
What have i do wrong?.
Thanks.
Click to expand...
Click to collapse
no log, no kernel info, no recovery info. cant help you.
Lanchon said:
no log, no kernel info, no recovery info. cant help you.
Click to expand...
Click to collapse
Hi.
Forgive me for not giving more information to solve the problem.
Yesterday I could partition the memory.
I had to change the partition type of memory EMMC to vfat and the script to start.
I used the IsoRec TWRP 2.8.7.0.
I used the last script publicated "lanchon-repit-20160415-system=1.0-data=same-sdcard=max-preload=min+wipe-i9100.zip"
Thanks
chapito said:
Hi.
Forgive me for not giving more information to solve the problem.
Yesterday I could partition the memory.
I had to change the partition type of memory EMMC to vfat and the script to start.
I used the IsoRec TWRP 2.8.7.0.
I used the last script publicated "lanchon-repit-20160415-system=1.0-data=same-sdcard=max-preload=min+wipe-i9100.zip"
Thanks
Click to expand...
Click to collapse
you didn't need to change your sdcard to FAT !!!
you could have used: -sdcard=max++ext4
if only you had read the instructions! that's what they are there for lol
well, it's your data you had to format, not mine!
thanks!