Need a system dump (AT&T H910) - LG V20 Questions & Answers

Hopefully there is a kind soul out there that has an H910 and doesn't mind doing a factory reset.
Over the weekend, I was testing an unbrick method if the H910 ended up losing download mode (Qualcomm HS-USB QDLoader 9008 mode).
I came across this thread: https://forum.xda-developers.com/att-g4/general/att-h810-qualcomm-hs-usb-qdloader-9008-t3539554
It just so happened that I had a spare LG G4 laying around that I wasn't worried about bricking, so I made a dump, and then flashed a broken boot loader and viola -- 9008 mode.
I then proceeded to create the SD card, and flash the phone. What do you know -- it worked.
So then I made a dump of my H910. What I didn't know at the time was that I either had a bad USB cable, or bad USB port, and I wasn't paying attention. The image file that I got was WAY too small (corrupt). So now I have an H910 in 9008 mode that I have no way to recover.
So, if one of you with a rooted H910 doesn't mind doing these steps:
* Do a full factory reset from CWM TWRP or any recovery
* Now open ADB shell
adb shell
su
dd if=/dev/block/mmcblk0 of=/storage/sdcard1/backup.img bs=8192
That will give me a full dump, and then I can figure out the offset, and size (seek= / size=) since I highly doubt that it is the same for H810 and H910
Bonus if you can give me the partition layout...
Thanks,
-- Brian

I need this too
I have an H910 with the 9008 message only, too. I would also like it if someone can provide this system dump in order for me to get my phone running again.

@alanwid I have given up on the hopes that someone will be willing to provide the dump, so I have sent the phone for repair. When I get it back *IF* it still has rootable firmware, then I will create the image for you to try.
I wish I could hang on to the phone a little while longer, because I did a lot of research on Qualcomm 9008 (EDL - Emergency DownLoad mode). At one time it was possible to send a command to go from 9008 to 9006. In 9006 mode, you can see the individual partitions, and as long as you have the images -- flash back to a working phone. For that matter, if we had newer version of QPST that supported the msm8996 (Snapdragon 820) we could recover our phones in 9008 mode without having to resort to an SDCard.
Unfortunately, it looks like Qualcomm has changed the protocol, and I don't have time to try and putz with it.
EDIT: it is STILL possible to go into 9006 by shorting test pins, but I don't want to open this phone and void the warranty.

Thanks!! Would this link have the image that would work with your method? https://forum.xda-developers.com/v20/development/rom-natf-1-00-test-5-debloated-stock-t3509750
and this link says they have a boot img https://forum.xda-developers.com/v20/development/devs-h910-v10l-rom-boot-img-included-t3579011

runningnak3d said:
Hopefully there is a kind soul out there that has an H910 and doesn't mind doing a factory reset.
Over the weekend, I was testing an unbrick method if the H910 ended up losing download mode (Qualcomm HS-USB QDLoader 9008 mode).
I came across this thread: https://forum.xda-developers.com/att-g4/general/att-h810-qualcomm-hs-usb-qdloader-9008-t3539554
It just so happened that I had a spare LG G4 laying around that I wasn't worried about bricking, so I made a dump, and then flashed a broken boot loader and viola -- 9008 mode.
I then proceeded to create the SD card, and flash the phone. What do you know -- it worked.
So then I made a dump of my H910. What I didn't know at the time was that I either had a bad USB cable, or bad USB port, and I wasn't paying attention. The image file that I got was WAY too small (corrupt). So now I have an H910 in 9008 mode that I have no way to recover.
So, if one of you with a rooted H910 doesn't mind doing these steps:
* Do a full factory reset from CWM TWRP or any recovery
* Now open ADB shell
adb shell
su
dd if=/dev/block/mmcblk0 of=/storage/sdcard1/backup.img bs=8192
That will give me a full dump, and then I can figure out the offset, and size (seek= / size=) since I highly doubt that it is the same for H810 and H910
Bonus if you can give me the partition layout...
Thanks,
-- Brian
Click to expand...
Click to collapse
Can anyone get this dump? I am trying to use either MiFlash or Qfil to unbrick my phone with the 8996.mbn or .elf and xml files. I'm not sure which ones v20s use. My phone is in the 9008 mode.
Anyone try this method?

No one is willing to make a dump? It can be from a H915 or H910 -- going to have to flash the 915 KDZ anyway since we don't have a 910 KDZ (yes, it has been verified that they are identical hardware).
So little effort to do this, and you would be helping several people out...
EDIT: In case anyone thinks this would just be a waste of time, I just recovered an H901 (LG V10) using this method. I bought a used v10 off Ebay when I bricked my v20 to use until it came back from repair.
I had the v10 all of 10 minutes, and bricked it. Yep -- didn't pay attention to the version of MM that was on it, and flashed the wrong bootstack while I was rooting it. It turns out that the folks over in the v10 forum already had an image. Wrote the SDcard, and viola, the phone booted all the way to the OS. That got me looking at more info concerning 9008. In the event that the Qualcomm XXX chip can't find a boot partition on the eMMC, then it looks at the SDcard. As long as the SDcard has a valid partition, it will boot from the SDcard. You can have the entire OS on the SDcard if you want, but it will attempt to jump to the eMMC at every point in the boot process. So, if you blow up your boot loader -- write one to the SDcard and viola -- you are back in business. Problem is, you need those images because all of the current KDZ extractors that I can find can't make a decent image
OK -- I rambled enough for an edit. Bottom line, some kind soul please make an image. 9008 errors will be a thing of the past.

Hate replying to myself, but I think I did enough editing in that last post
OK, I futtzed around until I got a good extraction. The only thing I need now is for someone that has an H910 or 915 to run this:
Code:
adb shell "/sbin/fdisk -l /dev/block/mmcblk0"
And paste the output in here. With the partitions I have extracted, and that little piece of info, I can make an image that will finally fix our freaking phones. Please. This command is non-intrusive, and if you have adb setup already (which I would hope) then it will take you 10 seconds

I have a H910 rooted with dirty santa. I have the TWRP backup from stock (rooted). I'll be installing a custom room soon but if I can do anything before that'll help let me know
---------- Post added at 04:40 PM ---------- Previous post was at 04:35 PM ----------
runningnak3d said:
Hate replying to myself, but I think I did enough editing in that last post
OK, I futtzed around until I got a good extraction. The only thing I need now is for someone that has an H910 or 915 to run this:
Code:
adb shell "/sbin/fdisk -l /dev/block/mmcblk0"
And paste the output in here. With the partitions I have extracted, and that little piece of info, I can make an image that will finally fix our freaking phones. Please. This command is non-intrusive, and if you have adb setup already (which I would hope) then it will take you 10 seconds
Click to expand...
Click to collapse
Microsoft Windows [Version 6.3.9600]
(c) 2013 Microsoft Corporation. All rights reserved.
C:\Windows\System32>cd C:\platform-tools
C:\platform-tools>adb devices
List of devices attached
LGUS9966cc96e9f device
C:\platform-tools>adb shell
elsa:/ $ /sbin/fdisk -l /dev/block/mmcblk0
/system/bin/sh: /sbin/fdisk: not found
127|elsa:/ $
---------- Post added at 12:43 AM ---------- Previous post was at 12:40 AM ----------
staplerz said:
I have a H910 rooted with dirty santa. I have the TWRP backup from stock (rooted). I'll be installing a custom room soon but if I can do anything before that'll help let me know
---------- Post added at 04:40 PM ---------- Previous post was at 04:35 PM ----------
Hate replying to myself, but I think I did enough editing in that last post
OK, I futtzed around until I got a good extraction. The only thing I need now is for someone that has an H910 or 915 to run this:
Microsoft Windows [Version 6.3.9600]
(c) 2013 Microsoft Corporation. All rights reserved.
C:\Windows\System32>cd C:\platform-tools
C:\platform-tools>adb devices
List of devices attached
LGUS9966cc96e9f device
C:\platform-tools>adb shell
elsa:/ $ /sbin/fdisk -l /dev/block/mmcblk0
/system/bin/sh: /sbin/fdisk: not found
127|elsa:/ $
Click to expand...
Click to collapse
Sorry I'm a noob but would like to help

It would be very awesome if you are willing to help.
The first and most important will be an image dump of your entire eMMC -- that is the command in the first post:
Code:
adb shell
su
dd if=/dev/block/mmcblk0 of=/path-to-your-external-sdcard/backup.img bs=8192
Let me know if you need help finding the correct path. It must be your external SD card because you are dumping your internal, and that would be a bit of a loop
As for the fdisk command, Dunno why, but maybe the Windows adb command is different. Try this:
Code:
adb shell
fdisk -l /dev/block/mmcblk0
Just an FYI. That first one dumps your entire internal storage, so don't do it if you have anything you wouldn't want me to see -- or like I said in my first post, do a backup and then wipe your data partition.
I know this seems like a lot, but you will really be helping a few people (that I know of) out of a jam.

runningnak3d said:
It would be very awesome if you are willing to help.
The first and most important will be an image dump of your entire eMMC -- that is the command in the first post:
Code:
adb shell
su
dd if=/dev/block/mmcblk0 of=/path-to-your-external-sdcard/backup.img bs=8192
Let me know if you need help finding the correct path. It must be your external SD card because you are dumping your internal, and that would be a bit of a loop
As for the fdisk command, Dunno why, but maybe the Windows adb command is different. Try this:
Code:
adb shell
fdisk -l /dev/block/mmcblk0
Just an FYI. That first one dumps your entire internal storage, so don't do it if you have anything you wouldn't want me to see -- or like I said in my first post, do a backup and then wipe your data partition.
I know this seems like a lot, but you will really be helping a few people (that I know of) out of a jam.
Click to expand...
Click to collapse
Microsoft Windows [Version 6.3.9600]
(c) 2013 Microsoft Corporation. All rights reserved.
C:\Windows\system32>cd C:\platform-tools
C:\platform-tools>adb devices
List of devices attached
LGUS9966cc96e9f recovery
C:\platform-tools>adb shell
~ # ←[6n
~ # ←[6nfdisk -l /dev/block/mmcblk0
Disk /dev/block/mmcblk0: 63.8 GB, 63864569856 bytes
256 heads, 63 sectors/track, 7734 cylinders
Units = cylinders of 16128 * 512 = 8257536 bytes
Device Boot Start End Blocks Id System
/dev/block/mmcblk0p1 * 1 7735 62366720 7 HPFS/NTFS
~ # ←[6n
---------- Post added at 05:32 PM ---------- Previous post was at 05:27 PM ----------
If I make a backup in TWRP of my current setup, "Factory Reset" in TWRP and then make the eMMC back up. I will have to dirtysanta again and then can I restore my backup via TWRP?
I'm more concerned with time. I need my phone for work tomorrow.
---------- Post added at 05:36 PM ---------- Previous post was at 05:32 PM ----------
****. Well I was in TWRP and forgot I was under factory reset. I thought it was "Slide to Unlock"... I just factory reset via TWRP (didnt have any important data). Please advise

