I rooted two nooks, and made tar backups of their partitions (I also got the dd image just in case). Out of curiosity, and with the goal of keeping minimal backup and increasing the partition for side-loaded contents to maximum, I tried to compare the contents of each partition. Since I followed the same process for rooting (Touch-Formatter v2, 1.2.1 update, NookManager, NTGAppsAttack - but before booting the Nook I got the backup), I guessed quite a lot of them are the same, and found some interesting results.
1. Boot partition is nearly the same except uRamdisk. I inspected the contents of the two uRamdisk files using bootutil by Renate, and they are identical.
-> Why are they different, and can one replace the other?
2. As we all know, rom partitions are different, but it looks only a few of them can meaningfully affect the operation. Anyway, it's small and I decided to leave them untouched and keep two separate copies.
-> What is the BCB file by the way? It just has zeroes inside. Is it automatically created if not there?
-> Some files in the devconf directory seem to be modified during the normal process or firmware update, notably BootCnt (four zero bytes), Bq275020Dffs (12 in the rombackup.zip, 13 after 1.2.1 update). What are these? Any idea?
3. The factory partition, I want to bust it (empty it up and resize it to the minimum), and let me know if I'm on a dangerous path. The idea is that I don't need rombackup.zip because I can revive the rom partition with my own tar backup if something bad happens, and it's out of date anyway after 1.2.1 update (some files in the rom partition are modified). Also, with Touch-Formatter and CWM, I wouldn't need the factory.zip file.
-> What are the files in the "touch" directory? One of my nook has them, but the other doesn't. Looking at the data inside they must be related to the display or touch screen. Maybe byproduct of calibration?
-> Can I use 1.2.1 update file with CWM instead of using Touch-Formatter, bringing it to a new fresh 1.2.1 Nook? According to this post, it seems possible.
4. The system partitions are identical, as expected. but with CWM recovery, we wouldn't need a backup of it, right?
5. The cache partition is way too big. I know the firmware update uses this space (when I resized it to something like 64MB, 1.2.1 update didn't work. I needed to increase it to something like 128MB to make it work). However, for normal operation, we surely don't need it that big.
-> How small can it be? I know it depends on individual's usage patterns... but in my case, I mostly use Nook for reading side-loaded contents. I've gone down to 32MB, but I guess that's still big.
-> Do we really need the cache partition? Can we just symlink it to somewhere in the data partition?
Out of curiosity, I just deleted BCB and BootCnt in the rom partition, and rebooted. First it said "Install Failed", a screen I have never seen before on Nook. So I looked into the rom partition and found that BCB file is recreated, but not BootCnt. On the subsequent boot, it said "Installing Rom", and then quickly rebooted. Now it's back to work. So, I guess these two files are essential for normal operation. Again, this time I deleted all files in the factory partition and also deleted BootCnt. Now, it tries to do the "Installing Rom" thing, but fell back to "Install Failed" screen. I opened up the rom partition again and I saw only BCB and BootCnt files, and none else. Nook surely formatted the rom partition first before trying to recreate it.
So I wonderfully bricked my Nook, and thought this is a good time to test if the rom partition backup works. I mounted the rom partition, untarred the backup, and rebooted. There we go, the Bronte Sisters are back. So the conclusion is that
1. When the BCB file's missing, it's simply recreated after a failed boot.
2. When the BootCnt file's missing, Nook thinks the rom partition is corrupted and tries to recreate it using rombackup.zip in the factory partition. I think this may have some side effects because firmware updates only change the files in the rom partition, leaving rombackup.zip untouched. So you will go back to the old rom partition after the built-in rom recovery.
3. The best rom recovery, I think, is using your manual backup of the rom partition. And maybe updating the rombackup.zip with a new one too?
BootCnt is a 32 bit little-endian count of the number of failed boots.
Once it hits eight your Nook will boot into the recovery image uRecImg, uRecRam.
You could also echo about anything to that file to make it arithmetically greater than 8.
Code:
echo 000 > /rom/devconf/BootCnt
That is 0x0a303030 > 8
Normally this is a B&N thing that asks you about factory restore.
If you replaced those two files it could be Clockwork Mod Recovery.
Related
I have a question that is more android-in-general than Nook specific. I am trying this out on my Nook first, as it is an unbrickable device, before tinkering with my target device (a phone). My phone also does not have Clockworkmod recovery support, so a bricked device would be fatal.
I am attempting to increase the memory available for installed apps. My phone has limited space, but a bunch of pre-installed junk that I thought I might be able to get rid of in order to make more space for more apps. Knowing that simply deleting these pre-installed apps from the /system folder does really nothing, I set about making and editing an image file from the /system partition, then reflashing this image back to phone. As I am trying this on the Nook first, here is what I did:
1. Adb into the Nook and dd the system partition to a system.img file on the sd card.
2. Copy the system.img file to my desktop and mount the image.
3. Edit the image, removing the LiveWallpapers.apk file (a hefty ~3M file), then save the result back out as a new system.img.
4. Copy the new system.img to the sd card, then adb back into the Nook and dd the system.img from the sd card back to the system partition.
Everything appeared to work fine. The Nook boots, runs fine, and the LiveWallpapers.apk file is nowhere to be seen. Problem is, there is no difference in the available memory on the device.
In retrospect, I suppose I should not have expected there to be a difference. I am under the impression that the system partition is a read-only partition, and that extra space on this partition is not available for installation of apps. I am guessing that in order to increase the memory available, I would need to resize the data partition.
So, ultimately, my question is whether or not this is correct. Do I need to resize the data partition in order to actually get more memory available for apps, or is there an easier way? If I would need to resize the partition, how would I go about doing this, and would I need to take this extra space away from the system partition (the extra memory would need to come from somewhere, I imagine). I would envision removing bloatware from the system partition, shrinking that partition as I would no longer need that much space, and giving that extra memory to the data partition. Bear in mind that I need to do all of this through adb as I will not have Clockworkmod recovery on my target device.
Alternatively, I could be out my gourd and none of this makes any sense. Feel free to let me know if this is the case.
Thanks!
You've got it right.
The Nook emmc has partitions for boot, rom, system, data, and media. Originally data was 1g and media (/emmc under CM7) was 5g, newer models have reversed this. Data is where apps and their data go.
There are threads here about repartitioning newer Nooks with lots of good discussion. It sounds like you are capable (or want to be capable) of creating a custom partition scheme; there's enough info there for you to do that.
Experimenting with an 8g SD card might be a good place to get familiar with the tools. The "size-agnostic" installer will use a pre-partitioned SD if it finds one IIRC.
Good luck!
Sent from my NookColor using xda premium
xdajunkman said:
I have a question that is more android-in-general than Nook specific. I am trying this out on my Nook first, as it is an unbrickable device, before tinkering with my target device (a phone). My phone also does not have Clockworkmod recovery support, so a bricked device would be fatal.
...
Click to expand...
Click to collapse
I just wanted to re-iterate the importance of what you said here.
I have sent several people off to buy Nook Colors who were interested in developing for android, for this very reason.
Nothing else you can get your hands on ( to my knowledge ) is as safe of a dev-tool as the Nook Color, because of the first boot to sd-card.
It doesn't matter what you do to it, at the end of the day you'll have a working device unless you throw it down the stairs or something.
Bonus points for running an sd-install directly, because when you hose it you just reflash a new microsd card.
Can't reformat the card because windows only reads the boot partition? No problem - if you still have your Nook Color with it's stock software just boot it up and pop the microsd card in. The B & N software in the Nook Color will just format the card, without a care in the world for any existing partition schemes or whatnot.
You're on the right track for what you're trying to do, as the previous poster has pointed out, so just wanted to give you another vote of confidence letting you know you're doing all the right things for all the right reasons.
Thanks for the replies!
You know, I actually did the repartition of my Nook using the CWR zip file. I hadn't thought to go look through the original thread for the manual instructions. As you pointed out, I found the directions here:
http://forum.xda-developers.com/showpost.php?p=13971291&postcount=110
The only problem is that his instructions require that you boot from the SD card in order to manipulate your interal memory. This is fine and good on the Nook, but not possible with my phone. Any idea what would happen if I tried to repartition the internal memory while booting from the internal memory? Seems that this would not be possible....or at least wrought with peril. I think that my phone can boot into a fastboot mode, but have not tried that...anyone know if this would help?
Perhaps I am just playing with fire here and need to settle for cramped memory space on my phone. I am just too accustomed to my 5GB of available app space on my Nook.
Thanks again.
Well, after some more Googling, I think I might abandon the repartitioning bit. I think I am likely to brick my phone, even though I think I could do it manually on the Nook. In addition, it appears that many phones are set up so that the kernel resets the internal memory partitioning on boot....so I might also need to mess with the kernel to get this to stick. This is beyond my skill set and really not worth my turning my phone into a paperweight.
I thought of a bit of a workaround, however. As I can extract and edit the image of the system partition, I will simply install the apps that I will eventually want on my phone on my Nook instead, extract the apk's from the Nook, then insert them into the system image file from my phone. Reflashing the system image then puts these apps into the system partition instead of the data partition, effectively saving me hoards of space on my data partition. A bit laborious, but for several core apps that I know I will want and that are memory hogs, I think it will be worth it.
Anyone see any problem with this approach?
Hi,
I have a problem that hopefully can be easily fixed. Heeeelp!
After rooting with SalsichaNooter3 , unrooting, re-rooting. Well, basically trying everything (for fun), I’m ending with a Nook that have no storage space available. At one point, my Nook was connected to the same PC where I was doing a Wi32Image with SalsichaNooter to the SDCard. The image might have been written to the Nook instead of the SDCard (here I’m not sure). The Nook would not boot, so after different manipulation, I can now boot the Nook with original recovery firmware 1.0.0 but there is no storage available. I can download from B&N shop, read, do all of what is expected from this device but the NOOK folder doesn't appear when connected to the PC. If I look at ‘Available storage’ in the settings menu, I get ‘0. 00B free of 0.00B’
I tried ‘erase, reset Nook’ from the menu, also the recovery with the power-left,right bottom buttons. I tried with n2T-Recovery 0.1 and 0.2. All seems to properly do their job but the storage partition still doesn’t seem to be available.
I suspect that the ‘boot’, ‘rom’ and ‘firmware’ partition are proper since I can boot, register and use the device so I tried with Partition Wizard to adjust the ‘*:NOOK’ and ‘*:userdata’ partition (formatting, change ID, etc), without success.
I don’t have a valid backup – I did my original backup using the drive ref. instead of the physical disk (I know, I should have read more - sniff).
Below is the screen shoot of Partition Wizard. Does anyone have an idea? Have none left. Maybe replacing the NOOK partition from a valid image using Partition Wizard would work but I don’t have access to such image.
Thanks.
For those interrested in my solution.
Inspired by this thread:
http://forum.xda-developers.com/showthread.php?p=16818990
I recreated the image partitions under linux with dd and sfdisk and repopulate the boot, factory, rom and empty name partition with my broken backup.
Write image to Nook using Noogie and RoadKill Disk Image.
Did a factory restore with power+2 lower side button method to be on safe side.
Seems to work nicely with extra space for sideloading (used the same space assigments as describe in the above thread).
Now, my recovered 1.0.0 version doesn't seems to apply the updates - but that's another story.
Cheers,
GM
I was able to update my Nook touch to 1.1 by resizing the partition. Seems that the system needs more space in the ./factory area (I think) to apply an update. The resizing modification specified in the above didn't left enough space.
Thanks.
You should take the time to update your title with [Solved]
ros87 said:
You should take the time to update your title with [Solved]
Click to expand...
Click to collapse
ha! ok. Done
My Nook Simple Touch (1.1.2) is now not working because I wiped ALL the partitions before attempting to restore a backup (which I didnt know was bad at the time)
Notes
1. I have two backups:
a) the first is 239mb which contains my ebooks and pdfs
b) the second is the boot partition (77mb) - I backed up again when when noogie was on micro SD
2. So basically (both backups) I backed up the NST without selecting the whole physical drive.
3. After a failed root, I tried to restore the backup (and seeing it fail), I decided to wipe the whole partition before attempting to restore again :crying:
4. Are there any restorable backup images that can be downloaded online? Or anything which can restore the partition table including the ROM partition with the serial address etc.
5. Please help me restore the Nook back to factory or any working state. Cos AFAIK i've bricked the device.
p.s. I have tried touchnooter and installed touchformatv2 but all I get now is a Read Forever load screen. N2Tsecurity doesnt work without the ROM partition.
Please Please Help Me Im so sad (I know this is down to carelessness on my part but I really need help)
Did you really wipe all the partitions (like write zeroes over the entire physical drive)?
Or did you just try to repartition it?
The question is whether you truly wiped out the /rom and /factory partitions.
Sometimes partitioning them correctly you can rediscover the file system.
The /rom partition is necessary, even ClockworkMod needs to be able to see it.
The /rom info is replicated in /factory/rombackup.zip
Renate's solution may work.
Also, there is a tool called testdisk available for linux that I've used to recover data and partition layouts before; I would expect that it may work a champ for situations like yours.
To use it, you would need a linux box or find a windows port and boot the NSTG or NST from the noogie disk.
Testdisk can recover deleted partitions automatically, including the all-important /rom partition.
That one's important because it contains device-specific info for your NST. It'll do it automatically, but you do need to read up on what commands to give it. You can also rebuild the table manually using fdisk (and I've done so successfully before.)
A windows file recovery utility might let you recover /rom as well (or the files from it.)
You most need the contents of /devconf, and there are lots of files there. I am not sure which ones are absolutely required.
Hello,
we already have 3 Nooks in the family, all of them rooted. One with Touchnooter on 1.1 about a year ago, two of them with Nookmanager on 1.2 and 1.2.1.
There are more to come for friends, so I wanted to know if there is a possibily to use the Nookmanager backup and change the B&N and Google account setting later on ?
I did them individually so far, as from memory I thought they are individual to some degree, but it get's a bit inefficient.
A) Is cloning in my case possible?
Another thing:
B) Could I update from 1.2 to 1.2.1 without going through the whole process again ? I tried making a backup with Nookmanager, reset to factory, manual update, restore backup - but after restoring the backup it shows 1.2 again. Maybe it's not worth the hassle (?)
Thanks for your help !
It's certainly possible, but I haven't done it so take this advice with a grain of salt.
Before you try any of this, please take a complete backup of the your device with NookManager so if you completely mess up your partitions, you'll still be able to restore your device to a working state. As you've noticed, NookManager does a complete backup of the entire Nook memory, so restoring a backup will take your device back to the exact state it was in at the the time of the backup, including firmware version, partition table, user data, etc. No matter how messed up your Nook is, your backup will get you back in the clear. You do not want to restore a backup made with NookManager to a different device, so with multiple devices make sure you've got your backups identified.
The Nook's internal memory is divided into seven partitions (1-7): boot, rom, factory, system, userdata, cache, and data
What you're looking to do is a backup/restore of selected partitions, which is do-able but you'll need to get your hands dirty. You'll want two SD cards, one with the NookManager, and one for your 'clone' backups.
I think you'll probably want to backup/restore the boot, rom, and system partitions while leaving factory, userdata, cache, and data alone.
To backup select partitions from your 'master' Nook, insert your 'backup' sdcard and use adb to run the following commands:
dd if=/dev/block/mmcblk0p1 of=/sdcard/p1
dd if=/dev/block/mmcblk0p2 of=/sdcard/p2
dd if=/dev/block/mmcblk0p4 of=/sdcard/p4
This will create three files on your sdcard: p1 p2 and p4 containing the data from the boot, rom, and system partitions, respectively.
Use the NookManager card to boot the Nook you want to clone to, enable wireless and enable adb. Make a backup now if you do not already have one for this Nook. Remove the NookManager sdcard, insert the backup sdcard, and run the following commands with adb:
mount -t vfat /dev/block/mmcblk1p1 /sdcard
ls /sdcard # make sure you see the p1 p2 and p4 images
umount /system
umount /data
umount /cache
umount /rom
dd if=/sdcard/p1 of=/dev/block/mmcblk0p1
dd if=/sdcard/p2 of=/dev/block/mmcblk0p2
dd if=/sdcard/p4 of=/dev/block/mmcblk0p4
umount /sdcard
sync
reboot
If that works, your Nook should reboot and be very similar to your master device. If this is something you plan to be doing regularly, you can work the backup/restore procedures into scripts, and run them as a custom plugin for NookManager (details here). That way you'll just need the one SD card and you won't have to fuss with all the adb commands.
Good luck, and be sure to post your results when you've got this working.
Thanks a lot for that. I will get my sisters Nook on Thursday. She wants an update to 1.2.1, Relaunch and NoRefesh anyway. So I will make a Nookmanagerbackup, then update to 1.2.1 and then copy the partitions you suggested. I will let you know how that goes.
I have do admit that I already bricked a NSG, but the mistake was not doing my noogie backup correctly. With Nookmanager I fell a lot safer doing all this.
As I'm leaving user data alone I hope to keep the connection to google play and B&N intact with the old settings.
Hello. I have a problem. I've rooted my NST and after 2 months i wanted to get back it to stock so I've deleted all partitions on my Nook and then i realized my backup is wrong (it has only 245mb). Now i have intetnion to buy a 2nd NST and fix 1st one. How I can do it? Can I simply make a (proper) backup new NST and restore using it my old NST? I've readed other post and i know there might be a problem with registatrion. Is there any way to fix my nook using backup from antoher device and how cen i do this? Plese help and sorry for my english.
darksd87 said:
Hello. I have a problem. I've rooted my NST and after 2 months i wanted to get back it to stock so I've deleted all partitions on my Nook and then i realized my backup is wrong (it has only 245mb). Now i have intetnion to buy a 2nd NST and fix 1st one. How I can do it? Can I simply make a (proper) backup new NST and restore using it my old NST? I've readed other post and i know there might be a problem with registatrion. Is there any way to fix my nook using backup from antoher device and how cen i do this? Plese help and sorry for my english.
Click to expand...
Click to collapse
Hi darsd87,
Yes you will be able to fix your nook using the 2nd.
But, have another way to do this.
I do the same mistake, but my device is a NST Glowlight. I think you can do a backup of your nook now and try to recover using NSTG just in case. In the worst case you can overwrite your backup.
Considering what I do to recover, I sugest you do this steps:
1. create a image backup of NST.
2. recover the ROM partition with MiniTool Partition Wizard
3. write the NSTG backup image
4. copy the ROM partition to NSTG image
5. do a hard reset
The instructions and the backup image of NSTG are available in:
http://forum.xda-developers.com/showthread.php?t=2104145
If some post a image of NST without the rom partition would be better.
But, i think the only "problem" you will have is a useless glowlight button in the nook menu.
Best luck!
PS: sorry for my english... i´m from Brazil.
Thank you very much You saved my nook. I didn't have room partition so i've just used NSTG-backup-norom.img and then made a hard reset. I've registered my nook and now it stuck on the glow light screen "Give it a try" I'm pressing n button for 2 seconds but nothing happen co i can't move on. I can only turn on screensaver or turn off device. Is there any way to skip this screen? I think this is the last step of registering because when i restart nook the registration process starts again (only this time skips logging)
Edited.
I skiped registration using "Oobee method" and when I go to device info menu --> About Your NOOK it seems to be registered on me. Now the only thing what doesn't work is Screen menu, when I tap the screen button the screen flash once and nothing happen. Also i don't have internal storage but I think I can fix it using this method: http://forum.xda-developers.com/showthread.php?t=1374777. I have one more question. How I can unroot my nook? Hard reset doesn't work. My nook is still rooted. (I have *Development menu in settings and access to android launcher)
I didn't want to trouble anyone, but I really couldn't find any thread on the same topic as this one.
Also, I don't have ten posts, so I can't post direct links. I'll have to post them in plain text.
I'm a generally disk-space conservative person.
When Android version 4.2.2 was released, I tried updating but without any luck (update failed).
So a couple of days later, I factory reset my Nexus 7, then I truly wiped it and proceeded to flash 4.2.2 and root the device.
No custom ROM:s.
Yesterday, I randomly checked my storage information, just to find that 4 gigabytes out of max 6 gigabytes storage was used.
See puu.sh/2fe9V for an image.
I'm a newcomer to both xda and Android and I followed several tutorials whilst doing this. One of them led to me bricking my device.
I wish I could, but I was only able to track up one of the ones I followed;
blog.laptopmag.com/how-to-hard-reset-a-bricked-nexus-7-with-your-pc (this is the one that was successful).
I'm guessing that I may possibly have accidentally created some other partion or something similar.
I would really appreciate some help in this (to me) confusing topic.
Re: [Q] Nexus 7 32GB down to 6GB internal memory
Sounds like you flashed an 8 gig image. Where did you get the image?
Sent from my Nexus 7 using xda app-developers app
rmm200 said:
Sounds like you flashed an 8 gig image. Where did you get the image?
Sent from my Nexus 7 using xda app-developers app
Click to expand...
Click to collapse
Thank you. That definitely sounds like a possibility.
I got mine from developers.google.com/android/nexus/images#nakasijdq39
(Sorry again for plain text links)
Zsded said:
...
So a couple of days later, I factory reset my Nexus 7, then I truly wiped it and proceeded to flash 4.2.2 and root the device.
No custom ROM:s.
...
Yesterday, I randomly checked my storage information, just to find that 4 gigabytes out of max 6 gigabytes storage was used.
See puu.sh/2fe9V for an image.
I'm guessing that I may possibly have accidentally created some other partion or something similar.
Click to expand...
Click to collapse
rmm200 said:
Sounds like you flashed an 8 gig image. Where did you get the image?
Click to expand...
Click to collapse
Could be, but then the Google factory images do not discriminate between 8/16/32, and in this case the OP used a factory image.
@Zsded
I had this happen to me the other night (in the middle of doing something else). The long & boring story follows, but let's begin with a solution: The partitioning data did not get changed, but mysteriously the /data filesystem got created with with only about 6-7 GB of capacity. Re-creating the /data filesystem using the "Format data" operation in TWRP will create an ext4 filesystem of 29 GB or so.
You need to backup everything worth saving and re-create the /data filesystem. This can be accomplished (for instance) using the "Format data" operation in TWRP. But - again - this destroys everything in /data including everything in /sdcard. (Note it does not touch /system or /cache though - so your bare ROM is still there)
What you might want to do is the following:
1) back up everything in /sdcard that you want to save
2) make a full Nandroid backup of your current ROM
3) get copies of the TWRP Nandroid backup off the device (on to the PC)
4) perform the "format data" operation in TWRP (iirc it is in the Wipe sub-menu)
5) copy your Nandroid backup back to the tablet***
6) restore the Nandroid backup (or just the data partition if you prefer)
7) Boot into the ROM and copy the saved contents of /sdcard back onto your device from your PC
*** This is a mouthful. On a fresh /data filesystem, TWRP (v2.4.1.0, anyway) wants to find its backup folders at
/data/media/TWRP/BACKUPS/<device-id>/*
But if you use MTP with the OS to copy the nandroid backup files, you will only have access to /data/media/0/* (the "sdcard" mount point) using MTP So, you might need to copy the files and then using a root shell or the custom recovery, get a copy of your TWRP folder into /data/media/ e.g. with TWRP recovery booted:
Code:
adb shell cp -R /data/media/0/TWRP/ /data/media/
OK, now for the long and boring story.
I had something identical happen to me the other night - I have a 32G N7, and it ended up showing only 6.5 GB total in /data. Because of the sequence of events involved, I don't know the exact cause, but using TWRP to re-create the /data filesystem as explained above solved the problem.
First, some background so you will know why I don't know the cause (get a beverage, this is going to be a long post):
The other night, I decided to capture Nandroid backups of every N7 factory ROM from JZO54K through JDQ39 (4.1.2 - 4.2 - 4.2.1 - 4.2.2). My plan was to do a factory install of JZ054K (4.1.2) and then apply each of the OTAs in sequence. So, I backed everything up (including using a certain busybox version of "tar" to backup about 2.5 Gigs of stuff from the /sdcard mount point), and completely wiped the device and did a fastboot install of 4.1.2 (JZO54K) nakasi (WiFi N7) factory ROM.
The ony thing that I did not do in the initial step was flash the bootloader - I left the 4.18 bootloader in place (initially). I did not follow the factory install script; instead I used the following sequence:
Code:
fastboot erase boot
fastboot erase recovery
fastboot erase system
fastboot erase userdata
fastboot erase cache
fastboot flash boot boot.img
fastboot flash recovery recovery.img
fastboot format system
fastboot format userdata
fastboot format cache
fastboot flash system system.img
fastboot flash userdata userdata.img
The above installed the JZO54K factory ROM - but with the newer 4.18 bootloader still in place.
For each of the OTA package installs & nandroid backups, I would "soft-boot" TWRP (thus leaving the factory recovery still flashed on the tablet), e.g.:
Code:
C:\foo> fastboot boot openrecovery-twrp-2.4.1.0-grouper.img
C:\foo> adb push 094f6629314a.signed-nakasi-JOP40C-from-JZO54K.094f6629.zip /cache/update.zip
C:\foo> adb shell sha1sum /cache/update.zip
C:\foo> adb shell
# cd /cache/recovery
# echo '--update_package=/cache/update.zip' > command
# exit
C:\foo> adb reboot recovery
... (OTA runs, device reboots into OS, perform shutdown, boot to bootloader) ...
C:\foo> fastboot boot openrecovery-twrp-2.4.1.0-grouper.img
... take a Nandroid backup (including recovery partition!)...
Now, as it turned out, before any of this had taken place I had noticed filesystem corruption in my /system partition. Because I was making Nandroid backups for reference/archival purposes, after each OTA install, just prior to making the nandroid backup (with TWRP soft-booted as shown above), I did a filesystem check on system and data:
Code:
adb shell e2fsck -f -n /dev/block/mmcblk0p3
adb shell e2fsck -f -n /dev/block/mmcblk0p9
(for Wifi/nakasi/grouper devices, mmcblk0p3 is /system and mmcblk0p9 is /data).
The reason I mention this is that I was focused on making sure that there were no filesystem errors (there were none). Had I been paying attention, I might have noticed that something was wrong with the allocation size. But, read on...
When I finally got finished (3 OTAs and 3 Nandroid backups) I decided to restore the contents of my 2.5 Gb tarball. Nothing should been in /data except for a couple (TWRP) Nandroid backups. So, I start restoring the tarball... and after a good long wait ... tar exits due to lack of space. WTF?
Well, /data and /sdcard were mounted (in TWRP), so I did a
Code:
adb shell df -k /data
and it showed a little over 4.5 GB used ... in a 6.5 GB partition - WTF?
Now, because I wasn't watching carefully, I can't be sure what caused the small filesystem in a big partition, but here's my theory:
Because the OTAs are designed to leave /data and /data/media/* alone (more or less), that means that the /data filesystem was only created once: it would not have been destroyed & re-created by the successive application of the 3 OTA bundles that took me from JZ054K -> JOP40C -> JOP40D -> JDQ39.
To me, that says that one of the two following initial operations was the culprit:
Code:
fastboot erase userdata
fastboot format userdata
OR
Code:
fastboot flash userdata userdata.img
What is rather shocking about this is because of the way that I did things, I had the newest bootloader on the device when I did this - v4.18. I wouldn't have been surprised if an older bootloader had a bug that got fixed... but it surprises me that the very newest bootloader seems to be implicated.
But anyway - to recap - your partition data has not been altered. AFAIK, nobody (but Asus/Google) knows how to do that as it probably requires talking to the device in APX mode. Somehow, whatever recreated your filesystem in /dev/block/platform/sdhci-tegra.3/by-name/UDA ( userdata ) mysteriously created a filesystem substantially smaller than the physical partition size.
My suspicion is that it is a bug in the bootloader.
good luck
Actually all you had to do is do a factory reset in the recovery, and reboot. BAM - all your actual storage is back
Fatal1ty_18_RUS said:
Actually all you had to do is do a factory reset in the recovery, and reboot. BAM - all your actual storage is back
Click to expand...
Click to collapse
Factory Reset in the recovery does not recreate the ext4 filesystem, it only does deep removal (rm -rf) excluding /data/media. That won't solve the problem of having a tiny filesystem in a huge partition; same filesystem - same max capacity.
bftb0 said:
Factory Reset in the recovery does not recreate the ext4 filesystem, it only does deep removal (rm -rf) excluding /data/media. That won't solve the problem of having a tiny filesystem in a huge partition; same filesystem - same max capacity.
Click to expand...
Click to collapse
Strange. After I flashed the stock 4.2.1 after playing with some custom ROMs - I, too, had only 6GB available, but then I did either factory reset/wipe data or something else - and BOOM everything was fixed
bftb0 said:
Could be, but then the Google factory images...
Click to expand...
Click to collapse
Snipped to save people's screen space.
Thanks a lot! This solved my problem and I'm now back to 27 gigabytes (which should be somewhere around the promised 32 gebibytes).
I truly appreciate it. I would do more than just to thank your post, but I'm kinda out of ideas (and money).
And of course I'd like to thank everyone else for the help.
This thread can be regarded as closed.
@Fatal1ty_18_RUS
There have been a couple of other reports about "6 Gigs in a 32 GB device". I just dismissed them as folks not being aware of how much space they were using (e.g. Nandroid backups) - until it happened to me.
Enough strangeness seems to be present to make me nervous for folks that don't have a lot of *nix experience to sort things out when they get mucked up.
The other thing I didn't mention in my story was that restoring a tar file into the /sdcard mount point using a root shell in TWRP (v2.4.1.0) was sufficient to massively corrupt the ext4 filesystem on /data every time I did that (based on looking at the output of "e2fsck -f -n" in TWRP). After cleaning things up (ugh - recreating userdata ext4 from scratch means shuttling everything back onto the tablet again) I booted into the (stock) OS, and restored the same tar file into /sdcard as an unprivileged user - and no problems. No clue how/why that would happen, as tar files contain no inode information; but it suggests that there is some strangeness in the way that that emulated /sdcard mount works when a root user writes things... at least in the TWRP version of things. Very bizarre indeed.
Suffice it to say the whole exercise blew away a massive chunk of my time, even though I'm comfortable with this kind of stuff (I have used *nix systems for 30+ years). I can only imagine how folks with less experience feel when they get into a jam.
---------- Post added at 12:01 PM ---------- Previous post was at 12:00 PM ----------
Zsded said:
Snipped to save people's screen space.
Thanks a lot! This solved my problem and I'm now back to 27 gigabytes (which should be somewhere around the promised 32 gebibytes).
I truly appreciate it. I would do more than just to thank your post, but I'm kinda out of ideas (and money).
And of course I'd like to thank everyone else for the help.
This thread can be regarded as closed.
Click to expand...
Click to collapse
Cool!
Change your thread title to include the token "[SOLVED]" - maybe it can help others.
bftb0
bftb0 said:
Cool!
Change your thread title to include the token "[SOLVED]" - maybe it can help others.
bftb0
Click to expand...
Click to collapse
Good idea and thanks for your help!
is there any alterations in ghrese steps for CWM users? I too am having this problem after installing a stock image friom the same sources as posted above, but i used onw of the nexus 7 toolkits to help asist me with this.
Thabnks, i am leaving for a trip tomorrow, so i was sorta shpcked to see 6 gb of storage on my device.
GH0 said:
is there any alterations in ghrese steps for CWM users? I too am having this problem after installing a stock image friom the same sources as posted above, but i used onw of the nexus 7 toolkits to help asist me with this.
Thabnks, i am leaving for a trip tomorrow, so i was sorta shpcked to see 6 gb of storage on my device.
Click to expand...
Click to collapse
Well, given that you need to rebuild the filesystem in the userdata partition, you may not have enough time to work on this tonight, as it means getting everything worth saving backed up to a PC, and then transferring it all back after /data is rebuilt (back to the size that it should be). At that point you can either boot the "factory reset" OS to push your backups back to the tablet, or push them with adb & the recovery running so you can restore the backup before the first time you boot.
You saw how long the TWRP post was; can't say I want to do the same thing for a CWM version. Nor do I know even the first thing about any "toolkit" or what their operational hazards are.
But basically, the bottom line is re-building the /data ext4 filesystem from scratch. Even though TWRP has "mke2fs" & "tune2fs" utilities in it's ramdisk, it appears that they use a custom-built "make_ext4fs" utility for rebuilding ext4 filesystems. CWM probably has something similar - maybe a "format data" menu pick/button or something that sounds like that.
If you think you have enough time for this, you could perform the format using fastboot, as in:
Code:
fastboot format userdata
bearing in mind that this wipes EVERYTHING in /data including the psuedo-SD card (just as will any other procedure which rebuilds /data). So, if you make a Nandroid backup before starting this process, make SURE you've got your backups in a safe place off of the tablet before the format occurs.
Not having an external SD card on the N7 sure makes everything like this a pain in the a**, especially when it's potentially 20+ Gigs of stuff to move around.
good luck
So... I currently did this:
erasing 'userdata'...
OKAY [ 9.107s]
formatting 'userdata' partition...
Creating filesystem with parameters:
Size: 30080499712
Block size: 4096
Blocks per group: 32768
Inodes per group: 8160
Inode size: 256
Journal blocks: 32768
Label:
Blocks: 7343872
Block groups: 225
Reserved block group size: 1024
Created filesystem with 11/1836000 inodes and 159268/7343872 blocks
sending 'userdata' (139157 KB)...
writing 'userdata'...
OKAY [ 30.145s]
finished. total time: 39.254s
Click to expand...
Click to collapse
I had to pull my CWM backup (however, doing a format data/cache using CWM didn't fix it). Eventually, the fastboot command fixed it. However, now when I try to transfer files over MTP/USB, it fails on the Internal Storage. So I am not sure why it is complaining. It doesn't give me an error, it just says the device has stopped responding, even though it is still listed and I have folders that are accessbile.
I guess I will just have to use adb push
EXT4
bftb0 said:
Factory Reset in the recovery does not recreate the ext4 filesystem, it only does deep removal (rm -rf) excluding /data/media. That won't solve the problem of having a tiny filesystem in a huge partition; same filesystem - same max capacity.
Click to expand...
Click to collapse
So where can u find the ext4 file to delete? I did this once, it was a while agao but i need to find it
fixed on my nexus 7 but not sure what happened
thanks to you guys I solved my problem, same thing after installing a stock image from google i got 8gb of storage instead of 32. I did format data on CWM and than i got all of the storage back...i was really worried of not finding a way to solve this a big thanks to you guys.
In case u have the same problem you need to do format data on CWM and NOT wipe data/factory reset.
-----------------------------------------------------------------------------------UPDATE---------------------------------------------------------------------------------
The same problem happened again, i was not worried I did everything i did the first time but for some reason this time nothing got fixed...so after trying many things i asked myself "well what happen if I do not flash in my device the stock userdata after i erased them with the command >>fastboot erase userdata<< ?"
I tried and apparently it solved the problem i had all of my GB back. A little bit scare because during the boot in while i was on the image of the nexus logo (the X with four colors) it went back to the google screen (that one that appears when you turn on your device) but than it kept going normally. I did this two times first flashing in the stock stuff of the 4.1.2 of android and than with the 4.3 version (stock images downloaded from google)
Here the list of commands I used:
fastboot erase boot
fastboot erase cache
fastboot erase system
fastboot erase userdata
fastboot flash boot (I flashed the boot image of android 4.3)
fastboot flash system (I flashed the system image of android 4.3)
For the 4.1.2 I did the same except that i flashed in the userdata image of the 4.1.2 version I turned on the device to check the space on the settings and than i came back and used >>fastboot erase userdata<< and than turned on the device to check if there were some issues but it worked and the storage was back at full size.
I ask to someone a little bit more skilled than me to explain better what happened, and what I really did, because I'm really not sure about this I mean why not flashing the userdata image that came with the full pack from google is not creating problems and flashing it makes my device loose space? I would like to understand more about this.
Thanks bftb0 for this excellent working solution.
My Nexus 7 recently wouldn't boot (bootloop after a power off for no good reason...) and I used the Nexus Root Toolkit in force mode to put 4.4 on (I was on some older version to keep Stickmount working as it didn't work straight off the bat with new Androids). I had to use force because my bootloader is 4.18 I think and the update procedure via the Root Toolkit threw an error about bootloader version. 4.4 appeared to go on fine with force. I have no idea how to update the bootloader. Just playing with GPS apps today and putting maps on and found out I couldn't do it due to lack of space. Found the box for my Nexus 7 as I wasn't 100% what size I had but thought it was a 32G... Your solution worked fine. I didn't have to move the TWRP backups, just copied them over MTP and TWRP found them.
Hello.
This is my 1st post here. Well I have the same probelm. Just bought nexus 7 32GB and 6GB is missing...
Desperion9 said:
Hello.
This is my 1st post here. Well I have the same probelm. Just bought nexus 7 32GB and 6GB is missing...
Click to expand...
Click to collapse
Does it say something like 27GB total? It's not at 32GB total because it needs room for the OS and everything.
NiteFang said:
Does it say something like 27GB total? It's not at 32GB total because it needs room for the OS and everything.
Click to expand...
Click to collapse
Also manufacturers advertise memory in base10 the decimal system so 1MB =1,000,000 bytes but computers don't work like that they operate in base2 the binary system so 1MB is actually 1,048,576 bytes. This is the brainchild of marketing gurus who think people can't understand binary.
On average for every GB advertised in base10 you get on average 70 mb less
Sent from my C5303 using xda app-developers app
Sorry for the slight necro
The same thing happened to me: coming from a custom rom and installing Nexus 7 4.4.4 factory image my 16gb device only showed 6.58gb total.
So i locked the bootloader (using WUG's) and unlocked it again. Result: it now shows 27.58Gb TOTAL SPACE LOL... I tried doing the data wipe in TWRP and i'm all out of ideas...
Anyone?