Related
SHORT: I need the filesystem block size (location would be nice too; however, I can guess that) so I can use e2fsck to restore my super-block.
LONG: I have been having issues for the past several days where I cannot umount /system. I thought it may have been a bad conversion going to/from or from/to rfs and ext4 and thought doing the conversion again had fixed it. But alas...it didn't.
I cannot umount the files system from adb ("device is busy" error) or CWMR ("Couldn't find valid filesystem superblock" in the log) on any version of ROM or using any kernel that I can find. Voodoo can seem to convert the filesystem (back/forth), but it only seem to work if I tell it to from the Voodoo Control and then reboot, which is odd. Still cannot umount.
When I try and use Navenedrob's Ext4 Formatter, it fails for /system. CWMR's log shows:
/tmp/tune2fs: Bad magic number in super-block while trying to open /dev/block/stl10
Couldn't find valid filesystem superblock
Should be fixable with e2fsck, if I can get the correct information from tune2fs.
Typically, the command should be:tune2fs -l /dev/block/stl10 OR tune2fs -l -L /system
That said, tune2fs is tell me "-l" is an unknown option.
Can someone who is familiar with tune2fs (or other filesystem tools) in the Android/BusyBox environment please post either the correct command or a list of the contents of the filesystem super-block? Please be sure to include if your /system is in EXT4 or RFS.
Man, I haven't see this **** in years. Even then, it was pretty exclusive to virtual/networked file system (e.g. LVM).
Any-who, much appreciated....
So, after sleeping on it, I came to realize an error in my thinking...
I cannot use e2fsck to fix an RFS filesystem. Even more upsetting is that I cannot seem to find anything on The Google about command line RFS tools. Guess I could try a conversion and EXT filesystem, then change the superblock, then convert back to RFS, but that seems awfully convoluted.
Suggestions?
I suggest you odin with pit and check repartition. That *usually* fixes everything.
Sent from my debloated ep1q charge......bro.
Thanks for the tip...I probably should have mention that I've used Pit+ED1 numerous times in a effort to fix this. It goes through successfully; however, it doesn't actually wipe the partition and I've found old files in /system.
UPDATE:
Last thing I tried is manually wiping everything from /system (in CWMR + adb shell). Also, wiped everything I could find having anything to do with voodoo or EXT4 (just in case). After power off then back to recovery, I found I could umount /system. Created a new partition, formatted, then wacked the partition.
I just (successfully) ran ED1+pit from the Samsung Flashing Utility (which I have NOT tried using before) and I am now in the process of upgrading. Once I have root back, I'll go see if the fix for /system was permanent.
I have a few questions related to smartphones. Searched and couldn't find anything like I was looking for.
I am vary familiar with PC's and would like to compare in my mind where things reside on a smartphone.
On a smartphone, where does the operating system reside? Is it in the ROM(I know is Read-only-memory)? Or is the ROM similar to the BIOS on a PC and contains the basic instructions to interact with the between software and hardware?
Just having a little problem comparing what is where.
i think its in ROM memory, but there is additonal memory for system/internal apps too.
In my XPlay I have 512mb+400mb.
There isn't anyth like bios but u can flash recovery
From what I know, everything is stored in NAND flash. There is a boot partition which contains the kernel, and a system partition which contains the OS (firmware) itself. Those essentially double as ROM. Technically it's not read-only memory but its contents won't change unless you root your phone and change them yourself.
Also, I don't think an embedded system such as a smartphone would benefit much from having a full-blown BIOS. Hardware initialization, I believe, is done during the boot sequence, not prior to it. Look up "Board support package".
If someone knows more about this subject, feel free to correct me and provide additional information.
I'm quite interested in embedded systems myself, but only have had the opportunity to work with simple microcontrollers.
So basically everything inside is more like a solid state hard drive? Just partitioned for different tasks? I figured the rom was not really a rom. Usually you have to build an interface and cut traces on the board in order to flash a rom.
Are we able to browse the rom? Like with root explorer? Or is that partition "hidden"?
Also, what are the caches for. I am familiar with caches like in ie. But the davlik seems to be persistent. Thanks for the answers so far guys.
Usually when you load a new os, the cache is usually wiped. But with phones, a step is to wipe the caches. Confusing when trying to grasp with the knowledge I have of older electronics. Lol I just called pc's old.
I wish there was some guide already making the comparison but Google can't find it!
Yes, you can browse those partitions in Root Explorer. It will allow you to mount even the /system partition r/w so you can modify the contents.
As for the caches, I'm not sure what exactly gets stored on the /cache partition, but the reason you have to wipe/format it when you flash a new ROM, is because it's separate from the /system partition. That's probably what you meant by "persistent".
It's actually convenient when you think about it. If you want to flash an update of the ROM you are currently using, you probably don't want the cache to be wiped as well. On the other hand, sometimes you may want to wipe just the cache. Same goes for the /data partition, when you are doing a factory reset, for example.
I would also assume that since /system partition normally isn't written to, and /cache and /data are, keeping them separate helps in case the filesystem gets corrupted.
Now you are confusing me.
/system is a folder. Not a partition. It may be in a folder but it is not a partition afaik. There is a root partition which is basically everything you see when you open file explorer that includes the system folder, then any other partitions are mounted under /mnt. Those include /asec /obb /sdcard and /secure. (using what I see in my kf for this example)
So when we flash the "rom" we are really only flashing one partition of a rom that has several partitions. That would be the basic partition containing the system files? We are not flashing the entire rom. Does that sound correct?
In Linux partitions are mounted under directories. So /cache, /data and /system are really just mount points for those partitions. It's understandable that this would confuse you if you haven't had experience with Linux. Windows handles partitions somewhat differently.
When you flash a ROM, you are actually flashing only the system partition. Kernel is flashed to the boot partition, and others (cache, data, sdcard, etc.) are used by the system itself.
DeVelox said:
In Linux partitions are mounted under directories. So /cache, /data and /system are really just mount points for those partitions. It's understandable that this would confuse you if you haven't had experience with Linux. Windows handles partitions somewhat differently.
When you flash a ROM, you are actually flashing only the system partition. Kernel is flashed to the boot partition, and others (cache, data, sdcard, etc.) are used by the system itself.
Click to expand...
Click to collapse
Yes i have a little knowledge, albeit very little, of Linux. But if it is an actual partition it will also show under /mnt after you mount it, correct? That is how you tell if it is an actual partition. I do realize that the others partitions like /sdcard are being automatically mounted. And you can browse them through the /sdcard folder or /mnt/scard.
/cache is no where under /mnt or any subs of any partitions that are mounted so that tells me the /cache folder that shows under root is actually only a folder. Well there is a cache subdirectory underone of the partitions under /mnt but the contents are different than the contents of the cache folder running off of root.
Sorry bout all of the questions. I have done a lot to my phone and kf. I just like to know what it's being affected when when I do what I am doing. And why I am doing what I am doing.
Like i said before, the term rom confused me as when i was flashing roms on other devices I was having to build a hardware interface and cut traces on the board, sometimes install jumpers across traces. All of that to flash "roms". This was on xboxes and satellite receivers mainly.
No, /mnt is just a directory like any other. In fact, it is rarely used for mounting purposes in modern Linux distributions.
When you open /cache, /data or /system in Root Explorer, please check the "x MB used, y MB free" line at the top. You will notice that it shows different values for each of those directories. That should be enough to convince you that they are indeed partitions, and not ordinary directories.
You will also notice that, for example, /etc shows the same used/free info as /system. That is because /etc is actually a symlink to /system/etc.
You should read up more on Linux, or just take my word for it.
P.S. If you have Terminal Emulator app installed, try the "df -h" command. It will list all the partitions, their mount points, and used/free space info. Mind you, only entries starting with "/dev/block" are actual partitions, tmpfs is something else.
I see said the blind man. I also found this as an example of the partitions on my kf.
Scrolling down I see all of the active partitions.
http://kindlefirenews.org/expand-app-storage-on-the-kindle-fire/
Thanks for the explanations. But I will say that ROM it's a misnomer!
Open a console on your android and type "df".
You will see the partitions.
Here's the scenario: say you try out encryption on a ROM, either because your employer makes you or because you want the extra security. What happens when you can root your phone, like we can (easily) with the S3, and you want to flash a different ROM? The problem you will find yourself in very quickly is that you cannot do a successful wipe. You can't format an encrypted /data in CWM or any other recovery. If you cannot format /data, you can't flash a ROM - it fails, because /data is encrypted, and it cannot proceed. It turns out none of the recoveries can format an encrypted /data. You also cannot reverse encryption once you've done it. You're stuck, all because you flipped the switch on encryption.
I found myself in this problem as others have in many other forums (like this one for the GNex) (and another one, more detailed).
I also tried, admittedly somewhat out of desperation, the soft-brick instructions here. That didn't work because Nand Erase All fails. You can flash on top, and luckily you can use your same password to decrypt your /data (which I did) but you're still not going to have a clean ROM. Dirty flashes = lots of problems down the road.
I finally found a simple way to do this and wanted to save anyone else the trouble of digging. You can do it using CWM and adb and a few commands. Credit goes Shawn Webb's blog and utkanos on FreeNode's irc at #cyanogenmod.
Here is how to do this on our Verizon S3:
In CWM, wipe cache
adb shell
mke2fs -t ext4 /dev/block/mmcblk0p15
mount /data
mount /dev/block/mmcblk1p1 /data/media
If adb doesn't work in CWM, reboot recovery. You might need to create /data/media after mounting /data in order to do the last step, which I opted not to do. I hope this saves someone else a few hours of frustration, and I also hope that someday one of our recoveries can handle formatting encrypted data. Until then... I'm just not using encryption, period. There already is a lot of documentation against it, and this is one more reason in my book.
Thanks for this. I fell into the same scenario yesterday but after reading a lot of helpful posts from people like yourself I have managed to solve the issue. Basically I found two ways of doing it, one is as you have suggested and the other is by just replacing the custom recovery with the stock recovery. The SGS3 toolkit available on XDA made the 2nd option just slightly simpler for me and by spending less than 10 mins (excluding time for backups and downloads) the issue was resolved.
Just to share this option to save others from the headache of looking for a solution:
1) Get the toolkit
2) Install drivers as recommended and follow instructions to choose the build, or closest build, for your S3
3) Restore stock recovery with toolkit via ODIN (follow instructions)
4) After rebooting, go into Android and reset to factory settings, this would bring you to the stock recovery and wipe
5) Restore custom recovery with toolkit via ODIN (follow instructions)
6) Restore your system (luckily for me I had a nandroid backup before I encrypted)
Note: I did "lose" my internal sdcard files (pictures/documents). But I backed that up on my external sdcard before starting the process. My sdcard was not encrypted.
kitleon said:
Thanks for this. I fell into the same scenario yesterday but after reading a lot of helpful posts from people like yourself I have managed to solve the issue. Basically I found two ways of doing it, one is as you have suggested and the other is by just replacing the custom recovery with the stock recovery. The SGS3 toolkit available on XDA made the 2nd option just slightly simpler for me and by spending less than 10 mins (excluding time for backups and downloads) the issue was resolved.
Just to share this option to save others from the headache of looking for a solution:
1) Get the toolkit
2) Install drivers as recommended and follow instructions to choose the build, or closest build, for your S3
3) Restore stock recovery with toolkit via ODIN (follow instructions)
4) After rebooting, go into Android and reset to factory settings, this would bring you to the stock recovery and wipe
5) Restore custom recovery with toolkit via ODIN (follow instructions)
6) Restore your system (luckily for me I had a nandroid backup before I encrypted)
Note: I did "lose" my internal sdcard files (pictures/documents). But I backed that up on my external sdcard before starting the process. My sdcard was not encrypted.
Click to expand...
Click to collapse
You just saved my month. Drop me a message if I can get you a beer via paypal for this.
Cheers!
THANKS!
olm3ca said:
Here's the scenario: say you try out encryption on a ROM, either because your employer makes you or because you want the extra security. What happens when you can root your phone, like we can (easily) with the S3, and you want to flash a different ROM? The problem you will find yourself in very quickly is that you cannot do a successful wipe. You can't format an encrypted /data in CWM or any other recovery. If you cannot format /data, you can't flash a ROM - it fails, because /data is encrypted, and it cannot proceed. It turns out none of the recoveries can format an encrypted /data. You also cannot reverse encryption once you've done it. You're stuck, all because you flipped the switch on encryption.
I found myself in this problem as others have in many other forums (like this one for the GNex) (and another one, more detailed).
I also tried, admittedly somewhat out of desperation, the soft-brick instructions here. That didn't work because Nand Erase All fails. You can flash on top, and luckily you can use your same password to decrypt your /data (which I did) but you're still not going to have a clean ROM. Dirty flashes = lots of problems down the road.
I finally found a simple way to do this and wanted to save anyone else the trouble of digging. You can do it using CWM and adb and a few commands. Credit goes Shawn Webb's blog and utkanos on FreeNode's irc at #cyanogenmod.
Here is how to do this on our Verizon S3:
In CWM, wipe cache
adb shell
mke2fs -t ext4 /dev/block/mmcblk0p15
mount /data
mount /dev/block/mmcblk1p1 /data/media
If adb doesn't work in CWM, reboot recovery. You might need to create /data/media after mounting /data in order to do the last step, which I opted not to do. I hope this saves someone else a few hours of frustration, and I also hope that someday one of our recoveries can handle formatting encrypted data. Until then... I'm just not using encryption, period. There already is a lot of documentation against it, and this is one more reason in my book.
Click to expand...
Click to collapse
Just wanted to say thanks very much for this. I'd tried the method of reloading the stock ROM as described by a previous poster, but this way worked.
I did run into a small issue I was wondering if you could shed some light on. When I entered "mount /data", I got the following:
Code:
~ # mount /data
mount: mounting /dev/block/mmcblk0p37 on /data failed: Invalid argument
I bullied ahead and entered the last line "mount /dev/block/mmcblk1p1 /data/media" and got this:
Code:
~ # mount /dev/block/mmcblk1p1 /data/media
mount: mounting /dev/block/mmcblk1p1 on /data/media failed: No such file or directory
However after doing this, I was able to perform a complete wipe of /data using CWM and load a new ROM without issue.
I'd curious to know what might be causing these Invald argument responses.
My Device: HTC One (GSM)
Thanks again! :laugh:
olm3ca said:
Here is how to do this on our Verizon S3:
In CWM, wipe cache
adb shell
mke2fs -t ext4 /dev/block/mmcblk0p15
mount /data
mount /dev/block/mmcblk1p1 /data/media
If adb doesn't work in CWM, reboot recovery. You might need to create /data/media after mounting /data in order to do the last step, which I opted not to do. I hope this saves someone else a few hours of frustration, and I also hope that someday one of our recoveries can handle formatting encrypted data. Until then... I'm just not using encryption, period. There already is a lot of documentation against it, and this is one more reason in my book.
Click to expand...
Click to collapse
I'm trying to follow your instructions but fail at finding out my mount points.
Sorry for the noob question, but who do I find out what the mount points of internal and external SD card are on my device (Samsung Galaxy S4 Mini International 4G)? I found this post
stackoverflow. /questions/6824463/how-to-get-all-the-mount-point-information-for-android-device
which seems to include the answer but I don't know what tool / software they use. I'm no programmer.
My phone is encrypted and doesn't turn on, it doesn't accept my password saying it's wrong, though I know it's correct. OS is Cyanogenmod 10.1 stable. Booting into CWM v6.0.3.7 is possible though.
I appreciate everyone's help.
Stephan
:good:Hello,
Just wondering if anyone knows the commands or steps needed to mount the /system on a phone with stock Jelly Bean 4.3?
I wanted to install Busy box, which fails because /system is read-only, I've tried some apps which haven't work. While Root explorer appears to mount /system a rw, it clearly not because when yoy attempt to do anything within system it fails saying its still r/o
Not sure if this can be done via a recovery method (Its stock recovery btw) but I really looking to get this done one way or another.
Any help would be great.
Thank you :good:
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.