Sorry about that dude.
If you don't mind throwing in a 64gig SD card and doing the dump it would be awesome. If you don't have a 64 gig card, I can figure something else out.

No worries. I was able to boot into TWRP and am currently making a backup (stock non rooted). I have a 64gb sd card but it's probably 30% full. Do i need to backup my sd card and format it? How big of a dump are we talking about here (-;
EDIT: Also need help finding sd path
---------- Post added at 06:21 PM ---------- Previous post was at 06:06 PM ----------
runningnak3d said:
Sorry about that dude.
If you don't mind throwing in a 64gig SD card and doing the dump it would be awesome. If you don't have a 64 gig card, I can figure something else out.
Click to expand...
Click to collapse
adb shell
su su: not found
also need to figure out my sdcard location

Sorry but I had to restore back... If you really need it let me know but its hard to believe there isn't a h910 system dump floating around

Totally understandable. Having a full dump would be nice, but at this point I would just settle for the partition layout so I can make the image myself.
You need to be rooted, and have busybox installed for these commands to work.
Not sure what happened when you tried to run it the last time, but could you try running again:
Code:
adb shell
su
fdisk -l /dev/block/mmcblk0
You should get a list of partitions with their start, end, and size. With that info, I can partition an SD card, and then dump the images that I extracted from the KDZ. Once I have a bootable SD card with the proper partitions -- it should work and I shouldn't need a dump from a running phone. Although at the end of the day, it is MUCH easier to just take a dump from a running phone. Far less room for error
I appreciate you working with me on this, and I know it can be frustrating when you are trying to use your phone to get work done

I think I got stuck in 9008 mode this weekend while testing my kernel, but was able to boot to recovery manually, reinstalled a known good kernel, and all was fine. But to be honest, the text was so small, I couldn't read it very well. It took several attempts to get it to boot into recovery, but I eventually got it.
Disconnect from computer and pull battery
Wait a few seconds to ensure everything has powered down
Hold Vol - and Power button
When LG splash appears while still holding Vol -, release power button and immediately press it again. You should get a white screen telling you that if you proceed it will wipe data, scroll to yes, then it will ask if you're sure, select yes again. Then you should boot back into TWRP, flash a known good kernel (for me, I used my previous kernel build as I knew it was booting, but I have also used schwifty kernel).
I have to tell you, that this phone is very picky on manually booting to recovery. You have to hold the Vol - firmly and when you release and press the power button, make sure you firmly press it. Like me, it may take you a few tries.
In your case, because of what you were doing, I'm not sure just flashing a kernel and/or rom would fix things for you, but maybe you can make a flashable bootloader (not sure if there are any for this phone atm as I have not researched it). Either way, if you still get the LG splash screen, and have TWRP, you should be able to boot to recovery and fix your phone.

I can assure you that you did not brick your phone into 9008 mode. In 9008 mode the phone will not power on -- no lights, nothing. The fact that you were able to get an LG logo means your boot partition was fine.
The first thing a Qualcomm chip does is look for a valid boot partition on the eMMC. If it can't find one there, it looks for it on the SDcard (which is why I will never buy a phone that doesn't have an SDcard slot ).
-- Brian

elsa:/ $ adb shell
/system/bin/sh: adb: not found
127|elsa:/ $ su
elsa:/ # adb shell
sush: adb: not found
127|elsa:/ # shell
sush: shell: not found
127|elsa:/ # fdisk -l /dev/block/mmcblk0
Disk /dev/block/mmcblk0: 59 GB, 63864569856 bytes, 124735488 sectors
7734 cylinders, 256 heads, 63 sectors/track
Units: cylinders of 16128 * 512 = 8257536 bytes
Device Boot StartCHS EndCHS StartLBA EndLBA Sectors Size Id Type
/dev/block/mmcblk0p1 * 1023,255,63 1023,255,63 2048 124735487 124733440 59.4G 7 HPFS/NTFS
elsa:/ #

I am freaking blind, or just flat out wasn't paying attention the first time you posted that output. Sometime between MM 6.0 and N 7.0 they switch from using an MBR partition table to a GPT partition table. Hence fdisk works for me (T-Mobile hasn't released 7.x for the V10 yet, so I am on MM 6.0), but not for you. I can't find a good source to download gdisk (fdisk that works with GPT), so I am compiling it. As soon as I have it built, I will post a link.
Again, thanks for working with me on this. Do have to point out that an image dump would be far far easier *nudge* *hint*
-- Brian

Lol no worries i thought i was doing something wrong. If i can finess my simcard into my g3 ill be able to get to it sooner.

Just a heads up guys. if you do this theres a good chance that your EFS and userdata will be shared with him(which is a nono).

Related

Acer A200 - BRICKED, cannot mount /data /sdcard

