Universal Lagfix corrupt badly /system - Galaxy S I9000 General

supercurio has reported:
SpeedMod based (Doc's ROM and others) and every other Universal Lagfix corrupt badly /system
It means that as long as they don't restore a /system with Odin, they're stuck on kernels using broken mount options.
If you want to verify, try to boot a stock Samsung kernel. Depends on how much it is corrupt it will boot, or not, or with unexpected errors
Want proof?
http://bit.ly/bq2oXg
Highlighted line is using wrong and corruption mount points
lack of check=no which causes corruption. Every Samsung mount uses check=no
Second Issue:
Even with NO RFS Config selected... RFS is still used in /system mounts... means phone are slowly Dying of corruption..

please fix linky - I want to know more about this:
That page doesn't exist!
Click to expand...
Click to collapse
thanks !

zacharias.maladroit said:
please fix linky - I want to know more about this:
thanks !
Click to expand...
Click to collapse
Fixed XD Sorry for that

Not 100% sure on this, since I have not used or looked at sztupy's lagfix very much, but that line you are pointing out is not a problem.
If /system is EXT4, then calling mount -t rfs on it will simply return an error message, and not mount it. It will do exactly nothing.
The following line would then mount it correctly.
Basically, this seems to be totally false. More evidence please.
EDIT: Okay, OP was updated with better information. Lack of check=no means that the FAT32 check *may* be running on the /system, which would cause corruption.
Probably a good idea to confirm if the filesystem check is actually happening though!

In case that supercurio is right (I hope he’s not for obvious reasons), I guess that it wont affect to users that are running harcore kernel without any lagfix applied, right?

RyanZA said:
If /system is EXT4, then calling mount -t rfs on it will simply return an error message, and not mount it. It will do exactly nothing.
The following line would then mount it correctly.
Click to expand...
Click to collapse
That is correct, however /system is not EXT4, but RFS.

good catch.
but im sure sztupy can fix this with a small patch, although i agree the priority should be flagged 'critical'...
as always, good work supercurio

NetCopAD said:
That is correct, however /system is not EXT4, but RFS.
Click to expand...
Click to collapse
Thanks, I thought this was referring to a problem when /system is converted, rather than when it isn't. Which means that if you are running sztupy's kernel with one of the settings that convert /system then it should be fine.
In case that supercurio is right (I hope he’s not for obvious reasons), I guess that it wont affect to users that are running harcore kernel without any lagfix applied, right?
Click to expand...
Click to collapse
It would actually affect you in this case, as the problem occurs when the lagfix is NOT applied, rather than when it is applied!
If it even is a problem, and the fat32 check runs rather than the system trying to do fsck.rfs and failing.

RyanZA said:
Thanks, I thought this was referring to a problem when /system is converted, rather than when it isn't. Which means that if you are running sztupy's kernel with one of the settings that convert /system then it should be fine.
It would actually affect you in this case, as the problem occurs when the lagfix is NOT applied, rather than when it is applied!
If it even is a problem, and the fat32 check runs rather than the system trying to do fsck.rfs and failing.
Click to expand...
Click to collapse
Maybe I am wrong but there is no settings in sztupy's kernel which convert /system
Lagfix only convert /data, /cache and /dbdata

Mopral said:
Maybe I am wrong but there is no settings in sztupy's kernel which convert /system
Lagfix only convert /data, /cache and /dbdata
Click to expand...
Click to collapse
Yeah i just looking further system is still mounted as
/sbin/busybox mount -t rfs /dev/block/stl9 /system - Possible corruption happens here without check=no

RyanZA said:
Thanks, I thought this was referring to a problem when /system is converted, rather than when it isn't. Which means that if you are running sztupy's kernel with one of the settings that convert /system then it should be fine.
It would actually affect you in this case, as the problem occurs when the lagfix is NOT applied, rather than when it is applied!
If it even is a problem, and the fat32 check runs rather than the system trying to do fsck.rfs and failing.
Click to expand...
Click to collapse
Yes this would affect the speedmod kernel as well, if it indeed is a problem. ULFK does not change /system in any lagfix scheme. So, its always mounted as rfs, apparently "wrongly".
I am testing an updated speedmod (shall we say, K9-pre) with the changed mount option. At the very least it should do no harm. And trying to get in touch with curio but over at IRC they say he's probably sleeping now after a coding binge!
Hmm and I found a minor 'bug' in the post-init.sh that was not properly setting /system to read-only after its done.... mainly because the logfile is being written to /system!

Method to test if this is a problem:
Replace your fsck_msdos (this is the only fat32 fsck in the filesystem) with a script file. Inside the script put the following:
Code:
echo "$?" > /somewhere
Then reboot your phone a lot of times. If the check is being called, then you will now get a log message instead of the check happening.
Will also affect checking of /sdcard though.
As far as I know though, fsck_msdos is only ever called by vold, and therefore check=no in /system may not have any effect, and this could be a false alarm. Anyway as hardcore says, can't hurt to fix it!
EDIT: Just wanted to add that running fsck_msdos even once on my /system (using the awesome pre-init scripts from z4mod!) made my phone immediately unbootable (damnit!). Not a big sample size, but I believe that if this was really a problem, we would be seeing many many reports of the sztupy kernel breaking devices! Since we don't have these reports, I'm gonna put this myth down as 'likely to be busted soon!'

RyanZA said:
Method to test if this is a problem:
Replace your fsck_msdos (this is the only fat32 fsck in the filesystem) with a script file. Inside the script put the following:
Code:
echo "$?" > /somewhere
Then reboot your phone a lot of times. If the check is being called, then you will now get a log message instead of the check happening.
Will also affect checking of /sdcard though.
As far as I know though, fsck_msdos is only ever called by vold, and therefore check=no in /system may not have any effect, and this could be a false alarm. Anyway as hardcore says, can't hurt to fix it!
Click to expand...
Click to collapse
Well the intention of this post is to show the issue for it to be fixed So let hope it does not do too much damage :S

deathst said:
Well the intention of this post is to show the issue for it to be fixed So let hope it does not do too much damage :S
Click to expand...
Click to collapse
Looks like this may have been a bit too sensationalist!
More checking, less guessing is always good! (And I could learn a lot from that motto myself!! )

RyanZA said:
Looks like this may have been a bit too sensationalist!
More checking, less guessing is always good! (And I could learn a lot from that motto myself!! )
Click to expand...
Click to collapse
Well we could check it by running it on RFS and reboot alot of time and then flashing a original Kernel

RyanZA said:
Looks like this may have been a bit too sensationalist!
More checking, less guessing is always good! (And I could learn a lot from that motto myself!! )
Click to expand...
Click to collapse
yeah when i saw that post my balls shrank.. thinking that by precious phone may be 'slowly dying of corruption'
not like there is a repair file system tool to use

Code:
/dev/block/stl9 /system rfs ro,noatime,vfat,log_off,check=no,gid/uid/rwx,iocharset=utf8 0 0
K8, u had a short life... looks like its time for K9
Important thing to note is that this is the way stock kernels mount /system: read-only, and we see the option log_off too.
The thing I noticed this way is that if u do a mount -o remount,rw /system and modify stuff... it may corrupt /system. All modifications to /system should then ideally be done via CWM or update.zip only.

deathst said:
Well we could check it by running it on RFS and reboot alot of time and then flashing a original Kernel
Click to expand...
Click to collapse
Why would flashing an original kernel make a difference? Original kernel will mount /system in exactly the same way, so any corruption in /system would be seen on both the original kernel and on the sztupy kernel before the reflash.
Reflash or not has nothing to do with it.
Only method would be to reboot (or remount) enough times to hit the unclean filesystem check parameter (which rfs might not even have?), or wait long enough for the unclean check time to elapse. Not really sure how you would check what this parameter is - maybe tune2fs could be used? RFS is a bit of a black box!

RyanZA said:
Why would flashing an original kernel make a difference? Original kernel will mount /system in exactly the same way, so any corruption in /system would be seen on both the original kernel and on the sztupy kernel before the reflash.
Reflash or not has nothing to do with it.
Only method would be to reboot (or remount) enough times to hit the unclean filesystem check parameter (which rfs might not even have?), or wait long enough for the unclean check time to elapse. Not really sure how you would check what this parameter is - maybe tune2fs could be used? RFS is a bit of a black box!
Click to expand...
Click to collapse
It may mount correctly with Original Kernel..If it does quite a damage to the /system the phone might report errors even it is will not be able to boot.

deathst said:
It may mount correctly with Original Kernel..If it does quite a damage to the /system the phone might report errors even it is will not be able to boot.
Click to expand...
Click to collapse
No, that doesn't make sense. The difference between stock and sztupy is that sztupy's mount is telling the system to try and check the drive. If /system works fine in the sztupy kernel, it will still work fine in the stock kernel, because the only difference is that the stock kernel DOESN'T check. Well, testing so far seems to be showing that neither check, and the check option does nothing at all.

Related

Minimal UI for LUKS encryption on the Wildfire

This is a basic gui I wrote to unlock my encrypted partitions during boot.
I'm running my /data and /sdcard partitions encrypted, and the "luksunlock" binary is launched from init.rc to read the password and unlock the encrypted partitions.
I have included my somewhat modified init.rc for those interested.
For more information about LUKS on Android see this blogpost, written by shawn (Seems I'm not allowed to have urls in the post, but Google for 'android luks' , first hit)
This works good on Wildfire, altough it should work fine on other phones as well. Just remember that you need to set up your partitions as in the luksunlock.c (or change the defines).
Dont forget to backup before you start playing around!
Good luck!
Thanks! i'll give a try!
Hi,
I tried to use your cryptsetup binary from your blog, but I have some issues that you'll sure have an answer:
I run ./cryptsetup luksFormat -c aes-plain /dev/block/loop2 and after i put the luks password it says 'Command failed', no logs, no other output, even using the -v flag...
Any clue?
Thanks in advance!
PS: the module dm-crypt is necessary for cryptsetup? could be this the error? I don't have it installed on the system because I can't find it for 2.6.35.9-cyanogenmod
tusabe said:
Hi,
I tried to use your cryptsetup binary from your blog, but I have some issues that you'll sure have an answer:
I run ./cryptsetup luksFormat -c aes-plain /dev/block/loop2 and after i put the luks password it says 'Command failed', no logs, no other output, even using the -v flag...
Any clue?
Thanks in advance!
PS: the module dm-crypt is necessary for cryptsetup? could be this the error? I don't have it installed on the system because I can't find it for 2.6.35.9-cyanogenmod
Click to expand...
Click to collapse
CM6.1 for wildfire uses a 2.6.32 kernel (see HCDR.jacob's post about his custom kernel for more info)
tusabe said:
PS: the module dm-crypt is necessary for cryptsetup? could be this the error? I don't have it installed on the system because I can't find it for 2.6.35.9-cyanogenmod
Click to expand...
Click to collapse
Yeah you really need dm-crypt support, either compiled into the kernel or as a module. You also need the AES ciphers support.
sigkill1337 said:
Yeah you really need dm-crypt support, either compiled into the kernel or as a module. You also need the AES ciphers support.
Click to expand...
Click to collapse
Hi! Yeah, that's what I was afraid of.... ok, but the problem is that i'm running CM6.1 with 2.6.35.9 which has no dm-crypt module neither compiled in kernel... where can i find some kernel with this modules included? Is for an HTC Desire (@Sympnotic )
Thanks in advance!
Great work and thanks for sharing @Sigkill. Working on building it here for my NexusOne with CM6.1.
BTW, I’m the lead on a project working on general secure Android distro – we’ve ported Tor, have an OTR IM app, and have supported other projects along those lines. Would love to talk more about supporting anyone working on this specific capability.
wow! awesome work!!! Very exciting news. Gonna give this a go on my MyTouch Slide
NathanFreitas said:
Great work and thanks for sharing @Sigkill. Working on building it here for my NexusOne with CM6.1.
BTW, I’m the lead on a project working on general secure Android distro – we’ve ported Tor, have an OTR IM app, and have supported other projects along those lines. Would love to talk more about supporting anyone working on this specific capability.
Click to expand...
Click to collapse
Seems really nice. I like the secure phone concept.
New Makefile and wiki info up
_hc from the @guardianproject has a new build process up for Crypsetup/LUKS which includes a Makefile compatible with Android NDK r5.
We have new instructions up on our wiki, as well.
I cannot post links under this account, but you can find the info on github if you search "LUKS" or just under our guardianproject account.
How did you create the encrypted partitions? Could you give some pointers for that. I am familiar with using dmcrypt/cryptsetup on desktop linux, I guess this works similar. What are the relevant device names? Did you run into any problems?
Calavera1 said:
How did you create the encrypted partitions? Could you give some pointers for that. I am familiar with using dmcrypt/cryptsetup on desktop linux, I guess this works similar. What are the relevant device names? Did you run into any problems?
Click to expand...
Click to collapse
Hi, sorry for the late answer,
/dev/block/mtdblock5 is the "userdata" partition. I formatted it and mount it to /encrypted-data during init:
mount yaffs2 [email protected] /encrypted-data nosuid nodev
The only file on this partition is "data.encrypted" file, which gets created in init.rc as a loopback device:
exec /system/bin/losetup /dev/block/loop0 /encrypted-data/data.encrypted
I created the "data.encrypted" file on my computer with cryptsetup and losetup, and copied all files from my old unencrypted userdata partition to it and then copied it back as a file to the formated userdata partition.
The sdcard "/dev/block/mmcblk0p2" partition is formated with "cryptsetup luksFormat", I did this also on my computer, saves some time. And then copy everything from the old unencrypted sdcard.
I did run in to one problem recently, my phone hung during boot, about 4 months after I started encrypting my phone.
Had to copy my data.encrypted file to my computer, mount it as a loopback device and do a fsck, and then copy it back to my phone.
I suspect this has to do with the filesystem not being umounted properly. (I have had this on my to do list for a while hehe)
Probably should make a script run during shutdown to cleanly "luksClose" the encrypted partition and then umount them. Not doing this is probably very crazy
I also want to fix it so my "/dev/block/mmcblk0p2" partition gets presented to my computer when i attach my usb cable (as it should do), so i can unlock it in ubuntu and copy images and files. Right now i have to take my memorycard out and put it into the computer.
I hope this post makes sense, it was written in haste =) Good luck!
sigkill1337 said:
Hi, sorry for the late answer,
/dev/block/mtdblock5 is the "userdata" partition. I formatted it and mount it to /encrypted-data during init:
mount yaffs2 [email protected] /encrypted-data nosuid nodev
The only file on this partition is "data.encrypted" file, which gets created in init.rc as a loopback device:
exec /system/bin/losetup /dev/block/loop0 /encrypted-data/data.encrypted
I created the "data.encrypted" file on my computer with cryptsetup and losetup, and copied all files from my old unencrypted userdata partition to it and then copied it back as a file to the formated userdata partition.
The sdcard "/dev/block/mmcblk0p2" partition is formated with "cryptsetup luksFormat", I did this also on my computer, saves some time. And then copy everything from the old unencrypted sdcard.
I did run in to one problem recently, my phone hung during boot, about 4 months after I started encrypting my phone.
Had to copy my data.encrypted file to my computer, mount it as a loopback device and do a fsck, and then copy it back to my phone.
I suspect this has to do with the filesystem not being umounted properly. (I have had this on my to do list for a while hehe)
Probably should make a script run during shutdown to cleanly "luksClose" the encrypted partition and then umount them. Not doing this is probably very crazy
I also want to fix it so my "/dev/block/mmcblk0p2" partition gets presented to my computer when i attach my usb cable (as it should do), so i can unlock it in ubuntu and copy images and files. Right now i have to take my memorycard out and put it into the computer.
I hope this post makes sense, it was written in haste =) Good luck!
Click to expand...
Click to collapse
I figured most of that out without your post and tried it on my desire (I created the luks partitions with adb on the phone though, worked anyway ). Then I couldn't figure out where my regular init.rc is stored (I could only find the one used by Clockwork Recovery), and then I figured I already spent enough time, tried a reboot (which of course didn't work). Then I couldn't even get into recovery (probably because its init.rc tries to mount /data which doesn't work? I didn't investigate any further). Flashed my backup with fastboot and was stuck again with my un-encrypted pre-experiment state
Oddly enough, it was no problem to unlock my encrypted SD-card from my computer (running ubuntu) while in recovery (clockword has an option to present the sd card to a computer connected via usb). Maybe the booted system handles this differently than recovery though? I didn't get a chance to try, as I couldn't boot after my encryption attempt.
I will try again after my algorithm and data structure exam this friday and report back
Is anybody using the UI on another device than the Wildfire? Does it work?
How much is the performance drain when using an encrypted /data partition?
Amazing work!
Did anyone manage to make sigkill1337's luksunlock build from source ?
I would like to change the path of the data/sdcard partitions to match my device but I tried many ways using the NDK and I can't get it to compile properly.
Is there any way to do this ?
I have been trying for days, I am getting literaly insane !
@sigkill1337 : could you give me some pointers ? I would appreciate a lot.
mount manpage said:
The bind mounts.
Since Linux 2.4.0 it is possible to remount part of the file hierarchy somewhere else. The call is
mount --bind olddir newdir
or shortoption
mount -B olddir newdir
or fstab entry is:
/olddir /newdir none bind
After this call the same contents is accessible in two places. One can also remount a single file (on a single file).
This call attaches only (part of) a single filesystem, not possible submounts. The entire file hierarchy including submounts is attached a second place using
mount --rbind olddir newdir
or shortoption
mount -R olddir newdir
Note that the filesystem mount options will remain the same as those on the original mount point, and cannot be changed by passing the -o option along with --bind/--rbind. The mount options can be changed by a separate remount command, for example:
mount --bind olddir newdir
mount -o remount,ro newdir
Click to expand...
Click to collapse
If nothing helps, you should always be able to bindmount it
I'd rather get sigkill1337's UI to compile...
Lots of nice security tweaks and settings could be done with a pre-boot GUI
Anyway, concerning encryption, I'll use the bind option for now, thanks for the tip.
But if anyone here could give me some pointers about compiling this stuff it would be great.
I managed to compile it by integrating luksunlock in Android source externals and main.mk but when I push it to my phone and modify init.rc to call it, it just does not work...
Other modifications are working (mount, mkdir, etc.) but the GUI won't show up
Sorry for the late reply.. But you could try running it from a shell when the phone is booted, just to verify that the binary starts (thats how I tested it without having to reboot my phone all the time)
My environment for building the source was setup using one of the tutorials online, nothing out of the ordinary
Im still running this on my phone, for almost 8 months now, I havent noticed that much in performance problems, the Wildfire was slow before i started using luks.
When i get a new phone (maybe SE Arc) i will be easier to see if performance is affected
There is an Issue for getting CM support for encrypted filesystems during boot:
Issue 2736: support encrypted filesystem from boot
If you want to get that feature, just "star" it, so it may get more attention.

