Related
Hi all,
Here are my findings about how to boot android from an SD card, useful for example to test development Android builds without messing your phone. This procedure was inspired by legacy GNU/Linux boot process and then should work on most hardware with a flashable recovery.
########################################
I can't stress enough the fact that this procedure is targeted to experienced user. A good knowledge of linux/android booting process is more than required. This procedure is not meant to be useful to most people given its limitations (no recovery mode, rebuild of boot.img required)
########################################
I won't propose a step by step tutorial as it's better to understand how to do it and adapt the procedure to each need.
Two modifications are required:
1. Declare to mount sd card partitions instead of internal flash volumes. This has to be done in the init.rc script.
For example:
mount yaffs2 [email protected] /system
mount yaffs2 [email protected] /system ro remount
with
mount ext2 /dev/block/mmcblk0p6 /system
2. For some reasons, in the boot process, sd card partitions generally show up later than the mount actions, so it is generally necessary to add a timer in init binary to give to to the kernel to detect sd card partitions before mounting them (adding a sleep(5) after the "A N D R O I D" text in init.c is enough).
Build your special boot.img embedding those two modifications and flash it on the recovery volume of your phone. Now, booting into recovery will launch the system on your sd.
Regards,
I would like to report success on booting the G1 from a system located on sd card (cyanogenmod 4.2.7.1). I will describe the procedure step by steps when every thing is okay.
There is just an issue that you might have encountered during cyanogenmod ROM cooking, all wireless connexions (wifi, BT, GSM) do not work. The same system on flash if okay. I made a diff on boot log messages and the only notable difference is this error :
E/MemoryHeapBase( 83): error opening /dev/pmem_gpu0: Permission denied
E/MemoryHeapBase( 83): error opening /dev/pmem_gpu1: Permission denied
E/MemoryHeapBase( 83): error opening /dev/hw3d: Permission denied
I tried to chmod 0555 /dev/pmem* with no success.... Any idea ?
Although I finally managed to have a usable system, this work is still experimental. Please fell free to test and report success, failures here so I can improve the thing.
Let's see how we can boot a copy of cyanogen ROM 4.2.7.1 located on sd card. The main purpose is to test future ROMs (eclair ?) without messing up your phone...
DISCLAIMER : This procedure is targeted to experienced user. I am not responsible if you loose your data, your phone or your Mom !
Prerequisites are :
- adb and fastboot operationnal on your host computer
- Boot image file boot.img :
http://www28.zippyshare.com/v/19654421/file.html
- files data.cpio.gz, system.cpio.gz (data.cpio.gz and system.cpio.gz are unmodified images of a fresh install of cyanogen ROM that fit the modified boot.img) from :
http://www15.zippyshare.com/v/57489279/file.html
http://www15.zippyshare.com/v/13077582/file.html
1.
Create 3 partitions on sd card. The first one (vfat) is to store your music, videos etc. The second and the third will hold /data and /system. Result shoul look like this :
# fdisk /dev/block/mmcblk0
Command (m for help): p
Disk /dev/block/mmcblk0: 1977 MB, 1977614336 bytes
64 heads, 63 sectors/track, 957 cylinders
Units = cylinders of 4032 * 512 = 2064384 bytes
Device Boot Start End Blocks Id System
/dev/block/mmcblk0p1 1 864 1741792+ c Win95 FAT32 (LBA)
/dev/block/mmcblk0p2 865 903 78624 83 Linux
/dev/block/mmcblk0p3 904 957 108864 83 Linux
Command (m for help):
2.
Copy data.cpio and system.cpio on the first partition of your sd card.
3.
Connect to your device with adb :
adb shell
4.
Mount mmcblk0p2 on temporary folder and extract user.cpio.gz archive :
mkdir /dev/tmp
mount /dev/block/mmcblk0p2 /dev/tmp
cd /dev/tmp
gunzip -c /sdcard/data.cpio.gz | cpio -i
cd /
umount /dev/tmp
5.
Mount mmcblk0p3 on temporary folder and extract system.cpio.gz archive :
mount /dev/block/mmcblk0p3 /dev/tmp
cd /dev/tmp
gunzip -c /sdcard/system.cpio.gz | cpio -i
cd /
umount /dev/tmp
6.
Reboot the phone in bootloader :
adb reboot bootloader
7.
Boot the phone with custom boot image :
unzip boot.img.zip
fastboot boot boot.img
Reports are welcome !
I haven't tried this, but great idea. Well done.
Maybe a nice additional idea would be a boot-menu style idea. Eg, detect OS on mem card and display a menu of "Internal" or "SD Card"?
I'm on it but as it will imply flashing people's phone, I need more testing and suggestions from experienced hackers. I only own my G1 for 5 days...
I acytually just started a thread about this in the Dream development subforum!
Some suggestions:
-Use a recovery image to boot the ROM on the sd card (look at modifying the CM recovery image) if this is possible. This way, you can boot from sd card when you want to, by booting into recovery image, without interfering with the flashed rom at all. No worries that flashin a new rom will require a reflash of your bootloader. Also, you can use the ROM installed in flash after a reboot without any hassle, which would be very useful when testing a ROM from the SD if it doesn't work very well and you need a working phone.
-Have the /data and /system-partition as folders on the 4th partition on the SD card, or as logical volumes on a primary one. Why?
Well, many people have their sd-cards set up with fat, extX, swap in that order. The partition layout you have described here simply isn't compatible with that, and will require a separate SD card just for this testing (which everyone might not have).
I must say, I think this is a GREAT idea! I so often want to test a few ROMS, but often they don't get the test-time they deserve because I need to swicth back to my working environment for job/uni the day after. This would be a great way to test a ROM thoroughly. And also it would be the best way to give a ROM a quick testdrive. switchroming back and forth is, for all its simplicity, hassle.
Using the recovery is the only way I found at the moment to boot from the sd card and was about to extend cm recovery with a dedicated menu Nevertheless, there will be a limitation with that: it will not be possible to use a different kernel for the system on sd as it will have to use the kernel of the recovery... Anyway, many custom roms around here use cm kernel (even those I saw with eclair) so it is not so problematic I think (tested Eugene373 AOSP20 yesterday). Anyway, it is possible to adapt the recovery with a test kernel...
I think I found a workaround for sd partitionning scheme pb, using bind mounts but I have not tested already. I will work on it this WE.
If I remember correctly you can use the command "reboot recovery" from the recovery shell to reboot again into recovery. It could mean that it is possible to choose what (kernel) to boot after the reboot. Even cyanogenmod has made quite a few changes to the kernel since the recovery image came out, and I think it would not be a very good solution to use the same kernel as the recovery image for all ROMs loaded via SD. (Especially the Hero ones won't work at all, I'm afraid.
It could also be possible maybe, to tweak the built-in bootloader into booting form either SD-card or from the internal flash? It already has the possibility to boot different things on different keypresses (home for recovery mode, and camera for fastboot). I have (again) no idea of its capabilities for reading anything off of the sd card, though.
I get your point naguz . I am not satisfied either with the solution of using the recovery kernel to boot the system on sd. I found that it adds quite much complexity to the init process: I tweaked the recovery executable to add an entry to boot from sd but I faced troubles in services startup and pre-init definitions. I think that the solution of using the recovery menu to choose to boot from sd have to be abandoned as it will require heavy additional changes to the init.rc scripts of the second system and will break its advanced features.
The ideal solution (as you suggested) would be to tweak the bootloader to boot natively from the sd card but unfortunately, we do not have the sources of the SPL (tell me if I am wrong) so it is definitely not possible.
The remaining solution is to use the recovery partition to flash the boot image of the second system. I works well, just press the home key and the second system boots ! The drawback is that you do not have recovery any more... Personnaly, I don't find that so problematic as I is still possible to boot a recovery image with fastboot when needed, so I think I will stick to this solution. I somebody have another solution, I am ok to investigate...
Aha, it makes sense that booting the sd directly from recovery mode would mess something up. I would think some of the same problems would be faced when booting the kernel from the recovery partiotion, doesn't it look like a different device to the kernel? Well, if it works, it works.
Regarding the source of the SPL, I have no idea, but I know hyakuro (a (former?) user here) has released a modified one. Trying to get in touch with him
As for the latest method: Is the recovery partiotion big enough to hold both the recovery image AND the kernel? If so, one could maybe have both. Maybe make a new "recovery image" that can either boot from sd or boot recovery image? Just throwing out ideas here.
Personally I don't see the big problem with not having a recovery image, as I would (in a dual-boot scenario) already have another, working install on the flash that I could use if the one booted from sd wasn't good enough. Re-flashing the recovery image could also be done from the working ROM in flash, for those without the SDK tools.
I think, however, that quite a few people will object to not having a recovery image.
Btw, was your latest working test done with one (4th) partition on the sd card for loading the ROM from SD? If so, new instructions please. I'd like to give it a try.
I think that it is technically impossible to boot directly from the sd, even with the sources of the SPL as drivers are required to drive the sd that can not be included in a SPL. It is the same issue on PC with PCMCIA network cards for instance. IPL+SPL has to be seen more or less like a simple BIOS...
The recovery partition size is not a matter her. The problem is the lack of control over what has to be booted as the only action we can make in the SPL is the HOME key to choose a regular boot or a recovery boot (the system on SD here). I think I have a good knowledge now of the boot process and I think we can not got further than that, despitely...
I am now trying to have /data and /system on the same partition, mount them on /mnt and bind mount each directory on /system and /data but with no succes . investigating....
Okay, bind mounting was a dumb idea of mine. The solution is to create an extended partition with 2 logical drives in it, so partitions are:
[1-3] FAT and/or EXTX and/or swap as needed (I have personnaly just one partition here)
4 extended
5 ext2 for /data
6 ext2 for /system
Now its time to bake a boot.img with the kernel of the system on the sd card + the ramdisk. I do not explain how to do that, google knows :
1.
In the ramdisk image, put my modified init program attached hereater
2.
In the init.rc script, change the lines that mount /data and /system :
mount yaffs2 [email protected] /system
mount yaffs2 [email protected] /system ro remount
with
mount ext2 /dev/block/mmcblk0p6 /system
and
mount yaffs2 [email protected] /data nosuid nodev
with
mount ext2 /dev/block/mmcblk0p5 /data
Flash boot.img on the recovery and reboot in recovery... That's all.
Jahrome,
Trying the idea on the HTC has a subtle difference. So I'm curious what change you put in the /init process.
Lets say the image one wants to use is the 'eclair' branch. This branch uses vold, so the block device, such as '/dev/block/mmcblk0p#', does not appear to be created until the vold service is started, which is after the init.rc mount operations. So the mount proposed does not work.
Curious what changes you made to the init process that might give me some ideas of what might be the simplest change. It seems that there is a relatively easy solution, that I don't yet see.
Ideas (or additional questions to clarrify) appreciated...
Hi Dale !
On which HTC are you trying the trick ?
First your trouble is not related to eclair as I successfully booted eclair on my G1 with this trick. You need to add a timeout in init so as it waits for the kernel to detect sd card partitions (need to recompile init, or use my recompiled init).
Vold has nothing to do at this point
Hope this helps
Init Delay for SDisk
Thanks for the reply. That's what I needed, it seems so ungraceful.
I thought vold was enabling something to make the kernel's discovery of the SD partitions. It is "by coincidence" that the log of the vold occured shortly before the adding of the block-device event. My apologies for not recognizing the coincidence of the log entries.
I had hoped the solution was a bit more "graceful", though I can't say what that would be or why a sleep is "ungraceful". I would like a "mount retry for n-seconds" option in the init.rc, that would be slick. Nonetheless I will add in a sleep-spin-check for a few seconds.
For the record, we are discussing the change to:
android-source: .../system/core/init/init.c
code-routine: main()
code-location: Somewhere after the "A N D R O I D" text
code-change: add in a sleep spin-check of some sort
I appreciate the comment that all we need is just a sleep. I think this completes the thread?!
Most interesting...
This is something akin to how I am using my company's Android solution for the Beagle Board...
In that environment, the entire kernel and rootfs are located on a SD/MMC card. The environment variables and boot script are stored in the NAND chip
through a "setenv" command. The U-boot monitor on the hardware defaults to run the boot script unless there is any user interaction. This image can then be converted into a typical distribution that can be flashed and ran without the SD card...
I have wondered about the implementation of this approach on my G1, but I have not had time to test it out. It is good to see that there are others that are interested in this as well...
I will be following this thread and will try to help in any way if I can... meaning if I can get some free time...
If you are interested in our Beagle Board solution, it is open source and can be found by a simple Google search using "Android rowboat"...
L8R...
very easy fix.
rename the /init to /init.android (or whatever you like)
create an init script. have it prompt on boot too boot from sd or internal. symlink the init.rc from /system. That way you only need one boot.img for multiple builds. We've been doing this a really long time on the android on vogue project. My development phone is simple, I hold down the menu button if I want to boot from the sdcard otherwise it boots from the internal.
Oh and don't worry about this.
jahrome said:
log messages and the only notable difference is this error :
E/MemoryHeapBase( 83): error opening /dev/pmem_gpu0: Permission denied
E/MemoryHeapBase( 83): error opening /dev/pmem_gpu1: Permission denied
E/MemoryHeapBase( 83): error opening /dev/hw3d: Permission denied
Click to expand...
Click to collapse
That's just that you don't have HW3D enabled in your kernel. It's important to note that if you're trying to use multiple builds that eclair with 3d and donut use different kernels.
Exactly the vogue and kaiser have been doing this for ages. If you want you can also boot ext2 and squashfs images. It's pretty simple stuff.
Anyone have a backup of the files in post #3? I've been trying this solution with files of my own creation (as in: my own cooked boot.img, and data/system files) but it doesn't seem to get past the G1 boot screen (as in: blank screen.) I've also tried the recovery boot solution however it gives me the same reaction. It leads me to believe the problem lies in my boot file.
ok anyone interested in creating a simple step by step manual? and can someone post the files again please?
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?
Hello
After in ulocked my nexus 4 bootloader i discovered that the data partition was wiped during the process. Because i forgot to save my photos i'm curently trying to recover thoses using apropriate tools.
So i made a backup of the data partition of my nexus 4 using "dd" (adb shell 'stty raw && dd if=/dev/block/mmcblk0p23' > ~/userdata.img)
I got the entire partition image and i tried data recovery tools as :
- foremost
- photorec
- magicrescue
unfortunately i did not found any deleted pictures or any usefull document and i dont realy understand why.
Thoses tools usualy find jpg images from formated gard drives or sd card and i already used theme in the past.
Can any one explain if the unlocking process wipes the data partition by overwriting the entire partition or anything like that ?
Sory for my lousy english
Dear All:
This is a fundamental / dumb question that I am not sure where to post it.
I have a Moto X Pure/Style. I have a relatively strange variant (Chinese, XT1570). But that is not the point.
I have obtained two official images from Chinese website. Version wise they are identical.
One strange difference is size of "system.img" file.
The one I choose to flash my phone with (mind you that this is the OFFICIAL stock image with no modifications) has a system.img file which is 1.36GB in size.
Another package I obtained from a different Chinese source has a system.img file of 3.99GB in size.
When I looked to my phone, system.img file of 4GB is about right, that is how much it occupied on my phone.
Why this 1.36GB system.img file worked at first place? is there a differeces?
thanks in advance.
The larger image is probably a sector/sector image of the entire partition (dd). The smaller is just the files in use.
If you want to test this, flash the smaller image and note the free space remaining. Then flash the larger. I bet the two numbers will be similar if not the same.
sector/sector image of entire partition?
gpz1100 said:
The larger image is probably a sector/sector image of the entire partition (dd). The smaller is just the files in use.
If you want to test this, flash the smaller image and note the free space remaining. Then flash the larger. I bet the two numbers will be similar if not the same.
Click to expand...
Click to collapse
Thanks for your reply. I got a couple questions.
The large system.img file was created by clobber the sparsechunk.x file together.
What do you mean "entire partition?"
Here is what I am trying to do:
I have a Chinese version of Moto X Pure. It is the only dual-SIM version that support both AT&T and China's LTE band. However, China banned Google services thus the Chinese version contains NO Google services nor Google Service framework. What I want is to flash the XT1572 version (Rest of Asia) dual SIM Android OS while keep the modem part intact.
1. is it safe to assume all Moto X Pure|Style's partition structure is identical?
2. on Chinese web, an article stated that all I have to do is flash the boot.img AND system.img and leave everything else intact, the phone will work. Is this something I can just assume?
3. I noticed that bluetooth has its on firmware (BTFM.bin). does GPS has its own firmware as well? if it is, which image file is it? The reason I am asking this is because hardware wise, Chinese variant is different from rest of Moto X Pure in terms of navigation hardware: Chinese variant has GPS, Beidou (Chinese), and Glonass (Russian) all three receivers. and given the choice, i would like to keep that intact as well.
Thanks in advance
Entire partition as in the entire 4GB partition space. Obviously the system is not occupying all of this space, but the image created was a snapshot of the entire space including unused space.
1) I don't see why they would create different partition layouts for different regions. Usually the only difference would be in software
2) Boot.img is the kernel and system.img is the system partition. You should be fine flashing these two.
3) I don't recall ever seeing a separate gps partition. I'd think the code for it would be part of the baseband.
Whether or not the xt1572 has the right drivers for this is another matter.
Make a backup of system, boot, and data partitions, then flash the xt1572 boot and system only. You'll maybe able to boot right up or you'll have to do a factory reset from within the recovery if it bootloops on startup.
now I am confused... I see TWO system partitions in Teamwin recovery
when I tried to do a backup with Teamwin recovery, i actually see TWO "System" partition:
System (which is about 1.5GB)
and
System R/O (which is about 4GB)
what is the differences between these two system partitions?
when I do
fastboot -s XXXYYYZZZ flash system system.img
which "system" partition am I really flashing?
and when teamwin recovery said I can backup "system" partition and "system R/O" partition, how doe these two partition map to fastboot's partition? I see I can flash
partition
bootloader
modem
fsg
bluetooth
boot
recovery
system
there is only one system...
gpz1100 said:
Entire partition as in the entire 4GB partition space. Obviously the system is not occupying all of this space, but the image created was a snapshot of the entire space including unused space.
1) I don't see why they would create different partition layouts for different regions. Usually the only difference would be in software
2) Boot.img is the kernel and system.img is the system partition. You should be fine flashing these two.
3) I don't recall ever seeing a separate gps partition. I'd think the code for it would be part of the baseband.
Whether or not the xt1572 has the right drivers for this is another matter.
Make a backup of system, boot, and data partitions, then flash the xt1572 boot and system only. You'll maybe able to boot right up or you'll have to do a factory reset from within the recovery if it bootloops on startup.
Click to expand...
Click to collapse
Strange. Which version of twrp are you using?
Can you post a pic?
Hello Everyone
I'm user redmi 2 1gb variant
i want to change my system partition, and i use file 1,5GB Partition @jsidney96
, i click partition.bat, and it works, my system partition change to 1.5gb, but after i flash rom Lineage OS, Viper OS, Validus.. my system partition change to default size.. and i try to repair partition on twrp wipe menu, and no changes has made,... can you help me to fix my problem? or are you have a recommendation rom for resize partition?
Thank You
#Redmi2
because your rom using raw system partition dump from smaller system partition size
inunxelex said:
because your rom using raw system partition dump from smaller system partition size
Click to expand...
Click to collapse
Ohhh..,, thanks