I did something stupid. Got an A200 that could not get OTA 4.0.3, so I managed to get it updated manually. However, I then proceeded to try to root it using the "SimpleRoot" scripts on Acertabletforum, and at this point, the thing is bricked. In Recovery, I cannot get anything to mount. /SDCard, /data, etc
Bootloader is Unlocked
I tried with some different Recoveries with slightly different results:
1) Hbwelch CWM v5.5.0.4 (the one that comes with SimpleTool) - All mounting attempts fail
2) nics-TWRP_stable (twrp v 2.1.4) - Seems to be able to mount System and Cache, but not DATA or SDCARD (Internal or External)
3) thor v 5.5.0x (thor2002ro rev1.7) - errors mounting data, sdcard and /mnt/sdcard. Is able to mount system, cache, flexrom and flex.
Any idea how to fix it? I am afraid that if I try to return the tablet where I bought it as it is now, it will get rejected. (even though the damn thing was supposed to be ICS upgradable in the first place, but wasn't... long story)
Thanks
Jerry
I finally got the tablet working again. Was very close to sending it back. Got bits and pieces of info from various other posts on this forum and on acertabletforum. For the sake of anyone else that may find this thread, here are a few things that were wrong, and how to fix them
(I cannot post outside links, so just google the file names when relevant)
1) /SDCard would not mount. Solution - PARTITION the SD card. NOTE: The card worked on a PC, and even on that tablet when Android was fully booted. However it would NOT mount in recovery until I explicitly partitioned it. Doing a FORMAT on the PC does NOT count. I had to partition it within Recovery.
NOTE: This may also be why people are unable to get the update.zip thing working.
2) /Data would not mount - I have no idea how this got screwed up, but the solution was:
* Connect the tablet to the PC in RECOVERY. At this point, ADB should work. If not, check the drivers on the PC - I had to manually specify the Acer ADB Composite driver.
* Open a Command prompt window
* Start ADB shell by typing:
ADB SHELL
* Now execute the following:
mke2fs -j -b 4096 /dev/block/mmcblk0p8
tune2fs -O extents,uninit_bg,dir_index -C 1 /dev/block/mmcblk0p8
e2fsck -fy /dev/block/mmcblk0p8
After this is done your file system on /data will be fixed. (solution posted by spoupard on XDA-Developers.com)
3) Putting it all together:
* Flashed the BOOT partition with Honeycomb 3.2.1_boot.img
* Flashed the RECOVERY partition with nics-TWRP_stable.img
* At this point, I noticed that the Bootloader was once again LOCKED. So, start into FASTBOOT mode and execute the following from the command prompt again:
fastboot oem unlock
* Re-Start in Recovery and select MOUNT and make sure that everything is mounted. If /SDCARD or /DATA refuse to mount, fix that issue first (step 2 above)
* Now I select to INSTALL Acer_AV041_A200_1.037.00_PA_CUS1.zip
Upon reboot, I noticed that it said "Updating Bootloader", then got the Acer screen and locked up. I restarted again into Recovery and again selected the option to install INSTALL Acer_AV041_A200_1.037.00_PA_CUS1.zip and reboot. This time it restarted, indicated that it has a new version of bootloader (previously was 3.1.3) and proceeded to boot up into Android 4.0.3. At that point, I think my neighbors heard me scream YES!, considering I spent 2 days on this
I hope I got all the steps. Most of it is from memory and some notes, since I did not want to experiment and go through this hell again.
Jerry
Great info but you might want to add fixed to the title. For the time being doesn't look like I will be rooting till these issues are sorted out. I am see too many people saying they are bricking with this root method.
FIXED - Acer A200 - BRICKED, cannot mount /data /sdcard
agapecs said:
Great info but you might want to add fixed to the title. For the time being doesn't look like I will be rooting till these issues are sorted out. I am see too many people saying they are bricking with this root method.
Click to expand...
Click to collapse
Didn't see a way to edit the title. As for rooting, note that after all was said and done, I am still not rooted. I just managed to get updated to 4.0.3, which should have been done OTA anyway. I may try again now that I am a bit more confident that I can get it back to working state, but will do a full backup in ADB first. Too much of a pain in the *** to have to reconfigure everything again once the OS is installed.
I cannot get the device to connect to my PC at all, or get the correct driver selected. Any tips?
crazyjimbo said:
I cannot get the device to connect to my PC at all, or get the correct driver selected. Any tips?
Click to expand...
Click to collapse
what state is the tablet in when you try to connect? Fastboot, Recovery, or fully booted up and operating?
What do you see in the device manager when the tablet is connected?
ext3 oder ext4?
1) /SDCard would not mount. Solution - PARTITION the SD card. NOTE: The card worked on a PC, and even on that tablet when Android was fully booted. However it would NOT mount in recovery until I explicitly partitioned it. Doing a FORMAT on the PC does NOT count. I had to partition it within Recovery.
Try to do this with twrp v.2.1.4: do I use ext3 or ext4 for the Partition? And which size needs the ext Partition?
Thanx
teacherHH
teacherhh said:
Try to do this with twrp v.2.1.4: do I use ext3 or ext4 for the Partition? And which size needs the ext Partition?
Click to expand...
Click to collapse
Don't think it matters. I picked the defaults.
mke2fs -j -b 4096 /dev/block/mmcblk0p8
Thanx j_medved for yor reply!
So I did and just faced the next problem: I can conect my Tablet to the PC and can finde it with adb devices and can start the shell with adb shell.
But then when I start: mke2fs -j -b 4096 /dev/block/mmcblk0p8
nothing seems to happen....waited about 30 minutes....
in the next turn I get the reply, that mmcblk0p8 is allready in use....next turn again: nothing seems to happen....
any ideas? .-(
teacherhh
teacherhh,
If I remember correctly, that command should finish pretty quick. You may want to try leaving it for a bit longer, but it seems that you may have something else wrong. I am not that familiar with this area. Haven't dealt with Linux much. Sorry.
Okay. Thanx anyway!
Sent from my GT-I9300 using xda app-developers app
again mke2fs
Once again j_medved...
did it look likes this, wenn you run mke2fs ?
Regards,
teacherhh
teacherhh said:
Once again j_medved...
did it look likes this, wenn you run mke2fs ?
Regards,
teacherhh
Click to expand...
Click to collapse
Don't remember what it was for me (was a month ago ) , but another couple users that ran it had the following:
Code:
~ # mke2fs -j -b 4096 /dev/block/mmcblk0p8
mke2fs -j -b 4096 /dev/block/mmcblk0p8
mke2fs 1.40.8 (13-Mar-2008)
Warning: 256-byte inodes not usable on older systems
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
1831424 inodes, 7311872 blocks
365593 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=0
224 block groups
32768 blocks per group, 32768 fragments per group
8176 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
4096000
Writing inode tables: 52/224
Couple users that were hosed, were stuck at this point. Did not see any indication of resolution for those users
Driver Problems
Hi Guys,
I've the same problem. I can't wipe the Data, so I've found this instruction. unfortunenately will my PC not found my Tab. I've installed the drivers many times, but it will not work. Can anybody help, how to install? btw. fastboot is working, but not adb.
I'm using an Samsung Netbook with Win 7. THe PC's trying to install drivers, altough they are already installed, but can'T find any drivers.
If you need more informations, just let me know.
@Benninator,
If you look in Windows 7 Device Manager, does the device show up there OK? Or does it show up as unrecognized device, or as some device code with a yellow triangle and exclamation on it? Or not at all?
Yes, their is a yellow triangle. I've tried to install the driver manually, but with no success. In my driverlist were the Acer driver not listed. furthermore I've tried to configure the usb-adb.ini with also no success. I have absolutly no idea what I can do.
In device manager, and does it show up as a200 or unknown device?
Is the device I am recovery at the time?
And also, and which recovery?
Tab is missing recovery and won't boot in to android
FASTBOOT WORKS BUT I GET THIS MESSAGE EVERY TIME I TRY TO FLASH RECOVERY.IMG says unknown partiton 'C:\James\Downloads\recovery.img'
error: cannot determine image filename for 'C:\James\Downloads\recovery.img'
Please help me
jram0421 said:
FASTBOOT WORKS BUT I GET THIS MESSAGE EVERY TIME I TRY TO FLASH RECOVERY.IMG says unknown partiton 'C:\James\Downloads\recovery.img'
error: cannot determine image filename for 'C:\James\Downloads\recovery.img'
Please help me
Click to expand...
Click to collapse
I think you may be mistyping the command. What is the exact command that you are typing in that gets you this error?
cant get adb drivers installed in my pc
adb driver seems not to work at all when i try to boot my tablet on cwd when i boon on fastboot only fastboot recognice my device and when i let my acer a200 try to boot itself it gets stuck on acer screen whit this on top ( bootloader version 0.03.06-ics ) but windows recognice it but fails when installing the mtp usb drivers.
what can i do to get adb working so i can fix my mount issues so i can install my room again ?
hope you can help me tnks

EU bug fix guide!!!!!!!!! actuall fix NOT external sd workaround

ok so first boot into recovery make a nandroid than remove your external sdcard and download the odin flashible semaphore kernel for vibrant from semaphore.gr (be sure its the newest one) now go to download mode and flash that. as soon as its done it will reboot and you want to reboot into recovery. next plug it into your pc while still in recovery mode and run the adb devices command to be sure your devie is connected and recognized now go to adb shell and run these commands hitting enter after each line
parted /dev/block/mmcblk0
print
rm 1
rm 2
and what that does is removes all your partitions so just do rm X for each partition number you have puting a space between rm and whatever number you have. now go back to download mode and flash Eugene_2E_JK2_Froyo.tar heres a link to download http://d-h.st/VGX. and your going to go through the process of everything flashing in oden. besure to flash that as pda. than you will be at stock recovery and you will get the ant mount bla bla bla or if it boots straight to the rom to thats fine. and now go to settings and format internal sdard under storage settings your external sdcard should still be REMOVED now after thats done reboot and you should have a fully working vibrant. this fixed mine. if it doesnt work tell me hope i helped
also works with captivate and facinate too!!
First and foremost, thanks for posting this guide.
I'm gonna' run through this right now. Wish me luck. :fingers-crossed:
if it doesnt work tell me
N00B_IN_N33D said:
First and foremost, thanks for posting this guide.
I'm gonna' run through this right now. Wish me luck. :fingers-crossed:
Click to expand...
Click to collapse
if it doesnt worl tell me
Would it sound messed up if I wanted to EU my phone just to try this lol nice find C looks like a really nice guide
Sent from my Nexus 7 using xda app-developers app
Not 100% working yet sorry people
But im putting alot of work into it.
Sent from my SGH-T959 using xda premium
LOL
So I attempted your guide...and the good news is that i was able to access recovery right after flashing the sephamore kernel .tar in odin. The bad news on the other hand is that I was unable to execute the adb shell commands you've listed in your guide. I got an error stating that "there is no such file or directory". So I skipped the commands and flashed ICS passion v13 and it booted!!! but only to be followed by the dreadful "Encryption Unsuccessful" screen lol.
I took a screenshot of the EU screen by pressing the power button hoping to upload it here for you guys to see...but this is where things got really strange. So I removed the battery, sdcard, and inserted the sdcard into my pc to look for the screenshot and it wasn't there!!!. So this means that the screenshot was saved to the internal memory. I can sense I am getting closer to fixing my old vibrant.
Stay tuned
Like Merio I, too, flashed the Semaphore kernel via ODIN.
But unlike him, I cannot access Recovery.
fham said:
Like Merio I, too, flashed the Semaphore kernel via ODIN.
But unlike him, I cannot access Recovery.
Click to expand...
Click to collapse
Try the following commands in adb.
adb devices
adb remount (might fail but don't worry)
adb reboot recovery
i use devil kernel to access the recovery.....but at 'parted /dev/block/mmcblk0' this step i got the same as merio90
Yeah devil or semaphore. Semaphore is just easer to boot to recovery
Sent from my SGH-T959 using xda premium
Update
Well after 5+ hours of countless rebooting and flashing/modding I have failed to bring my vibrant back to life. However... I was able to go real deep into the device's storage hardware both internal and external(sdcard) and discovered that the internal storage is alive and functioning. In other words it is not hardbricked or physically damaged as a result of the EU bug...it is just corrupted and unable to mount.
Furthermore I attempted several times to create or recreate the partions on the internal sdcard but It just would not allow me to do so. By the way this is all done using the "parted /dev/block/mmcblk0" command(s). Hopefully there is some one who understands how to use this "parted" function in adb as this can be a very useful tool in restoring our devices back to normal.
Here are some helpful details I have learned in the process of all of this...
For those who are having trouble entering the commands in the guide make sure you are entering a space in between "parted" and "/dev/..."
At first I forgot to enter the space and as a result I got an error reading "no such file or directory" so make sure to include the space.
adb shell >>>>>>>>>>> Don't forget to enter this command first...won't work otherwise.
parted /dev/block/mmcblk0 >>>>>>> mmcblk0 is the external sdcard (at least in my case it is) while mmcblk0p1 is the internal sdcard (in my case)
print >>>>>>>> This command list the specifications for the storage device mmcblk0 along with some other useful information.
rm 1 >>>>>>>> This removes partition 1
rm 2 >>>>>>>> This removes partition 2 (if existent)
While still using the "parted" function in adb shell you can simply type "help" and it will give you all the details on how to use this useful tool.
Well I guess that is all I can say for now. Thanks again cannondale...your guide was certainly helpful and allowed me to learn more about this EU bug and how it is "bricking" our devices. This is certainly a step forward in the right direction...I am confident we will have this EU bug squashed pretty soon once and for all.
signing off.
@merio90 i did a lot of research on the EU BUG read my thread.... http://forum.xda-developers.com/showthread.php?t=2176108
manu_ha2001 said:
@merio90 i did a lot of research on the EU BUG read my thread.... http://forum.xda-developers.com/showthread.php?t=2176108
Click to expand...
Click to collapse
Thanks manu...this isn't the first time I've read your thread concerning the EU bug. I simply ignored it at first because it seemed a bit too technical at the time. But now that I've gone through this guide cannondale has provided your thread certainly makes more sense. I'll get back to working on this case soon.
So has anyone besides the OP gotten this to work?
well cannondale has
Merio90 said:
... This is certainly a step forward in the right direction...I am confident we will have this EU bug squashed pretty soon once and for all.
Click to expand...
Click to collapse
@Merio90 ... Just wondering if you made any further progress on the matter. Thanks to cannondaleV2000 for opening these doors and to Merio90 for the detailed posts (esp. concerning syntax). Very interesting thread.
I gave it a go but no nookie for me. In a nutshell, GNU Parted only appears to work on the external sdcard (mmcblk0p1) and not on the internal. Here are my results (after numerous attempts).
RECOVERY ACCESS
My observations flashing Semaphore JB .tar's (after a fresh Odin to Eugene_2E_JK2_Froyo.tar).
* Hangs on Semaphore splash: 2.9.21v, 2.9.15sv, 2.9.12sv.
* Recovery access successful: 2.9.21sv, 2.6.5v, 2.5.0sv
EXTERNAL SD REMOVED:adb shell
# parted /dev/block/mmcblk0
parted /dev/block/mmcblk0
Error: Could not stat device /dev/block/mmcblk0 - No such file or directory.
adb shell
# parted /dev/block/mmcblk0p1
parted /dev/block/mmcblk0p1
Error: Could not stat device /dev/block/mmcblk0p1 - No such file or directory.​EXTERNAL SD INSERTED:adb shell
# parted /dev/block/mmcblk0
parted /dev/block/mmcblk0
Error: Could not stat device /dev/block/mmcblk0 - No such file or directory.
adb shell
# parted /dev/block/mmcblk0p1
GNU Parted 1.8.8.1.179-aef3
Using /dev/block/mmcblk0p1
Welcome to GNU Parted! Type 'help' to view a list of commands.​So ... it's rather curious that cannondaleV2000 actually had access to his mmcblk0 while others weren't so lucky. That's the obvious key to using the parted functionality on the internal sdcard. If only we could break through that road block ... and return to the internal sdcard holy grail!! Any thoughts?
@yosup
No I have not made any progress other than the info I have already posted. My vibrant is no longer my daily driver, my Galaxy Nexus is... so my apologies for not giving this issue a higher priority.
I was only able to "fix" my vibrant to the point where I was able to use the SD card swap method many of us have attempted. In case you were unaware I had to take some extra steps as my vibrant was totally screwed up. It was unable to read either internal or external sdcard so that was an obstacle I had to overcome and that's how cannondale's guide was able to help me. So as of today no progress has been made...I haven't really worked on this problem in quite a while now so any progress has come to a halt for now...until someone comes up with a new guide On another note, the good news is that I have yet to encounter the EU bug on JB 4.2.2 (AOKP M1). So those who are using the sdcard swap method you should try a JB ROM...they seem to not be vulnerable to this EU bug.
Sent from my Galaxy Nexus using xda app-developers app
Try this
http://forum.xda-developers.com/showthread.php?p=44794873
Sent from my GT-I9505 using xda premium

[HELP] mmcblk0p7 flashed with recovery.img

Hello, I think I have did a big mistake.
I was trying to install CWM via Terminal Emulator with this command:
dd if=/sdcard/cwm.img of=/dev/block/mmcblk0p7
Then I know what mmcblk0p7 was not the recovery partition, but it is a PER partition.
Until now, my device is still on because I didn't reboot/turn-off it. I'm afraid if I reboot it, then it will die because mmcblk0p7 was flashed with wrong image.
Does anybody know how to fix it, or is it safe if I reboot my device? It has been 4 days of no reboot until I'm sure it's ok for reboot.
Thanks in advance!
What exactly lies in the mmcblk0p7 partition?
MOVZX said:
Hello, I think I have did a big mistake.
I was trying to install CWM via Terminal Emulator with this command:
dd if=/sdcard/cwm.img of=/dev/block/mmcblk0p7
Then I know what mmcblk0p7 was not the recovery partition, but it is a PER partition.
Until now, my device is still on because I didn't reboot/turn-off it. I'm afraid if I reboot it, then it will die because mmcblk0p7 was flashed with wrong image.
Does anybody know how to fix it, or is it safe if I reboot my device? It has been 4 days of no reboot until I'm sure it's ok for reboot.
Thanks in advance!
Click to expand...
Click to collapse
PER - Per device provisioned data or per device calibration.
A cursory scout around XDA suggests this contains sensor calibration and such like.
http://forum.xda-developers.com/showthread.php?t=1739119
(edit: checkout the last posts by osm0sis - this guy knows his stuff when it comes to partitions).
I'm pretty sure it isn't the BOOTLOADER partition...
I would tentatively suggest you're OK for a reboot. I can't think of what else you can do, to be honest.
-----------
If you must flash a recovery using the dd command use the by-name syntax...
su
dd if=/sdcard/recovery.img of=/dev/block/platform/sdhci-tegra.3/by-name/SOS
Rgrds,
Ged.
@GedBlake
Thanks for the info. I was asking, because if it didn't vary from device to device I could probably dd up a backup of the partition and upload it here for the user to dd into his partition in his tablet.
That being said, I'll keep an eye on this thread for further consequences or the like.
@MOVZX
Please state whether you have a Grouper or Tilapia device, and the approximate manufacturing date, if known.
The PER partition is formatted as a FAT filesystem**. It seems to contain measurement data created during factory testing procedures. See here.
Note that there seem to be differences from device to device (compare the two posts in the above link). Here are the two critical questions:
1) What is the exact FAT format? (There are a couple of different FAT variants)
2) Does the bootloader read this partition during hardware initialization?
I seem to remember a thread here in the Nexus 7 forums where someone was claiming to adjust the ambient light sensor by altering a file in the PER partition. If that is correct, then indeed this partition *could* be critical to correct operation of the device.
I think you are being prudent about not rebooting. I also think that you should find someone to volunteer to give you a raw image dump (dd) from a device that is as close to yours as possible. Note that like many other devices, the N7 has hardware variants, and the PER partition seems to reflect that.
The calibration data for your device is now permanently lost, and you are the unfortunate experimenter who will find out the consequences of that.
**If you can not get someone to help you, the issue of the filesystem formatting can be solved by one of us by:
- raw dumping our PER partition, loopback mounting it, removing all files, unmounting it, and then giving that to you.
At least you would then have the correct filesystem formatting, but empty.
Also, please do a
dd bs=1024 of=/dev/null if=/dev/block/platform/sdhci-tegra.3/by-name/PER
to let us know what size your partition is.
@MOVZX
I did a little more poking around. What I had recalled about the lightsensor thing was users reporting mods to a setting in
/data/lightsensor/AL3010_Config.ini
not the file of the same name in the PER partition.
The file in PER (of this same name) appears to have the same value (1382) on my tablet in both the above location as well as the file in PER. I don't know if that really means anything though.
I looked through the ASCII strings in the bootloader image (v 4.18) to see if there was any evidence of the bootloader using the file names in the (intact) PER partition. There was no evidence of this happening whatsoever. Does that mean that the bootloader does not read the PER partition? No, but at least there is no direct evidence of that nature that it does. That is certainly hopeful for you.
I dumped my own PER partition to have a look at it. It is definitely FAT32, but probably was not created with a variant of 'mkdosfs' - more likely a BSD tool, as it has a "BSD 4.4" OEM name. I tried to erase/remove files from a copy of my PER image; unfortunately the linux "shred" utility doesn't really do it's job correctly. I failed trying to create an identical (blank) image using 'mkfs.vfat' - I couldn't get the FAT header data identical to the FAT32 headers in the from-the-factory image in the PER partition on my device.
None of this might be important, though. It is possible that the only reason that there is manufacturing data on the tablet is if Asus wanted to look at aging effects for units returned for RMA (or subjected to shake-n-bake testing).
good luck with your tablet - let us know how everything turns out.
bftb0 said:
@MOVZX
I did a little more poking around. What I had recalled about the lightsensor thing was users reporting mods to a setting in
/data/lightsensor/AL3010_Config.ini
not the file of the same name in the PER partition.
The file in PER (of this same name) appears to have the same value (1382) on my tablet in both the above location as well as the file in PER. I don't know if that really means anything though.
I looked through the ASCII strings in the bootloader image (v 4.18) to see if there was any evidence of the bootloader using the file names in the (intact) PER partition. There was no evidence of this happening whatsoever. Does that mean that the bootloader does not read the PER partition? No, but at least there is no direct evidence of that nature that it does. That is certainly hopeful for you.
I dumped my own PER partition to have a look at it. It is definitely FAT32, but probably was not created with a variant of 'mkdosfs' - more likely a BSD tool, as it has a "BSD 4.4" OEM name. I tried to erase/remove files from a copy of my PER image; unfortunately the linux "shred" utility doesn't really do it's job correctly. I failed trying to create an identical (blank) image using 'mkfs.vfat' - I couldn't get the FAT header data identical to the FAT32 headers in the from-the-factory image in the PER partition on my device.
None of this might be important, though. It is possible that the only reason that there is manufacturing data on the tablet is if Asus wanted to look at aging effects for units returned for RMA (or subjected to shake-n-bake testing).
good luck with your tablet - let us know how everything turns out.
Click to expand...
Click to collapse
Interesting stuff, bftb0, as always...
So what, in your opinion, is the worst case scenario?
If the bootloader is still accessible, couldn't the OP just fastboot flash back to stock?
(Assuming a simple reboot doesn't fix it).
Or does this not touch the PER partition? I would have thought that running the flash-all.* script would reset all partitions back to their default values.
I'm probably missing something here, so apologies - just a suggestion.
Rgrds,
Ged.
@GedBlake
The factory install procedure doesn't touch anything but the "usual suspects".
We sort of already know what the worst case is. As to whether to bootloader "needs" the PER partition or not, I don't really know. At this point my bet is that it does not, but that is purely an educated guess.
@MOVZX
I am attaching a "PER-empty.zip" file to this post. It is tiny because it is an almost empty FAT32 filesystem image (PER.img), so it compressed by nearly 100%. (When you unzip it, the "PER.img" image file should be 5,242,880 bytes, or 5120 kB) If you want to, feel free to un-zip it, and then flash the extracted "PER.img" file to the PER partition on your device.
Assuming you are using adb from your PC with the custom recovery still running:
Unzip PER-empty.zip, then
Code:
adb push PER.img /sdcard/PER.img
adb shell dd if=/sdcard/PER.img bs=1024 of=/dev/block/platform/sdhci-tegra.3/by-name/PER
What this will do is install an almost empty FAT32 filesystem which was created with the exact parameters used on my device. (I assume that your device also has a 5120 kB PER partition, but you have not replied.) The almost part is that I truncated every file in my image to zero length.
That's not much, but at least you will have a valid filesystem and most files of the correct name, even if they are zero length.
Note that once you have a filesystem in the PER partition, you are free to mount it using the custom recovery, and do whatever you please, e.g.:
Code:
adb shell mkdir /data/local/tmp/permount
adb shell mount -t vfat /dev/block/mmcblk0p7 /data/local/tmp/permount
adb shell
$ cd /data/local/tmp/permount
... do whatever you want in here...
$ sync
$ exit
adb shell umount /data/local/tmp/permount
adb shell rmdir /data/local/tmp/permount
good luck with your tablet - let us know how everything turns out.
.
I'm using Nexus 7 WiFi 16GB.
I almost have all the required files. The sensors and lightsensor directories were found mounted at /data/sensors and /data/lightsensor, so I copied it.
Here is the content of my sensors & lightsensore files:
lightsensor/AL3010_Config.ini
1476
Click to expand...
Click to collapse
sensors/AMI304_Config.ini
921368
2048 2048 2048
0 0 0
600 600 600
210 42 -256
0 0 0
0 0 0
103 100 101
0
Click to expand...
Click to collapse
sensors/KXTF9_Calibration.ini
1071 -1035 1034 -1030 -1097 1213
Click to expand...
Click to collapse
The FAT partitions is now Ok.
Now, I'm missing these files:
adc-rawdata.csv
ISN
KXTF9_Calibration.ini
prom-filter-rawdata.txt
rawdata.csv
rek-prom-rawdata.txt
SSN
Click to expand...
Click to collapse
I'm having no confidence to reboot this device yet

Kobo Arc Development

So I was randomly flying around on Google today, and I noticed that someone had claimed to root the Kobo Arc, and gave written instructions here -- http : // www . mobileread . com / forums / showthread.php?p=2584491 (Remove the spaces, XDA won't let me post an actual link, since I don't have 10 posts yet). After running through this myself, I went on the Google Play store and used root checker. Much to my surprise, it worked, and my device now has root access. I even tested with Root Explorer, and mounted the system partition as R/W, and I can move things in and out of it. I'm currently working on trying to get a custom ROM working, but I'm worried that I will cause a brick, since Cyanogen doesn't support the Arc. (yet...)
ThunderBird2678 said:
So I was randomly flying around on Google today, and I noticed that someone had claimed to root the Kobo Arc, and gave written instructions here -- http : // www . mobileread . com / forums / showthread.php?p=2584491 (Remove the spaces, XDA won't let me post an actual link, since I don't have 10 posts yet). After running through this myself, I went on the Google Play store and used root checker. Much to my surprise, it worked, and my device now has root access. I even tested with Root Explorer, and mounted the system partition as R/W, and I can move things in and out of it. I'm currently working on trying to get a custom ROM working, but I'm worried that I will cause a brick, since Cyanogen doesn't support the Arc. (yet...)
Click to expand...
Click to collapse
confirmed, was just going to post this but was beaten to it.
http://www.mobileread.com/forums/showthread.php?t=218928
ive attached the file but please go to that website and pay homage to whoever did this work...now to the next stop, a ROM
Device now has a working custom recovery see post 15
Sent from my Arc using xda app-developers app
dazza9075 said:
confirmed, was just going to post this but was beaten to it.
http://www.mobileread.com/forums/showthread.php?t=218928
In terms of a ROM do we not need a compatible boot loader that will allow unsigned ROMs?
ive attached the file but please go to that website and pay homage to whoever did this work...now to find a man about a ROM
Sent from my Arc using xda app-developers app
Click to expand...
Click to collapse
i have absolutely no idea what im doing but I think I have dumped 12 partitions using
dd if=/dev/block/mmcblk0p10 of=/sdcard/p10.img
is there anyone around that fancies a challenge? im in a position where bricking this thing isn't really much of a problem so if someones up for a challenge and wants to help im willing to lend myself and the device to this
Warning : Block of Text Ahead.
dazza9075 said:
confirmed, was just going to post this but was beaten to it.
In terms of a ROM do we not need a compatible boot loader that will allow unsigned ROMs?
ive attached the file but please go to that website and pay homage to whoever did this work...now to find a man about a ROM
Sent from my Arc using xda app-developers app
Click to expand...
Click to collapse
Haha. As soon as I found a thread called "root the Kobo Arc" on Google, I posted it here right away. Sorry if I deprived you of the satisfaction! *troll*
Joking aside, I'm not too sure about the bootloader. I think it's pretty locked down (since I put a nexus 7's cyanogenmod onto the data partition and rebooted. It tried to updated, but said validation failed, or something of that sort). I can't install any custom recoveries either, since I have no idea how to do it in the first place, and there's none made for the Arc.
Also, I analyzed the Arc with the "Droid Examiner" App from the play store (That is a really great app, just so you know), and found that it uses a board called "zeus". The funny thing, though, is that one of Sony's Xperia phones, also has a board called "Zeus", and there's Cyanogenmod for that (albiet not the latest version). However, these two devices have nothing in common. The closest thing to an Arc that has Cyanogenmod is the Nook HD/HD+, which uses the exact same chip (OMAP TI 4470).
If someone is smart enough (not me) to analyze the Cyanogenmod files for the Nook, and see how they work, that may lead into flashing the Arc.
Anyway, I'm resetting the Arc, since I'm having weird cases where the Arc would freeze after booting it from sleep mode, and I'd have to turn it off and on again. I think that was something else I did, since it happened before the root, but neh, I might as well try this all from factory default settings.
Sorry for the block of text, guys!
P.S. Using the stock Jelly Bean boot animation on the Arc looks amazing!:laugh:
Haha, its cool, like yourself I just happened to Google kobo arc root and for once my googe fu was up to the task and the root appeared
I've been looking at starting my own recovery mod branch but its no simple task by the looks of it, if their are similar devices we can use all their data and tweak it to ours which would help a lot!
Oh I think we have fast boot, I held vol down and pushed power on, it just sat at the kobo arc screen, I used the nexus 7 driver from the universal adb/fastboot driver I found on here and it connected up http://forum.xda-developers.com/showthread.php?t=2263822
I stumbled on some to good to be true program on Xda dev that apparently can root anything and unlock any bootloader once your in fastboot mode. I have tried that part and it said it was successful but i have no idea how to test this out yet, the program does a bunch of other stuff too, the adb stuff worked as did apk sending, and the rooting options knew i was rooted, it also has flashing functions, I'll be damed if I can find it now I'm at home though , I'll have another look.
I don't mind doing leg work but if someone can read the map it would be very helpful!
Edit, found it
http://forum.xda-developers.com/showthread.php?t=2399385
http://www.mediafire.com/?vwxpq62pa927s9c
Sent from my Arc using xda app-developers app
dazza9075 said:
Haha, its cool, like yourself I just happened to Google kobo arc root and for once my googe fu was up to the task and the root appeared
I've been looking at starting my own recovery mod branch but its no simple task by the looks of it, if their are similar devices we can use all their data and tweak it to ours which would help a lot!
Oh I think we have fast boot, I held vol down and pushed power on, it just sat at the kobo arc screen, I used the nexus 7 driver from the universal adb/fastboot driver I found on here and it connected up http://forum.xda-developers.com/showthread.php?t=2263822
I stumbled on some to good to be true program on Xda dev that apparently can root anything and unlock any bootloader once your in fastboot mode. I have tried that part and it said it was successful but i have no idea how to test this out yet, the program does a bunch of other stuff too, the adb stuff worked as did apk sending, and the rooting options knew i was rooted, it also has flashing functions, I'll be damed if I can find it now I'm at home though , I'll have another look.
I don't mind doing leg work but if someone can read the map it would be very helpful!
Edit, found it
http://forum.xda-developers.com/showthread.php?t=2399385
http://www.mediafire.com/?vwxpq62pa927s9c
Sent from my Arc using xda app-developers app
Click to expand...
Click to collapse
Um... Okay. I've installed the drivers (I think I installed them correctly), and I booted my device using "volume down + power". I have it connected to my System, but whenever I try to use one of the options in the Android Root Toolkit, it tells me it's waiting for the device. I don't know what I did wrong, but something's clearly not working.
As far as the recovery goes, I think that looking at the Nook Tablet from TWRP would work quite nicely. It runs on a similar processor ( I believe it's a OMAP TI 4430 ), and it seems to be quite similar in specs to the Arc. If only I was a bit better at programming...
ThunderBird2678 said:
Um... Okay. I've installed the drivers (I think I installed them correctly), and I booted my device using "volume down + power". I have it connected to my System, but whenever I try to use one of the options in the Android Root Toolkit, it tells me it's waiting for the device. I don't know what I did wrong, but something's clearly not working.
As far as the recovery goes, I think that looking at the Nook Tablet from TWRP would work quite nicely. It runs on a similar processor ( I believe it's a OMAP TI 4430 ), and it seems to be quite similar in specs to the Arc. If only I was a bit better at programming...
Click to expand...
Click to collapse
im usig the generic android adb driver and the bootloader driver for fast boot
im dumped all partitions and mapped them all out, see below for file system details
But again I'm blindly stabbing in the dark and most tutorials are a bit lacking in depth or not relevant to the kobo :/
Sent from my Arc using xda app-developers app
127|[email protected]:/ # blkid
/dev/block/dm-2: UUID="57f8f4bc-abf4-655f-bf67-946fc0f9f25b" TYPE="ext4"
/dev/block/dm-1: UUID="57f8f4bc-abf4-655f-bf67-946fc0f9f25b" TYPE="ext4"
/dev/block/dm-0: UUID="57f8f4bc-abf4-655f-bf67-946fc0f9f25b" TYPE="ext4"
/dev/block/mmcblk0p12: UUID="57f8f4bc-abf4-655f-bf67-946fc0f9f25b" TYPE="ext4"
/dev/block/mmcblk0p11: UUID="57f8f4bc-abf4-655f-bf67-946fc0f9f25b" TYPE="ext4"
/dev/block/mmcblk0p10: UUID="57f8f4bc-abf4-655f-bf67-946fc0f9f25b" TYPE="ext4"
/dev/block/mmcblk0p4: UUID="57f8f4bc-abf4-655f-bf67-946fc0f9f25b" TYPE="ext4"
[email protected]:/ #
Okay, so I can't even push apps to the Arc using ADB. I think you have to boot into recovery (power + volume up). I don't know how to use the terminal at all (I'm lost, I know D: ), so I don't have that installed on the Arc. I remember being able to do ADB even with my Sony Reader (First gen, PRST1), so I'm not sure why the Arc isn't quite working. I have both drivers installed, BTW.
As for the recovery, I can't even find a method to flash it. I'm still trying everything I can, though. :\
Sent from my Arc using xda app-developers app
ive mapped out the following partitions and any info ive found about each of them, im not in a position to help at the moment, got a big day at work tomorrow, as mentioned above ive used several tools,
SuperSU,
ROM toolbox pro
busybox
remount
Below is a list of all the available partition names and numbers
/dev/block/mmcblk0p1 xloader
/dev/block/platform/omap/omap_hsmmc.1/by-name/xloader
348KB
/dev/block/mmcblk0p2 bootloader
/dev/block/platform/omap/omap_hsmmc.1/by-name/bootloader
1.50MB
/dev/block/mmcblk0p3 cypto
/dev/block/platform/omap/omap_hsmmc.1/by-name/crypto
Completely empty
64KB partition size
/dev/block/mmcblk0p4 EFS
Mounted as /FACTORY
/dev/block/mmcblk0p4:UUID="57f8f4bc-abf4-655f-bf67-946fc0f9f25b" TYPE="ext4"
/dev/block/platform/omap/omap_hsmmc.1/by-name/efs /factory ext4 ro,relatime,barrier=1,data=ordered 0 0
20MB
/dev/block/mmcblk0p5 misc
/dev/block/platform/omap/omap_hsmmc.1/by-name/misc
Completely empty
128KB partition size
/dev/block/mmcblk0p6 Bootlogo
/dev/block/platform/omap/omap_hsmmc.1/by-name/bootlogo
Contains kobo arc picture
4MB partition size
/dev/block/mmcblk0p7 Logos
/dev/block/platform/omap/omap_hsmmc.1/by-name/logos
contains the battery charge logo
28MB partition size
/dev/block/mmcblk0p8 recovery
/dev/block/platform/omap/omap_hsmmc.1/by-name/recovery
data contains a GZ file, when decompressed we get a 8.5MB file of unknown type, exact same as in boot
5MB of data
16MB partition size
/dev/block/mmcblk0p9 boot
/dev/block/platform/omap/omap_hsmmc.1/by-name/boot
data contains a GZ file, when decompressed we get a 8.5MB file of unknown type, exact same as n recovery
4.5MB of data
8MB partition size
/dev/block/mmcblk0p10 CACHE
Mounted as /CACHE
/dev/block/mmcblk0p10: UUID="57f8f4bc-abf4-655f-bf67-946fc0f9f25b" TYPE="ext4"
/dev/block/platform/omap/omap_hsmmc.1/by-name/cache /cache ext4
rw,nosuid,nodev,noatime,errors=panic,barrier=1,nom blk_io_submit,data=ordered 0
0
768MB partition size
/dev/block/mmcblk0p11 SYSTEM
Mounted as /SYSTEM
/dev/block/mmcblk0p11: UUID="57f8f4bc-abf4-655f-bf67-946fc0f9f25b" TYPE="ext4"
/dev/block/platform/omap/omap_hsmmc.1/by-name/system /system ext4
rw,relatime,barrier=1,data=ordered 0 0
910MB partition size
/dev/block/mmcblk0p12 USERDATA
Mounted as /DATA
/dev/block/mmcblk0p12: UUID="57f8f4bc-abf4-655f-bf67-946fc0f9f25b" TYPE="ext4"
/dev/block/platform/omap/omap_hsmmc.1/by-name/userdata /data ext4
rw,nosuid,nodev,noatime,errors=panic,barrier=1,nom blk_io_submit,data=ordered 0
0
12GB partition size
Watching with interest. The root works. No frills CPU installed and working. There may be hope for this thing yet:good:
Moved to new thread and more appropriate forum - keep up the good work guys
im not sure that's going to work you know, ive had some permission errors with adb which suggests the root isn't full, terminal on the device works fine, but adb just has some problems, adb shell and the su seems to fix them.
http://www.gadgetsdna.com/android-terminal-adb-shell-command-list/1168/
http://www.addictivetips.com/android/make-nandroid-backups-on-android-without-booting-into-recovery/
im busy today but ive found these useful
i think Clockwork Recovery should be our focus at this point or if you have dumped your partitions(?) attempt to construct a rom for later use
or this should work too
Install any Custom Recovery with flash_image:
Just like the previous method, this method also requires following advanced steps and is not recommended if the first method is working for you. flash_image is a tool for Android devices that lets you rewrite your phone’s system partitions with partition image files and installing it to your device requires ADB. If you don’t already have ADB installed, check out our guide on installing ADB. Once you have ADB installed, flash the custom recovery image as follows:
WARNING: It is very important that the recovery image that you use in this method is compatible with your device. Else it will not work and flashing it could possibly brick your device.​
Download flash_image and extract it from the zip file to a location on your computer. We extracted it to the main C drive (not in any folder) and will use that in the next steps.
Copy the recovery image for your phone to a convenient location on your computer, preferably with a short path. We will be placing it on the C Drive directly (not in any folder) and using that in the next steps.
Note: The recovery image should have .img extension. If it is in a zip file, extract the .img file from it.
Enable USB debugging mode on your device from Menu > Settings > Applications > Development.
Connect your device to your computer via USB.
Open a Command Prompt window on your computer and enter the following commands: adb push c:\flash_image /sdcard/adb push c:\recovery.img /sdcard/adb shellsumount -o remount, rw /systemcp /sdcard/flash_image /system/bincd /system/binchmod 777 flash_imageflash_image recovery /sdcard/recovery.imgThis will first transfer flash_image and recovery.img to your phone. Then it will copy flash_image to the /system/bin folder of your Android device and make it executable. Finally, it will flash the custom recovery image to your device using flash_image.
Note that we used c:\flash_image and c:\recovery.img in the first two lines as we had these files extracted at the root of our C drive. If you extracted the files elsewhere, use the appropriate paths and if your recovery image has a different name, use the appropriate name.
Reboot your device once the process is finished and you’re done. You may exit adb and the Command Prompt window on your computer by entering ‘exit’ thrice.
dazza9075 said:
im not sure that's going to work you know, ive had some permission errors with adb which suggests the root isn't full, terminal on the device works fine, but adb just has some problems, adb shell and the su seems to fix them.
http://www.gadgetsdna.com/android-terminal-adb-shell-command-list/1168/
http://www.addictivetips.com/android/make-nandroid-backups-on-android-without-booting-into-recovery/
im busy today but ive found these useful
i think Clockwork Recovery should be our focus at this point or if you have dumped your partitions(?) attempt to construct a rom for later use
or this should work too
Install any Custom Recovery with flash_image:
Just like the previous method, this method also requires following advanced steps and is not recommended if the first method is working for you. flash_image is a tool for Android devices that lets you rewrite your phone’s system partitions with partition image files and installing it to your device requires ADB. If you don’t already have ADB installed, check out our guide on installing ADB. Once you have ADB installed, flash the custom recovery image as follows:
WARNING: It is very important that the recovery image that you use in this method is compatible with your device. Else it will not work and flashing it could possibly brick your device.​
Download flash_image and extract it from the zip file to a location on your computer. We extracted it to the main C drive (not in any folder) and will use that in the next steps.
Copy the recovery image for your phone to a convenient location on your computer, preferably with a short path. We will be placing it on the C Drive directly (not in any folder) and using that in the next steps.
Note: The recovery image should have .img extension. If it is in a zip file, extract the .img file from it.
Enable USB debugging mode on your device from Menu > Settings > Applications > Development.
Connect your device to your computer via USB.
Open a Command Prompt window on your computer and enter the following commands: adb push c:\flash_image /sdcard/adb push c:\recovery.img /sdcard/adb shellsumount -o remount, rw /systemcp /sdcard/flash_image /system/bincd /system/binchmod 777 flash_imageflash_image recovery /sdcard/recovery.imgThis will first transfer flash_image and recovery.img to your phone. Then it will copy flash_image to the /system/bin folder of your Android device and make it executable. Finally, it will flash the custom recovery image to your device using flash_image.
Note that we used c:\flash_image and c:\recovery.img in the first two lines as we had these files extracted at the root of our C drive. If you extracted the files elsewhere, use the appropriate paths and if your recovery image has a different name, use the appropriate name.
Reboot your device once the process is finished and you’re done. You may exit adb and the Command Prompt window on your computer by entering ‘exit’ thrice.
Click to expand...
Click to collapse
I've already tried that recovery method (I spent about two hours just googling), and it doesn't work with the Arc. The ADB won't let me push the image over.
As for Cyanogenmod, I tried something yesterday. A person on the Mobileread forums (apparently a Kobo employee) put out an update.zip file for the Kobo Arc. The file was quite old, and it's really just the 4.1.1 update that (I hope) we're all running. He said that as long as you put it on the root of the data partition, the Arc will flash it immediately. When I tried taking a Nexus 7's Cyanogenmod file and sticking it in the same place, the Arc started flashing it, but then just said there was an error with the update. So I personally think that you do require a properly signed ROM.
However, if you open up Kobo's update.zip using Winrar, a sidebar pops up that says "signed by SignApk". I don't know too much about this, but couldn't we use this "signapk" to sign our own ROMS and flash them?
Just a thought.
​
ThunderBird2678 said:
As for Cyanogenmod, I tried something yesterday. A person on the Mobileread forums (apparently a Kobo employee) put out an update.zip file for the Kobo Arc. The file was quite old, and it's really just the 4.1.1 update that (I hope) we're all running. He said that as long as you put it on the root of the data partition, the Arc will flash it immediately. When I tried taking a Nexus 7's Cyanogenmod file and sticking it in the same place, the Arc started flashing it, but then just said there was an error with the update. So I personally think that you do require a properly signed ROM.
However, if you open up Kobo's update.zip using Winrar, a sidebar pops up that says "signed by SignApk". I don't know too much about this, but couldn't we use this "signapk" to sign our own ROMS and flash them?
Just a thought.
Click to expand...
Click to collapse
I think there is a problem with the setup, I just flashed a CW recovery image and it worked, or didn't rather! but the concept did, transferred, flashed using adb, I had to replace it though as it was totally borked and kept restarting, apparently the touch based recovery methods can be like that, ill have some good time tomorrow night (UK time) if your about, and ill keep at it tonight if I get a chance!
copy recovery to adb location
adb push recovery.img /sdcard/
adb shell
su
cat /sdcard/recovery.img > /dev/block/platform/omap/omap_hsmmc.1/by-name/recovery
exit adb shell and type
adb reboot recovery
fixed it by holding power button and vol down to boot to fastboot recovery
then ran
fastboot flash recovery inputrecovery.img
inputrecovery being my original recovery file taken from partition 8!
ive updated the partition map on the post above with my progress, but it looks like we can flash to them my name so its probably less relevant now
oh ive ditched the drivers I was using and reinstalled the drivers from the official SDK, generic android adb for within android and android bootloader for fastboot
EDIT
Yaaas!! recovery replaced
ok, deleting or renaming /etc/install-recover.sh appears to have stopped custom recovery being changed back to stock after reboot, I used the recovery builder to make a build from partition 8, which it did without error, flashed using the above commands.​
Still don't know what im doing though, but progress is progress ​
ill post a link to the custom recovery ive made soon, we need to make up some fstab file listing all the mounts etc, i tried one but it must be borked as recovery couldnt see anything​
​
ok i have a working recovery http://jenkins.cyanogenmod.com/job/recovery/35325/artifact/
its not quite done, i need to mount the sdcard, its physical location is mounted, ie /data, but its virtual mount isn't /storage/sdcard
I have asked for some help so hopefully someone can help be on this, I think it needs to be symlinked
im going to need some help soon, so if your reading this with a kobo arc, I need you! im needing a hand folks! if your stuck getting this far let me know and we can PM to get it working
oh and recovery is also now persistant by deleting or renaming /etc/install-recover.sh"
Sorted folks!
I have made a stable and thus far, a working custom recovery.
its mounting everything and backing up / restoring works as it should, unless anyone can find any issues I consider this step in building a complete ROM completed,
you must have root, download arctic.apk and install on your tablet, you will need to enable unknown sources In dev options first
you must have android and java sdk also installed, you will need to add the google usb drivers in the android sdk, you will find them in the "extras"
Enable usb debug on the arc and install the generic google adb usb drivers
Delete or rename /etc/install-recover.sh this will make the custom recovery persistent
Copy the recovery.img to the SDCard, either by using drag and drop in windows ( to root of "internal storage") or by adb push, if you use adb push then remember to copy recovery.img to the same folder as adb
adb push recovery.img /sdcard/
The next job is to open up a command window and navigate to adb folder, type the following exactly, even better copy and paste them!
adb shell
su
cat /sdcard/recovery.img > /dev/block/platform/omap/omap_hsmmc.1/by-name/recovery
exit adb shell (ctrl+C) and type
adb reboot recovery
and bobs your uncle, one happy new recovery
Thanks for your hard work. Everything works quite well.
Sent from my Arc using Tapatalk 4
cancuck said:
Thanks for your hard work. Everything works quite well.
Sent from my Arc using Tapatalk 4
Click to expand...
Click to collapse
that's the easy bit, I have a feeling I need to make a couple of changes to the recovery.img but noting major, just a couple of other mounts I may have missed
I probably would like some help with the next bit however.
im just trying to build a development platform, I have a loathing for Linux as a desktop so will need to re educate myself without throwing my laptop out of the window, after that "challenge" the ROM should be easy
Well, I've just done it, and it works. Everything seems to be in order for the time being. I'm going to muck around with the new capabilities, and see what I can do.

[Tutorial] LG Gpad v410 5.1 to 4.4 downgrade, root, & internal storage fix.

EDIT: If you are coming here for the first time, this guide should still work, but @PorygonZRocks has created a flashable zip that should deal with a lot of these issues automatically. You can check out his post here:
https://forum.xda-developers.com/showpost.php?p=75787067&postcount=699
This method will indirectly allow you to root the LG Gpad v410 after it has been upgraded to Lollipop 5.1.1. Yes. Rooting LG v410 Lollipop. It's through a downgrade, but it works.
It took a while to get working, but here's how I did it. The process is straightforward, but the details matter greatly. You will brick your device if you mess up. Please read everything *first* before you do anything. Be sure you understand the process. I'll try to explain what's going on along the way.
An external SD card is extremely helpful for this process. You *could* adb push everything, but that will tedious.
First, you need some files.
The 4.4.2 KDZ which is a TEST OS, but it can be rooted and it downgrades to a Bump'able bootlaoder:
http://forum.xda-developers.com/g-pad-10/general/kdz-lg-g-pad-7-0-v410-t3224867
The LG 2014 Flash Tool:
http://www.mediafire.com/download/fwrcd3pdj0svjtb/LG_Flash_Tool_2014.zip
Android LG Drivers:
https://www.androidfilehost.com/?fid=24052804347802528
Parted for Android. You can probably find it other places, but I found this file:https://dl.dropboxusercontent.com/u/84115590/LG%20G2%2016GB%20Solution/sdparted-recovery-all-files.zip
EDIT: There seems to be a lot of confusion here. My bad. All you need is the file named "parted" from this zip file - nothing else. Just put that one file in the root of your external SD card.
https://dl.dropboxusercontent.com/u/84115590/LG G2 16GB Solution/sdparted-recovery-all-files.zip linked from here: http://www.**********.com/your-32gb-lg-g2-shows-only-16gb-storage-space-heres-the-fix/
EDIT2: The dropbox link is down. I've attached the file directly.
The Candy5 ROM (This will potentially save you some manual steps. Somewhat optional, but highly recommended):
http://forum.xda-developers.com/g-pad-10/development/rom-candy5-g-pad-v410-lollipop-5-1-1-v2-t3111987
Flashify APK:
http://www.apkmirror.com/apk/christian-gollner/flashify/flashify-1-9-1-android-apk-download/
TWRP for the v410:
http://forum.xda-developers.com/g-pad-10/development/recovery-twrp2-8-5-0lgv400-410-t3049568
LG One Click Root:
http://forum.xda-developers.com/lg-g3/general/guide-root-lg-firmwares-kitkat-lollipop-t3056951
(You may use Purple Drake or whatever else you want. They all use the same root script as this does and the GUI is helpful for novices.)
Android SDK (specifically adb.exe. After installing go to SDK Manager and ensure that Android SDK Platform Tools is checked):
http://developer.android.com/sdk/index.html
For clarification below, when I have commands in "quotes" they are Windows commands. When they are in `backticks` they are commands that you run inside of ADB which actually run on your device....as root. Root can screw things up. Please be extra cautious. If you blame me for messing up your device I will laugh at you. But that's not gonna happen, right? Good. Let's go.
Now that you have everything, put it all into a folder where you can access it easily.
Install the LG Drivers.
Install Android SDK (or otherwise get adb.exe).
Extract all of the archives.
Move the KDZ to the LG Flash Tool 2014 folder.
Put the tablet into Download Mode by powering it off, holding VolUp, and plugging in the USB cable. Press VolUP when instructed. You must be in Download mode before continuing.
Run LGFlashTool2014.exe. Select the KDZ file. Click "CSE Flash". Click "Start". Select "English" and click OK. Do not change anything else.
WAIT for the flash to continue. If you really want to brick your device, here's a good opportunity.
The device will reboot into Android 4.4.2. You will only have 4GB of internal storage at this point. DON'T PANIC! We are fixing it.
Enable USB debugging.
Connect the device.
Install and run LG One Click Root. Wait for the device to be rooted before proceeding.
Copy the Flashify apk, TWRP image, and Candy5 ROM to your external SD card.
Install Flashify and flash TWRP to the recovery partition.
Use the Flashify menu to reboot in to recovery.
DON'T PANIC! You will get white vertical lines on the boot screen from now on. They only show up during boot animations. A small price to pay. This may be fixed at a later date. for the time being! Thanks to marcsoup's first post ever, we have a fix! Details below. PLEASE click this link and thank him!
Things get tricky here. Copy parted to your external SD card and then run "adb shell" from Windows to get a shell in TWRP.
In TWRP, unmount /data by tapping Mount > uncheck Data.
`cp /sdcard/parted /sbin/` This copies the parted binary to /sbin so it can be executed in the path. I had trouble running `/sdcard/parted`, but YMMV.
`chmod +x /sbin/parted` Make it executable.
`parted /dev/block/mmcblk0` Run parted against the internal mmc
`p` Prints the partition table.
`rm 34` Deletes partition 34 labeled "grow". This is the root of our problem. The KDZ apparently only creates a 4GB partition, I assume so the test build has maximum compatibility with all sized devices.
`rm 33` Deletes partition 33 "userdata"
`p` Print to verify
`mkpartfs` Create a partition and put a filesystem on it. If we only expand the partition it won't help us because the filesystem is still only 4 GB.
a) name: userdata
b) type: ext2 (the tool only supports ext2. This is ok for now.)
c) start: 3439MB (the end of part 32. IT MAY BE DIFFERENT FOR YOU!) Be sure you do not omit the MB part otherwise the offset will overwrite another critical partition.
d) end: 15.8GB (where "grow" ended above. IT MAY BE DIFFERENT FOR YOU!) Be sure you do not omit the GB part otherwise the offset will overwrite another critical partition.
`p` Verify. For me it did not name the partition properly. Gotta fix that.
(if necessary) `name 33 userdata` This is critical for mount to find it in /dev/block/platform/msm.sdcc.1/by-name/ on some/all ROMS.
`p`. Verify one last time. Compare it to my partition table in the attachments. If you want to brick, delete some random partitions here.
Flash Candy5 with TWRP. It's only 239 MB, so it will flash quickly. I do this because Candy5 will reformat mmcblk0p33 from ext2 to ext4 for you. It does this as part of it's system boot, apparently. If you install a different ROM that does not do this, you can reformat it by running `make_ext4fs /dev/block/mmcblk0p33`. If your ROM does not have make_ext4, it likely has some differnt method to make an EXT4 filesystem. `/system/bin/mke2fs -t ext4 /dev/block/mmcblk0p33` may work better. Just flash Candy5 and be done with it.
Tap Wipe > Swipe to Factory Reset.
Tap Reboot > System.
WAIT!!! It will take a minute for the ROM to start the first time. You will have white lines and and possibly a white screen. WAIT. It's moving the DEX files to cache, formatting a partition, creating default folders on the internal storage, and several other things. WAIT! When the screen goes dim or turns off then it's ready.
Cycle the display or turn it on. You should be at the Candy5 lock screen.
USB debugging is on by default. Run "adb shell".
`mount | grep userdata` Make sure mmcblk0p33 is mounted.
`df` Make sure /data is 11.3 GB (or whatever size it is on non-16GB devices).
HELL YEAH, you downgraded, rooted, and fixed the partition problem. Enjoy your tablet!
Thanks to dopekid313 for finding the KDZ.
Thanks to timmytim for Candy5.
Thanks to the creators of the root script, flashify, TWRP, and XDA for being so awesome.
Thanks to marcsoup for fixing a fix to the white lines.
Thanks to navin56 for the partition dumps. PLEASE thank his post!
White lines fix.
What we are going to do is flash the aboot partition with the stock image provided by navin56. I've removed the extra files from the dump, so simply download aboot.img.7z below. Unzip it using 7zip.
These commands are to be run in TWRP. Reboot to TWRP recovery and connect with "adb shell". All of the following commands will be run in ADB under TWRP. If you cannot figure out how to get here, please post in the thread and someone will help you. Onward:
If you do everything correctly then you don't have to reflash your ROM and you won't lose data. This process can be done any time after flashing the KDZ, even before you follow the steps above to resize the userdata partition. It's a completely separate process.
Unzip aboot.img.7z so you have the file named aboot.img. You should also make sure that aboot.img's MD5 sum is e97431a14d1cee3e9edba513be8e2b52. Do not flash the 7z file. Please.
Copy aboot.img to your external SD card. It should live at /sdcard/aboot.img
Boot to TWRP and run "adb shell"
`ls -al /dev/block/platform/msm_sdcc.1/by-name/` Let's make sure we are flashing the right partition. On my device "aboot" is /dev/block/mmcblk0p6. You should verify this on your device or you WILL brick your tablet.
`dd if=/dev/block/mmcblk0p6 of=/sdcard/aboot-fukt.img` Let's back up our current aboot partition before we go flashing things just in case there are unintended consequences later. Be sure you have the same partition that "aboot" referred to in the 4th step or you have just backed up the wrong partition.
`dd if=/sdcard/aboot.img of=/dev/block/mmcblk0p6` Be sure the file exists, is the correct aboot.img, and you are flashing the right partition. You have been warned!!
Reboot TWRP and enjoy your boot animations again.
If I missed anything, please let me know. As far as I know this is the very first tutorial that details what is necessary to accomplish this. Please hit the Thanks button on every thread that you visit to download files!
FAQ:
Q: Why do I only have 11.3 GB of space when my device is 16GB?
A: The entire internal SD card (eMMC) is 16 GB. Gotta have someplace to install the bootloader, recovery, android, the modem OS, the secondary bootloader, the cache, the resource and power manager, and all of the other partitions necessary for the table to operate. Please look at the second screenshot in the OP. All of those 33 partitions take up room on the internal card. Fortunately ALL of those partitions ONLY take up about 4.4 GB. Hence the 'userdata' partition is ~11.3 GB.
If anyone wants to use my work to create a flashable zip to make it easier for novices, please do so. My problem is solved and I don't have the time to create the zip. Please post any questions and I'll gladly answer them! I'm so stoked that we have a usable downgrade method now!
Thank You, Worked Great
Thanks for making this I was gonna do it but was to lazy lol and thanks for linking my thread and giving cred instead of just linking straight to the kdz thank you
grandamle91 said:
Thank You, Worked Great
Click to expand...
Click to collapse
Glad to be of help!
dopekid313 said:
Thanks for making this I was gonna do it but was to lazy lol and thanks for linking my thread and giving cred instead of just linking straight to the kdz thank you
Click to expand...
Click to collapse
Of course! If you hadn't obtained the firmware then we'd all still be looking for a solution. It pisses me off to no end when people try to take credit for other people's work. We all just need to realize and acknowledge that we are simply standing on the shoulders of those who did the work necessary for each of us to do our work.
I just noticed since we formatted the userdata it screws up TWRP. It won't mount Data and it says the settings are corrupted
grandamle91 said:
I just noticed since we formatted the userdata it screws up TWRP. It won't mount Data and it says the settings are corrupted
Click to expand...
Click to collapse
Is this after you've rebooted into Candy5 and the partition is reformatted as ext4 (or you've done so manually)? TWRP may not be able to mount an ext2 partition.
EDIT: I just tested this. Following my instructions and flashing to Candy5, TWRP sees mmcblk0p33 (userdata) as the full size and mounts it at /emmc.
For clarification, after you run the parted commands, it will mess with the partition table and TWRP will most likely not be able to see it to remount it - at least not until after a reboot. This is why you need an external SD card from which to install ROMs.
/data not mounted
Edit: nevermind. The partition 33 was still ext2. I had to run make_ext4fs /dev/block/mmcblk0p33 and now I am able to mount /data. Thanks.
Thanks for taking the time to help us.
I followed the steps and till 33 I am good. But once I am in Candy5, I am not able to adb shell (adb not recognizing device eventhough usb debugging is on). I rebooted to recovery and adb works there. But my /data partition is not enabled in TWRP. I am not able to check it either under Mount in TWRP.
Code:
mount | grep userdata
is empty
Code:
df
does not show data
I tried this and my tablet bootlooped. I was able to get into fastboot and restore. I would GREATLY appreciate it if someone who has the time, would kindly donate their valuable time to into making an exe zip or something.
gridironbear said:
I tried this and my tablet bootlooped. I was able to get into fastboot and restore. I would GREATLY appreciate it if someone who has the time, would kindly donate their valuable time to into making an exe zip or something.
Click to expand...
Click to collapse
At what point did it bootloop? What was the last step that you took before rebooting?
Zip
I would really appreciate a zip file as I have never been savvy with adb and for whatever reason it doesn't want to work on Windows 10.
drumm3rb0y said:
I would really appreciate a zip file as I have never been savvy with adb and for whatever reason it doesn't want to work on Windows 10.
Click to expand...
Click to collapse
A zip file for what part? The only part that requires ADB directly is to fix the internal storage. You absolutely have to flash the KDZ and then root before you can do anything. If you are on 5.x then you have no possible way to root, much less flash a zip file.
If you tell me what exactly you are having issues with I will try to help.
fatbas202 said:
A zip file for what part? The only part that requires ADB directly is to fix the internal storage. You absolutely have to flash the KDZ and then root before you can do anything. If you are on 5.x then you have no possible way to root, much less flash a zip file.
If you tell me what exactly you are having issues with I will try to help.
Click to expand...
Click to collapse
The adb part is the part im having issue with. Everything else is flashed already. I was wondering if you could make a zip for the adb part so I can just flash it through twrp.
thanks for the great help. it did work perfectly to regain the lost space.
what about white lines ? is there any solution for that problem ?
I have tried flashing back stock recovery extracted from kdz, dd' but didn't help.
Now i am thinking of flashing back the aboot.bin extracted from original kdz or i can dump ".img" from another working device. (i have 4 similar devices)
what is your opinion i m not a developer and i need your advise. should i go ahead and which partition should i dd ? aboot or abootb or boot ?
regards
shahidmianoor said:
thanks for the great help. it did work perfectly to regain the lost space.
what about white lines ? is there any solution for that problem ?
I have tried flashing back stock recovery extracted from kdz, dd' but didn't help.
Now i am thinking of flashing back the aboot.bin extracted from original kdz or i can dump ".img" from another working device. (i have 4 similar devices)
what is your opinion i m not a developer and i need your advise. should i go ahead and which partition should i dd ? aboot or abootb or boot ?
regards
Click to expand...
Click to collapse
I have no solid evidence of this, but I suspect that the white lines are caused by a display driver issue where when the bootloader hands over control of the display to the kernel it doesn't get reinitialized properly. I have no ideas as to how to get rid of that at the moment but if I stumble across something I'll be sure to post here.
While I'm not an Android developer, I've been a Linux admin for 10+ years and have a lot of experience with Android devices. I'd be really hesitant to go flashing things ad hoc. While Download Mode may save you if you flash the wrong thing, I'm not entirely sure what the limitations that you may run in to with a locked bootloader are.
After having this device for months on 5.x and FINALLY being able to downgrade and run custom ROMs with root, not seeing a boot animation is a pittance to pay. But I'll keep looking.
i have same problem entered in TWRP but when ADB sheel thorough DP tools it didn't connect to my device. i m also using windows 10
Do I need to Re-mount Data ? I press format data button at TWRP and mount data. It looks work great.
After all process, it shows 16Gb total at storage, 11.04GB available. it works perfectly.
I need the stock V41010d, so I reflash the stock rom rooted at [ROM][STOCK](V410 ONLY)KOT49I.V4101d | 4.4.2 | Rooted + Busybox
Now, my Gpad is at stock V41010d, but I have a question about the boot screen, is it still with white lines and white screen? Any method to fix it?
Hello,
Thanks for the great work. unfortunately I am facing some difficulty, starting from step# 16 "Things get tricky here", how to run"adb shell in TWRP?
also can I use minimal_adb_fastboot_v1.1.3_setup.exe as mentioned in the link in the OP http://www.droidviews.com/your-32gb-lg-g2-shows-only-16gb-storage-space-heres-the-fix/ ?
also I noticed the path have been used includes 'parted' folder, but the folder I have after unzipping the parted zip called 'sdparted-recovery-all-files', do I rename the folder to 'parted' instead?
please help and excuse my broken English.
I'm also having trouble with the adb shell step. When my device is powered on normally, adb commands work. However, in TWRP mode my computer can't recognize the tablet, mount properly, and copy over parted. All the steps have been identical to this point. Any ideas?
iphone5sf said:
Do I need to Re-mount Data ? I press format data button at TWRP and mount data. It looks work great.
After all process, it shows 16Gb total at storage, 11.04GB available. it works perfectly.
I need the stock V41010d, so I reflash the stock rom rooted at [ROM][STOCK](V410 ONLY)KOT49I.V4101d | 4.4.2 | Rooted + Busybox
Now, my Gpad is at stock V41010d, but I have a question about the boot screen, is it still with white lines and white screen? Any method to fix it?
Click to expand...
Click to collapse
You shouldn't need to remount or format data. The parted command nukes the filesystem and creates a new one formatted as ext2. At this point the running kernel has the old partition table loaded and won't know that the partition has been extended. Simply flash Candy5 and reboot at this point and it will reformat the userdata partition.
See above for the white lines during the boot animation. Known issue, no fix in sight, doesn't really matter.
nmnm4alll said:
Hello,
Thanks for the great work. unfortunately I am facing some difficulty, starting from step# 16 "Things get tricky here", how to run"adb shell in TWRP?
also can I use minimal_adb_fastboot_v1.1.3_setup.exe as mentioned in the link in the OP http://www.droidviews.com/your-32gb-lg-g2-shows-only-16gb-storage-space-heres-the-fix/ ?
also I noticed the path have been used includes 'parted' folder, but the folder I have after unzipping the parted zip called 'sdparted-recovery-all-files', do I rename the folder to 'parted' instead?
please help and excuse my broken English.
Click to expand...
Click to collapse
You only need the sdparted-recover-all-files.zip from that site. "parted" is not a folder, but the binary (without a file extension) inside of that zip file. Copy that file to /sbin and you are in business.
zmali1 said:
i have same problem entered in TWRP but when ADB sheel thorough DP tools it didn't connect to my device. i m also using windows 10
Click to expand...
Click to collapse
summonholmes said:
I'm also having trouble with the adb shell step. When my device is powered on normally, adb commands work. However, in TWRP mode my computer can't recognize the tablet, mount properly, and copy over parted. All the steps have been identical to this point. Any ideas?
Click to expand...
Click to collapse
I'd recommend installing the SDK and pulling the drivers from that. Alternatively, you can try the drivers here: https://github.com/koush/UniversalAdbDriver.
Technically, when I ran the "parted" commands I was actually booted in to rooted 4.4.2 from the KDZ; I wasn't actually in TWRP. It's just not a very recommended way of going about it. I explained how to run all of this from TWRP, but there's no technical reason that you *can't* run this from Android. You just *shouldn't* because you can't cleanly unmount the filesystem and it theoretically could cause filesystem corruption. I just figured that I don't care about that partition getting corrupted since it's getting wiped out.

Categories

Resources