I'm posting this because I am seeing lots of confusion in this area.
Most of the guides found on this forum as well as answers given in the q/a section pertaining to this give the following advice for formatting/wiping a ext parition:
Code:
rm -rf /system/sd/*
Although this may fix a lot of problems it does not really reformat the partion.
"rm -rf" just means "remove(delete) --recursively(subfolders as well) --force(don't ask if ok)". This only deletes the files by removing the inode entries from the filesystem table.
To truly reformat and ensure there are no remnants on the partition you need to make a new filesystem on that partition. This will build a new inode table completely instead of just removing entries in the table.
Enter recovery console (filesystem should NOT be mounted when formatted)
Code:
mke2fs /dev/block/mmcblk0p2 #for ext2 partitions
mke2fs -j /dev/block/mmcblk0p2 #for ext3 partitions
"mke2f2" means "make extended2 filesystem"
"-j" means "add a journal"(ext2+journal=ext3)
Hope this helps
Printing this out right now this is a keeper
Thankyou
Thanks buddy...printing now...
Ok, even though I am just begining at Linux I do understand the difference here between the 2 methods (its like the quick format option under windows). My question is, does it matter? Can you explain why the quick method may be detramental or unsafe.
Thanks for the advice dumfuq, but what if you have a ext4 partition?
Total Noob:
I've just been removing the partition and creating a new one.. is that just as effective (obviously the longer route)?
Also, how would you go about reformatting a linux-swap partition? Again, I've just been removing and recreating every time I flash.. I realize this isn't the fastest way.
Thanks a lot. This is very helpful.
Baldyman1966 said:
Ok, even though I am just begining at Linux I do understand the difference here between the 2 methods (its like the quick format option under windows). My question is, does it matter? Can you explain why the quick method may be detramental or unsafe.
Click to expand...
Click to collapse
I don't think just deleting the files is detrimental or unsafe...its just not formatting. For the most part it doesn't matter but if you want a fresh filesystem make a new one.
Thanks for the advice dumfuq, but what if you have a ext4 partition?
Click to expand...
Click to collapse
It should be
Code:
mke2fs -T ext4 /dev/block/mmcblk0p2
But I haven't tried it
I've just been removing the partition and creating a new one.. is that just as effective (obviously the longer route)? Also, how would you go about reformatting a linux-swap partition? Again, I've just been removing and recreating every time I flash.. I realize this isn't the fastest way
Click to expand...
Click to collapse
Yup...just as effective.
For swap
Code:
mkswap /dev/block/mmcblk0p3
But I don't think it is usually necessary to remake the swap after the initial creation (could be wrong on that though and I guess it can't really hurt)
This thread should be listed in the "Informative Links" sticky
simliarly, how would you go about removing the entire ext3 partition, so reclaim that 500mb back into the fat32? i have a htc magic and no longer need apps2sd, so having a ext partition isnt neccesary in my case. i rather use that extra 500mb for media and storage.
is there a special command to do this? i dont want to reformat the entire card since i have a lot of stuff on my fat32. i was hoping there was an easy way. thanks for any advice!
NguyenHuu said:
simliarly, how would you go about removing the entire ext3 partition, so reclaim that 500mb back into the fat32? i have a htc magic and no longer need apps2sd, so having a ext partition isnt neccesary in my case. i rather use that extra 500mb for media and storage.
is there a special command to do this? i dont want to reformat the entire card since i have a lot of stuff on my fat32. i was hoping there was an easy way. thanks for any advice!
Click to expand...
Click to collapse
Not really.
To do this you have to modify the partition table. Personally I would just back up the data, use fdisk (available in recovery console) to delete old and create new partitions, use windows to format the new fat32 partition created with fdisk, and then restore the data.
However since you don't want to reformat, you could try using gparted(or even parted for that matter) to remove the ext3 partition and resize the fat32. Still probably want to backup first though. There are a few tutorials already that walk you through adding an ext3 partition without losing your fat32. It shouldn't be to hard to follow one of them and tweak the commands to remove ext3 and expand the fat32.
thanks for all the advice, i have removed the ext partitions and resize my fat32 successful without data lost. i backed up just in case too. thanks.
I was able to convert /data to F2FS and flash EX kernel. That boots and runs fine, but I converted cache to F2FS and it won't boot. I'd also love to convert /system as well, but as far as I understand that takes a custom ROM. Anyone else have any experience with F2FS on 5.0?
Bumps
Not on 5, no. But cache and system are of little or no benefit anyway. IMHO only /data needs to be f2fs. It improves read/writes on flash memory but you're not really doing that on /system (and some extent, /cache) as you are with /data.
Hu? You read/write from cache, system, and data all the time! Lots of google apps are system apps, obviously /data is everything else and cache gets used by both!
bobloadmire said:
Hu? You read/write from cache, system, and data all the time! Lots of google apps are system apps, obviously /data is everything else and cache gets used by both!
Click to expand...
Click to collapse
System? Absolutely not. You Never write and it is rare that you read too.
Cache is hardly used. If you look in there.
Ah yes you wre right about system, though you still do a lot of read from it. I'm under the impression that cache actually can get hammered as hard as /data because every app launch pulls cache.
bobloadmire said:
Ah yes you wre right about system, though you still do a lot of read from it. I'm under the impression that cache actually can get hammered as hard as /data because every app launch pulls cache.
Click to expand...
Click to collapse
App cache is on /data. /cache is primarily used for play downloads
Really? Well I'm learning a lot today. Why is a play store cache it on a separate partition?
bobloadmire said:
Really? Well I'm learning a lot today. Why is a play store cache it on a separate partition?
Click to expand...
Click to collapse
It just downloads the apk there until it is installed. Just to keep it tidy
gotcha. So if we convert /system to F2FS that will help things like boot, system apps etc, I'm assuming. Resume from sleep?
bobloadmire said:
gotcha. So if we convert /system to F2FS that will help things like boot, system apps etc, I'm assuming. Resume from sleep?
Click to expand...
Click to collapse
Boot maybe. Systems apps, debatable. Negligible if any. Data is where the payload is.
Hi all! I'm running CM13 Snapshot, with ElementalX. As now I formatted /data and /cache in F2FS. Would it be worth to also format /system in F2FS, since is mostly read-only?
Well you simply can't, every ROM installation will re-format /system to ext4 automatically. And even if you could, you probably can't notice any improvements on the Nexus 5. The Nexus 5 still has pretty powerful hardware which can handle almost everything without any problems so I wonder why you would want to have /system formatted to F2FS. In my experience things never really got that much better with the /cache and /data formatted to F2FS, only benchmarks scores got a bit higher. In my opinion F2FS is pretty useless on this device. Could be helpful for lower end ones.
Thanks for the answer! I must say i jumped on the f2fs train without doing any benchmarks, and also going from KK to LP long time ago, so I couldn't do a proprer comparison. Also I didn't think about the rom installation process reformatting...well than my question is pretty useless
Short answer, no. From what I've read, F2FS has slightly better write speeds than ext4 and slightly worse read speed. On a partition that you write often to, such as data and cache, it could be beneficial because of the better write speed. But on the system partition, it would even cause performance drop since it's read-only.
No.
The system partition is mounted mostly with ro permissions anyway.
Write operations are few and rare.
Finally, f2fs seems to have more overhead (allocates more space) which might be an issue for devices with small-ish system partitions.
you can now use REPIT to increase the size of the /system partition on the Nook HD/HD+ to 1 GiB to support the newest roms with gapps. while you do this, you can optionally also add 0.5 GiB of free space to /data. the extra space is repurposed from partitions that go unused in custom roms.
see the details here:
https://github.com/Lanchon/REPIT/issues/59
full doc for REPIT is here, please read it:
https://github.com/Lanchon/REPIT
additionally, this note can be interesting for users and rom developers alike:
https://github.com/Lanchon/REPIT/issues/56
this is for Nook HD+ only, but HD owners can request a port of REPIT by following the instruction in the doc page.
UPDATE: a port request was submitted by BultoPaco and now REPIT supports the Nook HD too.
thanks!
Lanchon said:
you can now use REPIT to increase the size of the /system partition on the Nook HD+ to 1 GiB to support the newest roms with gapps. while you do this, you can optionally also add 0.5 GiB of free space to /data. the extra space is repurposed from partitions that go unused in custom roms.
see the details here:
https://github.com/Lanchon/REPIT/issues/59
full doc for REPIT is here, please read it:
https://github.com/Lanchon/REPIT
additionally, this note can be interesting for users and rom developers alike:
https://github.com/Lanchon/REPIT/issues/56
this is for Nook HD+ only, but HD owners can request a port of REPIT by following the instruction in the doc page.
thanks!
Click to expand...
Click to collapse
This is great. Would also be helpful if you included information on how to go to stock partition layout, but big thanks indeed.
ajislav said:
This is great. Would also be helpful if you included information on how to go to stock partition layout, but big thanks indeed.
Click to expand...
Click to collapse
added to the github note.
Following the guide \https://github.com/Lanchon/REPIT/issues/59 to increase /data,
"you can also add approximately 0.5 GiB to /data"
Does it make difference if the Ovation is 16gb or 32gb model
king200 said:
Following the guide \https://github.com/Lanchon/REPIT/issues/59 to increase /data,
"you can also add approximately 0.5 GiB to /data"
Does it make difference if the Ovation is 16gb or 32gb model
Click to expand...
Click to collapse
this was made and tested with the 16GB version. in all other devices REPIT has been smart enough to adapt to these differences automatically. it should work with the 32GB version. but if there's anything strange or too different, REPIT will bail instead of messing up your device.
Ext4 only?
Mine returns an error not able to read superblock on data even if I am only trying to expand system. my data and cache are f2fs. Is that the problem? I'll cut/paste the log here when I'm back on my ovation.
This with the 3.0.2 twrp currently in experimental folder
Update: OK, went back and reread the general instructions. Looks like doesn't work for f2fs. I did convert cache to ext4 and set data=same, but still returned error.
Using Android 7 and latest TWRP on Nook HD+. Downloaded repit file zip, renamed as per instructions & downloaded delete stock rom zip. Flashed delete stock rom in twrp w/o problems. Flashed renamed repit file and Got error 1 after flashing. Told to reboot and flash from tmp folder and also got error 1. The error related to unable to reload partition table and unable to mount all partitions. Info from file manager shows using 5.11 GB out of 27.01 GB of internal storage
Any ideas???.
I just did this today.
I tried to flash lanchon-repit-XXXXXXXX-factory=same-system=1G-cache=112M+wipe-data=same-ovation.zip using twrp, but it gave me errors. I tried to follow the instructions to flash the file from the /tmp folder that it has copied, but it still gave me errors about /emmc partition not able to be umounted. I tried this a few times according to instructions posted on github but still no-go.
This is how I got around the issue:
I went into TWRP's Advanced menu and open up Terminal. Then I did
umount -a
There will be some errors that some partition cannot be umounted (eg. /tmp). I ignored that.
Now, I flashed the REPIT script again from /tmp folder. This will now run the script, but at the end, it will fail with the error about not being able to write /etc/fstab file. I ignored that (Android's file is /fstab.ovation).
Then I went ahead and flashed a cm13 build as usual. After rebooting into cm13, I opened up terminal and then did a df. I could see that /system partition had then expanded to 1034136 1-K blocks, which was roughly 1GB. Hoping that the partition will stay, I then flashed a gapps package, and it went through. On rebooting, I found that about 73% of the /system partition was used (it was around 55% without gapps). So, everything seems to look good.
Hope that helps.
tsoheq said:
I just did this today.
I tried to flash lanchon-repit-XXXXXXXX-factory=same-system=1G-cache=112M+wipe-data=same-ovation.zip using twrp, but it gave me errors. I tried to follow the instructions to flash the file from the /tmp folder that it has copied, but it still gave me errors about /emmc partition not able to be umounted. I tried this a few times according to instructions posted on github but still no-go.
This is how I got around the issue:
I went into TWRP's Advanced menu and open up Terminal. Then I did
umount -a
There will be some errors that some partition cannot be umounted (eg. /tmp). I ignored that.
Now, I flashed the REPIT script again from /tmp folder. This will now run the script, but at the end, it will fail with the error about not being able to write /etc/fstab file. I ignored that (Android's file is /fstab.ovation).
Then I went ahead and flashed a cm13 build as usual. After rebooting into cm13, I opened up terminal and then did a df. I could see that /system partition had then expanded to 1034136 1-K blocks, which was roughly 1GB. Hoping that the partition will stay, I then flashed a gapps package, and it went through. On rebooting, I found that about 73% of the /system partition was used (it was around 55% without gapps). So, everything seems to look good.
Hope that helps.
Click to expand...
Click to collapse
I tried following this unsuccessfully - any chance of an idiot's walkthrough?
I got as far as running the report file from tmp with no errors but when trying to flash Pico gapps I'm told it runs out of space. so close and yet I'm too thick to know what I'm doing wrong
gascomm said:
I tried following this unsuccessfully - any chance of an idiot's walkthrough?
I got as far as running the report file from tmp with no errors but when trying to flash Pico gapps I'm told it runs out of space. so close and yet I'm too thick to know what I'm doing wrong
Click to expand...
Click to collapse
What was the partition size when you do a "df" in a terminal? If it did expand, then the df command should show you the expanded /system partition size.
prsa01 said:
Mine returns an error not able to read superblock on data even if I am only trying to expand system. my data and cache are f2fs. Is that the problem? I'll cut/paste the log here when I'm back on my ovation.
This with the 3.0.2 twrp currently in experimental folder
Update: OK, went back and reread the general instructions. Looks like doesn't work for f2fs. I did convert cache to ext4 and set data=same, but still returned error.
Click to expand...
Click to collapse
f2fs partitions cannot be resized without wiping on planet earth. if there exists an f2fs resize tool, only aliens have it.
you can can wipe data (not recommended) or you can flash the standard repit to simply grow /system with /cache if you want. /data will not be enlarged of course.
f2fs on /cache is stupid, don't ever do it!!! only /data should be f2fs.
acr123 said:
Using Android 7 and latest TWRP on Nook HD+. Downloaded repit file zip, renamed as per instructions & downloaded delete stock rom zip. Flashed delete stock rom in twrp w/o problems. Flashed renamed repit file and Got error 1 after flashing. Told to reboot and flash from tmp folder and also got error 1. The error related to unable to reload partition table and unable to mount all partitions. Info from file manager shows using 5.11 GB out of 27.01 GB of internal storage
Any ideas???.
Click to expand...
Click to collapse
this has been explained to death now, read the REPIT docs for the solution. create a github issue WITH THE REQUIRED INFO (as detailed in the docs) if you need official support.
tsoheq said:
I just did this today.
I tried to flash lanchon-repit-XXXXXXXX-factory=same-system=1G-cache=112M+wipe-data=same-ovation.zip using twrp, but it gave me errors. I tried to follow the instructions to flash the file from the /tmp folder that it has copied, but it still gave me errors about /emmc partition not able to be umounted. I tried this a few times according to instructions posted on github but still no-go.
This is how I got around the issue:
I went into TWRP's Advanced menu and open up Terminal. Then I did
umount -a
There will be some errors that some partition cannot be umounted (eg. /tmp). I ignored that.
Now, I flashed the REPIT script again from /tmp folder. This will now run the script, but at the end, it will fail with the error about not being able to write /etc/fstab file. I ignored that (Android's file is /fstab.ovation).
Then I went ahead and flashed a cm13 build as usual. After rebooting into cm13, I opened up terminal and then did a df. I could see that /system partition had then expanded to 1034136 1-K blocks, which was roughly 1GB. Hoping that the partition will stay, I then flashed a gapps package, and it went through. On rebooting, I found that about 73% of the /system partition was used (it was around 55% without gapps). So, everything seems to look good.
Hope that helps.
Click to expand...
Click to collapse
you didn't need to reflash system of course, REPIT keeps the data as explained in the docs. glad it worked.
btw, it is enough to follow the docs about unmounting partitions using the TWRP UI.
gascomm said:
I tried following this unsuccessfully - any chance of an idiot's walkthrough?
I got as far as running the report file from tmp with no errors but when trying to flash Pico gapps I'm told it runs out of space. so close and yet I'm too thick to know what I'm doing wrong
Click to expand...
Click to collapse
read the docs, everything is there. you can't be helped if you don't provide the REPIT log. (that is also stated in the docs, btw.)
Can confirm this works on 32gb ovation. Just finished after a bit of fighting. As always, YMMV but this was the process I followed:
Ran the delete file. Success.
Ran the resize file, errors.
Ran the resize file from tmp, errors.
Ran "umount -a" from terminal then reran resize from tmp, errors.
I found both my data and cache partitions were f2fs. Formatted both back to ext4 since f2fs cannot be resized. This was easy for me as I had all the important stuff backed up but be sure to back your data up before doing this, it will wipe the partition.
After the wipe I loaded one file on to the data drive, the renamed resize file.
Tried running the resize file. Unmount errors and the run from tmp message.
Went into terminal, ran "umount -a" 3 times. The first I got several errors, the second and third only one.
Went into tmp and ran the file. After realizing the process was working and was going to take a while, I plugged up the charger (wall, not pc) and let it set overnight.
Came back this morning to one error, the fstab error. No unmount errors though.
Remounted the drives in twrp and ran "df" in terminal. 1gb system.
Rebooted and ran through the setup
Reloaded my roms/gapps folder manually via USB
Rebooted to TWRP and ran opengapps pico. Completed succesfully.
Rebooted and had play store in apps. Logged into gapps.
Thank you Lanchon, this helps bring life back to an old love.
asksmity said:
Can confirm this works on 32gb ovation. Just finished after a bit of fighting. As always, YMMV but this was the process I followed:
Ran the delete file. Success.
Ran the resize file, errors.
Ran the resize file from tmp, errors.
Ran "umount -a" from terminal then reran resize from tmp, errors.
I found both my data and cache partitions were f2fs. Formatted both back to ext4 since f2fs cannot be resized. This was easy for me as I had all the important stuff backed up but be sure to back your data up before doing this, it will wipe the partition.
After the wipe I loaded one file on to the data drive, the renamed resize file.
Tried running the resize file. Unmount errors and the run from tmp message.
Went into terminal, ran "umount -a" 3 times. The first I got several errors, the second and third only one.
Went into tmp and ran the file. After realizing the process was working and was going to take a while, I plugged up the charger (wall, not pc) and let it set overnight.
Came back this morning to one error, the fstab error. No unmount errors though.
Remounted the drives in twrp and ran "df" in terminal. 1gb system.
Rebooted and ran through the setup
Reloaded my roms/gapps folder manually via USB
Rebooted to TWRP and ran opengapps pico. Completed succesfully.
Rebooted and had play store in apps. Logged into gapps.
Thank you Lanchon, this helps bring life back to an old love.
Click to expand...
Click to collapse
you are welcome!
lol! why not read the docs???
if you wanted to change the file system in /data to ext4 all you needed was to change:
-cache=32M+wipe-data=max
to:
-cache=32M+wipe-data=max+wipe
which is the same as:
-cache=32M+wipe+ext4-data=max+wipe+ext4
given that ext4 is the default fs for /data and /cache.
using -data=max+wipe would have been so much faster than moving a huge empty partition around!!! it would have finished the operation in around a minute. not to mention adding less wear and tear to the emmc of your aging device.
the file system in /cache was never a problem, you did not need to change it back to ext4. you were using -cache=32M+wipe which means that REPIT would resize/move the partition without keeping its contents (wiping) and without regard for the previous file system type and state (ie, whether it had errors, etc).
if you wanted to enlarge /data AND ALSO KEEP /DATA AS F2FS, all you needed was to change:
-cache=32M+wipe-data=max
to:
-cache=32M+wipe-data=max+wipe+f2fs
f2fs cannot be resized, but it can be moved/resized while wiping. (ie, the partition can be recreated from scratch with the new size, if data retention is not required.) this is all explained in the docs, seriously lol...
https://github.com/Lanchon/REPIT#partition-types
using an f2fs /cache partition is dumb and completely useless. all who have f2fs /cache are adviced to change /cache back to ext4 and leave it that way.
regarding the umount stuff, maybe your TWRP has an issue, but i'm willing to bet that if you followed instructions to the letter, you wouldn't have needed all that. the guy that requested the ovation port of repit (look for the github issue (closed now)) and first ran the test version did not have any of this issues. the TWRP he used is documented in the port request.
anyway, thank you very much for documenting what worked for you!
Lanchon said:
you are welcome!
lol! why not read the docs???
if you wanted to change the file system in /data to ext4 all you needed was to change:
-cache=32M+wipe-data=max
to:
-cache=32M+wipe-data=max+wipe
which is the same as:
-cache=32M+wipe+ext4-data=max+wipe+ext4
given that ext4 is the default fs for /data and /cache.
using -data=max+wipe would have been so much faster than moving a huge empty partition around!!! it would have finished the operation in around a minute. not to mention adding less wear and tear you the emmc of your aging device.
the file system in /cache was never a problem, you did not need to change it back to ext4. you were using -cache=32M+wipe which means that REPIT would resize/move the partition without keeping its contents (wiping) and without regard for the previous file system type and state (ie, whether it had errors, etc).
if you wanted to enlarge /data AND ALSO KEEP /DATA AS F2FS, all you needed was to change:
-cache=32M+wipe-data=max
to:
-cache=32M+wipe-data=max+wipe+f2fs
f2fs cannot be resized, but it can be moved/resized while wiping. (ie, the partition can be recreated from scratch with the new size, if data retention is not required.) this is all explained in the docs, seriously lol...
https://github.com/Lanchon/REPIT#partition-types
using an f2fs /cache partition is dumb and completely useless. all who have f2fs /cache are adviced to change /cache back to ext4 and leave it that way.
regarding the umount stuff, maybe your TWRP has an issue, but i'm willing to bet that if you followed instructions to the letter, you wouldn't have needed all that. the guy that requested the ovation port of repit (look for the github issue (closed now)) and first ran the test version did not have any of this issues. the TWRP he used is documented in the port request.
anyway, thank you very much for documenting what worked for you!
Click to expand...
Click to collapse
Very good info above!
I could have done that as well, and probably should have. But there was conformation in the thread that the options I renamed to worked. So for me being a "part timer" I wanted to make sure that I was not the reason for the issue (ie: fat fingering an extra letter in one of the options or misplacing an option). I have a bad habit of screwing things up.
As a recommendation, it might be a good idea to include some of these sample options in you main thread and explain what they do. I know I know, docs docs docs but it helps us roughians and would probably keep the issue posts down.
Thanks again for the tool and the feedback!
I read all the docs and used Lanchon's tip above to wipe /data and retain f2fs file structure. Got an error running it from my SD card but, when I ran it from the internal tmp folder (as instructed), it worked perfectly. Thank you @Lanchon! I'm going to request a Hummingbird version so I can have both of my Nooks optimized?
Sent from my Nook HD using Tapatalk
Is this supposed to provide more space for Gapps? I ran this and it worked with no errors, but I can't install any different sized gapps than nano.
EDIT: nano is still too big too.
Jazviper said:
Is this supposed to provide more space for Gapps? I ran this and it worked with no errors, but I can't install any different sized gapps than nano.
EDIT: nano is still too big too.
Click to expand...
Click to collapse
read:
https://github.com/Lanchon/REPIT/issues/56
tl;dr: you can fix this by pressing the resize partition button on twrp.