after Data2loop Quadrant Advanced Score 3333

after Data2loop Quadrant Advanced Score 3333
i modify /system/etc/inandop.sh create a loopback device,Please make sure that you have the file.
USE THIS PACK AT YOUR OWN RISK
install adb drivers.
Unzip and run data2loop.bat.
thanks : Dexter_nlb ownhere
What is data2loop? Please elaborate.
Yeah what is that, and are there any drawback to using it?
i am guessing this is some sort of reallocation in the programming, so some programming terminology and not actually something u install....lol, i wish i had experience in this!
I would submit that it is programming, but also something that is installed to take advantage of the great hardware we have.
Asst Dean, IT
rapcon said:
What is data2loop? Please elaborate.
Click to expand...
Click to collapse
create a 512m loopback device,moving some data into the device, this can acheive rapid read and write on buffer data , such as the data under /data.
Is there a reason we r not sharing the wealth...lol. I am guessing this is something that will have to be added to the ROM? Imagine this and ext4! Whew! we might actually have something. If only Honeycomb source was out and viewsonic gave it to the developers....lol
Chenglu said:
create a 512m loopback device,moving some data into the device, this can acheive rapid read and write on buffer data , such as the data under /data.
Click to expand...
Click to collapse
Soudsn great, but again I am not programmer But let me know when it gets simpler
I uploaded the pack
Where please is your post and what we should.
Chenglu said:
I uploaded the pack
Click to expand...
Click to collapse
Do we just place inandop.sh and dataloop.bat in system/ect and reboot?
run dataloop.bat on your pc.
install adb drivers first
can you wrap this up in a zip for those that have ADB issues?
mzimand said:
Do we just place inandop.sh and dataloop.bat in system/ect and reboot?
Click to expand...
Click to collapse
Download and unzip the file on your PC which has a ADb connection to yout GT.
Then run the include data2loop.bat, this will install all the files.
Just like install any update, MAKE SURE you BACKUP your system first.
mzimand said:
Do we just place inandop.sh and dataloop.bat in system/ect and reboot?
Click to expand...
Click to collapse
Download and unzip the file on your PC which has a ADB connection to yout GT.
Then run the include data2loop.bat, this will install all the files.
Just like install any update, MAKE SURE you BACKUP your system first.
Chenglu said:
after Data2loop Quadrant Advanced Score 3333
i modify /system/etc/inandop.sh create a loopback device,Please make sure that you have the file.
USE THIS PACK AT YOUR OWN RISK
Click to expand...
Click to collapse
You beat my ext4 fix to the punch. But I like the way you packaged this up.
Just an explanation for what I believe chenglu is doing here -
His kernel enables loop devices, although I think they may be enabled by default too (http://en.wikipedia.org/wiki/Loop_device).
Then the modified inandop.sh script gets run at the end of init.rc, and that script is creating a file in the data area and mounting it as a loopback device.
He is then moving the stuff from data/data, data/anr and data/app-private directories and copying over the actual contents of those directories into the newly mounted directories on the loopback device.
I am not certain why the loopback device would be so much faster than the standard filesystem access, since it's still on the same device - I think it just has to do with some of the parameters he's passing to mount it? Or simply because it's plain ext2 rather than ext3 - i.e. no journalling.
Not to knock this impressive work (it's impressive because it's deceptively simple but seems to yield - at least in benchmarking - a significant improvement), but I'm not sure about the long term data integrity side of this - is the ext2 loopback device more prone to corruption? And we seem to already have more than enough data integrity issues with our ext3 /data partitions as it is.
Also, do you know how much of the gain is just attributable to the change in how you are mounting the data partition itself (noatime, nodiratime parameters obviously speed things up too, I'd already added that to my init.rc for the plain ext3 mount of the /data partition - I see you did that too in here).
I'm going to test this for TnT Lite today - I might add it to a 3.1.5 supplement, if it seems stable.
One concern is that it replaces busybox, which might break Titanium Backup. Anyone running might want to check if TB is still working, afterwards.
EDIT: Give me 30 minutes and I'll have something generic that should work on VEGAn and TnT Lite 3.x (they share the same busybox setup). And it will an update.zip.
roebeet said:
I'm going to test this for TnT Lite today - I might add it to a 3.1.5 supplement, if it seems stable.
One concern is that it replaces busybox, which might break Titanium Backup. Anyone running might want to check if TB is still working, afterwards.
EDIT: Give me 30 minutes and I'll have something generic that should work on VEGAn and TnT Lite 3.x (they share the same busybox setup). And it will an update.zip.
Click to expand...
Click to collapse
Patiently waiting for that update.zip =P For some reason when I try to download the usb drivers for adb it tells me access is denied... oh well.
I think, the most stable is fdisk inand 3 partions, mmcblk3p3 storage loopback device.
Yesterday I tested, scores almost. For users, it is very difficult..
husker91 said:
Patiently waiting for that update.zip =P For some reason when I try to download the usb drivers for adb it tells me access is denied... oh well.
Click to expand...
Click to collapse
sending you a PM

How to make rootfs / writable

The root filesytem, /, is read-only. This makes /sbin and a bunch of other stuff read-only as well.
I'm fairly noobish w.r.t. Android (but rapidly less so!), but long in the tooth with unix and linux.
All I want to do is put a .bashrc in /, so don't worry and/or feel the need to post a bunch of warnings, caution, etc.
For the life of me, examing the output of mount, I can't figure out what device path to use in the command,
mount -o rw -o remount <device> /
I'm guessing it probably isn't this simple, and there is some convoluted loop config with mount or something as part of the Android security mechanism.
You can mount it as r/w with Root Explorer...
SubnetMask said:
You can mount it as r/w with Root Explorer...
Click to expand...
Click to collapse
ES File explorer will also allow you mount as writable. Under Menu>Settings>Root options.
It's a little flaky though, I have to turn on the root options then shut down the app and restart it to get it to work. It's free and available in the Android Market.
dwallersv said:
The root filesytem, /, is read-only. This makes /sbin and a bunch of other stuff read-only as well.
Click to expand...
Click to collapse
You can remount / as read-write with:
Code:
mount -wo remount rootfs /
and read-only again with:
Code:
mount -ro remount rootfs /
However, the root filesystem is actually a ram disk (initramfs), so any changes to it aren't persistent across reboots. You can modify the initramfs, but it requires rebuilding it and packaging it with a kernel, and flashing the kernel containing the new initramfs.
dwallersv said:
All I want to do is put a .bashrc in /, so don't worry and/or feel the need to post a bunch of warnings, caution, etc.
Click to expand...
Click to collapse
Can you get away with placing it in /data or even /system? If you can't recompile bash, you'll have to invoke it with "bash --init-file /data/local/.bashrc" or something.
If you're using ConnectBot Local, you can do that automatically with "Post-login automation", e.g., "exec bash --init-file /whatever/.bashrc".
I believe the one-click version 2.5.5 installs the scripts that let you simply "remount rw" and "remount ro" from the command line as root.
DiGi760 said:
I believe the one-click version 2.5.5 installs the scripts that let you simply "remount rw" and "remount ro" from the command line as root.
Click to expand...
Click to collapse
That's for "/system", OP is asking about "/".
You cannot keep anything in / anyway. / is the initramfs. Folders, permissions, etc are set on init, and rewritten every boot. So anything you end up putting in / will be removed on reboot.
The only way you can accomplish what you want, in this circumstance, is the method listed above, or to modify the initramfs.
Thanks everyone, for all the great information... Man, I love this place!
@mkasick: Crap!! Well, that torpedoes this one.
I've already used the various "workarounds" you cited (use connect automation with ConnectBot, for example). My reason for this was to attack connecting via telnet via PuTTY from my PC after starting telnetd on the device. It's simply a matter of convenience -- saving the step of typing "bash -l" after I connect.
I'm not going to go to all the trouble to rebuild a custom initramfs for just this.
However, you've given me an idea I'll try and report back (and should work): Modify/add an init.d user script to remount / as writable, copy the .bashrc from sdcard to /, then remount / as read-only. That should take care of persistence across boots.
Once again, mkasick, you are a most helpful fellow around here. I must say -- and it may make you blush -- I am a big fan and admirer of yours, with the things you've found and fixed for the community. You are unique among the devs in my view, given the nature of what you have looked into and fixed. I'm a pretty experienced, knowlegable software guy myself, and fancy learning enough about Android to make contributions in the not-too-distant future like you have.
As I mentioned in another thread, I'm looking at a major driver re-design for the keyboard based on your analysis and patch for the dropped keypress problem... I plan to have some discussions with you (if your interested) sometime in the next few weeks about what I'm planning, just to get your feedback, if nothing else. Basically, the idea is to add some full state-handling to the driver and interrupt handler to substitute for the lack of hardware latch support.
Keep up the good work, friend. You are a uniquely valuable member of this community, in my judgement
-- And that's not to shortchange any of the other devs here, it's just that the nature of your work resonates with me especially, given my own background, career, interests, and past work in software.
Dameon87 said:
You cannot keep anything in / anyway. / is the initramfs. Folders, permissions, etc are set on init, and rewritten every boot. So anything you end up putting in / will be removed on reboot
Click to expand...
Click to collapse
Spot-on, and very good point. However, there are ways around that:
dwallersv said:
However, you've given me an idea I'll try and report back (and should work): Modify/add an init.d user script to remount / as writable, copy the .bashrc from sdcard to /, then remount / as read-only. That should take care of persistence across boots.
Click to expand...
Click to collapse
In fact, in a more generalized sense, this approach can be used to make any changes to the rootfs that "persists" across boots, without the pain of rebuilding initramfs and repackaging the kernel. This is especially messy to track and manage when you take advantage of one of the excellent custom ROMs here (in my case, Bonsai).
FWIW, and maybe helpful to others, I already have organically evolved as "reinstall" framework/process for doing some customizations to the system after installing a new/updated ROM. I use shell scripting for a lot of little things, and keeping this stuff working became a challenge across ROM releases, because necessary components -- like shells, busybox versions, whether busybox of toolbox is being called by the default path, and a bunch of other things (like the ALSA tools) are present in places like the /system filesystem.
All this gets mucked up with each ROM/kernel update. Now, I'm slicing this bologna even thinner by messing with rootfs, so I've got to get things to persist across boots!
I have a simple, one-step process for fixing all this after a new ROM. Nothing fancy -- just a flashable, Edify zip of my stuff that I hit right after a ROM update. Found a template zip with very generic Edify script in it that simply copies the file tree. I keep my custom stuff updated there.
dwallersv said:
My reason for this was to attack connecting via telnet via PuTTY from my PC after starting telnetd on the device. It's simply a matter of convenience -- saving the step of typing "bash -l" after I connect.
Click to expand...
Click to collapse
How about setting BASH_ENV or HOME in telnetd's environment? Or is the environment not preserved?
dwallersv said:
However, you've given me an idea I'll try and report back (and should work): Modify/add an init.d user script to remount / as writable, copy the .bashrc from sdcard to /, then remount / as read-only.
Click to expand...
Click to collapse
That works. "init.d" is the hard part though. To my knowledge, there's no generalized "init.d"-like folder for Android, except statements in init.rc itself (which isn't simply modified).
CyanogenMod does support /system/etc/init.d I believe. Perhaps other ROMs do as well--I've not checked.
There's also using gscript, maybe Tasker, or another program that hooks ACTION_BOOT_COMPLETED. Those won't run at root privileges, but a tie in to "su -c" should work.
dwallersv said:
You are unique among the devs in my view, given the nature of what you have looked into and fixed.
Click to expand...
Click to collapse
Thanks!
I think of my contributions as complementary though. I don't really have the time or patience for "maintaining stuff" that other folks do here very well.
dwallersv said:
Basically, the idea is to add some full state-handling to the driver and interrupt handler to substitute for the lack of hardware latch support.
Click to expand...
Click to collapse
I suppose discussion elsewhere is appropriate. Sounds ambitious, but a good idea. The existing keyboard driver architecture could be improved for certain. To date though, I've tried to make my kernel changes relatively non-invasive, even if not ideal, for maintenance sake.
In a perfect world, a rewritten driver would make it back to Samsung and that would be the "end of it" for us. Personally, I wouldn't want to expend the effort to do so unless I knew it would be merged. But if that something you feel like attempting, there's no harm in trying and seeing what results.
mkasick said:
That works. "init.d" is the hard part though. To my knowledge, there's no generalized "init.d"-like folder for Android, except statements in init.rc itself (which isn't simply modified).
CyanogenMod does support /system/etc/init.d I believe. Perhaps other ROMs do as well--I've not checked.
Click to expand...
Click to collapse
I'm not 100% certain at this point, but from what I've found investigating this, it looks like the "user scripts" /etc/init.d/<scripts> mechanism is a standard part of the Android system. I'll see if I can find where I saw that and post a link.

