Related
Just wondering if anyone has the original nook color's partition layout. I attempted to push HoneyComb to emmc with dd; however, that didn't work the way I expected. Now I'm missing the correct partition layout. In other words, I just need
fdisk -l /dev/mmcblk0
So I can correctly setup the partitions again and install Stock again.
Any word on this would be greatly appreciated.
Thanks.
bdkoepke said:
Just wondering if anyone has the original nook color's partition layout. I attempted to push HoneyComb to emmc with dd; however, that didn't work the way I expected. Now I'm missing the correct partition layout. In other words, I just need
fdisk -l /dev/mmcblk0
So I can correctly setup the partitions again and install Stock again.
Any word on this would be greatly appreciated.
Thanks.
Click to expand...
Click to collapse
I suspect that's the least of your worries if you did a dd to the DEVICE rather than partitions...... Geez.
Code:
# busybox 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 935 7060567+ 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 935 5253223+ c Win95 FAT32 (LBA)
Thanks
I will let you know how I make out.
(If it doesn't work, then there is probably just a little bit of boot code in the beginning of the device, but I suspect that it simply runs the boot code from the first partition. This is how it is done in OpenBoot, and pretty much every other system besides x86/bios)
Perhaps I should have done a full dd backup beforehand.
bdkoepke said:
Thanks
I will let you know how I make out.
(If it doesn't work, then there is probably just a little bit of boot code in the beginning of the device, but I suspect that it simply runs the boot code from the first partition. This is how it is done in OpenBoot, and pretty much every other system besides x86/bios)
Perhaps I should have done a full dd backup beforehand.
Click to expand...
Click to collapse
In the developers forums theres a recovery thread that has the partitions backed up. As for Honeycomb on internal I will be posting an install image in a bit under an hour (it's uploading now) that will allow you to use honeycomb on internal.
Thank you khaytsus and MattJ951.
I was able to get this to work properly after restoring the partition layout.
Something of interest, there are 935 cylinders allocated in the default partition layout (assuming khaytsus didn't modify it at all). There are actually 965 cylinders, so there is some extra space there for the vfat partition.
Thanks again.
bdkoepke said:
Thank you khaytsus and MattJ951.
I was able to get this to work properly after restoring the partition layout.
Something of interest, there are 935 cylinders allocated in the default partition layout (assuming khaytsus didn't modify it at all). There are actually 965 cylinders, so there is some extra space there for the vfat partition.
Thanks again.
Click to expand...
Click to collapse
Heh, no, rooted stock B&N ROM. Even knowing how fixable it is, I haven't experimented beyond booting NF or HC off SD.
So I have been able to get stock loaded again, but it can't detect the Mac Address/Serial Number... (Uh oh...)
Now this isn't the end of the world, but I can't use Market.apk on stock roms.
As I understand it:
/dev/block/mmcblk0p1 /boot (This should be fine, you can dd this)
/dev/block/mmcblk0p2 /rom (I'm guessing this is what I'm missing)
/dev/block/mmcblk0p3 /emmc (I just copied factory.zip here, there are no other files)
/dev/block/mmcblk0p5 /system (This should be fine...)
/dev/block/mmcblk0p6 /data (This is definitely fine to dd)
/dev/block/mmcblk0p7 /cache (Definitely fine as well)
/dev/block/mmcblk0p8 /sdcard (And also fine...)
So I'm just wondering what the original files are in /rom and /emmc.
I can't imagine the final blocks (935 and on) being used for hard-coded serial numbers/etc. That would be pretty stupid... Also the dual/froyo would clear these values.
I'm assuming the identity information is in /rom and /emmc.
Any word on this would be appreciated.
bdkoepke said:
So I have been able to get stock loaded again, but it can't detect the Mac Address/Serial Number... (Uh oh...)
Now this isn't the end of the world, but I can't use Market.apk on stock roms.
As I understand it:
/dev/block/mmcblk0p1 /boot (This should be fine, you can dd this)
/dev/block/mmcblk0p2 /rom (I'm guessing this is what I'm missing)
/dev/block/mmcblk0p3 /emmc (I just copied factory.zip here, there are no other files)
/dev/block/mmcblk0p5 /system (This should be fine...)
/dev/block/mmcblk0p6 /data (This is definitely fine to dd)
/dev/block/mmcblk0p7 /cache (Definitely fine as well)
/dev/block/mmcblk0p8 /sdcard (And also fine...)
So I'm just wondering what the original files are in /rom and /emmc.
I can't imagine the final blocks (935 and on) being used for hard-coded serial numbers/etc. That would be pretty stupid... Also the dual/froyo would clear these values.
I'm assuming the identity information is in /rom and /emmc.
Any word on this would be appreciated.
Click to expand...
Click to collapse
/dev/block/mmcblk0p2 contains the device specific information...
/dev/block/mmcblk0p3 contains factory.zip and a backup of /rom/devconf which also contains device specific info.
I think my mmcblk0p3 is hosed... thus my 8 failed boots always fails to install... I have yet to be able to mount it in adb to push new factory.zip... would love to get this fixed.
Got it... had to mke2fs /dev/block/mmcblk0p3 then i could copy mmcblk0p2's devconf and push factory.zip to it.... 8 failed boots work as it should now.
DizzyDen said:
/dev/block/mmcblk0p2 contains the device specific information...
/dev/block/mmcblk0p3 contains factory.zip and a backup of /rom/devconf which also contains device specific info.
I think my mmcblk0p3 is hosed... thus my 8 failed boots always fails to install... I have yet to be able to mount it in adb to push new factory.zip... would love to get this fixed.
Got it... had to mke2fs /dev/block/mmcblk0p3 then i could copy mmcblk0p2's devconf and push factory.zip to it.... 8 failed boots work as it should now.
Click to expand...
Click to collapse
DizzyDen, I am having the same problem i.e. 8 failed boots always fails to install. I am also unable to boot a CM7 image off of uSD card (hangs at Android) step. I can boot into CWM but it fails on installing a stock build.
I am hoping maybe my problems are related to yours. How did you accomplish the above? What tools did you use. I am fairly tech literate but a little loss with the tools and procedures for the Nook Color. I have tried several posts on restoring to stock non of which have worked. My assumption is that my partitions are messed up somehow such that it prevents my Nook from booting stock. I don't know why I have the same problem booting an image from a uSD card but it hangs on those. I am desperate at this point and any help would be much appreciated!
Thanks,
John
JoJa15 said:
DizzyDen, I am having the same problem i.e. 8 failed boots always fails to install. I am also unable to boot a CM7 image off of uSD card (hangs at Android) step. I can boot into CWM but it fails on installing a stock build.
I am hoping maybe my problems are related to yours. How did you accomplish the above? What tools did you use. I am fairly tech literate but a little loss with the tools and procedures for the Nook Color. I have tried several posts on restoring to stock non of which have worked. My assumption is that my partitions are messed up somehow such that it prevents my Nook from booting stock. I don't know why I have the same problem booting an image from a uSD card but it hangs on those. I am desperate at this point and any help would be much appreciated!
Thanks,
John
Click to expand...
Click to collapse
If you boot off a CWR sd... adb shell into NC... do a fdisk -l mmcblk0... verify your info against this one:
Code:
~ # fdisk -l /dev/block/mmcblk0
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 935 7060567+ 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 935 5253223+ c Win95 FAT32 (LBA)
as long as the partition is present as listed above...
mke2fs /dev/block/mmcblk0p3
You will now have a file system on the mmcblk0p3 partition that you can mount to /emmc...
mount /dev/block/mmcblk0p3 /emmc
exit from adb shell
You can then push the sideload.zip (or factory zip... fyi 1.1.0 will not work)...
adb push sideload.zip /emmc/factory.zip (replace sideload.zip with whatever zip file you intend to use for the 8 failed boot recovery file)
you will want to do the following in a blank folder on your computer... keeps cleanup a lot easier....
I then pulled mmcblk0p2 to my computer and zipped the contents to rombackup.zip and pushed it to mmcblk0p2 also...
adb shell mkdir /temp
adb shell mount /dev/mmcblk0p2 /temp
adb pull /temp
zip everything you pulled from mmcblk0p2 into a zip file named rombackup.zip
then push it to /emmc
adb shell push rombackup.zip /emmc
ALTERNATIVELY: the first time I did this... I merely copied the devconf folder from mmcblk0p2 to mmcblk0p3...
adb shell
cd /temp
cp -a devconf /emmc
and it seemed fine... so I don't know if you MUST do the rombackup or not... also note....
I did delete all the files and did the zip as mentioned above.
I am not 100% certain of exactly WHAT rombackup is supposed to have in it....I just know that what I listed (both methods) has worked so far.
I kind of like the idea of the cp instead... seems it would be eaiser to just cp them back should anything ever happen to mmcblk0p2... but currently have my version of rombackup.zip trying to stay with stock setup.
Hoping someone else will pull the rombackup.zip from theirs and give me the filestructure in it.
I hope this has been explicit enough... if you need any more help let me know.
ALSO... the CM7 off uSD... are you by chance using one larger than 8 Gb? We've discovered an issue with the mke2fs on 16 Gb cards.
Thanks DizzyDen, currently I have not been able to get ADB to work. I have it installed but it does not see my device when in CWM. I did get a Froyo and Honeycomb off of uSD booting which is good. I can probably add market place and then get ADB wi-fi app to do my copying to the nook. Once I get that setup I will follow your instructions above and report back.
You might want to mount mmcblk0p3 to /emmc before you do any of the more advanced stuff I listed... just to make sure.... IF it mounts... list files before you do anything else.
I was having issues mounting the partition... that's why I had to go to the extent of formatting it.... you may be luckier and only have a corrupt factory.zip
DizzyDen said:
You might want to mount mmcblk0p3 to /emmc before you do any of the more advanced stuff I listed... just to make sure.... IF it mounts... list files before you do anything else.
I was having issues mounting the partition... that's why I had to go to the extent of formatting it.... you may be luckier and only have a corrupt factory.zip
Click to expand...
Click to collapse
OK, I got ADB working now but it seems fairly complex. Please bear with me as I am a newb when it comes to ADB. I did ADB Shell and then the command you listed. Here is the output:
Code:
# fdisk -l /dev/block/mmcblk0
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
Let me know what I need to do next.
Comparing your listing and mine it appears I am missing the 5-8 partitions. Also my mmcblk0p4 partition has a different ending then yours. So how do I go about adding the 5-8 partitions back and fixing the mmcblk0p4 one?
Those are partitions that are actually created on the logical partition mmcblk0p4... as you can see in the listing I posted.
Did you use ADB from and installed ROM or did you use a cwm bootable uSD ?
anyway to check your recovery options....
in adb mount mmcblk0p3 to /emmc and list its contents:
adb shell
mount /dev/block/mmcblk0p3 /emmc
ls /emmc
See if it has either recovery file... or both... or nothing
Post back whe you can and we'll go further.
If you want I could post the img files I got of ALL my partitions... well... won't share my mmcblk0p2 or mmcblk0p3 since they have my device specific information. They may help in getting your partitions straightened out.
Another option would be that we could use teamviewer to remote connect and look through it.
DizzyDen said:
Those are partitions that are actually created on the logical partition mmcblk0p4... as you can see in the listing I posted.
Did you use ADB from and installed ROM or did you use a cwm bootable uSD ?
Click to expand...
Click to collapse
I used ADB from my PC connecting to my nook that was running a bootable Froyo build from a uSD card
One other note, when booting from CWM on the uSD card when I try to do the fdisk command I get the following. I was still able to mount the partitions though in the shell example later in this message.
Code:
~ # fdisk -l mmcblk0
fdisk -l mmcblk0
fdisk: can't open 'mmcblk0': No such file or directory
~ #
anyway to check your recovery options....
in adb mount mmcblk0p3 to /emmc and list its contents:
adb shell
mount /dev/block/mmcblk0p3 /emmc
ls /emmc
See if it has either recovery file... or both... or nothing
Post back whe you can and we'll go further.
Click to expand...
Click to collapse
Here is what it shows. This is connecting to ADB via my PC with the nook booting into CWM on a uSD card. I do not have CWM installed on the Nook.
Code:
~ # mount /dev/block/mmcblk0p3 /emmc
mount /dev/block/mmcblk0p3 /emmc
~ # ls /emmc
ls /emmc
factory.zip lost+found rombackup.zip
~ # mount /dev/block/mmcblk0p1 /boot
mount /dev/block/mmcblk0p1 /boot
~ # ls boot
ls boot
charging.zip romrestore.zip uImage uRecImg
mlo u-boot.bin uRamdisk uRecRam
~ # mount /dev/block/mmcblk0p2 /rom
mount /dev/block/mmcblk0p2 /rom
mount: mounting /dev/block/mmcblk0p2 on /rom failed: No such file or directory
~ # mount /dev/block/mmcblk0p4 /system
mount /dev/block/mmcblk0p4 /system
mount: mounting /dev/block/mmcblk0p4 on /system failed: Invalid argument
~ # mount /dev/block/mmcblk0p5 /system
mount /dev/block/mmcblk0p5 /system
mount: mounting /dev/block/mmcblk0p5 on /system failed: No such file or director
y
~ # mount /dev/block/mmcblk0p6 /data
mount /dev/block/mmcblk0p6 /data
mount: mounting /dev/block/mmcblk0p6 on /data failed: No such file or directory
~ # mount /dev/block/mmcblk0p7 /cache
mount /dev/block/mmcblk0p7 /cache
mount: mounting /dev/block/mmcblk0p7 on /cache failed: No such file or directory
~ # mount /dev/block/mmcblk0p8 /sdcard
mount /dev/block/mmcblk0p8 /sdcard
mount: mounting /dev/block/mmcblk0p8 on /sdcard failed: No such file or director
If you want I could post the img files I got of ALL my partitions... well... won't share my mmcblk0p2 or mmcblk0p3 since they have my device specific information. They may help in getting your partitions straightened out.
Another option would be that we could use teamviewer to remote connect and look through it.
Click to expand...
Click to collapse
I'll PM you.
I really appreciate all the help!
I've been doing mine from bootable CWR SD... just to get the commands and make sure I am seeing actual internal emmc...
THAT may be why you can't get list of mmcblk0... not certain... but I responded to your pm's.
You couldn't get fdisk -l mmcblk0 to work cause I gave you the wrong command... it should be...
fdisk -l /dev/block/mmcblk0
The same as you did earlier....
It does look like we may get away with just replacing your factory.zip file...
I can send you the 1.0.1 file... the newest 1.1.0 won't work for recover for whatever reason B&N did it.
You are getting the fails (I think) because you are trying to mount all those partitions to /system...
Try this:
adb shell
mkdir /tmp4
mount /dev/block/mmcblk0p4 /tmp4
If that works... try doing the same for the remainder (5,6,7,8) increasing the tmpx each time... to match the partition you are trying to mount.
If it DOES NOT work... then I would suspect because of corrupt mmcblk04p partition... and we'll find out together if the factory.zip will fix that or if we have to go other methods.
With correct fdisk command
Code:
c:\android-sdk-windows\platform-tools\rombackup>adb shell
~ # fdisk -l /dev/block/mmcblk0
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
~ #
Looks like we will be trying to fix mmcblk0p4.... I'm gonna have to reseach exactly how to repartition it (maybe my mmcblk0p4 dd image will fix that) and how to fix the logical partitions that should be on that partition.
Will talk to ya in a bit.
here.....
DizzyDen said:
Looks like we will be trying to fix mmcblk0p4.... I'm gonna have to reseach exactly how to repartition it (maybe my mmcblk0p4 dd image will fix that) and how to fix the logical partitions that should be on that partition.
Will talk to ya in a bit.
here.....
Click to expand...
Click to collapse
That file at least helped me see my other partitions:
Code:
~ # dd if=/sdcard/mmcblk0p4-logical.img of=/dev/block/mmcblk0p4
dd if=/sdcard/mmcblk0p4-logical.img of=/dev/block/mmcblk0p4
2+0 records in
2+0 records out
1024 bytes (1.0KB) copied, 0.013641 seconds, 73.3KB/s
~ # fdisk -l /dev/block/mmcblk0
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)
~ #
Now I need to figure out why my 4 and 8 partitions end at 965 instead of 935. I a going to try a factory reset first and then if that does not work try messing with resizing the partition.
John, glad we got it working for you... might want to check the fdisk -l /dev/block/mmcblk0 now and see if it still shows mmcblk0p2 ending at 965 after the factory reset and data clear.
Nonetheless... I'm glad we got the 8 failed boots/factory resets working for you.
I'm sure we can mess with parted enough to fix it... or REALLY mess it up ;-)
BTW... in messing with this... we have you enough posts now to post in the dev forums
I did something really bad to my INTERNAL SD CARD partition layout, so now I have
I have the i8190N model
Code:
~ # cat /proc/partitions
major minor #blocks name
179 0 7634944 mmcblk0
179 1 7634936 mmcblk0p1
179 64 2048 mmcblk0boot1
179 32 2048 mmcblk0boot0
179 96 3866624 mmcblk1
179 97 3862528 mmcblk1p1
~ # df
Filesystem 1K-blocks Used Available Use% Mounted on
tmpfs 411756 48 411708 0% /dev
~ # mount
rootfs on / type rootfs (rw)
tmpfs on /dev type tmpfs (rw,nosuid,relatime,mode=755)
devpts on /dev/pts type devpts (rw,relatime,mode=600)
proc on /proc type proc (rw,relatime)
sysfs on /sys type sysfs (rw,relatime)
~ # parted /dev/block/mmcblk0
GNU Parted 1.8.8.1.179-aef3
Using /dev/block/mmcblk0
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) print
print
Warning: /dev/block/mmcblk0 contains GPT signatures, indicating that it has a
GPT table. However, it does not have a valid fake msdos partition table, as it
should. Perhaps it was corrupted -- possibly by a program that doesn't
understand GPT partition tables. Or perhaps you deleted the GPT table, and are
now using an msdos partition table. Is this a GPT partition table?
Yes/No?
As you can see, there is no /system, /cache and other stuff, that should be there.
My ClockWorkMod recovery tool can't mount anything (/cache, /system, nothing)
I really did everything I could. I tried: restore from backup (I have one, made with recovery tool), install new ROM (With recovery tool), install stock firmware and stock kernel in ODIN mode. I even tried some PIT file: nothing did absolutely nothing to my status.
Frankly I miss some important part in understanding of filesystem, partitions, images, what is ROM, what is stock kernel etc ...
What should I do?
UPDATE:
Short answer: user right PIT file and burn it with Odin3. Long answer in post below.
Found interesting file:
Code:
~ # tail ./etc/recovery.fstab
/system ext4 /dev/block/mmcblk0p22
/cache ext4 /dev/block/mmcblk0p23
/data ext4 /dev/block/mmcblk0p25 length=-16384
/efs ext4 /dev/block/mmcblk0p11
/boot emmc /dev/block/mmcblk0p20
/recovery emmc /dev/block/mmcblk0p21
/preload ext4 /dev/block/mmcblk0p24
/modem ext4 /dev/block/mmcblk0p12
/sdcard datamedia /dev/null
/external_sd vfat /dev/block/mmcblk1p1
~ # tail ./etc/fstab
/dev/block/mmcblk0p23 /cache ext4 rw
/dev/block/mmcblk0p25 /data ext4 rw
/dev/block/mmcblk0p22 /system ext4 rw
/dev/null /sdcard datamedia rw
And here is more info
Code:
~ # ls -la /dev/block/mmcblk*
brw------- 1 root root 179, 0 Jan 1 10:30 /dev/block/mmcblk0
brw------- 1 root root 179, 32 Jan 1 09:28 /dev/block/mmcblk0boot0
brw------- 1 root root 179, 64 Jan 1 09:28 /dev/block/mmcblk0boot1
-rw-rw-rw- 1 root root 16777216 Jan 1 10:07 /dev/block/mmcblk0p20
-rw-r--r-- 1 root root 0 Jan 1 10:07 /dev/block/mmcblk0p22
brw------- 1 root root 179, 96 Jan 1 09:28 /dev/block/mmcblk1
brw------- 1 root root 179, 97 Jan 1 09:28 /dev/block/mmcblk1p1
This is what kind of stuff I get in CWM:
Code:
-- Wiping cache...
Formatting /cache...
Need size of filesystem
E:format_volume: make_extf4fs failed on /dev/block/mmcblk0p23
Cache wipe complete.
W:failed to mount /dev/block/mmcblk0p23 (Block device required)
E:Can't mount /cache/recovery/log
E:Can't open /cache/recovery/log
W:failed to mount /dev/block/mmcblk0p23 (Block device required)
E:Can't mount /cache/recovery/last_log
E:Can't open /cache/recovery/last_log
W:failed to mount /dev/block/mmcblk0p23 (Block device required)
W:Can't unlink /cache/recovery/command
Formatting /data...
warning: get_file_size: Computed filesystem size less than 0
Need size of filesystem
E:format_volume: make_extf4fs failed on /dev/block/mmcblk0p25
Error formatting /data!
W:failed to mount /dev/block/mmcblk0p23 (Block device required)
E:Can't mount /cache/recovery/log
E:Can't open /cache/recovery/log
Have you tried to flash stock firmware again with re partition ticked and the pit file? Using the pit file make sense only if you flash the whole firmware with it
Inviato dal mio GT-I8190 con Tapatalk 2
Byteater said:
Have you tried to flash stock firmware again with re partition ticked and the pit file? Using the pit file make sense only if you flash the whole firmware with it
Click to expand...
Click to collapse
As I wrote in initial post - yes, I did. But maybe I used wrong pit file =\
Btw, looks like I have everything in console buffer (full history of distraction actions)
In the beginning I had this:
Code:
cat /proc/partitions
major minor #blocks name
7 0 2111 loop0
179 0 7634944 mmcblk0
179 1 128 mmcblk0p1
179 2 384 mmcblk0p2
179 3 1024 mmcblk0p3
179 4 1024 mmcblk0p4
179 5 512 mmcblk0p5
179 6 512 mmcblk0p6
179 7 512 mmcblk0p7
179 8 512 mmcblk0p8
179 9 1024 mmcblk0p9
179 10 1024 mmcblk0p10
179 11 16384 mmcblk0p11
179 12 16384 mmcblk0p12
179 13 16384 mmcblk0p13
179 14 51200 mmcblk0p14
179 15 64 mmcblk0p15
179 16 14336 mmcblk0p16
179 17 2048 mmcblk0p17
179 18 2048 mmcblk0p18
179 19 16384 mmcblk0p19
179 20 16384 mmcblk0p20
179 21 16384 mmcblk0p21
179 22 1228800 mmcblk0p22
179 23 860160 mmcblk0p23
179 24 327680 mmcblk0p24
179 25 4945920 mmcblk0p25
179 64 2048 mmcblk0boot1
179 32 2048 mmcblk0boot0
179 96 3872256 mmcblk1
179 97 3868160 mmcblk1p1
254 0 2110 dm-0
Code:
/ $ df
Filesystem Size Used Free Blksize
/dev 402.1M 84K 402M 4096
/mnt/asec 402.1M 0K 402.1M 4096
/mnt/obb 402.1M 0K 402.1M 4096
/dev/shm 402.1M 0K 402.1M 4096
/system 1.2G 414.5M 766.6M 4096
/modemfs 15.7M 4.3M 11.4M 4096
/cache 826.8M 84.8M 742M 4096
/efs 15.7M 4.5M 11.2M 4096
/preload 315M 64.2M 250.8M 4096
/data 4.6G 4G 699.2M 4096
/mnt/.lfs: Function not implemented
/storage/sdcard0 4.6G 4G 699.2M 4096
/mnt/asec/com.spruds.transport.pro.tallin-1 2M 888K 1.1M 4096
/storage/sdcard1 3.7G 905.7M 2.8G 32768
Even before everything went wrong I tried to use parted command and get an error
Code:
~ # parted /dev/block/mmcblk0
GNU Parted 1.8.8.1.179-aef3
Using /dev/block/mmcblk0
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) list
list
check NUMBER do a simple check on the file system
cp [FROM-DEVICE] FROM-NUMBER TO-NUMBER copy file system to another partition
.....
.....
copyright information of GNU Parted
(parted) print
print
Error: Unable to satisfy all constraints on the partition.
This is fdisk print before disaster
Code:
~ # fdisk /dev/block/mmcblk0
The number of cylinders for this disk is set to 954368.
There is nothing wrong with that, but this is larger than 1024,
and could in certain setups cause problems with:
1) software that runs at boot time (e.g., old versions of LILO)
2) booting and partitioning software from other OSs
(e.g., DOS FDISK, OS/2 FDISK)
Command (m for help): p
Disk /dev/block/mmcblk0: 7818 MB, 7818182656 bytes
1 heads, 16 sectors/track, 954368 cylinders
Units = cylinders of 16 * 512 = 8192 bytes
Device Boot Start End Blocks Id System
/dev/block/mmcblk0p1 1 954368 7634943+ ee EFI GPT
Partition 1 does not end on cylinder boundary
And then I deleted it
Code:
~ # fdisk /dev/block/mmcblk0
The number of cylinders for this disk is set to 954368.
There is nothing wrong with that, but this is larger than 1024,
and could in certain setups cause problems with:
1) software that runs at boot time (e.g., old versions of LILO)
2) booting and partitioning software from other OSs
(e.g., DOS FDISK, OS/2 FDISK)
Command (m for help): p
Disk /dev/block/mmcblk0: 7818 MB, 7818182656 bytes
1 heads, 16 sectors/track, 954368 cylinders
Units = cylinders of 16 * 512 = 8192 bytes
Device Boot Start End Blocks Id System
/dev/block/mmcblk0p1 1 954368 7634943+ ee EFI GPT
Partition 1 does not end on cylinder boundary
Command (m for help): d
Selected partition 1
Command (m for help): w
The partition table has been altered.
Calling ioctl() to re-read partition table
fdisk: WARNING: rereading partition table failed, kernel still uses old table: Device or resource busy
To be honest, I've never seen a problem like that. In Odin there's an option to erase all nand. I don't know if this would help you, since you should have an efs backup and I don't know if it will bring consequences.
Inviato dal mio GT-I8190 con Tapatalk 2
Try firmware posted here, with pit-file.
It's worth a try. It has saved me a few times, but from other problems.
tys0n said:
Try firmware posted here, with pit-file.
It's worth a try. It has saved me a few times, but from other problems.
Click to expand...
Click to collapse
I have "some" goldenxx.pit file already. And I took original firmware from some semi-official sources. Though I didn't have this CSC file. Also In original article (on 4pda.ru) they say NOT TO use this firmware with I8190N (which I have) ...
soswow said:
I have "some" goldenxx.pit file already. And I took original firmware from some semi-official sources. Though I didn't have this CSC file. Also In original article (on 4pda.ru) they say NOT TO use this firmware with I8190N (which I have) ...
Click to expand...
Click to collapse
Oh sorry. My mistake. I missed it was i8190N.
Sent through time and space from my s3mini/CM10.
Found it!
I found it!
The answer was in PIT file, because as it says here:
you will only need to use this if a firmware update needs to change your partition layout (very very unlikely) or if you mess up you partition table (you don’t want to do this)
Click to expand...
Click to collapse
Which is definitely my case.
So, I tried that GT-I8190N and GT-I8190 should be used with different PIT files (I tried to use for GT-I8190 one). So I found long list of PIT files here
Thank you everyone for help.
Hi everyone,
First of all - apologies if this is in the wrong forum. First time I post something, so not too sure if this is the right place.
I've been struggling with my Nexus 5 for the past 3 days after I attempted a factory reset. After trying everything I could find, I managed to combine some strategies from different threads, and got some help from a friend who is a linux specialist. As it has been REALLY HARD for me to fix this, I thought I would post the solution in case anyone is seeing the same issue.
Summary of my issue:
I attempted a factory reset to cleanup the phone. That was really all I intended to do.
The factory reset got stuck on "erasing". After 30 minutes waiting, I forced the phone to reboot. Then everything went downhill.
My Nexus 5 started bootlooping. It wouldn't even get in recovery mode.
I've flashed ClockWorkMod Recovery, and tried to format everything and start again. The processes to wipe partitions would fail.
Flashing stock also failed, as things would hang on "erasing cache".
I found references on multiple threads about things to try - from flashing other ROMs, to formatting the file system manually, and basically trying every step of a flashing a stock installation manually.
The bottom line is everything would hang because the system could not mount the /data partition.
When I tried to use "e2fsck" to check /userdata partition, it would give me an error about the file system being corrupted, and suggesting to use a different superblock.
Some threads here in XDA suggested to use CWM and TWRP to format the partition, as that would usually fix the problem. It didn't work in my case.
The system would basically hang when trying to format /data, with any method I tried.
When using the "dmesg" command, I would also see lots of errors with superblocks when trying to mount "/data".
I considered it could be a hardware issue, but I was not seeing problems with the other partitions (/cache, /system, /recovery, and so on).
Solution:
I fixed the problem by removing the partition, recreating it with "ext2" file system, then upgrading to "ext4" manually, and finally flashing the system images again WITHOUT flashing userdata.
Every time I flash "userdata", the partition just gets corrupted.
This is the step by step on how I did it:
1) Start the phone on bootloader by holding power button + volume down. Flash CWM recovery through fastboot.
Download CWM recovery from here: https://clockworkmod.com/rommanager
I'm using windows, so I opened a command prompt on the "Android SDK\platform-tools" folder.
run: "fastboot flash recovery <CWM_Recovery_Folder>\recovery-clockwork-6.0.4.5-hammerhead.img"
2) Reboot in recovery mode, so that it would load ADB. In the command prompt I ran "adb shell" so I could use the linux tools
Use "parted /dev/block/mmcblk0" to open the parted tool for the mmc block.
Use command "print" to list all partitions. You should see something like this:
Number Start End Size File system Name Flags
1 524kB 67.6MB 67.1MB fat16 modem
2 67.6MB 68.7MB 1049kB sbl1
3 68.7MB 69.2MB 524kB rpm
4 69.2MB 69.7MB 524kB tz
5 69.7MB 70.3MB 524kB sdi
6 70.3MB 70.8MB 524kB aboot
7 70.8MB 72.9MB 2097kB pad
8 72.9MB 73.9MB 1049kB sbl1b
9 73.9MB 74.4MB 524kB tzb
10 74.4MB 75.0MB 524kB rpmb
11 75.0MB 75.5MB 524kB abootb
12 75.5MB 78.6MB 3146kB modemst1
13 78.6MB 81.8MB 3146kB modemst2
14 81.8MB 82.3MB 524kB metadata
15 82.3MB 99.1MB 16.8MB misc
16 99.1MB 116MB 16.8MB ext4 persist
17 116MB 119MB 3146kB imgdata
18 119MB 142MB 23.1MB laf
19 142MB 165MB 23.1MB boot
20 165MB 188MB 23.1MB recovery
21 188MB 191MB 3146kB fsg
22 191MB 192MB 524kB fsc
23 192MB 192MB 524kB ssd
24 192MB 193MB 524kB DDR
25 193MB 1267MB 1074MB ext4 system
26 1267MB 1298MB 31.5MB crypto
27 1298MB 2032MB 734MB ext4 cache
28 2032MB 31.3GB 29.2GB ext4 userdata
29 31.3GB 31.3GB 5632B grow
Click to expand...
Click to collapse
3) Remove the existing data partition by running command "rm 28" .
4) Recreate the partition and the file system with "mkpartfs". I didn't use all parameters at once, but just informed the proper values as requested by the tool:
(parted) mkpartfs
mkpartfs
mkpartfs
Partition name? []? userdate
userdate
userdate
File system type? [ext2]? ext2
ext2
ext2
Start? 2032MB
2032MB
2032MB
End? 31.3GB
31.3GB
31.3GB
Click to expand...
Click to collapse
5) The partition should now be recreated as "ext2" file system. I've set the partition name with:
(parted) name 28 userdata
name 28 userdata
name 28 userdata
Click to expand...
Click to collapse
If you print again, you should see the new partition as ext2 file system:
(...)
28 2032MB 31.3GB 29.2GB ext2 userdata
(...)
Click to expand...
Click to collapse
6) Upgrade the FS from ext2 to ext4 by using make_ext4fs:
make_ext4fs -l 29236371456 -b 4096 -g 32768 -i 8192 -I 256 -j 32768 -L msdos -a /data /dev/block/mmcblk0p28
Now here is the interesting part. When I tried to run "flash-all" from the google stock image, this is what I would see when it ran the format script on the userdata partition:
OKAY [ 13.186s]
formatting 'userdata' partition...
Creating filesystem with parameters:
Size: 29236371456
Block size: 4096
Blocks per group: 32768
Inodes per group: 8192
Inode size: 256
Journal blocks: 32768
Label:
Blocks: 7137786
Block groups: 218
Reserved block group size: 1024
Created filesystem with 11/1785856 inodes and 156120/7137786 blocks
sending 'userdata' (139109 KB)...
writing 'userdata'...
OKAY [ 16.625s]
finished. total time: 29.811s
Click to expand...
Click to collapse
When I manually ran the make_ext4fs, the only difference was I added a label "msdos" and this was the result:
Creating filesystem with parameters:
Size: 29236371456
Block size: 4096
Blocks per group: 32768
Inodes per group: 48
Inode size: 256
Journal blocks: 32768
Label: msdos
Blocks: 7137786
Block groups: 218
Reserved block group size: 1024
Click to expand...
Click to collapse
Almost the same thing, but with a difference in "Inodes per group": stock script shows 8192, and running manually it shows 48.
I have no idea why is that. Honestly I know very little about linux and its file systems, so I don't know what that means.
After I did this, I was FINALLY able to mount the "/data" partition.
8) Checked the file system with e2fsck. It now worked fine:
~ # e2fsck /dev/block/mmcblk0p28
e2fsck /dev/block/mmcblk0p28
e2fsck 1.41.14 (22-Dec-2010)
msdos: clean, 11/10464 files, 45158/7137786 blocks
~ #
9) Manually flash google stock system, cache, boot, and bootloader.
I was using this image: hammerhead-ktu84p-factory-35ea0277.tgz
I uncompressed this to a folder, and also uncompressed the image-hammerhead-ktu84p.zip.
So I ran:
fastboot flash system system.img
fastboot flash cache cache.img
fastboot flash boot boot.img
After this, I rebooted the system and it loaded, after loooooong 3 days reading through everything I could on XDA!
These were some of the threads that helped me in one way or another to get to this solution:
http://forum.xda-developers.com/showpost.php?p=26285877&postcount=12
http://forum.xda-developers.com/google-nexus-5/help/help-nexus-5-bricked-clearing-cache-t2564509
http://forum.xda-developers.com/google-nexus-5/help/stuck-erasing-doing-factory-reset-t2530342
http://forum.xda-developers.com/google-nexus-5/orig-development/nexus-5-f2fs-t2668486
http://forum.xda-developers.com/goo...o-repairing-corrupted-data-partition-t2577447
http://forum.xda-developers.com/showthread.php?t=1441928
http://forum.xda-developers.com/google-nexus-5/help/help-nexus-5-bricked-clearing-cache-t2564509
http://forum.xda-developers.com/google-nexus-5/help/help-stuck-bootloop-t2515338
http://forum.xda-developers.com/google-nexus-5/help/stuck-google-logo-recovery-mode-t2898337
I really hope no one else had the same "luck" as I did, since this problem has been a nightmare.
But in case you unfortunately do... hope this helps!
Great guide. Might become handy for other users. It should be stickied
Why would you force reboot while factory resetting in the first place lol
Sent from my Nexus 5
Good guide but a bricked phone is rendered useless, hence the name 'bricked.' If your phone can still power on, it is not bricked. You said your self you got it out of a bootloop. That's essentially all you had, a bootloop, and you were able to figure out what was wrong with it.
Just a heads up so we don't throw that term around loosely since a lot of people do so.
You can't bring a phone back from a brick. I think JTAG is an option but its for Samsung phones only. (Feel free to correct me if I'm wrong.)
dicecuber said:
Why would you force reboot while factory resetting in the first place lol
Sent from my Nexus 5
Click to expand...
Click to collapse
Yeap, I know it sounds stupid but the factory reset was hanging, lol.
I tried multiple times and it would hang every time. I left it running for more than 3h once and nothing happened.
jayRokk said:
Good guide but a bricked phone is rendered useless, hence the name 'bricked.' If your phone can still power on, it is not bricked. You said your self you got it out of a bootloop. That's essentially all you had, a bootloop, and you were able to figure out what was wrong with it.
Just a heads up so we don't throw that term around loosely since a lot of people do so.
You can't bring a phone back from a brick. I think JTAG is an option but its for Samsung phones only. (Feel free to correct me if I'm wrong.)
Click to expand...
Click to collapse
Thanks for clarifying! I thought bricked also meant "the phone is about to go useless, but there is a tiny hope", lol.
Is there a way to correct the thread name?
You're right - it was only bootlooping.
There's soft-brick and hard-brick.
Wysłane z mojego Nexus 5
rm 28
3) Remove the existing data partition by running command "rm 28": im getting a error on this step .
need help..
How did the phone become bricked? What was the phone doing before trying to unbrick?
audit13 said:
How did the phone become bricked? What was the phone doing before trying to unbrick?
Click to expand...
Click to collapse
dont know how it got bricked..in morning when i wake up its suddenly start showing the boot only for hours. I've tried flashig it.evertime got flash write failure for bootloader and other images except boot.img .i've checked for emmc its fine and showing the device partion.
I'm using nexus 5 16gb device.pls anyone help
I assume the bootloader is unlocked since you are able to flash the boot.img. Try this: re-lock the bootloader, reboot to fastboot and see if the bootloader remains locked. If the bootloader unlocks itself, this is an indication that the memory chip is damaged. Also try flashing the older stock ROM available.
audit13 said:
I assume the bootloader is unlocked since you are able to flash the boot.img. Try this: re-lock the bootloader, reboot to fastboot and see if the bootloader remains locked. If the bootloader unlocks itself, this is an indication that the memory chip is damaged. Also try flashing the older stock ROM available.
Click to expand...
Click to collapse
havn't tried to lock the bootloader but tried all these after reading too many posts but dont't what the issue is?...pls have a look into this..
_____________________________________________
C:\Program Files (x86)\WugFresh Development\Nexus Root Toolkit\data>adb shell
~ # list users
/sbin/sh: list: not found
~ # df
Filesystem 1K-blocks Used Available Use% Mounted on
tmpfs 949780 128 949652 0% /dev
tmpfs 949780 0 949780 0% /storage
tmpfs 949780 0 949780 0% /mnt/secure
tmpfs 949780 0 949780 0% /mnt/fuse
~ # cat /proc/partitions
major minor #blocks name
179 0 15388672 mmcblk0
179 1 65536 mmcblk0p1
179 2 1024 mmcblk0p2
179 3 512 mmcblk0p3
179 4 512 mmcblk0p4
179 5 512 mmcblk0p5
179 6 512 mmcblk0p6
179 7 2048 mmcblk0p7
179 8 1024 mmcblk0p8
179 9 512 mmcblk0p9
179 10 512 mmcblk0p10
179 11 512 mmcblk0p11
179 12 3072 mmcblk0p12
179 13 3072 mmcblk0p13
179 14 512 mmcblk0p14
179 15 16384 mmcblk0p15
179 16 16384 mmcblk0p16
179 17 3072 mmcblk0p17
179 18 22528 mmcblk0p18
179 19 22528 mmcblk0p19
179 20 22528 mmcblk0p20
179 21 3072 mmcblk0p21
179 22 512 mmcblk0p22
179 23 512 mmcblk0p23
179 24 512 mmcblk0p24
179 25 1048576 mmcblk0p25
179 26 30720 mmcblk0p26
179 27 716800 mmcblk0p27
179 28 13404138 mmcblk0p28
179 29 5 mmcblk0p29
179 32 4096 mmcblk0rpmb
~ # mount
rootfs on / type rootfs (rw)
tmpfs on /dev type tmpfs (rw,seclabel,nosuid,relatime,mode=755)
devpts on /dev/pts type devpts (rw,seclabel,relatime,mode=600)
proc on /proc type proc (rw,relatime)
sysfs on /sys type sysfs (rw,seclabel,relatime)
selinuxfs on /sys/fs/selinux type selinuxfs (rw,relatime)
tmpfs on /storage type tmpfs (rw,seclabel,relatime,mode=050,gid=1028)
tmpfs on /mnt/secure type tmpfs (rw,seclabel,relatime,mode=700)
tmpfs on /mnt/fuse type tmpfs (rw,seclabel,relatime,mode=775,gid=1000)
~ # mount -o,rw /system
~ # mount
rootfs on / type rootfs (rw)
tmpfs on /dev type tmpfs (rw,seclabel,nosuid,relatime,mode=755)
devpts on /dev/pts type devpts (rw,seclabel,relatime,mode=600)
proc on /proc type proc (rw,relatime)
sysfs on /sys type sysfs (rw,seclabel,relatime)
selinuxfs on /sys/fs/selinux type selinuxfs (rw,relatime)
tmpfs on /storage type tmpfs (rw,seclabel,relatime,mode=050,gid=1028)
tmpfs on /mnt/secure type tmpfs (rw,seclabel,relatime,mode=700)
tmpfs on /mnt/fuse type tmpfs (rw,seclabel,relatime,mode=775,gid=1000)
/dev/block/platform/msm_sdcc.1/by-name/system on /system type ext4 (rw,seclabel,
relatime,data=ordered)
~ # moutn -o,rw /cah←[J
/sbin/sh: moutn: not found
~ # mount -o,rw /cache
mount: mounting /dev/block/platform/msm_sdcc.1/by-name/cache on /cache failed: I
nvalid argument
~ # mount -o,rw /data
mount: mounting /dev/block/platform/msm_sdcc.1/by-name/userdata on /data failed:
Invalid argument
~ # mount -o,rw /sdcard
mount: can't find /sdcard in /etc/fstab
~ # ls -l
drwxr-xr-x 2 root root 0 Jan 1 09:39 boot
drwxr-xr-x 2 root root 0 Jan 1 09:39 cache
-rwxr-x--- 1 root root 288392 Jan 1 00:00 charger
drwxr-xr-x 3 root root 0 Jan 1 09:39 data
drwxr-xr-x 2 root root 0 Jan 1 09:39 datadata
-rw-r--r-- 1 root root 3976 Jan 1 00:00 default.prop
drwxr-xr-x 10 root root 4480 Jan 1 09:39 dev
drwxr-xr-x 2 root root 0 Jan 1 09:39 emmc
drwxr-xr-x 2 root root 0 Jan 1 09:39 etc
drwxr-xr-x 2 root root 0 Jan 1 09:39 external_sd
-rw-r--r-- 1 root root 9375 Jan 1 00:00 file_contexts
-rw-r----- 1 root root 953 Jan 1 00:00 fstab.goldfish
-rw-r----- 1 root root 2653 Jan 1 00:00 fstab.hammerhead
-rwxr-x--- 1 root root 179556 Jan 1 00:00 init
-rwxr-x--- 1 root root 2708 Jan 1 00:00 init.rc
drwxr-xr-x 2 root root 0 Jan 1 09:39 internal_sd
drwxrwxr-x 5 root system 0 Jan 1 09:39 mnt
dr-xr-xr-x 127 root root 0 Jan 1 00:00 proc
-rw-r--r-- 1 root root 2161 Jan 1 00:00 property_contexts
drwxr-xr-x 2 root root 0 Jan 1 09:39 recovery
drwxr-xr-x 3 root root 0 Jan 1 00:00 res
drwx------ 2 root root 0 Dec 1 2013 root
drwxr-x--- 2 root root 0 Jan 1 00:00 sbin
drwxr-xr-x 2 root root 0 Jan 1 09:39 sd-ext
lrwxrwxrwx 1 root root 11 Jan 1 09:39 sdcard -> /data/media
-rw-r--r-- 1 root root 711 Jan 1 00:00 seapp_contexts
-rw-r--r-- 1 root root 74942 Jan 1 00:00 sepolicy
d---r-x--- 2 root sdcard_r 40 Jan 1 09:39 storage
dr-xr-xr-x 12 root root 0 Jan 1 09:39 sys
drwxr-xr-x 14 root root 4096 Jan 1 00:00 system
drwxrwxr-x 2 root shell 0 Jan 1 09:39 tmp
-rw-r--r-- 1 root root 272 Jan 1 00:00 ueventd.goldfish.rc
-rw-r--r-- 1 root root 2204 Jan 1 00:00 ueventd.hammerhead.rc
-rw-r--r-- 1 root root 5897 Jan 1 00:00 ueventd.rc
~ # cat recovery.fstab
cat: can't open 'recovery.fstab': No such file or directory
~ # cat recovery.fstab.bak
cat: can't open 'recovery.fstab.bak': No such file or directory
~ # system /bin
/sbin/sh: system: not found
~ # system/bin
/sbin/sh: system/bin: Permission denied
~ # e2fsck
Usage: e2fsck [-panyrcdfvtDFV] [-b superblock] [-B blocksize]
[-I inode_buffer_blocks] [-P process_inode_size]
[-l|-L bad_blocks_file] [-C fd] [-j external_journal]
[-E extended-options] device
Emergency help:
-p Automatic repair (no questions)
-n Make no changes to the filesystem
-y Assume "yes" to all questions
-c Check for bad blocks and add them to the badblock list
-f Force checking even if filesystem is marked clean
-v Be verbose
-b superblock Use alternative superblock
-B blocksize Force blocksize when looking for superblock
-j external_journal Set location of the external journal
-l bad_blocks_file Add to badblocks list
-L bad_blocks_file Set badblocks list
~ # -p
/sbin/sh: -p: not found
~ # p
/sbin/sh: p: not found
~ # e2fsck -p
Usage: e2fsck [-panyrcdfvtDFV] [-b superblock] [-B blocksize]
[-I inode_buffer_blocks] [-P process_inode_size]
[-l|-L bad_blocks_file] [-C fd] [-j external_journal]
[-E extended-options] device
Emergency help:
-p Automatic repair (no questions)
-n Make no changes to the filesystem
-y Assume "yes" to all questions
-c Check for bad blocks and add them to the badblock list
-f Force checking even if filesystem is marked clean
-v Be verbose
-b superblock Use alternative superblock
-B blocksize Force blocksize when looking for superblock
-j external_journal Set location of the external journal
-l bad_blocks_file Add to badblocks list
-L bad_blocks_file Set badblocks list
~ # c
/sbin/sh: c: not found
~ # e2fsckc
/sbin/sh: e2fsckc: not found
~ # e2fsck c
e2fsck 1.41.14 (22-Dec-2010)
e2fsck: No such file or directory while trying to open c
Possibly non-existent device?
~ # e2fsck -c
Usage: e2fsck [-panyrcdfvtDFV] [-b superblock] [-B blocksize]
[-I inode_buffer_blocks] [-P process_inode_size]
[-l|-L bad_blocks_file] [-C fd] [-j external_journal]
[-E extended-options] device
Emergency help:
-p Automatic repair (no questions)
-n Make no changes to the filesystem
-y Assume "yes" to all questions
-c Check for bad blocks and add them to the badblock list
-f Force checking even if filesystem is marked clean
-v Be verbose
-b superblock Use alternative superblock
-B blocksize Force blocksize when looking for superblock
-j external_journal Set location of the external journal
-l bad_blocks_file Add to badblocks list
-L bad_blocks_file Set badblocks list
~ # e2fsck -y /dev/block/platform/msm_sdcc.1/by-name/persist
e2fsck 1.41.14 (22-Dec-2010)
/dev/block/platform/msm_sdcc.1/by-name/persist: recovering journal
Superblock needs_recovery flag is clear, but journal has data.
Run journal anyway? yes
e2fsck: unable to set superblock flags on /dev/block/platform/msm_sdcc.1/by-name
/persist
~ # cat /proc/partitions
major minor #blocks name
179 0 15388672 mmcblk0
179 1 65536 mmcblk0p1
179 2 1024 mmcblk0p2
179 3 512 mmcblk0p3
179 4 512 mmcblk0p4
179 5 512 mmcblk0p5
179 6 512 mmcblk0p6
179 7 2048 mmcblk0p7
179 8 1024 mmcblk0p8
179 9 512 mmcblk0p9
179 10 512 mmcblk0p10
179 11 512 mmcblk0p11
179 12 3072 mmcblk0p12
179 13 3072 mmcblk0p13
179 14 512 mmcblk0p14
179 15 16384 mmcblk0p15
179 16 16384 mmcblk0p16
179 17 3072 mmcblk0p17
179 18 22528 mmcblk0p18
179 19 22528 mmcblk0p19
179 20 22528 mmcblk0p20
179 21 3072 mmcblk0p21
179 22 512 mmcblk0p22
179 23 512 mmcblk0p23
179 24 512 mmcblk0p24
179 25 1048576 mmcblk0p25
179 26 30720 mmcblk0p26
179 27 716800 mmcblk0p27
179 28 13404138 mmcblk0p28
179 29 5 mmcblk0p29
179 32 4096 mmcblk0rpmb
~ # df
Filesystem 1K-blocks Used Available Use% Mounted on
tmpfs 949780 128 949652 0% /dev
tmpfs 949780 0 949780 0% /storage
tmpfs 949780 0 949780 0% /mnt/secure
tmpfs 949780 0 949780 0% /mnt/fuse
/dev/block/platform/msm_sdcc.1/by-name/system
1033516 1020920 12596 99% /system
~ #
C:\Program Files (x86)\WugFresh Development\Nexus Root Toolkit\data>fastboot dev
ices
034dd8de828dd06c fastboot
C:\Program Files (x86)\WugFresh Development\Nexus Root Toolkit\data>fastboot for
mat system
Creating filesystem with parameters:
Size: 1073741824
Block size: 4096
Blocks per group: 32768
Inodes per group: 8192
Inode size: 256
Journal blocks: 4096
Label:
Blocks: 262144
Block groups: 8
Reserved block group size: 63
Created filesystem with 11/65536 inodes and 8536/262144 blocks
target reported max download size of 1073741824 bytes
erasing 'system'...
OKAY [ 0.187s]
sending 'system' (18800 KB)...
OKAY [ 0.813s]
writing 'system'...
FAILED (remote: flash write failure)
finished. total time: 1.188s
C:\Program Files (x86)\WugFresh Development\Nexus Root Toolkit\data>fastboot for
mat cache
Creating filesystem with parameters:
Size: 734003200
Block size: 4096
Blocks per group: 32768
Inodes per group: 7472
Inode size: 256
Journal blocks: 2800
Label:
Blocks: 179200
Block groups: 6
Reserved block group size: 47
Created filesystem with 11/44832 inodes and 5813/179200 blocks
target reported max download size of 1073741824 bytes
erasing 'cache'...
FAILED (remote: failed to erase partition)
finished. total time: 0.219s
C:\Program Files (x86)\WugFresh Development\Nexus Root Toolkit\data>fastboot for
mat bootloader
Formatting is not supported for file system with type ''.
_______________________________________________________
Try the suggestion about relocking there bootloader and checking to see if it stays locked. If it doesn't stay locked, I would replace the motherboard.
When trying to delete partition 28, I get:
Error: Input/output error during write on /dev/block/mmcblk0
Anybody else got this and found a way to solve it?
audit13 said:
I assume the bootloader is unlocked since you are able to flash the boot.img. Try this: re-lock the bootloader, reboot to fastboot and see if the bootloader remains locked. If the bootloader unlocks itself, this is an indication that the memory chip is damaged. Also try flashing the older stock ROM available.
Click to expand...
Click to collapse
Thanks, I've been reading for quite some time looking for a solution to fix my Nexus 5 (I bought it brick just to fix it), and it does exactly what you mention here in your post. It recognize fastboot, it lock the bootloader but when the phone reboot, it display bootloader unlock. It doesn't let me flash the recovery img. by computer.
Thanks
The motherboard's flash memory is defective which means you'll need to replace the motherboard to have functional phone.
[Guide] Repartition Nexus5 to increase system partition - Space for Rom & Stock Gapps
Before I begin...don't do this if you don't know what you're doing. If you know what you're doing still don't do this. This is dangerous, and in general people don't even make good guides for this likely because it's SUCH a stupid thing to do. Samsung phones support PIT re partitioning, but for something like a Nexus, there is no easy guide. You can and likely will brick your phone...at best you will certainly wipe all data.
I wanted to install a nougat rom on my cracked-screen Nexus5, but in flashing it AND stock gapps would error out since there isn't enough room on the /system partition for both. The Nexus5 comes with a 1GB system partition which was fine way back in the day, but isn't really fine anymore. In order to pull space from the large userdata partition, we need to do some linux trickery. I chose to make /system 2GB, which may be overkill, but this phone is going to be a baby monitor/white noise machine for a 5 month old so who cares.
The prerequisite for this process is a TWRP recovery, and that's pretty much it. Ideally, fdisk would be baked in with busybox or the parted utility would be on the phone and you could use the resize function...every time I tried to use busybox's fdisk led to errors or commands wouldn't work, and parted's resize command can't deal with ext4.
The high-level procedure here is, since filesystems must be contiguous and in order so they can be addressed properly, we need to delete every partition inclusively from system to userdata, then recreate them with new storage offsets. To visualize this, here's the storage layout as it started out on my Nexus 5:
Code:
Model: MMC SEM32G (sd/mmc)
Disk /dev/block/mmcblk0: 31.3GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Number Start End Size File system Name Flags
1 524kB 67.6MB 67.1MB fat16 modem
2 67.6MB 68.7MB 1049kB sbl1
3 68.7MB 69.2MB 524kB rpm
4 69.2MB 69.7MB 524kB tz
5 69.7MB 70.3MB 524kB sdi
6 70.3MB 70.8MB 524kB aboot
7 70.8MB 72.9MB 2097kB pad
8 72.9MB 73.9MB 1049kB sbl1b
9 73.9MB 74.4MB 524kB tzb
10 74.4MB 75.0MB 524kB rpmb
11 75.0MB 75.5MB 524kB abootb
12 75.5MB 78.6MB 3146kB modemst1
13 78.6MB 81.8MB 3146kB modemst2
14 81.8MB 82.3MB 524kB metadata
15 82.3MB 99.1MB 16.8MB misc
16 99.1MB 116MB 16.8MB ext4 persist
17 116MB 119MB 3146kB imgdata
18 119MB 142MB 23.1MB laf
19 142MB 165MB 23.1MB boot
20 165MB 188MB 23.1MB recovery
21 188MB 191MB 3146kB fsg
22 191MB 192MB 524kB fsc
23 192MB 192MB 524kB ssd
24 192MB 193MB 524kB DDR
25 193MB 1267MB 1074MB ext4 system
26 1267MB 1298MB 31.5MB crypto
27 1298MB 2032MB 734MB ext4 cache
28 2032MB 31.3GB 29.2GB ext4 userdata
29 31.3GB 31.3GB 5632B grow
Looking at that, we want to increase system (partition 25), shift crypto (partition 26), shift cache (partition 27), and shrink userdata (partition 28). If you try this on a different phone, you'll have different partitions to move.
I did this from a Debian desktop using adb, but you can use any platform that has adb. You need to download the parted binary linked below, a nexus5 Nougat rom (or any rom I guess), and a gapps package (I chose stock). Here's the commands I used:
Code:
wget http://iwf1.com/iwf-repo/parted.rar
unrar e parted.rar
sudo adb push parted /
sudo adb shell
~ # chmod +x parted
~ # ./parted /dev/block/mmcblk0 p
~ # umount /data
~ # umount /sdcard
~ # umount /cache
~ # ./parted /dev/block/mmcblk0 rm 25
~ # ./parted /dev/block/mmcblk0 rm 26
~ # ./parted /dev/block/mmcblk0 rm 27
~ # ./parted /dev/block/mmcblk0 rm 28
~ # ./parted /dev/block/mmcblk0 mkpart primary 193MB 2291MB
~ # ./parted /dev/block/mmcblk0 mkpart extended 2291MB 2322MB
~ # ./parted /dev/block/mmcblk0 mkpart primary 2322MB 3056MB
~ # ./parted /dev/block/mmcblk0 mkpart primary 3056MB 30.8GB
~ # ./parted /dev/block/mmcblk0 p
~ # ./parted /dev/block/mmcblk0 name 25 system
~ # ./parted /dev/block/mmcblk0 name 26 crypto
~ # ./parted /dev/block/mmcblk0 name 27 cache
~ # ./parted /dev/block/mmcblk0 name 28 userdata
~ # mke2fs -b 4096 -T ext4 /dev/block/mmcblk0p25
~ # mke2fs -b 4096 -T ext4 /dev/block/mmcblk0p27
~ # mke2fs -b 4096 -T ext4 /dev/block/mmcblk0p28
~ # ./parted /dev/block/mmcblk0 p
~ # mount -a
~ # exit
# Download from here: http://www.androiddevs.net/downloads/
sudo adb push aosp_hammerhead-7.1-nougat-*.zip /data/
# Download from here: http://opengapps.org/
sudo adb push open_gapps-arm-7.1-stock-*.zip /data/
sudo adb reboot recovery
# Install the nougat rom through twrp...this will resize the /system partition back to 1GB!
sudo adb shell
~ # umount /system
~ # resize2fs -f /dev/block/mmcblk0p25 2000M
~ # mount -a
# Install opengapps in twrp
~ # exit
# Reboot into system through TWRP GUI
There were some logging errors with the SantoshM nougat rom I tried, but they had no impact. I am unmounting /sdcard and that's where it's trying to stash the logs, hence errors.
You can see that the offsets for the new partitions are 1024MB higher than the originals, meaning the partition will be 1GB bigger. Here's my final partition table:
Code:
Model: MMC SEM32G (sd/mmc)
Disk /dev/block/mmcblk0: 31.3GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Number Start End Size File system Name Flags
1 524kB 67.6MB 67.1MB fat16 modem
2 67.6MB 68.7MB 1049kB sbl1
3 68.7MB 69.2MB 524kB rpm
4 69.2MB 69.7MB 524kB tz
5 69.7MB 70.3MB 524kB sdi
6 70.3MB 70.8MB 524kB aboot
7 70.8MB 72.9MB 2097kB pad
8 72.9MB 73.9MB 1049kB sbl1b
9 73.9MB 74.4MB 524kB tzb
10 74.4MB 75.0MB 524kB rpmb
11 75.0MB 75.5MB 524kB abootb
12 75.5MB 78.6MB 3146kB modemst1
13 78.6MB 81.8MB 3146kB modemst2
14 81.8MB 82.3MB 524kB metadata
15 82.3MB 99.1MB 16.8MB misc
16 99.1MB 116MB 16.8MB ext4 persist
17 116MB 119MB 3146kB imgdata
18 119MB 142MB 23.1MB laf
19 142MB 165MB 23.1MB boot
20 165MB 188MB 23.1MB recovery
21 188MB 191MB 3146kB fsg
22 191MB 192MB 524kB fsc
23 192MB 192MB 524kB ssd
24 192MB 193MB 524kB DDR
25 193MB 2291MB 2098MB ext4 system
26 2291MB 2322MB 31.0MB crypto
27 2322MB 3056MB 734MB ext4 cache
28 3056MB 31.3GB 28.2GB ext4 userdata
29 31.3GB 31.3GB 5632B grow
When we resize /system, we're not quite giving it the whole space...I recommend running "resize2fs /dev/block/mmcblk0p25 2048M" and seeing the error...it's easier to adjust the actual filesystem size than the partition size, so we fudge it a bit here so long as it's safe. If this test is unsuccessful, it will tell you that you're allocating more blocks than you have. If it's successful, it'll tell you to run e2fsck...this is normal, and running the resize2fs command with the -f flag overrides that warning...but it'll also allow you to allocate too many blocks, hence why you run a test first as a sanity check. For this exact procedure, 2000M is the exact maximum size.
All in all, this technique can likely be adapted to other android phones. The key is making sure you resize system by the amount you take from data, and making sure you offset all partitions in between linearly by the correct amount. I'm not sure how updates will work...anything that basically lays down a partition is gonna cause issues since it'll try to resize to the default partition size. Anything just laying down new files should be fine.
Happy hacking!
I was looking for such an option as I wanted to install a bigger gapps package then just pico. But shrinking my userdata partition is not was i had in mind. I also really do not want to loose all my data, as i am leazy
so i was thinking about just resizing /cache to a bare minimum of lets say 128mb or even less. Because as i understand /cache is just used for OTA updates - if i am mistaken here, feel free to update my knowledge.
Has anybody done this? On the Galaxy Nexus this is the way to go afaik and one would not loose things in /data.
It worked, Thank you!
What i essentially did was make a nandroid backup followed by "adb pull /sdcard/" on the computer.
Followed your instructions (just before the flashing section), pushed the sdcard data back and restored the backup.
chowned and chmodded the /sdcard directory:
Code:
chown media_rw:media_rw /sdcard
chmod 755 /sdcard
Resized the /system bit, rebooted and hoped it wouldn't 'bootloop'.
The process was nerve wracking, but now the handset is ready for a future stable ROM (I'm still on stock).
So, we need to do
Code:
resize2fs -f /dev/block/mmcblk0p25 2000M
every time we flash a new ROM?
alexeius said:
So, we need to do
Code:
resize2fs -f /dev/block/mmcblk0p25 2000M
every time we flash a new ROM?
Click to expand...
Click to collapse
surfrock66 said:
All in all, this technique can likely be adapted to other android phones. The key is making sure you resize system by the amount you take from data, and making sure you offset all partitions in between linearly by the correct amount. I'm not sure how updates will work...anything that basically lays down a partition is gonna cause issues since it'll try to resize to the default partition size. Anything just laying down new files should be fine.
Happy hacking!
Click to expand...
Click to collapse
Depends on the ROM you're installing.
Everyone must pay attention that this guide is for 32gb model........for 16gb commands are different.......pay attention else u brick seriously you phone.....
SoftWord said:
Everyone must pay attention that this guide is for 32gb model........for 16gb commands are different.......pay attention else u brick seriously you phone.....
Click to expand...
Click to collapse
Yes, this...my numbers show the methodology, but for the 16GB nexus 5 (or any other phone) you need to start by looking at the starting state of the partition table, then do the math from start to finish. I hope I've provided enough methodology and warnings that someone will either abort or do it right.
poioq said:
I was looking for such an option as I wanted to install a bigger gapps package then just pico. But shrinking my userdata partition is not was i had in mind. I also really do not want to loose all my data, as i am leazy
so i was thinking about just resizing /cache to a bare minimum of lets say 128mb or even less. Because as i understand /cache is just used for OTA updates - if i am mistaken here, feel free to update my knowledge.
Has anybody done this? On the Galaxy Nexus this is the way to go afaik and one would not loose things in /data.
Click to expand...
Click to collapse
In general I would say that's a very bad idea...however, if you're very careful and are willing to incur some risk, it could possibly work...on the N5, since the cache partition sits between system and userdata (and more importantly doesn't touch recovery) you could theoretically try it, and if it doesn't work, undo it, all while leaving your userdata partition untouched. If preserving your data is your goal...it's probably a bad idea, but that doesn't mean it isn't possible.
How about taking space from cache to userdata? 1-1,5GB'll be unused anyway and on 16gb variant it'll be nice to have some more memory to have
TL;DR
Success: Repartition of a Nexus 5 16GB
Success: Flash cm-14.1-20161028-UNOFFICIAL-hammerhead.zip
Success: Flash open_gapps-arm-7.1-stock-20161217.zip
FAIL: Getting through the Google/CM set up process (Google Play services crashes)
Success: Flash Aroma Gapps
Gapps selections:
Code:
AndroidPay=0
Books=0
CalculatorGoogle=1
CalendarGoogle=1
CalSync=0
CameraGoogle=1
Chrome=1
ClockGoogle=1
CloudPrint=0
ContactsGoogle=1
DialerFramework=1
DialerGoogle=1
DMAgent=0
Docs=0
Drive=0
Earth=0
ExchangeGoogle=0
FaceDetect=0
FaceUnlock=1
Fitness=1
GCS=1
Gmail=0
GoogleNow=0
GooglePlus=0
GoogleTTS=0
Hangouts=0
Hotword=0
Indic=0
Japanese=0
Keep=1
KeyboardGoogle=1
Korean=0
Maps=1
Messenger=0
Movies=0
Music=1
NewsStand=0
NewsWidget=0
PackageInstallerGoogle=0
Pinyin=0
PixelIcons=1
PixelLauncher=1
Photos=1
PlayGames=0
PrintServiceGoogle=0
ProjectFi=0
Sheets=0
Slides=0
Search=1
Speech=0
StorageManagerGoogle=0
Street=0
TagGoogle=0
Talkback=0
Translate=1
VRService=0
Wallpapers=1
WebViewGoogle=1
YouTube=1
Zhuyin=0
inclorexcl=1
Aim
To convert my Nexus 5 16GB into a Pixel using CM14.1 and Stock Open Gapps (I didn't want to keep flashing random pixel-experience.zip files)
Issue (strikethrough issues are with Stock Gapps)
When using Aroma Gapps:
1. Launcher3 crashes everytime the G search bar is clicked on
2. Google Now is not on the left pane despite my chosen packages
1. I couldn't Sign into my WiFi because no soft keyboard would appear (workaround: I created a password-less Hotspot on another phone)
2. I wasn't able to get past through the Google setup process; Google Play Services would crash every time I attempted to skip Tap & Go taking me back to a SIM card missing screen. On skipping this, I get taken to Tap & Go... and repeat
I've wiped all the caches (of course). If anyone has any ideas, it would be great.
Question to @surfrock66
You have a parted command that says:
Code:
~ # ./parted /dev/block/mmcblk0 mkpart primary 3056MB 30.8GB
Should this not be:
Code:
~ # ./parted /dev/block/mmcblk0 mkpart primary 3056MB 31.3GB
I may not have understood this fully
Thanks surfrock66 for the original method; my method varies slightly and is as follows:
Code:
Download and unpack parted.rar via the
# With phone in TWRP Recovery
$ sudo adb push parted /
$ sudo adb shell
~ # chmod +x parted
~ # ./parted /dev/block/mmcblk0 p
Model: MMC SEM16G (sd/mmc)
Disk /dev/block/mmcblk0: 15.8GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Number Start End Size File system Name Flags
1 524kB 67.6MB 67.1MB fat16 modem
2 67.6MB 68.7MB 1049kB sbl1
3 68.7MB 69.2MB 524kB rpm
4 69.2MB 69.7MB 524kB tz
5 69.7MB 70.3MB 524kB sdi
6 70.3MB 70.8MB 524kB aboot
7 70.8MB 72.9MB 2097kB pad
8 72.9MB 73.9MB 1049kB sbl1b
9 73.9MB 74.4MB 524kB tzb
10 74.4MB 75.0MB 524kB rpmb
11 75.0MB 75.5MB 524kB abootb
12 75.5MB 78.6MB 3146kB modemst1
13 78.6MB 81.8MB 3146kB modemst2
14 81.8MB 82.3MB 524kB metadata
15 82.3MB 99.1MB 16.8MB misc
16 99.1MB 116MB 16.8MB ext4 persist
17 116MB 119MB 3146kB imgdata
18 119MB 142MB 23.1MB laf
19 142MB 165MB 23.1MB boot
20 165MB 188MB 23.1MB recovery
21 188MB 191MB 3146kB fsg
22 191MB 192MB 524kB fsc
23 192MB 192MB 524kB ssd
24 192MB 193MB 524kB DDR
25 193MB 1267MB 1074MB ext4 system
26 1267MB 1298MB 31.5MB crypto
27 1298MB 2032MB 734MB ext4 cache
28 2032MB 15.8GB 13.7GB ext4 userdata
29 15.8GB 15.8GB 5632B grow
~ # umount /data
~ # umount /sdcard
~ # umount /cache
~ # ./parted /dev/block/mmcblk0 rm 25
~ # ./parted /dev/block/mmcblk0 rm 26
~ # ./parted /dev/block/mmcblk0 rm 27
~ # ./parted /dev/block/mmcblk0 rm 28
~ # ./parted /dev/block/mmcblk0 mkpart primary 193MB 2291MB
~ # ./parted /dev/block/mmcblk0 mkpart extended 2291MB 2322MB
~ # ./parted /dev/block/mmcblk0 mkpart primary 2322MB 3056MB
~ # ./parted /dev/block/mmcblk0 mkpart primary 3056MB 15.8GB
~ # ./parted /dev/block/mmcblk0 p
~ # ./parted /dev/block/mmcblk0 name 25 system
~ # ./parted /dev/block/mmcblk0 name 26 crypto
~ # ./parted /dev/block/mmcblk0 name 27 cache
~ # ./parted /dev/block/mmcblk0 name 28 userdata
~ # mke2fs -b 4096 -T ext4 /dev/block/mmcblk0p25
~ # mke2fs -b 4096 -T ext4 /dev/block/mmcblk0p27
~ # mke2fs -b 4096 -T ext4 /dev/block/mmcblk0p28
~ # ./parted /dev/block/mmcblk0 p
~ # mount -a
~ # exit
Model: MMC SEM16G (sd/mmc)
Disk /dev/block/mmcblk0: 15.8GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Number Start End Size File system Name Flags
1 524kB 67.6MB 67.1MB fat16 modem
2 67.6MB 68.7MB 1049kB sbl1
3 68.7MB 69.2MB 524kB rpm
4 69.2MB 69.7MB 524kB tz
5 69.7MB 70.3MB 524kB sdi
6 70.3MB 70.8MB 524kB aboot
7 70.8MB 72.9MB 2097kB pad
8 72.9MB 73.9MB 1049kB sbl1b
9 73.9MB 74.4MB 524kB tzb
10 74.4MB 75.0MB 524kB rpmb
11 75.0MB 75.5MB 524kB abootb
12 75.5MB 78.6MB 3146kB modemst1
13 78.6MB 81.8MB 3146kB modemst2
14 81.8MB 82.3MB 524kB metadata
15 82.3MB 99.1MB 16.8MB misc
16 99.1MB 116MB 16.8MB ext4 persist
17 116MB 119MB 3146kB imgdata
18 119MB 142MB 23.1MB laf
19 142MB 165MB 23.1MB boot
20 165MB 188MB 23.1MB recovery
21 188MB 191MB 3146kB fsg
22 191MB 192MB 524kB fsc
23 192MB 192MB 524kB ssd
24 192MB 193MB 524kB DDR
25 193MB 2291MB 2098MB ext4 system
26 2291MB 2322MB 31.0MB crypto
27 2322MB 3056MB 734MB ext4 cache
28 3056MB 15.8GB 12.7GB ext4 userdata
29 15.8GB 15.8GB 5632B grow
# This didn't work for me
$ sudo adb push cm-14.1-20161028-UNOFFICIAL-hammerhead.zip /
$ sudo adb push open_gapps-arm-7.1-stock-20161217.zip /
$ sudo adb reboot recovery
# So I copied over the files once I reboot into recovery
# I had to reboot into recovery again to see my CM14.1 and Gapps files
# Flashed them using TWRP
$ sudo adb shell
~ # unmount /system/
/sbin/sh: unmount: not found
# I have no idea why this happened
~ # resize2fs -f /dev/block/mmcblk0p25 2000M
resize2fs 1.42.9 (28-Dec-2013)
Resizing the filesystem on /dev/block/mmcblk0p25 to 512000 (4k) blocks.
The filesystem on /dev/block/mmcblk0p25 is now 512000 blocks long.
~ # mount -a
mount: mounting /dev/block/mmcblk0p1 on /firmware failed: Invalid argument
mount: mounting /usb-otg on vfat failed: No such file or directory
# I have no idea why this happened either
~ # exit
@surfrock66 Hi, is the same way for n7 (2013) 32gb?
Thanks
Sent from my Nexus 7 using XDA-Developers mobile app
jordirpz said:
@surfrock66 Hi, is the same way for n7 (2013) 32gb?
Thanks
Click to expand...
Click to collapse
No, this is not necessarily true. You will need to use Parted to analyse the partitions and then make the relevant modifications. Again, do not try this unless you are willing to potentially brick your device.
@surfrock66
Faied copy parted to //parted : read-only file system
Whats hapend?
Sent from my Nexus 7 using XDA-Developers mobile app
jordirpz said:
@surfrock66
Faied copy parted to //parted : read-only file system
Whats hapend?
Sent from my Nexus 7 using XDA-Developers mobile app
Click to expand...
Click to collapse
In TWRP, you have to choose to mount your system as read/write, for me with TWRP 3.x it's an option right when TWRP starts. If you don't do that, you can't write to / and thus can't copy the file over.
surfrock66 said:
In TWRP, you have to choose to mount your system as read/write, for me with TWRP 3.x it's an option right when TWRP starts. If you don't do that, you can't write to / and thus can't copy the file over.
Click to expand...
Click to collapse
Ok thank you.
Other question please. Adb Shell steps, works in trwp or i need mount system and reboot system for make it? Thank you
Sent from my Nexus 7 using XDA-Developers mobile app
jordirpz said:
Ok thank you.
Other question please. Adb Shell steps, works in trwp or i need mount system and reboot system for make it? Thank you
Sent from my Nexus 7 using XDA-Developers mobile app
Click to expand...
Click to collapse
All done while in twrp.
surfrock66 said:
All done while in twrp.
Click to expand...
Click to collapse
Ok, thanks for you awesome guide.
For me works, now i have 2gb in system?
Sorry for ETA: can you in near future make a reparted file and guide for N7 2013 wifi please?
Sent from my Nexus 7 using XDA-Developers mobile app
jordirpz said:
Ok, thanks for you awesome guide.
For me works, now i have 2gb in system?
Sorry for ETA: can you in near future make a reparted file and guide for N7 2013 wifi please?
Sent from my Nexus 7 using XDA-Developers mobile app
Click to expand...
Click to collapse
I don't have that device, but the original post here should have everything you need to re-create the process for another device. You'll have to re-calculate the offsets based on what you find when you run the original partition query.
souheil said:
Depends on the ROM you're installing.
Click to expand...
Click to collapse
Just to double check.
Any ideas of what ROMs would need this?
I'm interested of the cyanogenmod in my particular case.
ricardo.adao said:
Just to double check.
Any ideas of what ROMs would need this?
I'm interested of the cyanogenmod in my particular case.
Click to expand...
Click to collapse
CM14.1 fits on the Nexus 5 /system partition WITHOUT repartitioning.
I wanted to try this because I want to flash Stock Gapps (as opposed to Nano), hoping to get a Pixel-like experience as described in my previous post (http://forum.xda-developers.com/showpost.php?p=70145560&postcount=10). However, I had lots of crashes with Stock Gapps.
Instead, I now use CM14.1 with Nano Gapps.
If you want a more Pixel-like experience, that side-loading doesn't provide (no Google Now on the left side of the Homescreen, no Pixel-like animations on clicking the G Search Bar), I have resorted to installing the Pixel Launcher and Wallpaper APKs into /system.
Instructions found: http://android.stackexchange.com/questions/76976/how-to-install-app-as-system-app
Re-flashing a ROM will require you to re-do these steps.
I got tired of installing amazing ROMs created by the talented folks here on XDA, but being held back on things like Google Apps because of the tiny /system partition we have on the Nexus 4. I looked around and found guides to increase the system space in the Nexus 5 and Nexus 7 2013, so I basically just adapted them to work on our beloved Nexus 4.
As always, do this at your OWN risk. I am not responsible for bricking your Nexus 4. I will simply list the process which I used to increase my Nexus 4's system partition (by taking a big ol' chunk from the cache partition). Remember, any sort of modification to your device of this caliber WILL void any warranty you might still have.
REQUIREMENTS:
parted (Uploaded to my Google Drive. If it downloads as a .txt, rename it to remove the extension and make it a plain file)
adb and fastboot, and preferably knowledge on how they work
Step 1: Install TWRP onto your Nexus 4 and reboot into it.
Step 2: Open up command prompt / terminal and check to see if your Nexus 4 is connected properly with "adb devices".
Step 3: Once you've confirmed that adb is fully working and your Nexus 4 is properly connected to your PC, download parted and use adb to push it to your Nexus 4 using the command:
Code:
adb push parted /
Step 4: Now enter the following command:
Code:
adb shell
and then the command:
Code:
chmod +x parted
This will enter adb shell and make the "parted" binary you pushed to your device earlier executable.
Step 5:
Now run the command
Code:
./parted /dev/block/mmcblk0 p
You should see a long list with a bunch of numbers and names in your terminal. These are the partitions on your device. parted will give you the partition number, the "start" and "end" of the partition, the size, and the name.
This is the partition layout on my device. It will probably be the same on your device, though the size of userdata may vary depending on whether you have the 8gb or 16gb Nexus 4.
Code:
~ # ./parted /dev/block/mmcblk0 p
Model: MMC 016G92 (sd/mmc)
Disk /dev/block/mmcblk0: 15.8GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Number Start End Size File system Name Flags
1 524kB 67.6MB 67.1MB fat16 modem
2 67.6MB 68.2MB 524kB sbl1
3 68.2MB 68.7MB 524kB sbl2
4 68.7MB 70.8MB 2097kB sbl3
5 70.8MB 71.3MB 524kB tz
6 71.3MB 94.4MB 23.1MB boot
7 94.4MB 117MB 23.1MB recovery
8 117MB 118MB 799kB m9kefs1
9 118MB 119MB 799kB m9kefs2
10 119MB 120MB 799kB m9kefs3
11 120MB 121MB 524kB rpm
12 121MB 121MB 524kB aboot
13 121MB 122MB 524kB sbl2b
14 122MB 124MB 2097kB sbl3b
15 124MB 124MB 524kB abootb
16 124MB 125MB 524kB rpmb
17 125MB 125MB 524kB tzb
18 125MB 126MB 524kB metadata
19 126MB 143MB 16.8MB misc
20 143MB 159MB 16.8MB ext4 persist
21 159MB 1040MB 881MB ext2 system
22 1040MB 1627MB 587MB ext4 cache
23 1627MB 15.8GB 14.1GB ext4 userdata
24 15.8GB 15.8GB 524kB DDR
25 15.8GB 15.8GB 507kB grow
Step 6:
Now run the following three commands:
Code:
umount /data
umount /sdcard
umount /cache
Step 7: So, on my Nexus 4, the system partition is number 21, and cache is 22. We're kinda lucky in the fact that system and cache are right next to each other, meaning we don't have to touch any other partition.
You'll want to run these two next commands. These commands will essentially "remove" the two partitions.
Code:
./parted /dev/block/mmcblk0 rm 21
./parted /dev/block/mmcblk0 rm 22
Step 8: Now it is time to recreate these two partitions, however, when recreating them, we will make system bigger and the cache smaller. From the partitions list we got in Step 5, we can see that system starts at 159 and ends at 1040, while cache starts at 1040 and ends at 1627. The following two commands will rebuild /system starting at 159, but ending at 1590, while rebuilding cache at 1590, and ending at 1627. We are essentially stealing a large chunk from cache, since we don't really need that anymore on newer ROMs.
Code:
./parted /dev/block/mmcblk0 mkpart primary 159 1590
./parted /dev/block/mmcblk0 mkpart primary 1590 1627
Step 9: Now run this command:
Code:
./parted /dev/block/mmcblk0 p
This will bring up the partitions list, or table, again. This time, however, we'll see the new partitions where system and cache were, however, they have no names! The following two commands will name the two partitions again.
Code:
./parted /dev/block/mmcblk0 name 21 system
./parted /dev/block/mmcblk0 name 22 cache
Step 10: Great! Now the partitions should be named again! Now, we still have to format the partitions as ext4 so that we can actually use them. The following two commands will do that for you.
Code:
mke2fs -b 4096 -T ext4 /dev/block/mmcblk0p21
mke2fs -b 4096 -T ext4 /dev/block/mmcblk0p22
Step 11: At this point, feel free to run the command from Step 5 to take one more look at the partition table and make sure everything looks good. Now run the command
Code:
mount -a
and then type in
Code:
exit
.
Step 12: Now we are pretty much done. We've extended the system partition from approx. 881mb to 1431mb, which is a nice large chunk of memory. In the future, we could always mess with the partitions more to add even more space by stealing from userdata, but until we reach that point, I think we are pretty well set for now!
Now...
You'll want to reboot TWRP, and flash a new ROM. You can now use a much bigger Google Apps package, without any worries.
Do note, however, that flashing a ROM will "resize" system to be smaller, but this isn't a huge deal. After flashing a ROM, while still in TWRP, you'll want to go to Wipe > Advanced Wipe > check "system" then head to "Repair or Change File System", > then tap on "Resize File System." If you encounter any errors while trying to resize, try remounting system or rebooting TWRP. Afterwards, you should be able to flash your Google Apps package. I'm not sure if you need to repeat these steps after flashing things other than ROMs, but repeating this process within TWRP should work just as well.
I hope I helped y'all out and feel free to post if this guide worked for you or if you have any other comments!
CREDITS:
@surfrock66 for his Nexus 5 guide here.
@rkhat for his Nexus 7 2013 guide here.
RESERVED
Worked Thanx
It worked here on my 8 Gb mako. Here are the original parted output:
Code:
Model: MMC 008G92 (sd/mmc)
Disk /dev/block/mmcblk0: 7818MB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Number Start End Size File system Name Flags
1 524kB 67.6MB 67.1MB fat16 modem
2 67.6MB 68.2MB 524kB sbl1
3 68.2MB 68.7MB 524kB sbl2
4 68.7MB 70.8MB 2097kB sbl3
5 70.8MB 71.3MB 524kB tz
6 71.3MB 94.4MB 23.1MB boot
7 94.4MB 117MB 23.1MB recovery
8 117MB 118MB 799kB m9kefs1
9 118MB 119MB 799kB m9kefs2
10 119MB 120MB 799kB m9kefs3
11 120MB 121MB 524kB rpm
12 121MB 121MB 524kB aboot
13 121MB 122MB 524kB sbl2b
14 122MB 124MB 2097kB sbl3b
15 124MB 124MB 524kB abootb
16 124MB 125MB 524kB rpmb
17 125MB 125MB 524kB tzb
18 125MB 126MB 524kB metadata
19 126MB 143MB 16.8MB misc
20 143MB 159MB 16.8MB ext4 persist
21 159MB 1040MB 881MB ext2 system
22 1040MB 1627MB 587MB ext4 cache
23 1627MB 7817MB 6190MB ext4 userdata
24 7817MB 7818MB 524kB DDR
25 7818MB 7818MB 507kB grow
I'm using Nitrogen OS 8.1 with GZR Gapps
jfsobreira said:
It worked here on my 8 Gb mako. Here are the original parted output:
Code:
Model: MMC 008G92 (sd/mmc)
Disk /dev/block/mmcblk0: 7818MB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Number Start End Size File system Name Flags
1 524kB 67.6MB 67.1MB fat16 modem
2 67.6MB 68.2MB 524kB sbl1
3 68.2MB 68.7MB 524kB sbl2
4 68.7MB 70.8MB 2097kB sbl3
5 70.8MB 71.3MB 524kB tz
6 71.3MB 94.4MB 23.1MB boot
7 94.4MB 117MB 23.1MB recovery
8 117MB 118MB 799kB m9kefs1
9 118MB 119MB 799kB m9kefs2
10 119MB 120MB 799kB m9kefs3
11 120MB 121MB 524kB rpm
12 121MB 121MB 524kB aboot
13 121MB 122MB 524kB sbl2b
14 122MB 124MB 2097kB sbl3b
15 124MB 124MB 524kB abootb
16 124MB 125MB 524kB rpmb
17 125MB 125MB 524kB tzb
18 125MB 126MB 524kB metadata
19 126MB 143MB 16.8MB misc
20 143MB 159MB 16.8MB ext4 persist
21 159MB 1040MB 881MB ext2 system
22 1040MB 1627MB 587MB ext4 cache
23 1627MB 7817MB 6190MB ext4 userdata
24 7817MB 7818MB 524kB DDR
25 7818MB 7818MB 507kB grow
I'm using Nitrogen OS 8.1 with GZR Gapps
Click to expand...
Click to collapse
Awesome! Thanks for letting me know. Glad it worked for you. :good:
thank you very much !
Thx !
Thx !
Great guide works perfectly.. has anyone tried to reverse the process and go back to stock to reflash a factory image?
I just tried it on my old Nexus 4, and after resettting the partitions, and reflashing the factory image, its just a permanent bootloop. I've cleared all the cache, tried a wipe from the stock recovery, tried flashing TWRP and wiping there.. nothing seems to work. Im not too worried, but it'd be nice if it could boot again.
Thanks for your guide. It worked like a charm for my Nexus 4.
Just a small addition: To resize the system partition automatically I placed a script in /system/addon.d:
Code:
#!/sbin/sh
#
# /system/addon.d/10-resize-system.sh
#
. /tmp/backuptool.functions
case "$1" in
backup)
# Stub
;;
restore)
# Stub
;;
pre-backup)
# Stub
;;
post-backup)
# Stub
;;
pre-restore)
/sbin/resize2fs /dev/block/platform/msm_sdcc.1/by-name/system
;;
post-restore)
# Stub
;;
esac
If it doesn't work for you
Thanks for this great guide!
Decided to breath some new life into an old N4 in my family and now it's going (very) strong again with LineageOS 15.1. Still had to clear a bit over 100 MB with .gapps-config from Stock-OpenGapps, but that's no biggie. I always liked to start with the big package and then remove everything that I don't need from it.
Second issue gave me some headaches at first.
"Resize File System" in TWRP apparently worked and Gapps-Install went through (~100 MB free at the end), but boot would fail and crash back to recovery.
(I'm using the daily LOS-nightlies by Milaq and Stock-Package from OpenGapps, maybe it's no problem with other ROMs and/or Gapps-Packages.)
Turns out the fix in TWRP wasn't really working, nevermind what partition size it shows for /system afterwards. It's somehow corrupted and still has the original size -> most of the gapps stuff get's written to nirvana, thus the failing boot.
I found the solution over in the Nexus5-Thread:
JekaPinsk said:
Hello guys!
Try this:
1) Install ROM
2) Backup ROM
3) Enable "Use 'rm -rf' instead of formatting" in TWRP settings
4) Format /system
4.1) Unmount /system and use 'resize2fs -f /dev/block/mmcblk0p21' in terminal (TWRP)
5) Reboot TWRP
5.1) Uncheck "Use 'rm -rf' instead of formatting" in TWRP settings
6) Restore backup
7) Install Stock OpenGapps
8) Done!
The idea behind it is that ROM installation somehow corrupt /system partition thus any write operations above normal data region silently fail.
Click to expand...
Click to collapse
at step 4.1 I already changed the partition number to 21 for Nexus4. In the original post it says mmcblk0p25, because on the Nexus 5 that's /system.
Now it works.
In theory this procedure should also work for updating the ROM without losing data, but haven't tested it yet. (Maybe throw in a wipe of /system as step 0...?)
To be clear: This isn't the fault of the guide to resize system-partition.
Problem is (at least certain) ROMs resetting size of file system to original and then TWRP failing to fix that doing it the easy way as described in OP (-> bug in TWRP?).
EDIT:
Above procedure also works for an update without data loss. Only difference was I did a normal wipe of /system first, "step 0" so to say.
No idea if all this is still necessary with TWRP 3.2.3-0, I'm not willing to risk a full wipe at this point. ^^
i need this...can't even install the smallest gapps package after oreo.... word!! thanks!
Really wanted to thank-you for this!
Two questions:
1. When you printed the partitions, system (21) was ext2. When you recreated it after resizing, you created it as ext4. Was that intentional?
2. You also made the claim that modern ROMs don't need such a big cache partition (your new one was 37MB, I wasn't so brave). Can you justify that claim or provide some technical details? It's not that I don't believe you (I trusted you enough to do this on my device!), just merely curious as to why/how this would be.
Thanks!
X:\xxx\xxx\xxx\xxx\adb>adb push parted /
487 KB/s (346680 bytes in 0.695s)
X:\xxx\xxx\xxx\xxx\adb>adb shell
~ # [6nchmod +x parted
chmod +x parted
~ # [6n./parted /dev/block/mmcblk0 p
./parted /dev/block/mmcblk0 p
Error: Can't have overlapping partitions.
~ # [6n
Please Help!!!!!!!!!!!!!!!!!!!
caliban2 said:
Thanks for this great guide!
Decided to breath some new life into an old N4 in my family and now it's going (very) strong again with LineageOS 15.1. Still had to clear a bit over 100 MB with .gapps-config from Stock-OpenGapps, but that's no biggie. I always liked to start with the big package and then remove everything that I don't need from it.
Second issue gave me some headaches at first.
"Resize File System" in TWRP apparently worked and Gapps-Install went through (~100 MB free at the end), but boot would fail and crash back to recovery.
(I'm using the daily LOS-nightlies by Milaq and Stock-Package from OpenGapps, maybe it's no problem with other ROMs and/or Gapps-Packages.)
Turns out the fix in TWRP wasn't really working, nevermind what partition size it shows for /system afterwards. It's somehow corrupted and still has the original size -> most of the gapps stuff get's written to nirvana, thus the failing boot.
I found the solution over in the Nexus5-Thread:
at step 4.1 I already changed the partition number to 21 for Nexus4. In the original post it says mmcblk0p25, because on the Nexus 5 that's /system.
Now it works.
In theory this procedure should also work for updating the ROM without losing data, but haven't tested it yet. (Maybe throw in a wipe of /system as step 0...?)
To be clear: This isn't the fault of the guide to resize system-partition.
Problem is (at least certain) ROMs resetting size of file system to original and then TWRP failing to fix that doing it the easy way as described in OP (-> bug in TWRP?).
EDIT:
Above procedure also works for an update without data loss. Only difference was I did a normal wipe of /system first, "step 0" so to say.
No idea if all this is still necessary with TWRP 3.2.3-0, I'm not willing to risk a full wipe at this point. ^^
Click to expand...
Click to collapse
I'm using TWRP 3.2.3-0 and it has this bug, too. After I followed your steps I was able to install Nitrogen OS and Open Gapps Micro in my phone without erros.
Thanks!
I believe that resize2fs step can be packaged as a flashable zip so we can batch flashing without manual intervention to it (i.e. manually resize fs on system after each rom flash) .
ivanich said:
I believe that resize2fs step can be packaged as a flashable zip so we can batch flashing without manual intervention to it (i.e. manually resize fs on system after each rom flash) .
Click to expand...
Click to collapse
Maybe then more users would dare to use this solution and could calmly install gapps on Pie.
You have a lot of experience. What do you suggest?
Hi all. I only discovered this thread after independently figuring out the partitioning scheme (plain GPT) and process.
Sadly, even after this effort, it seems L-OS upgrades won't work unless L-OS devs modify their upgrade script to make use of resize2fs. Here's what happens as of package 2018-09-11:
L-OS runs backup procedure for all addons found in the existing /system/addon.d/
The above creates files (I guess) in /tmp
The /system is unmounted
The partition is overwritten with the image in the upgrade package
The script in addon.d/ are then run to restore the addons from /tmp
The problem is, the partition image in the upgrade package is for the old partition size, and therefore step 5 fails when the free space runs out. It seems the install or restore scripts don't detect this failure, and just exit without reporting an error, with 0B free space on /system.
I'm guessing the problem can be "solved" by formatting the system partition and installing LOS and all addons from scratch, but that's ridiculous. has anyone tried to raise this issue with devs? I'm about to report this in L-OS's JIRA, as I haven't seen any relevant report there.
EDIT: If anyone wants to track: https://jira.lineageos.org/browse/BUGBASH-2306
myxal said:
Hi all. I only discovered this thread after independently figuring out the partitioning scheme (plain GPT) and process.
Sadly, even after this effort, it seems L-OS upgrades won't work unless L-OS devs modify their upgrade script to make use of resize2fs. Here's what happens as of package 2018-09-11:
L-OS runs backup procedure for all addons found in the existing /system/addon.d/
The above creates files (I guess) in /tmp
The /system is unmounted
The partition is overwritten with the image in the upgrade package
The script in addon.d/ are then run to restore the addons from /tmp
The problem is, the partition image in the upgrade package is for the old partition size, and therefore step 5 fails when the free space runs out. It seems the install or restore scripts don't detect this failure, and just exit without reporting an error, with 0B free space on /system.
I'm guessing the problem can be "solved" by formatting the system partition and installing LOS and all addons from scratch, but that's ridiculous. has anyone tried to raise this issue with devs? I'm about to report this in L-OS's JIRA, as I haven't seen any relevant report there.
EDIT: If anyone wants to track: https://jira.lineageos.org/browse/BUGBASH-2306
Click to expand...
Click to collapse
You may be able to fix that on your own by adding an add-on.d named 00-resize-system (so that's it's ran first) that just does "resize2fs /dev/block/.../system", with maybe an unmount before and a mount after. This way, LOS can just flash the full image when upgrading and the system is resized before the other addons.d scripts run.
Fif_ said:
You may be able to fix that on your own by adding an add-on.d named 00-resize-system (so that's it's ran first) that just does "resize2fs /dev/block/.../system", with maybe an unmount before and a mount after. This way, LOS can just flash the full image when upgrading and the system is resized before the other addons.d scripts run.
Click to expand...
Click to collapse
Thanks for the tip, will give that a try. Any idea where I could find an "authoritative" docs/guide to those scripts? Just looked at the one supplied by open g-apps, and I don't really see the difference between the various commands that the script is supposed to handle (which is executed when?). Also what list_file() is supposed to provide.
backup
restore
pre-backup
pre-restore
post-backup
post-restore
myxal said:
Thanks for the tip, will give that a try. Any idea where I could find an "authoritative" docs/guide to those scripts? Just looked at the one supplied by open g-apps, and I don't really see the difference between the various commands that the script is supposed to handle (which is executed when?). Also what list_file() is supposed to provide.
backup
restore
pre-backup
pre-restore
post-backup
post-restore
Click to expand...
Click to collapse
You want to put the resize2fs call in the pre-restore section.
It should look like this:
Code:
pre-restore)
unmount /system
resize2fs /dev/block/platform/.../system
mount /system
;;
This includes unmounting and remounting /system which I think are needed, but YMMV. You'll need to fill in the full path to system under /dev.
There is no authoritative resource for backup scripts that I know of, but the gapps script is a good example.
P.S.: If you make it work, please post the script for others...