Related
Hello!
This is my first time posting, i normally am able to solve problems by looking through the forums, but this time not so i created an account and posted.
Any help that could be offered would be greatly appreciated.
The Story:
I have had the nook for around a year running CM7 or CM9, and last semester i took a programming class and programmed apps for android and ran them on my nook. i got acquainted to adb and am somewhat familiar with it. i remember when i started the serial number which adb used to Id the device was normal, but then around halfway through it simply became a string of zeros. so that is when the device lost its serial number I assume. Sadly this is not the main issue.
A week or so ago i was attempting to return my nook back to the stock Rom, and got it booting fine but it would not register because it was missing the serial number and Mac address. I looked through the forums and tried to fix it. i figured out it was stored in partition 2. looking in to it i could easy reflash other roms and they would work fine, and i tried restoring an old backup i had, which did not fix the problem ( i didn't think they affect that partition at all). eventually i stumbled upon lepinars repair partitions zip, and with nothing else working, i flashed the repair partition 2 zip in hopes the backup from partition 3 would have the correct serial number in it and restore the serial number. This put my device in a recovery bootloop. i am able to boot into cwm and talk to the device over adb, and i can flash new roms, but it will ONLY boot into recovery, no matter what rom it is ( i have tried CM7, CM9, sdcard install of CM7, and stock 1.0.1) . i figured out that it is because of a file on the mmcblk0p2 which i think was BCB, but there might be some other things affecting it.
So now you know what has happened, can anyone help me? I would like to get a Rom to boot into the normal mode, and then restore serial number / mac address so that it could be registered.
Once again, Thank you so much.
The problem is that without a valid serial number on partition 2, no rom will boot even if the recovery flag is set properly. It will just keep going to recovery.
If you have adb working, look at p2 and see if you have a devconf folder. If you do, look in it to see what files are there. There should be simple text files that have data in them. Like SerialNumber that has a 16 digit serial number in it (but the file is 17 bytes long so must have a linefeed on the end.) MACAddress is another, with a 12 digit number and no linefeed. 17 files total. All of them with rw-rw---- permissions.
Those files are usually backed up in partition 3 in a file named rombackup.zip. Unzip that zip manually and place them all in the devconf folder in partition 2. Set permissions as above.
Also you said you flashed my repair zip. Did it give you the message that it completed successfully? I have it set to abort if everything is not right.
Edit: Your serial number is stamped on the little flap that covers the micro SD card. It is also on your box the NC came in. If you cannot find the SerialNumber file in the backup zip, you could try manually creating it and putting in the right place.
Thanks. A week ago i was more familiar with this because i had just done a day or two of reading, but sadly a bit has slipped my mind.
ADB is working just fine when i boot into CWM, but i am having trouble finding partition 2. For some reason I recall a rom folder on the root level, but when i do an ls while in adb shell, all i see is this:
boot etc sd-ext
cache init sdcard
data init.rc sys
datadata proc system
default.prop res tmp
dev root ueventd.goldfish.rc
emmc sbin ueventd.rc
more random info still in adb shell)
when i do an fdisk -l /dev/block/mmcblk0
Disk /dev/block/mmcblk0: 7944 MB, 7944011776 bytes
255 heads, 63 sectors/track, 965 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
/dev/block/mmcblk0p1 * 1 9 72261 c Win95 FAT32 (LBA)
/dev/block/mmcblk0p2 10 18 72292+ c Win95 FAT32 (LBA)
/dev/block/mmcblk0p3 19 56 305235 83 Linux
/dev/block/mmcblk0p4 57 965 7301542+ 5 Extended
/dev/block/mmcblk0p5 57 114 465853+ 83 Linux
/dev/block/mmcblk0p6 115 236 979933+ 83 Linux
/dev/block/mmcblk0p7 237 281 361431 83 Linux
/dev/block/mmcblk0p8 282 965 5494198+ c Win95 FAT32 (LBA)
just in case any of that helps.
i have heard of partition two being /dev/block/mmcblk0p2 but that is not a directory, or at least it appears so to me and i cannot get any files from it. I recall when the nook was booting fine i did look into the rom folder and the serial number was there and was correct, but in the settings/about Tablet it was simply a string of zeros.
when i try to pull the rombackup.zip from p3, i get the error message "adb pull /dev/block/mmcblk0p3/rombackup.zip
remote object '/dev/block/mmcblk0p3/rombackup.zip' does not exist" , so i am assuming i am barking up the wrong tree there.
when i flashed the repair zip there were no error messages and i am fairly certain it completed successfully as i was not alarmed and simply tried to reboot it as normal. after I flashed the repair zip it would not boot into anything but recovery, and this is when the more serious issue ( it seems to me) arose.
I probably am simply doing something wrong here, still the same situation on my end.
you have to mount the partitions...
rom should have been automatically mounted to /dev/block/mmcblk0p2 but you can try to manually do it:
adb shell busybox mount /dev/block/mmcblk0p2 /rom
adb shell mkdir /backup
adb shell busybox mount /dev/block/mmcblk0p3 /backup
adb pull /backup/rombackup.zip
unzip rombackup to a folder..
push the files to /rom/devconf
DizzyDen -
Thank you for telling me about the partition mounting. this explains a lot.
i had to create the /rom folder as it was not there. when i mounted it and did an ls -a command, in /rom there was only a BCB file. in /backup there was only factory.zip and an empty folder called lost+found. so there was no rombackup.zip for me to pull and extract.
sert57 said:
DizzyDen -
Thank you for telling me about the partition mounting. this explains a lot.
i had to create the /rom folder as it was not there. when i mounted it and did an ls -a command, in /rom there was only a BCB file. in /backup there was only factory.zip and an empty folder called lost+found. so there was no rombackup.zip for me to pull and extract.
Click to expand...
Click to collapse
That probably is why my repair failed. Try creating the SerialNumber file I mentioned in my last post and put it in the folder devconf. You may have to make that directory first. Mkdir /rom/devconf.
leapinlar said:
That probably is why my repair failed. Try creating the SerialNumber file I mentioned in my last post and put it in the folder devconf. You may have to make that directory first. Mkdir /rom/devconf.
Click to expand...
Click to collapse
I successfully created the file SerialNumber and it was 17 bytes, i moved it to /rom/devconf and looked at its permissions, and for some reason a chmod wouldn't let me remove rwx from others and x from user and group, so the permissions were rwxrwxrwx (not sure if this would create an issue). i tried to re-install the repair zip. the text displayed is
(after finding, opening, and installing update)
Repair /rom partition (P2)
found /factory - be patient this could take a while
Done.
This is the same message i received earlier when i did this. so no failure message but i guess it aborted or something. After this is done the devconf folder is gone. rom is still there and i mount it, and once mounted the only file in Rom is the BCB file.
I did some testing and the SerialNumber file by itself is not enough to get it going. There are 16 others and one or more may be critical. I will keep playing and see if I can find which one it needs. I don't know why you don't have that backup file. It is really critical. I modified my partition 2 zip to give a little more information to the user.
Edit: I did some more testing and it booted only to recovery when I removed a file named BootCnt. It is a file with four bytes in it which are all null (00's). Try making one and pushing it to /rom/devconf and see if it will boot. There is also another file named BootCount also with four null characters, but it is still there and it is not booting to the rom. I think that is the one for 8 failed boots. (When I rebooted again it was ok, that file was back).
Edit2: I think I found it. There is a file named DeviceID that is identical to the SerialNumber file. When I delete that file it will no longer boot to a rom, only recovery. Try putting that file in /rom/devconf. I deleted everything in that folder but BootCnt and DeviceID and it booted to the rom.
Thank you so much!! The nook is finally able to boot successfully to a ROM. Major problem finished! I was originally intending to return it to stock, but I am not sure if that is now possible as I am missing all but 2 of the very important files. I'll give an update when I get closer to getting stock back. Hopefully it will work, but we will see. Thanks for helping me get at least this far.
I have a CWM flashable 1.4.3 stock zip here:
http://d01.megashares.com/index.php?d01=CiYdDmP
sert57 said:
Thank you so much!! The nook is finally able to boot successfully to a ROM. Major problem finished! I was originally intending to return it to stock, but I am not sure if that is now possible as I am missing all but 2 of the very important files. I'll give an update when I get closer to getting stock back. Hopefully it will work, but we will see. Thanks for helping me get at least this far.
Click to expand...
Click to collapse
I .have a complete recovery.zip file available when I get my PC monitor working again... complete with infllo about what files are edited... and how to edit them
I think they are in my deposit files share
That would be spectacular if you could provide that. I'm still attempting leapinlars download ( 3 failed times, WiFi here is VERY slow right now). Let you know what happens.
So I installed 1.4.3 to the nook. it got stuck at the silver n screen, so i did a volume up, power, and n button reset. after this it reset to factory and intalled an update. it booted sucessfully to the stock firmware. now when i try to register it it is missing the model number and mac address. im assuming i am just supposed to create the two files for the nook and place them in /rom/devconf. Could some more assistance be had for me about what goes into the files and such? Mac address has been missing since the problem began, so that is nothing new, but this is the first time ive booted to stock that model number was not there.
Model number is BNRV200 in ModelNumber. Product ID begins with P11 and ends with a linefeed and is 11 bytes total in ProductID. Event Type is Manufactured in EventType. Date manufactured is just a date. Mine was 01/29/2011 in DateManufactured. Device attribute is New in DeviceAttribute for me. MAC address is a 12 digit number in hex in MACAddress. Main board serial number is a 12 digit alphanumeric number in MainboardSN. Mine starts with QI11M. Backlight is a 6 digit alphanumeric number in backlight. Mine is 1476AY. Ean is a 13 digit number in ean. Mine starts with 97814005. There is an empty Platform file. There is BootCnt and BootCount, both with four nulls (00). There is a SerialNumber file identical to DeviceID. There are three other files. WiFiBackupCalibration with 468 bytes, PublicKey with 333 bytes and HashOfPrivateKey with 28 bytes.
Some of these you can make and some you can put phony info in them. Others, I don't know.
Could you provide more info on obtaining the Mac address and how to write it? After that I should be good, but we will see.
[edit]
install cm7.2 and it was in the settings, so i copied it down and put it on the device. reverting back to stock, i will see if it takes. i am assuming by your description the semicolons are not placed in the MACAddress file, so i did not do it.
[edit2]
looks like all i need is the hashprivatekey. when i went to the factory area a few were null, but that one said Not Okay. is there any way i can create this file? i tried registering but it would not, so i am assuming this is needed.
Unblock your private messaging on XDA. I want to send you a message. Or send me a private message with your email address in it.
Sent from my NookColor using Tapatalk
ok. it boots fine. when i register it will not let me, with the typical error, i look into the details and everything is green except battery percentage (which is low) and username which is nonexistant. when i check the factory tab it says that the battery type and backlight are !null, so i dont thing that would affect it. besides that i have everything.
One more thing to try. You can reset some of your settings like wifi calibration, etc by following this procedure. It may just re-populate some of those files in devconf. Use the one that resets things. Back up devconf first though.
http://nookdevs.com/NookColor_Factory_Mode/Skip_Out_of_Box_Experience
done that a few times. it doesnt really do anything but erase known wifi networks. would the fact its missing battery type and backlight mean anything for registration?
I would not think so. But I have a Nook Tablet that has different things in devconf, like BatteryType is MCNAIR and Backlight is 070B16730338ZN4AC15-4J8D6Y01577C5. (Notice it has a capital B in the name. I think I made a mistake in the earlier post.) The Tablet I think has the same screen as the newer Nook Colors.
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
HOW TO AVOID BRICKING YOUR TAB
The best advice I can give to people who haven't bricked their tab (already?^^) : DO NOT EVER WIPE ANYTHING WHILE RUNNING STOCK 7.7 ROMS
Here is what to do in order to flash a custom rom safely when coming from stock :
- Flash the latest cwm with ODIN
- Do NOT wipe anything
- Flash the custom rom of your choice
- Reboot recovery
- Wipe what you need to wipe
- Re-flash the custom rom
- flash the gapps or whatever
- Reboot, done.
Ok guys, I'm seeing more and more people bricking their 7.7 and, being one of the unlucky owners of a bricked p6810, I understand how stressful and annoying it can be.
I've been reviving my tab like a hundred times using this technique, as you'll most likely have to re-do that whole process everytime you wanna flash something.
There are two ways of reviving from superbrick I know of :
- The first is to flash a PIT file with ODIN that will repartition your tab for you.
I will not cover this method as hg42 already wrote a very detailed tutorial about this. This tutorial is about Galaxy Note but you can appIy it to our 7.7 and you'll find PITs for P6800 there. I will soon make pits for P6810 using the scripts provided in hg42's guide.
- The second way is to repartition your tab manually through adb. This is the method I'll try to teach you here.
Let's first be very clear :
- This won't get your tab back in its former state
- Your internal storage will shrink by a lot
- All your data will be lost
- No guarantee it works for you
- You'll most likely have to do that every time you flash
- Your tab might rebrick itself after some days, so you'll have to do this again, get used to it.
- If you can get Samsung to repair your tab then go ahead
- I'm not responsible for any further damage made to your tab
- You need a computer for this tutorial
Ok, you read the above carefully ? You are ok with it ? then let's begin !
Using the Android Debugging Bridge (adb) to revive your tab
Setting up your environment
Prior to anything, you need to download and install the android sdk, I won't cover the installation here, it's explained on developer.android.com and there are plenty of guides on how to get adb and the sdk on xda.
Make sure you install the platform-tools in the sdk manager.
Ok now I assume you got the sdk installed, so let's move on to the serious things.
1) How to open an adb shell ?
First, you're going to need the latest ClockWorkMod Recovery (a.k.a CWM), download and instructions on locerra's thread here
Then boot your tab in recovery (Maintain power+volume up buttons) and plug it into your computer via usb.
Then do the following :
a- On Windows
Navigate to the directory where you installed the sdk, and open the folder called "platform-tools" (e.g : go to C:\android-sdk\platform-tools if your sdk is installed in C:\android-sdk)
Press shift and do a right clic on an empty space in the folder, then select "open a command prompt here" (or something like that).
b- On Linux
Open a terminal window (ctrl+T)
Let's assume you put the sdk in a folder called "android-sdk", located at the root of your home folder (~/android-sdk).
Then you have to enter this in the terminal :
Code:
cd ~/android-sdk/platform-tools
So now, all the rest of the commands you'll have to enter are the same on windows and linux, as the adb shell will actually be running in your tablet.
2) Meet a new friend, he's called parted.
First, we are going to use parted to take a look at our partitions and their file systems, and eventually replace the corrupt partitions with clean, freshly created ones.
Then, you'll meet your other very good friend with a barbarian name : e2fsck (e2 stands for ext2, and fsck for file system check. Not that barbarian finally is it ?). He will check your filesystems and fix the possible errors they got.
Ok now we've made the presentations, let's go !
First make sure you read the following :
In the code boxes of this tutorial, there are symbols at each line start, DO NOT COPY IT with the rest of the command ! :
-the "$" represents your bash shell or command prompt
-the "#" represents the adb shell
-the"(parted)" represents the (parted) shell
-Each end of line means "press Enter".
-The partitions numbers are not the same on p6810 and p6800 (please report to this reference), so there will be two code boxes in the examples, one for p6810 and one for p6800, it's indicated in bold red but make sure you don't mix it up, that could screw your tab even more.
Ok here we go !
Issue the following in your terminal/command prompt :
Code:
$ adb shell
# parted /dev/block/mmcblk0
(parted) print
The output should look like this :
>>> P6810 <<<
Code:
Number Start End Size File system Name Flags
1 4194kB 25.2MB 21.0MB ext4 EFS
2 25.2MB 26.5MB 1311kB SBL1
3 27.3MB 28.6MB 1311kB SBL2
4 29.4MB 37.7MB 8389kB PARAM
5 37.7MB 46.1MB 8389kB KERNEL
6 46.1MB 54.5MB 8389kB RECOVERY
7 54.5MB 264MB 209MB ext4 CACHE
8 264MB 1137MB 872MB ext4 FACTORYFS
9 1137MB 15.3GB 4163MB ext2 DATAFS
10 15.3GB 15.7GB 470MB ext4 HIDDEN
11 15.7GB 15.8GB 8389kB FOTA
>>> P6800 <<<
The start/end values are wrong, please give me your p6800 output so I can update this.
Code:
Number Start End Size File system Name Flags
1 4194kB 25.2MB 21.0MB ext4 EFS
2 25.2MB 26.5MB 1311kB SBL1
3 27.3MB 28.6MB 1311kB SBL2
4 29.4MB 37.7MB 8389kB PARAM
5 37.7MB 46.1MB 8389kB KERNEL
6 46.1MB 54.5MB 8389kB RECOVERY
7 54.5MB 264MB 209MB ext4 CACHE
8 3054MB 3926MB 872MB ext4 MODEM/RADIO (not sure as I don't own this model)
9 264MB 1137MB 872MB ext4 FACTORYFS
10 1137MB 15.3GB 4163MB ext2 DATAFS
11 15.7GB 15.8GB 8389kB HIDDEN
12 15.8GB 15.9GB 8389kB FOTA
The superbrick MMC_CAP_ERASE bug that affects our tab apparently only corrupts the /system and /data partitions (sometimes, /cache can also get corrupt in the process, I cover this in the last part of this guide, "extra cases").
Your emmc chip on which resides those /data & /system partitions is corrupt at some places.
To give you an example, think of it as a chain of dashes :
Code:
-----------------------------------------------------
This dash chain is divided in two parts (our /system and /data partitions), I'll symbolize their length with "[]" for /system and "()" for /data :
Code:
[----------](-------------------------------------------)
So that's how it was on your tab before brick, but now it's bricked some blocks (the dashes "-" here) are corrupt. I'll symbolize them with "?" :
Code:
[--??--???-](--???-?-----------????-----------??-?--??--)
Now you figure the workaround don't you ? We need to move our /system & /data partitions to places that are clean, at the cost of reducing their sizes :
Code:
--??--???---???-?[-----------]????(-----------)??-?--??--
We will strive to give /system its original size, or something close to it, while we can sacrifice more of the /data partition.
Ok, enough theory, let's move on to practice.
Here, in parted, /system = FACTORYFS and /data = DATAFS
We are going to remove the /data partition first, so we have some space to work on.
Enter the following :
>>> P6810 <<<
Code:
(parted) rm 9
>>> P6800 <<<
Code:
(parted) rm 10
Now please refer to the output of (parted) print you had earlier, just scroll up a little in your terminal window. See those Start/End values ? Well check the end value of your DATAFS partition and remember it.
Here's an example for P6810 :
Code:
9 *START -->*1137MB 15.3GB*<-- END* 4163MB ext2 DATAFS
So now comes the boring part. We are going to try to make a new clean /data partition.
Seems easy but the problem is :
- if you try to make it too big, it'll get stuck and return an I/O error.
- if some blocks are corrupt between the start/end values you'll enter it will get stuck and return an I/O error.
In both cases you'll have to reboot recovery and re-enter this in your terminal :
Code:
# adb shell
# parted /dev/block/mmcblk0
So this is long and boring to find the right place and the right size. Don't be greedy on the size, as long as you get at least 150-200mb it's cool, you'll be able to expand that later.
First you're gonna try to put the original end value (15300 in the p6810 example up there) as the new end value. So for the same example, if you wanna try to make a 500mb /data partition, you're gonna use 14800 as start value and 15300 as end value.
Ok let's go (this is still an example for p6810, for the p6800 owners, use your own (parted) print results) :
Code:
(parted) mkpartfs primary ext2 14800 15300
It will output something like this :
Code:
writing per-group metadata : XX %
Here there are two options :
- You were lucky, it will complete up to 100% and return "(parted)", which case you just have to enter the following :
>>> P6810 <<<
Code:
name 9 DATAFS
>>> P6800 <<<
Code:
name 10 DATAFS
- You were not lucky, it got stuck before reaching 100%, which case you have to reboot your recovery, re-enter parted and try again with a smaller start/end gap, or reducing the end value, you got about 14gb of space to try to make your partition, so it's sure you can find somewhere to put your small partition, just requires some blind testing.
Just remember to try to put your /data partition quite close to the end (original end value), so you still have some space to find somewhere to put your /system partition.
So now we'll assume you managed to have mkpartfs complete till 100%
Type this to see your updated partition table :
Code:
(parted) print
Now we're going to repeat last step with the /system partition.
Issue this :
>>> P6810 <<<
Code:
rm 8
>>> P6800 <<<
Code:
rm 9
The /system partition is much more important than /data, so you want to try to have its size remaining the same (872mb).
At first, you can try to re-make the /system partition with the same start/end values. It's not likely to work but it's worth trying.
Here's an example on P6810:
(again, if you're on P6800, then use your own start/end values for the 9th partition (FACTORYFS), you get them by typing print in parted).
Code:
(parted) mkpartfs primary ext2 264 1137
Same thing here, if it doesn't complete, then reboot recovery, type :
Code:
$ adb shell
# parted/dev/block/mmcblk0
And repeat this step until you find somewhere it works : (where YYY - XXX = 872)
Code:
(parted) mkpartfs primary ext2 XXX YYY
Remember to limit your research between FACTORYFS original start value (264 for P6810) and the new DATAFS start value you made, so you keep the order of the partitions.
Once you found the right place (where "writing per-group metadata" completes till 100%), type this :
>>> P6810 <<<
Code:
name 8 FACTORYFS
>>> P6800 <<<
Code:
name 9 FACTORYFS
The hardest part is done, if you type this you should get a full table of partition, make sure no number is missing or disordered (1,2,3,4,etc...).
Code:
(parted) print
3) Meet another good friend : e2fsck
Now we've done our fresh and clean partitions, you must be thinking we're done, but we're not ^^
In fact the two partitions we made are using ext2 filesystem, but the /system partition's filesystem should be ext4 (like it was at the beginning).
There are two ways of converting an ext2 filesystem to ext4 that I know of :
- Simply formatting /system in cwm recovery will convert the filesystem to ext4. To do this, just head to "mounts & storages" and select "format /system".
If it gets stuck while formatting, reboot your recovery by pressing the power+volume-up buttons for about 15 seconds, and head to the next part, you have to do something before you can try to format it again.
- Or issuing this in terminal :
>>> P6810 <<<
Code:
# tune2fs –O dir_index,uninit_bg,has_journal /dev/block/mmcblk0p8
>>> P6800 <<<
Code:
# tune2fs –O dir_index,uninit_bg,has_journal /dev/block/mmcblk0p9
To make sure either of the two ways worked do this :
Code:
# parted /dev/block/mmcblk0
(parted) print
And look if FACTORYFS shows ext4.
If it does, reboot recovery, then on to next part. If it doesn't, then still reboot recovery and head to next part, after which I'll redirect you here to try again.
Now we are going to use e2fsck to check our new partitions for errors, but not only, it also fixes some erros and it will even for example create lost & found in /data
So let's go, we'll begin with /system. If you're still in the (parted) shell, use ctrl+c and type "adb shell", then issue the following :
>>> P6810 <<<
Code:
e2fsck -yfDC0 /dev/block/mmcblk0p8
>>> P6800 <<<
Code:
e2fsck -yfDC0 /dev/block/mmcblk0p9
This might take long, or not, this might get stuck, or not. Either way reboot recovery if it gets stuck or whatever, but do it again till it finishes properly.
This is what my /system e2fsck final output looks like (p6810) :
Code:
/dev/block/mmcblk0p8: ***** FILE SYSTEM WAS MODIFIED *****
/dev/block/mmcblk0p8: 2636/53312 files (1.2% non-contiguous), 101948/212890 blocks
If you got 0.0% or like less than 5% in "(X.X% non-contiguous)" this is a good sign.
Now reboot recovery and let's do the same for /data :
>>> P6810 <<<
Code:
# e2fsck -yfDC0 /dev/block/mmcblk0p9
>>> P6800 <<<
Code:
# e2fsck -yfDC0 /dev/block/mmcblk0p10
Same thing here, if it gets stuck then reboot recovery and do it again.
Here you should get 0.0% non contiguous. If you don't, in cwm do wipe data/factory reset, then reboot recovery and do this e2fsck again.
Ok now you got both clean e2fsck, (if you still have an ext2 FACTORYFS then now is the time to go back to try converting ext2 to ext4 again)
Make sure the e2fsck still are clean by doing this (it should be quick this time) :
>>> P6810 <<<
Code:
# e2fsck -cy /dev/block/mmcblk0p8
# e2fsck -cy /dev/block/mmcblk0p9
>>> P6800 <<<
Code:
# e2fsck -cy /dev/block/mmcblk0p9
# e2fsck -cy /dev/block/mmcblk0p10
Now you should be nearly good to go ! :laugh:
Download the cm9/cm10-based rom you want, make sure you check known issues and that you like this rom because everytime you'll want to flash a rom it's likely you'll have to do the whole e2fsck part again, or even sometimes the whole guide.
Now reboot in recovery and flash the rom. Two options :
- it flashes, then reboot, pray and be patient, if it takes more than 15 minutes to boot first time, then reboot it again, do this a few times if it doesn't boot, it might eventually do. If it doesn't, then reboot recovery and redo the e2fsck command for both /data and /system, let it fix things if it has to, then reboot again. Anyway it should have booted by now.
- flashing gets stuck : make sure you waited at least 5 minutes then reboot recovery---> wipe data/factory reset---> wipe dalvik cache---> reboot recovery---> adb shell and redo the e2fsck on both /data and /system, then try flashing again.
DO NOT FLASH THE GAPPS NOW, that will screw all you just done ! If you need the gapps then head to the following section of this guide.
4) Installing the gapps
If you flash the gapps after flashing the rom you'll be screwed, you'll have to redo the e2fsck part and maybe even the parted, and I know you don't want to.
So the workaround is to add the gapps to the cm-based rom you downloaded.
It's easy, just follow me :
Open the zipped rom you downloaded with 7zip or WinRar (Windows), or with Archive Manager or else (Ubuntu). Do not extract it, we'll modify the zip directly.
Do the same with the gapps, so you have both archive side to side.
In the rom, you have boot.img, and two folders : "META-INF" and "system". We will modify things in "system" folder ONLY. Open "system" folder.
In the gapps we will only use things from the "system" and "optional" folders.
The rest is pretty easy to figure out. In the gapps's "system" and "optional" folders you have folders which have the same name as some folders in "system" of the rom.
Just copy/replace everything that is in those folders of the gapps to the corresponding folders of the rom. Don't forget to do that with both "system" AND "optional" folders of the gapps.
When it's done just close the freshly modified rom, copy it to your tab's external sdcard and flash it.
If you don't have an external sdcard, then reboot recovery, copy the rom to the "platform-tools" folder of your android-sdk and rename it rom.zip.
Then return to your terminal and do the following :
Code:
$ adb push rom.zip /sdcard
It will now be in your internal sdcard (remember you shrinked it earlier so make sure the rom doesn't take all the space).
5) Expanding your internal storage
I don't recommend you do this the first time you follow this guide.
It might screw your /data partition so you have to do the whole process I describe in this guide again.
Anyway if you wanna try, this allowed me to earn a few extra gigs (never managed to get back more than 4gb and boot).
Here's what to do :
>>> P6810 <<<
Code:
$ adb shell
# parted /dev/block/mmcblk0
(parted) resize 9
>>> P6800 <<<
Code:
$ adb shell
# parted /dev/block/mmcblk0
(parted) resize 10
This will output something like :
Code:
Start ?
End ?
writing per-group metadata : XX %
You can only move the end value in fact, trying to change the start value will return an error. Try doing this to earn like 250mb at a time so it doesn't get stuck. Good luck.
6) Extra cases
If when booting in recovery, the recovery says something like "can't read /cache/recovery/last-log, Read-Only file system" then your /cache partition is corrupt.
Then you'll need to recreate it with parted. /cache is quite small (209mb) so it should be easy to have "writing per-group metadata" finishing.
Here are the commands to remove and recreate /cache with parted (it's the same on both models) :
Code:
$ adb shell
# parted /dev/block/mmcblk0
(parted) print
(parted) rm 7
(parted) mkpartfs primary ext2 XX YY (where YY - XX = 209 and YY < FACTORYFS start value)
Nice guide...dude. Thanks for sharing
i being running e2fsck -yfDC0 /dev/block/mmcblk0p10 on my p6800 since yesterday this time. till now still show error reading block *******<attempt to read block from filesystem resulted in short read> while getting next indoe from scan. ignore error? yes
force rewrite? yes
question now is should i let it keep running or change to e2fsck -fDC0 /dev/block/mmcblk0p10 ?? hmm
Josvaz said:
i being running e2fsck -yfDC0 /dev/block/mmcblk0p10 on my p6800 since yesterday this time. till now still show error reading block *******<attempt to read block from filesystem resulted in short read> while getting next indoe from scan. ignore error? yes
force rewrite? yes
question now is should i let it keep running or change to e2fsck -fDC0 /dev/block/mmcblk0p10 ?? hmm
Click to expand...
Click to collapse
Not sure but this "attempt to read block resulted in short-read" error remembers me of my own brick, I think it's the error you get when you can't mount /data in recovery's mounts & storages.
Try to mount /data and if recovery can't mount it, then u need to recreate your /data partition with parted, like it's explained in this guide.
e2fsck alone won't fix it if it's not mountable.
Just talking from my own experience, but there might be other ways.
two questions:
1) i read something about having to back up the /efs partition? as it contains your bluetooth mac id and your emei number before flashing any alternative pit file
2) when i try to start the android SDK installer it says "Java SE Development Kit (JDK) no found. </br> Error: Failed to find Java version for 'C:\Windows\system32\java.exe,' blah blah blah"--is it because i tried to install the jdk 64-bit?
---EDIT--- solved the installation problem. setting up android SDK now...
aletheus said:
two questions:
1) i read something about having to back up the /efs partition? as it contains your bluetooth mac id and your emei number before flashing any alternative pit file
2) when i try to start the android SDK installer it says "Java SE Development Kit (JDK) no found. </br> Error: Failed to find Java version for 'C:\Windows\system32\java.exe,' blah blah blah"--is it because i tried to install the jdk 64-bit?
---EDIT--- solved the installation problem. setting up android SDK now...
Click to expand...
Click to collapse
Well yeah you can backup your efs but if you follow exactly this guide there's no way you can mess up your efs, as it's the first partition and we only deal with partitons 8 to 10.
Not sure but this "attempt to read block resulted in short-read" error remembers me of my own brick, I think it's the error you get when you can't mount /data in recovery's mounts & storages.
Try to mount /data and if recovery can't mount it, then u need to recreate your /data partition with parted, like it's explained in this guide.
e2fsck alone won't fix it if it's not mountable.
Just talking from my own experience, but there might be other ways.
Click to expand...
Click to collapse
I guess e2fsck won't run if the partition you check isn't mountable.
But you're right that e2fsck can't fix everything, the method I describe is drastic but it works.
So Josvaz, if after running e2fsck - try any options you want, won't harm (but add -y so it answers yes to all and you can go have a coffee) - you see more than 2 or 3% in " XX.XX% non contiguous" then remove your partition and recreate it using parted's mkpartfs, and re-run e2fsck, it should now be clean (0.0% non contiguous) and you can flash on it and boot your tab if your /system is clean (or close to) too.
Good luck.
Androguide.fr said:
- The first is to flash a PIT file with ODIN that will repartition your tab for you.
I will not cover this method as hg42 already wrote a very detailed tutorial about this. This tutorial is about Galaxy Note but you can appIy it to our 7.7 and you'll find PITs for P6800 there. I will soon make pits for P6810 using the scripts provided in hg42's guide.
Click to expand...
Click to collapse
but if i use this method, do i need to back up the /efs partition? i guess, i need the experience with abd, and its certainly not going to hurt anything if i do, and didn't need to. so i'll try that and see if i get a response in the mean time.
hg42 said:
You should be able to flash any stock ROM from samfirmware (click on n7000 under "models"), I would recommend the one you had before the brick and and before any stock ICS, else you risk a brick again!.
Note: I think the standard recovery doesn't give you enough format options (a guess, I am running cm9).
Click to expand...
Click to collapse
is this possibly a way to avoid having to go through this process every few days or so?
aletheus said:
but if i use this method, do i need to back up the /efs partition? i guess, i need the experience with abd, and its certainly not going to hurt anything if i do, and didn't need to. so i'll try that and see if i get a response in the mean time.
Click to expand...
Click to collapse
Yeag for the PIT method, backing up your efs is wise, although the PITs won't mess with it normally. But yeah, can't hurt to back it up.
You don't need no experience with adb to flash a PIT, just know how to use odin, download the pit for your particular model (eg : p6800 16gb) put it in odin's "PIT" slot (the first slot), make sure repartion IS ticked, click start and let it flash.
giving up lol .. any thing i need to do before i send to samsung ? like original pit, rom etc? anyone have original pit file ?
Josvaz said:
giving up lol .. any thing i need to do before i send to samsung ? like original pit, rom etc? anyone have original pit file ?
Click to expand...
Click to collapse
Don't give up, follow the guide step by step, I assure you that you can get your tab finally booting if you do.
Androguide.fr said:
Yeag for the PIT method, backing up your efs is wise, although the PITs won't mess with it normally. But yeah, can't hurt to back it up.
You don't need no experience with adb to flash a PIT, just know how to use odin, download the pit for your particular model (eg : p6800 16gb) put it in odin's "PIT" slot (the first slot), make sure repartion IS ticked, click start and let it flash.
Click to expand...
Click to collapse
okay, but i need adb to back up /efs i think.
aletheus said:
okay, but i need adb to back up /efs i think.
Click to expand...
Click to collapse
Good for you xda recognized developer lyriquidperfection made a tool to backup and restore your efs on samsung devices, head to this thread : http://forum.xda-developers.com/showthread.php?t=1308546
hee i wanna quit cos i cant save more than half the space, manage 3.82GB left~
Androguide.fr said:
Yeag for the PIT method, backing up your efs is wise, although the PITs won't mess with it normally. But yeah, can't hurt to back it up.
You don't need no experience with adb to flash a PIT, just know how to use odin, download the pit for your particular model (eg : p6800 16gb) put it in odin's "PIT" slot (the first slot), make sure repartion IS ticked, click start and let it flash.
Click to expand...
Click to collapse
the efs back up, is that used from within adb, or flashed as part of a recovery or? in other words, how do i use it?
aletheus said:
the efs back up, is that used from within adb, or flashed as part of a recovery or? in other words, how do i use it?
Click to expand...
Click to collapse
It's not done from adb, some apps allow you to backup/restore it (eg : Voodoo Sim Unlock for sgs3), check out the thread I linked earlier.
The best advice I can give to people who haven't bricked their tab (already?^^) : DO NOT EVER WIPE ANYTHING WHILE RUNNING STOCK 7.7 ROMS
Click to expand...
Click to collapse
even on stock honeycomb ?????
am going to get a p6800 3g tomorrow, please don't scare me lol
sos_sifou said:
even on stock honeycomb ?????
am going to get a p6800 3g tomorrow, please don't scare me lol
Click to expand...
Click to collapse
Yeah whether hc or ics, for some reason, samsung devs thought it was a good idea to include mmc_cap erase a.k.a superbrick bug in their kernels.
Anyway I doubt you'd love to stay on y
touchwiz hc, which the most laggy experience I ever had.
sos_sifou said:
even on stock honeycomb ?????
am going to get a p6800 3g tomorrow, please don't scare me lol
Click to expand...
Click to collapse
it wont be a problem in honeycomb...
but its a big problem in ICS
Anyway I doubt you'd love to stay on y
touchwiz hc, which the most laggy experience I ever had.
Click to expand...
Click to collapse
yeah I don't think that i will keep using hc for long, but consider that most isc roms are pipi-caca (wifi issues and battery drain) Ill wait for some stable builds (just like overcome on my beloved "sold" GTP1000).
I think that dedraks made a new kernel which is without the brick bug ? is it safe to use with hc ??
and thanks for the great work you're doing on the new galaxy tab 7.7 (merci beaucoup !)
so i have not figured out how to get a working pit file flashed. there are so many, and i VAGUELY understand his numbering system, so i figured i'd start with the smallest available space first, because that one would be the most likely to account for any bad blocks. i tried nearly ALL of them. now i'm trying to test to see whether adb is able to access ANYTHING-- (tab is booting into recovery and download, and adb detects the device from windows) however, what i'm getting is "/sbin/sh: parted: not found" is that saying that parted cant be found or that parted cant find the reference block? researching this now.
so obviously, i've had to sit down and warm up to your NOOB GUIDE!!! its very clear, i just havent done this level of anything with android, tho what better way to learn than sink or swim? problem is, i'm an artist, and pretty broke.... my computer fried months and months ago, and i just decided i'd rather spend my extra cash on the gTab 7.7 cus is the largest affordable sAMOLED to date, and well, a 30% expansion of the standard color model really appealed to me, so the only thing i have to work on is my super bricked tab!!! a friend of mine is lending me her laptop while she's at work, and i'd like to try to fix it this evening.... ughh....
if anybody can help me figure out my way through this tutorial, i'll be researching why 'parted' isn't working.
THANKS!!!
---UPDATE
okay, so for some reason, i can't seem to push files from adb to the device. from what i've read, i have to manually install parted to sbin, (or there's a flashable kit available also) but i can't figure out how to get it to pick up the file (its in the folder with ADB.exe, so i shouldn't need to reference the path for the copy location, right?)
now i'm looking up general "ADB device navigation and testing"
---ugghhh....
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
Hello,
I managed to break my fingerprint reader. I don't think the problem is my /persist because all sensors work fine. But unfortunately, I had never backed up the rest of the sensitive partitions: vbmeta, vbmeta_system, keystore, keymaster, odm, core_nhlos, secdata, abl, cmnlib, cmnlib64, devcfg, dsp, hyp, xbl, xbl_config, tz, rpm, aging, aging_mod.
Could someone on a TMO 7t Pro 5G McLaren (with a working fingerprint reader preferably running the latest 10.0.35 software, please pull and post these partition img files? If you don't know how, it's very simple, please ask.
I point to this because my previous phone, Essential PH1, had similar issues, but at least Essential had posted all of the firmware images on their website every month, and flashing the above partitions would fix it. 1+ doesn't provide anything and even the MSM doesn't restore all of these partitions.
Thanks so very very much in advance!
Edit: If possible, could one extract all partition img files from 10.0.35 in addition to those requested above?
EDIT2: ODM partition has 1st priority for anyone who can help.
Edit3: odm is fine. After looking through some logs,
I need keystore, keymaster (_a or _b, whichever is your current slot), vbmeta (a or b), and vbmeta_system (a or b). None are very large I think.
You're making me want a backup. I thought MSM was supposed to be that for us. Irritating.
A couple of those look like they could have sensitive data. Anyone know of a reason not to post them? Looks like they are all available via /dev/block..
ttabbal said:
You're making me want a backup. I thought MSM was supposed to be that for us. Irritating.
A couple of those look like they could have sensitive data. Anyone know of a reason not to post them? Looks like they are all available via /dev/block..
Click to expand...
Click to collapse
If you don't already have a backup of every partition, please please please do so urgently. Or an RMA will most likely be in your future. That should be in huge bold print with a link to instructions at the very top of the root and bootloader unlock threads.
I've never had a device with these issues before. It's starting to get ridiculous.
Edit: If you didn't take backups before unlocking the bootloader, Widevine L1 support (being able to watch Netflix in HD instead of 480p crap on our giant beautiful screens) is lost forever (except for RMA). And just flashing a "bad" canary version of magisk was enough to kill the fingerprint sensor. Of course I didn't learn any of this until it was too late.
MSM will get your phone back to life but not fully heal it. Basically all the MSM is guaranteed to do is get the phone to boot. No sensors, no fingerprint, no Widevine L1, no IMEI and wifi Mac address fix (if one is really screwed). And 1+ didn't take any measures to protect the sensitive partitions once bootloader is unlocked. It's all just a clusterf**k
Same issues on 7T and 8 and 8pro if that makes you feel any better ¯\_(ツ)_/¯
Well, that's irritating. WTF wouldn't you have a recovery tool for all those? Interestingly, I don't seem to have odm in there at all. Ah, scratch that, it's in /dev/block/mapper and there are 3. _a, _b, -verity.
It's rpm I don't seem to have. 10.0.35.
ttabbal said:
Well, that's irritating. WTF wouldn't you have a recovery tool for all those? Interestingly, I don't seem to have odm in there at all. Ah, scratch that, it's in /dev/block/mapper and there are 3. _a, _b, -verity.
It's rpm I don't seem to have. 10.0.35.
Click to expand...
Click to collapse
Yeah, system, vendor, product, and odm are stored in super.img on Android 10. But u found it. Find out what slot you are on, running 10.0.35, and you'd want the _a or _b files that match your current slot.
ttabbal said:
Well, that's irritating. WTF wouldn't you have a recovery tool for all those? Interestingly, I don't seem to have odm in there at all. Ah, scratch that, it's in /dev/block/mapper and there are 3. _a, _b, -verity.
It's rpm I don't seem to have. 10.0.35.
Click to expand...
Click to collapse
I think you are right. Rpm doesn't exist possibly on this phone. Don't have time to research right now.
But I noticed in /dev/block/mapper, I only have _a and _b. No -verity file. For system, vendor, odm, nor product. Could you post the -verity file(s)?
What files/file sizes do you have in /odm/ ?
starcms said:
I think you are right. Rpm doesn't exist possibly on this phone. Don't have time to research right now.
But I noticed in /dev/block/mapper, I only have _a and _b. No -verity file. For system, vendor, odm, nor product. Could you post the -verity file(s)?
What files/file sizes do you have in /odm/ ?
Click to expand...
Click to collapse
Doesn't look really interesting to me, but here's the ls output.
Code:
OnePlus7TProNR:/sdcard/img # ls -l /odm
total 20
drwxr-xr-x 4 root root 4096 2008-12-31 17:00 etc
drwx------ 2 root root 16384 2008-12-31 17:00 lost+found
OnePlus7TProNR:/sdcard/img # ls -l /odm/etc
total 12
-rw------- 1 root root 2735 2008-12-31 17:00 build.prop
-r--r--r-- 1 root root 0 2008-12-31 17:00 fs_config_dirs
-r--r--r-- 1 root root 0 2008-12-31 17:00 fs_config_files
drwxr-xr-x 2 root root 4096 2008-12-31 17:00 selinux
drwxr-xr-x 2 root root 4096 2008-12-31 17:00 vintf
OnePlus7TProNR:/sdcard/img # ls -l /odm/etc/selinux/
total 728
-rw-r--r-- 1 root root 733547 2008-12-31 17:00 precompiled_sepolicy
-rw-r--r-- 1 root root 65 2008-12-31 17:00 precompiled_sepolicy.plat_sepolicy_and_mapping.sha256
-rw-r--r-- 1 root root 65 2008-12-31 17:00 precompiled_sepolicy.product_sepolicy_and_mapping.sha256
OnePlus7TProNR:/sdcard/img # ls -l /odm/etc/vintf/
total 16
-rw-r--r-- 1 root root 5300 2008-12-31 17:00 manifest.xml
-rw-r--r-- 1 root root 1369 2008-12-31 17:00 manifest_ese.xml
-rw-r--r-- 1 root root 622 2008-12-31 17:00 manifest_noese.xml
I can try, but my upstream sucks. It might be faster for someone else to grab them.
-rw-r--r-- 1 travis travis 816K Jun 4 15:40 img/odm-verity.img
-rw-r--r-- 1 travis travis 1.3G Jun 4 15:41 img/product-verity.img
-rw-r--r-- 1 travis travis 2.2G Jun 4 15:40 img/system_root-verity.img
-rw-r--r-- 1 travis travis 884M Jun 4 15:43 img/vendor-verity.img
After looking through some logs, you can ignore most of that.
I need keystore, keymaster (_a or _b, whichever is your current slot), vbmeta (a or b), and vbmeta_system (a or b). None are very large I think.
Thanks for all of your time @ttabbal. Sorry if I'm driving you crazy Been driving myself crazy trying to fix this for 2 weeks now lol
My /odm seems to be fine. Matches yours. I was mainly concerned about those 2 files with 0 size. But I don't have any of the -verity.imgs from /dev/block/mapper. I'm pretty sure they are supposed to be created and mounted at boot (from super.img and by verity/vbmeta). I'm hoping those 2 vbmeta partitions will fix things up. If not, then I'll try keystore and keymaster. And then I'll have to send it in...
Edit:. Just curious, I'm assuming you are bootloader unlocked and running Magisk? Just confirming since you have those -verity.imgs
ok.. Hope it helps.
https://drive.google.com/file/d/1a9FTbvdEM2n12wjc4SL7kNMu3SAtfuAY/view?usp=sharing
https://drive.google.com/file/d/15Ssumik6iMY7kWgldHfFajsbyNdh9aTz/view?usp=sharing
Yes, I am unlocked and rooted with Magisk.
ttabbal said:
ok.. Hope it helps.
https://drive.google.com/file/d/1a9FTbvdEM2n12wjc4SL7kNMu3SAtfuAY/view?usp=sharing
https://drive.google.com/file/d/15Ssumik6iMY7kWgldHfFajsbyNdh9aTz/view?usp=sharing
Yes, I am unlocked and rooted with Magisk.
Click to expand...
Click to collapse
Well, not exactly lol.
Flashed your two images via fastboot, still broken fingerprint and still missing -verity files from /dev/block/mapper/ , went to flash my backups of vbmeta and vbmeta_system via fastboot, got into a bootloop, and after a couple hours of screwing with it, finally got back where I started from...except using your images.
I don't understand. vbmeta and vbmeta_system are NOT device specific. One from my phone, one from your phone, one from anyone's phone running 10.0.35 should be exactly the same.
What exact method did you use to pull the images? dd to a tmp dir on device and then adb pull img? dd directly to computer? or adb pull the partitions themselves direct to computer? Shouldn't all 3 methods return the same results?
I swear, after the RMA I really don't know if I am going to risk unlocking the bootloader again (this is coming from someone who has had s-off/bootloader unlock/root/su/Magisk on every single android device ever owned over the past 10 years...without ever having any problem I couldn't fix by myself)
It should all be the same img, but I did "dd bs=1M if=/dev/<partition> of=/sdcard/img/" and adb pull them to the computer. Pretty much the same dd command I use for most image work. I am on 10.0.35.
One of the biggest reasons I gave this device a shot was the ability to reflash back to stock. Now I hear that doesn't work. That's really annoying. This is something Oneplus should just provide as a backup. They don't even have to keep it up to date. We can OTA our way to the latest. They have to have something like that to flash the phones before shipping them out. I guess they could flash to storage chips before installing them on the PCBs.
I was also hoping to see some development, I didn't realize that the A/B thing or A10 was going to cause so many problems. Not the devs fault, just one more thing to shake my head at. Sadly, I think root stuff is going to start phasing out. I don't mind no support for modified software, but I hate that I don't own my devices.
ttabbal said:
It should all be the same img, but I did "dd bs=1M if=/dev/<partition> of=/sdcard/img/" and adb pull them to the computer. Pretty much the same dd command I use for most image work. I am on 10.0.35.
One of the biggest reasons I gave this device a shot was the ability to reflash back to stock. Now I hear that doesn't work. That's really annoying. This is something Oneplus should just provide as a backup. They don't even have to keep it up to date. We can OTA our way to the latest. They have to have something like that to flash the phones before shipping them out. I guess they could flash to storage chips before installing them on the PCBs.
I was also hoping to see some development, I didn't realize that the A/B thing or A10 was going to cause so many problems. Not the devs fault, just one more thing to shake my head at. Sadly, I think root stuff is going to start phasing out. I don't mind no support for modified software, but I hate that I don't own my devices.
Click to expand...
Click to collapse
What is the need or result of the "bs=1M" in the command? I've never seen that before in other threads. I'm assuming it means block size equal to 1MB. Is that definitely required to get a good pull? Same bs for any/all partitions?
If you have persist and both EFS images backed up, you should be okay. The MSM tool can restore I think everything else. I'd keep a backup especially of any partitions that don't end in _a or _b. The MSM tool definitely takes care of the rest (those ending in _a and _b). I just hate using it because there's no way to make it not wipe userdata. And without being able to make a nandroid backup due to no fully working twrp due to A10, it's just a giant pain.
And unfortunately we can't just OTA our way to the latest, at least not by manually downloading an OTA from 1+. Only way to update is with a real OTA update from T-Mobile.
The A/B partitioning isn't the problem with development. That's been around since Android 7 or 8. It's the new dynamic partitioning format that all phones that launch with Android 10 (or newer) have. Even the Pixel 4 doesn't have fully working twrp yet. It's coming soon though...
Edit: Also, for the dd commands, did you use /dev/block/actual_partition or /dev/block/by-name/friendly_name_of_partition? Again, should it really make a difference?
Edit2: All of these issues have a root cause from Android 10. The new required partitioning system for any phones that launch with it. That's why unlocking the bootloader wipes reserve.img. Because it's in userdata (cause of A10) and 1+ forgot about that and didn't rewrite the algorithm used when the bootloader is unlocked. It's also their negligence (combined with A10) which causes persist (and other key partitions) to become so easily corrupted. Virtually all devices launched since Android 7 use "fastboot flashing unlock" and then "fastboot flashing unlock_critical" to allow changes to device specific partitions. For some reason 1+ still is using the antiquated "fastboot oem unlock" command which unlocks literally everything, even some stuff that unlock_critical doesn't, and which in the old days, didn't matter. A10 especially should not ever be used with fastboot oem unlock. Google says so lol.
If it makes you feel better, this isn't unique to this phone. It's a problem on every device 1+ has launched with A10 and still is (OP7T/TPro/OP8/Pro). Because of A10 partitioning combined with the use of an antiquated bootloader that only supports "fastboot oem unlock"
The block size doesn't matter for the pull and doesn't change the image at all. It just reads in chunks, making it faster.
Yes, I used by-name and it shouldn't matter if you use that or the sd# names.
It's your persist and it's unique. The rest of your sensors won't care. If you didn't back it up, you're screwed. An MSM restore doesn't fix this.
LLStarks said:
It's your persist and it's unique. The rest of your sensors won't care. If you didn't back it up, you're screwed. An MSM restore doesn't fix this.
Click to expand...
Click to collapse
The issue is I had a backup of my unique persist. And restoring it doesn't fix the dang fingerprint. That's why I was thinking the issue had to be elsewhere