Thread closed.

Thread closed.
Thread closed.
Yank555 said:
Hi,
REMEMBER
FIRST OF ALL, do a Nandroid backup, as well as a backup of your sd-card content !
You're doing this at your very own risk, I'm not to be held responsible if something goes wrong
Now that said, let's get going
In case somebody wants to check it out, here is the swap activation script I wrote (attached) as well as explanations on how to make it all work :
1) Partition your sd-card (Minitool Partition Wizard, 4ext, CWM...)
2) Boot your system with the partitionned sd-card
3) If necessary customize the 99swap script (attached to this post) and then put it onto your sd-card's root folder, you'll need it while executing the commands in step 4.
4) Open a terminal and type the following
NB: Change "mkswap /dev/block/mmcblk0p3" accordingly to point to the swap partition you've created in step 1.
5) Reboot your phone, start a terminal again and type free, you'll need to see something different than 0 in your swap line, look at the attached print-screen
Swappiness will be set to 50 by the script, which is a rather conservative swap use, made sense to me since SD-swap is slower than ram, better not to use it too agressively. Feel free to experiment with the swappiness variable in the script (values between 0 and 100, 0 meaning "try not to swap", 100 meaning "try to swap all the time")
If you want to try and have a question, just let me know !
JP.
PS: You can find the thread for hard swap for the htc Sensation / XE here.
Click to expand...
Click to collapse
Hi JP,
This is a gem of a post! Thanks alot for the script and the detailed breakdown. Before I get into it though, I must warn you that I am more of a beginner with no coding/scripting experience (I don't know how to use adb or anything)...
Here's what I'm trying to do: I'm trying to activate hard-swap on my hd2 (currently) running the ParanoidAndroid by Xylograph. I've created 3 partitions on my 16gb class 6 sd card: first, fat32 (32k cluster), next, 1GB ext2 (default), 500MB swap.
Procedure:
1. I extracted the script and copied it directly to system/etc/init.d folder of the Rom (I looked at the terminal commands you posted and the first few lines looked like copying the file from the sd root to the init.d folder (it was just a guess though), so I figured might as well put it into the rom before I flash it)
2. Flashed the rom
3. To activate it, I typed the following into the terminal:
su
mount -o remount,rw /system
mkswap /dev/block/mmcblk0p3
mount -o remount,ro /system
exit
after the mkswap command, I did get an activation notification that a certain amount was assigned to swap. But my celebrations were cut short after I rebooted and used the free command to check. The entire swap row still read 0.
I was wondering if you can point me in the right direction... thanks!
Also, is there a way to create a cwm flashable version?
bullcrapr said:
Hi JP,
This is a gem of a post! Thanks alot for the script and the detailed breakdown. Before I get into it though, I must warn you that I am more of a beginner with no coding/scripting experience (I don't know how to use adb or anything)...
Here's what I'm trying to do: I'm trying to activate hard-swap on my hd2 (currently) running the ParanoidAndroid by Xylograph. I've created 3 partitions on my 16gb class 6 sd card: first, fat32 (32k cluster), next, 1GB ext2 (default), 500MB swap.
Procedure:
1. I extracted the script and copied it directly to system/etc/init.d folder of the Rom (I looked at the terminal commands you posted and the first few lines looked like copying the file from the sd root to the init.d folder (it was just a guess though), so I figured might as well put it into the rom before I flash it)
2. Flashed the rom
3. To activate it, I typed the following into the terminal:
su
mount -o remount,rw /system
mkswap /dev/block/mmcblk0p3
mount -o remount,ro /system
exit
after the mkswap command, I did get an activation notification that a certain amount was assigned to swap. But my celebrations were cut short after I rebooted and used the free command to check. The entire swap row still read 0.
I was wondering if you can point me in the right direction... thanks!
Also, is there a way to create a cwm flashable version?
Click to expand...
Click to collapse
Thanx
In fact you understood correctly that is was about copying the file to init.d.
By the way, these commands do the following :
mount -o remount,rw /system - Mount system partition in read-write
mount -o remount,ro /system - Mount system partition in read-only
So to format the swap partition "mkswap /dev/block/mmcblk0p3" there was no need for it, but it didn't harm in any way, so you're fine there
I guess what is missing is the "chmod 755 /system/etc/init.d/99swap" command which will set the correct file access to the script so it can get executed at boot.
You might do the following in a terminal :
su
mount -o remount,rw /system
chmod 755 /system/etc/init.d/99swap
mount -o remount,ro /system
exit
It should be fine then.
Alternatively you could set the rights with your file explorer (in root explorer mode), they must be "rwxr-xr-x" (which is Read-Write-Execute, Read-Execute, Read-Execute), most file-manager will allow you to do that as well.
I've been working on the script variant for htc Sensation, it is more advanced, dynamic so it can find the swap partition by itself.
I'll make a CWM flashable as soon as I get to it that will handle everything except partitioning the SD card, obviously, for both devices.
As soon as I'm done I'll post the HD2 version here as well (very little change, between both devices, just the access path to the sd-card partitons to change (=1 line in the script).
JP.
Edit ------------------------------------------------
I just reread your post, if in fact you put it into the ROM zipfile, then file access should be correct !?
Could you post the following file (if it exists) :
/data/swap.0.log ?
JP.
Yank555 said:
Thanx
In fact you understood correctly that is was about copying the file to init.d.
By the way, these commands do the following :
mount -o remount,rw /system - Mount system partition in read-write
mount -o remount,ro /system - Mount system partition in read-only
So to format the swap partition "mkswap /dev/block/mmcblk0p3" there was no need for it, but it didn't harm in any way, so you're fine there
I guess what is missing is the "chmod 755 /system/etc/init.d/99swap" command which will set the correct file access to the script so it can get executed at boot.
You might do the following in a terminal :
su
mount -o remount,rw /system
chmod 755 /system/etc/init.d/99swap
mount -o remount,ro /system
exit
It should be fine then.
Alternatively you could set the rights with your file explorer (in root explorer mode), they must be "rwxr-xr-x" (which is Read-Write-Execute, Read-Execute, Read-Execute), most file-manager will allow you to do that as well.
I've been working on the script variant for htc Sensation, it is more advanced, dynamic so it can find the swap partition by itself.
I'll make a CWM flashable as soon as I get to it that will handle everything except partitioning the SD card, obviously, for both devices.
As soon as I'm done I'll post the HD2 version here as well (very little change, between both devices, just the access path to the sd-card partitons to change (=1 line in the script).
JP.
Edit ------------------------------------------------
I just reread your post, if in fact you put it into the ROM zipfile, then file access should be correct !?
Could you post the following file (if it exists) :
/data/swap.0.log ?
JP.
Click to expand...
Click to collapse
Hi JP
You are incredibly helpful and I appreciate it!
I finally got some time off and tried out what you mentioned... but to no avail. I applied the necessary permissions through the terminal (chmod 755) as well as through the root browser, but it was still the same. After that I even retried the terminal commands, and included the "chown 0:2000...", but that didn't work either...
... and then I saw your post update...
About that, i just typed it into the terminal, and I got "not found".
Was that what I was supposed to do?
bullcrapr said:
Hi JP
You are incredibly helpful and I appreciate it!
I finally got some time off and tried out what you mentioned... but to no avail. I applied the necessary permissions through the terminal (chmod 755) as well as through the root browser, but it was still the same. After that I even retried the terminal commands, and included the "chown 0:2000...", but that didn't work either...
... and then I saw your post update...
About that, i just typed it into the terminal, and I got "not found".
Was that what I was supposed to do?
Click to expand...
Click to collapse
Hi,
You're welcome
The file '/data/swap.0.log' is a text-file containing info on the execution of the script...
If it's not there, then the script didn't run at all...
I should have a little time later today, will try to make the CWM flashable solution for you, should be a no fuss solution, as long as the sd-card has a swap partition
How did you partition the card ? CWM ?
JP.
Sent from my Android Revolution HD 6.6.5 XE / faux kernel 007b3 powered htc Sensation XE using xda premium
I created a 256Gb partition...
Click to expand...
Click to collapse
man thats a helluva sd card ya have there! hehe.
samsamuel said:
man thats a helluva sd card ya have there! hehe.
Click to expand...
Click to collapse
Haha I noticed that too :') I want one of those now
Nigeldg said:
Haha I noticed that too :') I want one of those now
Click to expand...
Click to collapse
Thanx for pointing that out Mb of course, but in a few years that might be possible
My first hdd had 60Mb, and that's not soooo long ago
JP.
Sent from my Android Revolution HD 6.6.5 XE / faux kernel 007b3 powered htc Sensation XE using xda premium
heh, my first was a 20mb HDD mounted on a pcb card and plugged into an ISA slot, took up the full length of the PC, weighed LOADS, could have beaten burglars to death with it.
bullcrapr said:
Hi JP
You are incredibly helpful and I appreciate it!
I finally got some time off and tried out what you mentioned... but to no avail. I applied the necessary permissions through the terminal (chmod 755) as well as through the root browser, but it was still the same. After that I even retried the terminal commands, and included the "chown 0:2000...", but that didn't work either...
... and then I saw your post update...
About that, i just typed it into the terminal, and I got "not found".
Was that what I was supposed to do?
Click to expand...
Click to collapse
+1 with this (also on Paranoid Rom 1.1a) but I think that it's something with the ROM coz on earlier build v1 this method worked verry good I hope that Yank will find a solution coz it reallly helps wit our 576 ram
samsamuel said:
heh, my first was a 20mb HDD mounted on a pcb card and plugged into an ISA slot, took up the full length of the PC, weighed LOADS, could have beaten burglars to death with it.
Click to expand...
Click to collapse
Mine was huge at the time, was on of the first to have such a big one, even partitioned it into 3 since it was just too big And it was an external device, the size of a pizza-box (it was en Atari Megafile 60, I still have it !!).
triggaz said:
+1 with this (also on Paranoid Rom 1.1a) but I think that it's something with the ROM coz on earlier build v1 this method worked verry good I hope that Yank will find a solution coz it reallly helps wit our 576 ram
Click to expand...
Click to collapse
I'm working on the CWM flashable right now, should be done within 1-2 hours at most
Yank555 said:
Hi,
You're welcome
The file '/data/swap.0.log' is a text-file containing info on the execution of the script...
If it's not there, then the script didn't run at all...
I should have a little time later today, will try to make the CWM flashable solution for you, should be a no fuss solution, as long as the sd-card has a swap partition
How did you partition the card ? CWM ?
JP.
Sent from my Android Revolution HD 6.6.5 XE / faux kernel 007b3 powered htc Sensation XE using xda premium
Click to expand...
Click to collapse
Hi JP, once you told me it was the address to the file, i just navigated there using my explorer and lo and behold!, there it was (attached). If you must know, in my earlier post, the idiot in me just typed it in the terminal and the terminal replied not found.
I made my partition using freeware called Minitool partition wizard. Is 500mb too big for swap in your opinion? I was thinking of compensating for zram, and hence the size... thanks for your speedy responses...
edit...
and hey! whadya know? in the meantime, this place is coming alive!!
bullcrapr said:
Hi JP, once you told me it was the address to the file, i just navigated there using my explorer and lo and behold!, there it was (attached). If you must know, in my earlier post, the idiot in me just typed it in the terminal and the terminal replied not found.
I made my partition using freeware called Minitool partition wizard. Is 500mb too big for swap in your opinion? I was thinking of compensating for zram, and hence the size... thanks for your speedy responses...
edit...
and hey! whadya know? in the meantime, this place is coming alive!!
Click to expand...
Click to collapse
Hmm ... strange, the content of the file looks like a logcat ?! Not what I was expecting to see
Give me a little hour, and I think I should be done with the flashable hard-swap and we'll go from there
Minitool is excellent, but did you pay attention to only create "primary" partition ? If it is a logical partition it won't work...
Can you insert your SD card into your card reader, start Minitool an post a print screen of it ?
JP.
EDIT :
About size ... I believe 256Mb is enough, even read somewhere t shouldn't be more than 256, but I think there was no specific reason given.
Yank555 said:
Hmm ... strange, the content of the file looks like a logcat ?! Not what I was expecting to see
Give me a little hour, and I think I should be done with the flashable hard-swap and we'll go from there
Minitool is excellent, but did you pay attention to only create "primary" partition ? If it is a logical partition it won't work...
Can you insert your SD card into your card reader, start Minitool an post a print screen of it ?
JP.
EDIT :
About size ... I believe 256Mb is enough, even read somewhere t shouldn't be more than 256, but I think there was no specific reason given.
Click to expand...
Click to collapse
Here we go...
Minitool image attached... I typically pay attention to the partition type and made sure both of them were primary
About the logcat, I suspect you're right... I was trying to do one from my pc for the first time using adb and tried the only few commands I know (mkswap...), I think that's what you saw then...
Incidentally, do you feel if I reduce the swap size, the script has a better chance at surviving the boot?
bullcrapr said:
Here we go...
Minitool image attached... I typically pay attention to the partition type and made sure both of them were primary
About the logcat, I suspect you're right... I was trying to do one from my pc for the first time using adb and tried the only few commands I know (mkswap...), I think that's what you saw then...
Incidentally, do you feel if I reduce the swap size, the script has a better chance at surviving the boot?
Click to expand...
Click to collapse
Don't bother, I will test 500Mb and let you know if that is the issue
JP.
I have 512mb partition and it worked without problems as I mentioned earlier so I think that opposite to the "size does matter" in this case it doesn't plus I used it with zram from marc1706.
triggaz said:
I have 512mb partition and it worked without problems as I mentioned earlier so I think that opposite to the "size does matter" in this case it doesn't plus I used it with zram from marc1706.
Click to expand...
Click to collapse
Hi triggaz, are you using the built in zram on Para1.1a? Or have you applied a script from elsewhere? I enabled the built-in zram, but get a "not found" reply when i try zram_stats in the terminal. Can you tell me how you got zram working? thanks...
bullcrapr said:
Hi triggaz, are you using the built in zram on Para1.1a? Or have you applied a script from elsewhere? I enabled the built-in zram, but get a "not found" reply when i try zram_stats in the terminal. Can you tell me how you got zram working? thanks...
Click to expand...
Click to collapse
https://www.dropbox.com/s/xr3z102gxiw2f62/marc1706_zram_100MB.zip
all credits to Dorimanx for ZRAM mod and mark1706 for modifications
I flashed this and then used the compcashe options in Paranoid (set to 26%)

[HOW-TO] Convert to F2FS on Nexus 6 (Any Rom)

I didn't see anything about how to convert to f2fs for the nexus 6 so I thought i'd write something up as somebody requested me to do this.
What are the benefits of using f2fs over ext4?
I could list pros and cons, but I strongly encourage you to do your own research on the matter.
Should I do this
If you want to at your own risk
Pre-requisites
You need a recovery that supports f2fs in kernel and has the f2fs tools. Dhacker20 has provided one (TWRP 2.8.5.0) here: https://twitter.com/dhacker29/status/568070387306766336
You will need a kernel that supports f2fs for /cache and /data (Obviously I recommend Zen Kernel, but there are some others. Zen has the newest f2fs from upstream, while others may not)
ONLY YOU ARE RESPONSIBLE FOR YOUR DATA. IT IS YOUR RESPONSIBILITY TO UNDERSTAND THE RISKS AND YOUR RESPONSIBILITY TO BACKUP YOUR DATA
How-To
1.) Back up everything you care about to your PC (everything will be erased, including sdcard)
2.) Install a kernel that supports f2fs. Get the boot.img and do "fastboot flash boot boot.img" in bootloader (Like Zen)
3.) Install the recovery with f2fs support (fastboot flash recovery twrp-recvery-f2fs.img)
4.) In TWRP, go to Wipe
5.) Do a full wipe by swiping right
6.) Go to Wipe -> Advanced Wipe
7.) Choose /cache
8.) Choose "Change Filesystem"
9.) Pick f2fs, proceed
10.) Do the same thing for /data
11.) While still in recovery, plug phone into PC and do this:
Code:
# adb shell
# mount -o rw /system
# cp /sbin/fsck.f2fs /system/bin/
# cp /sbin/mkfs.f2fs /system/bin/
# chmod a+x /system/bin/*f2fs*
12.) Reboot and you are done.
Reserved
Is adb shell in terminal app
jiv101 said:
Is adb shell in terminal app
Click to expand...
Click to collapse
No adb is part of the android SDK platform-tools
I did this a while ago (except for step 12), and I remember something happening, which caused my data partition to become corrupted. I tried to format the partition again using ext3 or whatever the default is and that ended up giving me a soft brick. I had to restore the factory software. I have read things of where it does improve R/W speeds but I don't know if it's worth the hassle of possibly losing everything at the drop of a hat if you flash ROMs often.
RSVP..
Thanks for the information on F2FS well needed..!
brando56894 said:
I did this a while ago (except for step 12), and I remember something happening, which caused my data partition to become corrupted. I tried to format the partition again using ext3 or whatever the default is and that ended up giving me a soft brick. I had to restore the factory software. I have read things of where it does improve R/W speeds but I don't know if it's worth the hassle of possibly losing everything at the drop of a hat if you flash ROMs often.
Click to expand...
Click to collapse
The last step is a huge component of the whole process. If the rom doesn't have f2fs-tools in by default (most don't have fsck.f2fs/mkfs.f2fs) you will not have standard integrity checking every time you boot like you do on ext4. If you do the last step you will get integrity checking every time you bootup.
Also, since f2fs is a relatively young file system it can do harm to revert to older versions of the file system. For example, zen kernel has the newest f2fs which was updated last about 2 days ago. If you go on stock kernel you will find an f2fs that is 1+ year old. There may be a compatibility issue between these two where if you flash different roms (which almost always bundle a kernel)/kernels you will almost certainly have an issue.
But that's all part of the risk with using a relatively young file system. I do not understate the risks of data corruption in doing something like this - but anybody who is doing this and has significant worry should take precautions is backing up all their important files.
bbedward said:
The last step is a huge component of the whole process. If the rom doesn't have f2fs-tools in by default (most don't have fsck.f2fs/mkfs.f2fs) you will not have standard integrity checking every time you boot like you do on ext4. If you do the last step you will get integrity checking every time you bootup.
Also, since f2fs is a relatively young file system it can do harm to revert to older versions of the file system. For example, zen kernel has the newest f2fs which was updated last about 2 days ago. If you go on stock kernel you will find an f2fs that is 1+ year old. There may be a compatibility issue between these two where if you flash different roms (which almost always bundle a kernel)/kernels you will almost certainly have an issue.
But that's all part of the risk with using a relatively young file system. I do not understate the risks of data corruption in doing something like this - but anybody who is doing this and has significant worry should take precautions is backing up all their important files.
Click to expand...
Click to collapse
Is there any sort of confirmations when you are doing the last steps? I see this when I do them and I'm not sure if it has actually done the last steps.
C:\Development\platform-tools>adb shell
~ # ←[6nmount -o rw /system
mount -o rw /system
~ # ←[6ncp /sbin/fsck.f2fs /system/bin/
cp /sbin/fsck.f2fs /system/bin/
~ # ←[6ncp /sbin/mkfs.f2fs /system/bin/
cp /sbin/mkfs.f2fs /system/bin/
~ # ←[6nchmod a+x /system/bin/*f2fs*
chmod a+x /system/bin/*f2fs*
~ # ←[6n
C:\Development\platform-tools>
lobrau said:
Is there any sort of confirmations when you are doing the last steps? I see this when I do them and I'm not sure if it has actually done the last steps.
C:\Development\platform-tools>adb shell
~ # ←[6nmount -o rw /system
mount -o rw /system
~ # ←[6ncp /sbin/fsck.f2fs /system/bin/
cp /sbin/fsck.f2fs /system/bin/
~ # ←[6ncp /sbin/mkfs.f2fs /system/bin/
cp /sbin/mkfs.f2fs /system/bin/
~ # ←[6nchmod a+x /system/bin/*f2fs*
chmod a+x /system/bin/*f2fs*
~ # ←[6n
C:\Development\platform-tools>
Click to expand...
Click to collapse
That's about it, you can type exit to get out of adb shell or just close it.
On your device you can make sure f2fs took by simply typing "mount" in terminal emulator. You should see you data and cache reads f2fs now.
lobrau said:
Is there any sort of confirmations when you are doing the last steps? I see this when I do them and I'm not sure if it has actually done the last steps.
C:\Development\platform-tools>adb shell
~ # ←[6nmount -o rw /system
mount -o rw /system
~ # ←[6ncp /sbin/fsck.f2fs /system/bin/
cp /sbin/fsck.f2fs /system/bin/
~ # ←[6ncp /sbin/mkfs.f2fs /system/bin/
cp /sbin/mkfs.f2fs /system/bin/
~ # ←[6nchmod a+x /system/bin/*f2fs*
chmod a+x /system/bin/*f2fs*
~ # ←[6n
C:\Development\platform-tools>
Click to expand...
Click to collapse
Nope, it will only inform you if something went wrong (like file not found) of it all went through with no error it worked.
After you bootup you can verify it worked by typing "mount" in adb shell or terminal emulator. It should say f2fs on /data and /cache. Also in something like root Explorer if you navigate to /system/bin you should see the files you copied (fsck.f2fs and mkfs.f2fs)
bbedward said:
Nope, it will only inform you if something went wrong (like file not found) of it all went through with no error it worked.
After you bootup you can verify it worked by typing "mount" in adb shell or terminal emulator. It should say f2fs on /data and /cache. Also in something like root Explorer if you navigate to /system/bin you should see the files you copied (fsck.f2fs and mkfs.f2fs)
Click to expand...
Click to collapse
Perfect thanks for the quick response looked like it worked. Just out of curiosity is there any reason to format system to f2fs or does it end up causing issues, or just no changes in use?
lobrau said:
Perfect thanks for the quick response looked like it worked. Just out of curiosity is there any reason to format system to f2fs or does it end up causing issues, or just no changes in use?
Click to expand...
Click to collapse
I've tested it partly in testing the newest f2fs Zen merges as well as just general f2fs testing before.
It seems like writes are a bit faster, especially sql stuff. I've seen some grossly huge benchmark differences on other devices - on the n6 I've seen improvements but nothing astronomical like those benchmarks portrayed (I presume the 200% increase in write performance they showed is not accurate regardless) .
Recovery
So currently I'm on a 5.1 stock based rom (sinless) and TWRP 2.8.6
HAve Downloaded the latest Zen Kernel, and am downloading the latest 5.1 Benzo Rom.
Am I going to have issues rolling back to a 2.8.5 recovery - does 2.8.5 support 5.1 based roms?
shaitan667 said:
So currently I'm on a 5.1 stock based rom (sinless) and TWRP 2.8.6
HAve Downloaded the latest Zen Kernel, and am downloading the latest 5.1 Benzo Rom.
Am I going to have issues rolling back to a 2.8.5 recovery - does 2.8.5 support 5.1 based roms?
Click to expand...
Click to collapse
Yea it's compatible. There isn't a 2.8.6 with f2fs support yet that I know if and I haven't had the time to make one myself, but the 2.8.5 one works just fine.
@bbedward
I didn’t know any about the part 11 (I mean I convert mine to F2FS before I read this) so I’m wondering I’m gonna face any problem or not?
And also if have to do it, can I do it now or I have to wipe everything and then do it (cause changing partition to F2FS will clean everything)
Also I’m on your kernel.
dany20mh said:
@bbedward
I didn’t know any about the part 11 (I mean I convert mine to F2FS before I read this) so I’m wondering I’m gonna face any problem or not?
And also if have to do it, can I do it now or I have to wipe everything and then do it (cause changing partition to F2FS will clean everything)
Also I’m on your kernel.
Click to expand...
Click to collapse
Every time you boot your phone, it automatically runs fsck (for ext4 on stock). Essentially it's an automatic integrity check and repair.
So if it finds issues at boot up in the file system, it will tend to fix them automatically. If you look at boot up logs currently you will probably see something like "/system/bin/fsck.f2fs not found skipping integrity check"
You don't have to wipe everything though, you can just install the tools now.
I'm almost happy I posted this now hopefully it saves a few filesystems for folks who didn't do it completely.
---
When you see a kernel say f2fs compatible it means:
- f2fs is built into the kernel or a module is provided
- It's ramdisk's fstab allows for mounting of partitions as f2fs. On zen - it supports /data and /cache
When you see a rom say f2fs compatible it means:
- They have an f2fs-compatible kernel included
- They have the f2fs tools in the rom (As step 11 does)
This is why I say in the title this is "Any Rom" compatible as it will work on any rom, while on other devices you may see "Rom x, rom y, and rom z are the only known roms to be fully compatible." If you just do it this way it doesn't matter because it'll make any rom compatible with f2fs.
@bbedward this worked perfectly! But I just want to confirm that it switches back to ext4 after flashing a new ROM? After wiping and doing a clean flash it seems I'm not booting in f2fs anymore.
Am I doing something wrong or will I have to do this every time I clean flash?
Thanks again for the tutorial!
philsfan said:
@bbedward this worked perfectly! But I just want to confirm that it switches back to ext4 after flashing a new ROM? After wiping and doing a clean flash it seems I'm not booting in f2fs anymore.
Am I doing something wrong or will I have to do this every time I clean flash?
Thanks again for the tutorial!
Click to expand...
Click to collapse
I think most likely when you flashed a rom it overwrote your f2fs kernel, which caused it to reformat to ext4 when you booted it up.
Whenever you flash a rom you will need to flash f2fs-kernel right afterwards, and re-copy the tools (step 11) if the rom doesnt have them already in order to keep f2fs.
bbedward said:
I think most likely when you flashed a rom it overwrote your f2fs kernel, which caused it to reformat to ext4 when you booted it up.
Whenever you flash a rom you will need to flash f2fs-kernel right afterwards, and re-copy the tools (step 11) if the rom doesnt have them already in order to keep f2fs.
Click to expand...
Click to collapse
Thanks for responding so soon!
So I did flash zen9 (so good BTW) immediately after but I didn't repeat step 11 again. So that means Chroma doesn't have the necessary files for f2fs, good to know!
Edit: @bbedward does that mean I don't have to reformat again? Just do step 11?
Edit 2: entered step 11 in recovery and now i'm back to f2fs thanks again!
bbedward said:
The last step is a huge component of the whole process. If the rom doesn't have f2fs-tools in by default (most don't have fsck.f2fs/mkfs.f2fs) you will not have standard integrity checking every time you boot like you do on ext4. If you do the last step you will get integrity checking every time you bootup.
Also, since f2fs is a relatively young file system it can do harm to revert to older versions of the file system. For example, zen kernel has the newest f2fs which was updated last about 2 days ago. If you go on stock kernel you will find an f2fs that is 1+ year old. There may be a compatibility issue between these two where if you flash different roms (which almost always bundle a kernel)/kernels you will almost certainly have an issue.
But that's all part of the risk with using a relatively young file system. I do not understate the risks of data corruption in doing something like this - but anybody who is doing this and has significant worry should take precautions is backing up all their important files.
Click to expand...
Click to collapse
That was probably it! It was just a pain because this is the first phone that I've had in a while that doesn't have an SD card, I had a nandroid, but it doesn't do any good if you can't access your data partition Hahaha I have now taken to uploading my nandroids to Google Drive or putting them on my pc just in case that happens.

Categories

Resources