WARNING:
Use this on your own risk! I will not be held responsible for any failure that might be caused by using this.
"How should I know if it works? That's what beta testers are for. I only coded it."
- Linus Torvalds
What:
Yet another attempt at breaking free from RFS on the SGS phone (ie, lagfix), for Eclair, Froyo, and hopefully Gingerbread...
Which:
Supported devices are I9000 ATM. Theoretically it should work on all SGS variants, but since I only have I9000 to test on, I can't confirm this. I'd appreciate if other model owners will give it a try and report back.
Why:
KISS. I don't want to compile my own kernel or use a specific kernel (see voodoo) for my lagfix. I'd like to have a lagfix for ANY kernel out there.
z4mod is the 1st attempt in achieving that.
Another issue is standards. We don't need multiple lagfixes, all doing the same thing. One method, easy to customize and implement - thats the way to go.
How:
1. Use the online z4mod patcher to patch your kernel.
2. Download and apply one of the following update.zip files to convert your /data partition to the filesystem of your choice.
z4mod update.zip variants:
z4mod.ext2.update.zip - convert to ext2 - works on ALL kernels.
z4mod.ext3.update.zip - convert to ext3 - works only on modified kernel which supports ext3.
z4mod.ext4.update.zip - convert to ext4 - works only on modified kernel which supports ext4.
z4mod.auto.update.zip - automatically find which fs are supported by the kernel and convert to best suited - works on ALL kernels.
z4mod.rfs.update.zip - convert back to RFS - works on ALL kernels..
These update.zip files can be applied only to kernels which has been patched with z4build - a shell script which patches zImage to allow the init scripts additional non-RFS mount to each RFS partition, or with our online z4mod patcher. If the ROM you wish to install wasn't originally patched with z4build already, you can run z4build yourself on the zImage from the ROM package and put the patched zImage back to the ROM package for flashing, or use the online z4mod patcher to do it for you. It is that easy.
[NOTE:] Kernels (zImage) patched by z4build supports both mounts - RFS and non-RFS. So it doesn't change anything for users who doesn't apply z4mod.
You can also patch your z4mod scripts to enhance it's functionality, add more filesystems support, etc.
Although z4mod allows converting all the partitions from RFS to ext2/3/4, our update.zip files only convert /data - since this is ment for the 'masses'. If you feel brave enough, feel free to experiment with converting more partitions. All the sources are well documented.
Who:
z4ziggy, aka Elia Yehuda.
___
Original post [for reference]:
Although this is a half-baked project and far from complete, im introducing it to the xda community so i might get more ideas, and fix/implement more functionality, as the project advances.
z4mod is the 1st step in breaking free from RFS death grip - or at least tries to achieve this. The project adds ext3 support to a given zImage's init scripts, and creates update.zip for converting all RFS partitions and flash the patched zImage.
...thats the idea anyway.
ext4 support is planned for future official release. for testings purposes ext3 is sufficient.
sources and information can be found on my blog here: http://z4ziggy.wordpress.com
And of course, I'm not the only one interested in your measurements and conclusions
This looks really awesome, I'm loving it!
As far as the kernel patch goes, though:
Does the same kernel patch work for both 2.1 and 2.2 kernels? They seem pretty different.
Instead of requiring a linux box to patch the kernel, do you see any problems with doing the actual patching on the stock device itself? I didn't see anything in the script that should make this too difficult.
At any rate, this looks like The Solution.
love the work all 3 of you are doing with the file system on the i9000!
awesome job.
the patch is for the initscripts only - doesn't mind which kernel version. im doing my testings on Froyo 2.2 but patching should work the same on 2.1 scripts.
I hope to have some time later tonight to update the updater-script to follow all RFS partitions, and test it. ATM it works with my /cache partition only since its easy for testings (or "crashes" should i say? ).
i will update soon.
[edit]
regarding the linux part - no can do. We patch the initramfs scripts (which resides in the zImage), and i don't know of an easy way todo so from recovery mode. The easiest way is to use linux (even in a WM - you don't even need a full blown desktop, just CLI and compile tools) and patch the zImage, but i saw some Windows tools who might be able to do the same - I don't really know since i hardly use windows.
Thanks for your efforts! Keeping a close watch on this thread
z4ziggy said:
the patch is for the initscripts only - doesn't mind which kernel version. im doing my testings on Froyo 2.2 but patching should work the same on 2.1 scripts.
I hope to have some time later tonight to update the updater-script to follow all RFS partitions, and test it. ATM it works with my /cache partition only since its easy for testings (or "crashes" should i say? ).
i will update soon.
[edit]
regarding the linux part - no can do. We patch the initramfs scripts (which resides in the zImage), and i don't know of an easy way todo so from recovery mode. The easiest way is to use linux (even in a WM - you don't even need a full blown desktop, just CLI and compile tools) and patch the zImage, but i saw some Windows tools who might be able to do the same - I don't really know since i hardly use windows.
Click to expand...
Click to collapse
That's what rooting your phone is for! Just root the device, copy over all of the required binaries (arm statically linked if required, but busybox should handle 99% of what you're using in the script) and the kernel itself can be easily exacted using dd, of course.
Whole thing can be wrapped in a UI using java without too much hassle as well.
Most users aren't gonna be up to installing linux in a VM to run the script!
just replacing those scripts on your system won't do. you need to patch the initramfs and flash zImage back.
repackaging zImage with a new initramfs is not that simple. I'm using kernel_repacker todo so.
im sure there must be a better way than kernel_repacker, but until then, this is what we use
and about the Linux usage - the user would probably never use z4build script. only the update.zip. Modders, ROM creators, etc, should use z4build (or similar method to add the appropriate "mount ext3..." command to the "mount rfs", as i showed in my blog) to allow their kernel to support ext3. Simply apply z4build on any rom's zImage, and it's users can now apply the update.zip to have this rom' work with ext3.
I hope this explanation is suffice.
z4ziggy said:
just replacing those scripts on your system won't do. you need to patch the initramfs and flash zImage back.
repackaging zImage with a new initramfs is not that simple. I'm using kernel_repacker todo so.
im sure there must be a better way than kernel_repacker, but until then, this is what we use
and about the Linux usage - the user would probably never use z4build script. only the update.zip. Modders, ROM creators, etc, should use z4build (or similar method to add the appropriate "mount ext3..." command to the "mount rfs", as i showed in my blog) to allow their kernel to support ext3. Simply apply z4build on any rom's zImage, and it's users can now apply the update.zip to have this rom' work with ext3.
I hope this explanation is suffice.
Click to expand...
Click to collapse
Ah... kernel_repacker uses GCC. That would be pretty hard to port over to the SGS's stock kernel I guess.
Guess you're right then - would have to be run externally to the device. Bit of a shame since it adds to the complexity of the whole thing, still.
This does make it nice and quick to patch up any kernel at all though, which should make it much easier to keep the kernel patching up with any leaked kernels that come out!
looks like a very promising project! i liked voodoo but sadly we can not use it for 2.2 until we get the sources and it only converts the /data partition...
thanks for your work and i will be sure to check back here & on your blog soon
z4ziggy said:
Although this is a half-baked project and far from complete, im introducing it to the xda community so i might get more ideas, and fix/implement more functionality, as the project advances.
z4mod is the 1st step in breaking free from RFS death grip - or at least tries to achieve this. The project adds ext3 support to a given zImage's init scripts, and creates update.zip for converting all RFS partitions and flash the patched zImage.
...thats the idea anyway.
ext4 support is planned for future official release. for testings purposes ext3 is sufficient.
sources and information can be found on my blog here: http://z4ziggy.wordpress.com
Click to expand...
Click to collapse
Did you manage to compile ext3 or ext4 support to Froyo kernels? I only found ext2 support in them. (At least in JPK)
Another thing I see that you mount the rfs file on the device, but for me it only got mounted as vfat, so the symlinks in /bin in factoryfs.rfs were gone. (I solved this issue by adding commands to the initramfs that restore these symlinks)
ext3 is built into 2.2 kernel, i assumed the same for 2.1.
ext4 module will have to be rebuilt for each kernel, unless we build a standard kernel with ext4 support built-in, but all this will have to wait until samsung releases the sources.
[EDIT:]
Don't use the method which mounts the rfs files on the device. It uses ext2 and its obsolete already. I've only used the rfs mount on the device since it is the only way to have RFS readable as RFS and not as FAT. if your device mounted the RFS images as FAT, either:
1. you didnt use busybox mount
2. you might need to supply "-t rfs" to your mount command
z4ziggy said:
ext3 is built into 2.2 kernel, i assumed the same for 2.1.
ext4 module will have to be rebuilt for each kernel, unless we build a standard kernel with ext4 support built-in, but all this will have to wait until samsung releases the sources.
[EDIT:]
Don't use the method which mounts the rfs files on the device. It uses ext2 and its obsolete already. I've only used the rfs mount on the device since it is the only way to have RFS readable as RFS and not as FAT. if your device mounted the RFS images as FAT, either:
1. you didnt use busybox mount
2. you might need to supply "-t rfs" to your mount command
Click to expand...
Click to collapse
I know ext4 is missing, but I couldn't even get ext3 to work on JPK. (ext2 works)
for the mounts:
1. I did use busybox mount (using toolbox mount I couldn't even mount it in vfat mode)
2. I did supply -t rfs, but it told me invalid parameter
Some additions:
When I try to mount factoryfs.rfs in rfs mode it won't work (invalid argument). in vfat mode it works, but no symlinks and other rfs stuff. I can also mount it in j4fs mode, where I get some files not available in vfat mode (like param.blk or charging.jpg), the strange thing is these files are actually the same as in /mnt/.lfs
RyanZA said:
Most users aren't gonna be up to installing linux in a VM to run the script!
Click to expand...
Click to collapse
There's an easier workaround for that.
Provide instructions to:
- Copy required files to USB stick
- Download Ubuntu Live CD
- Boot from CD
- Run scripts
If you wanted to get fancy it could be prepackaged into an existing bootable CD distro with the scripts included (checking for updates when they're launched).
From what I've read, Desire owners used bootable CDs to root their phones, so it's obviously a viable option for the standard user.
Alright, that's the extent of my expertise. I'll leave you guys to sort out the real issues now!
I'm also very interested in this so subing myself to this thread.
I quite like the fact you Windows users have to use a Linux install to do it, I get a bit fed up having to find a Windows box somewhere to use Odin and Kies all the time.
RyanZA said:
Most users aren't gonna be up to installing linux in a VM to run the script!
Click to expand...
Click to collapse
Why? Surely the people wanting to do this kind of thing will be the more technical users anyway and us Linux users have to do the more difficult task of installing Windows in a VM to use the normal tools.
my ct-ng seems to be broken, my binaries doesn't execute on my SGS for some reason, so this will have to wait for tomorrow so I can investigate this further.
I need to compile the mkfs.ext3 staticly (which seems to compile fine using several different toolchains, but none works) so i can execute it from z4mod/updater-script.
dirk1978 said:
Why? Surely the people wanting to do this kind of thing will be the more technical users anyway and us Linux users have to do the more difficult task of installing Windows in a VM to use the normal tools.
Click to expand...
Click to collapse
Not true at all!
z4ziggy said:
my ct-ng seems to be broken, my binaries doesn't execute on my SGS for some reason, so this will have to wait for tomorrow so I can investigate this further.
I need to compile the mkfs.ext3 staticly (which seems to compile fine using several different toolchains, but none works) so i can execute it from z4mod/updater-script.
Click to expand...
Click to collapse
I've had so much trouble with statically compiling stuff...
We really need some kind of complete guide on all the ins and outs of statically compiling these system utilities. For a lot of them it doesnt seem to be all that straight forward...
i've a question
i've tried to mount the partitions as ext2/3 before by replacing the rfs in init.rc and recomplied the kernel and pack the zimage, but the system wont boot. it seems it wont accept any other fs other than rfs, rootfs, etc. my init.rc looks like this:
mount ext2 /dev/block/stl9 /system
so how did u simply mount them as ext3 by just changing the init.rc and recompile the kernel?
EDIT: sorry, i just tried it again and it's ok now, but not with the "||" (or) in the middle
Related
Hmm
sorry guys. by now, I'm going to stop fixing this, sigh, I'm not good enough to fix this at the moment.
Can not garantee you the safety of this method but hopefully, the fantastic voodoo lagfix is coming.
Let's hope to see it soon!
I'll leave the update.zip here, if anyone who is intersted in this method, feel free.
FILE LINK :
http://www.multiupload.com/DU013PW7LW
Hi
I have made an update.zip which fixes I9000's lag.
The idea is to format the /data partition, which is the same as /dev/block/mmcblk0p2, to the EXT4 or NILFS2 File Systems.
It's worth because, at least, we don't need an external MicroSD card.
### Before getting started... ###
This method can damage your phone, so you should know what you are attempting to do. All risks are on your own. Also, I strongly recommend you to have a nandroid backup.
### It contains... ###
- absolutely pure JM2 kernel but a tiny modification of the ramdisk. It's from JM2 firmware but should be working on every ECLAIR devices. This kernel helps mounting the data partition to be mounted in every booting and the reason why this is nearly identical to the stock is because some people mind using user-built kernels for some reasons.
- an application called "sl4a" which has shell scripts inside named "EXT4_Lagfix.sh", "NILFS2_Lagfix.sh" and "Openvpn.sh".
※It will install the kernel in the process of applying update.zip so you don't need the Odin.
### More information about this kernel... ###
- As I said, the only thing I've modified is the ramdisk. In details, I've put two files, user_init.sh and user_early_init.sh which are from Unhelpful's kernel, and these files are essential for mounting the /data partition.
- The kernel is almost pure, so it uses modules.
- The user_init.sh, user_early_init.sh support user scripts are very useful. You can see the idea in below thread, OP of Unhelpful.
http://forum.xda-developers.com/showthread.php?t=762171
### About the scripts... ###
- If you touch the EXT4_Lagfix.sh script or NILFS2_Lagfix.sh, it will ask you a superuser permission, back up the entire /data folder in your /sdcard directory, and finally, reboot and do the rest works automatically.
- You can go over to the other file system whenever you want, for instance, it can be changed to the nilfs2 while you are using the ext4 FS.
- There also is a script called Openvpn.sh which will insert tun.ko module and this is for the people who want to use openvpn.
### What you need to do is... ###
- Needs busybox installed and rooted
- Make enough space in /sdcard to make the backing up process work properly.
- In order to use NILFS2 FS, a bit of studying is needed.
About nilfs2 binaries and the Gabage Collector.
go to this site
http://www.nilfs.org/
### What I want to say is...###
- I'm not actually a goot developer so the scripts must be very messy. But it works well, at least with my device.
- Unfortunately, I haven't got the going-back-to-rfs script. I'm working on it recently so if you want to restore the all fixes, you need to flash the firmware.
- Quadrant scores : NILFS2 ~ around 1300
EXT4 ~ around 1700
Do you really concern about the score? I don't. The NILFS2 is exactly what I've needed.
### What I MUST say is... ###
- Big thanks to these people!
## Tayutama -- the beautiful sl4a application is from his rom!
## Unhelpful -- used his idea to mount the /data partition. And the NILFS2 as well!
## supercurio -- He's the one who found how to flash kernels from the phone!
Also, I uploaded some useful utils.
- mkyaffs2image / unyaffs
- chcp / lscp / lssu / mkcp / rmcp
Hope this will help you guys.
So what's different between this and the voodoo lagfix? Is the the partition? I know that voodoo ext4 is /dev/block/mmcblk0p4 while this one is /dev/block/mmcblk0p2
Nice dkcldark.
Will you share your method to unpack-repack the ramdisk from a stock kernel ?
Very nice! Great job!
NeoXTC said:
So what's different between this and the voodoo lagfix? Is the the partition? I know that voodoo ext4 is /dev/block/mmcblk0p4 while this one is /dev/block/mmcblk0p2
Click to expand...
Click to collapse
Oh, I've been busy so I couldn't have a look at the voodoo lagfix. I'm gonna check it. It could be the same as mine or much better
mmcblk0p2 is equal to /data partition, BTW.
supercurio said:
Nice dkcldark.
Will you share your method to unpack-repack the ramdisk from a stock kernel ?
Click to expand...
Click to collapse
Why not? To do this, I've done a bunch of experiments and it made me get older, I think. Will write a reply or a new thread very soon.
RyanZA said:
Very nice! Great job!
Click to expand...
Click to collapse
Thanks!!
dkcldark said:
Why not? To do this, I've done a bunch of experiments and it made me get older, I think. Will write a reply or a new thread very soon.
Click to expand...
Click to collapse
Yeah, theorically it's simple, we have the smallest piece of code building the kernel so why should extracting then reinserting the ramdisk difficult ?
And there comes the difference between the theory and the practice
Congrats for your research and the result, i hope your method can be applied to any kernel including a ramdisk!
This is a major breakthrough in our Opensource Toolbox.
So do you recommend NILFS or ext4 for phones with nand disk? Just reading up a bit on nilfs and seems to create lots of checkpoints? Is it good for nand disk to be writing that much?
I'm tempted to try this tonight
NeoXTC said:
So do you recommend NILFS or ext4 for phones with nand disk? Just reading up a bit on nilfs and seems to create lots of checkpoints? Is it good for nand disk to be writing that much?
I'm tempted to try this tonight
Click to expand...
Click to collapse
Personally, I recommend the NILFS2 File system. I've searched some infomations.
NILFS2 is log-structured File System and known that it's suitable for SSD which is based on nand flash. Normally, Flash has a limited read-write times but nilfs2 tries to write to the entire space equally, and has got the smallest removing interval so the NILFS2 file system makes SSD work very nice. And a great Wear-Leveling as well.
Click to expand...
Click to collapse
I'm not a good developer, as I already said on my post, so I'm not sure it'd also be nice for SGS but it sounds good to me. Actually, I'm using NILFS2 and it's bloody fast!
How difficult would this be to adapt to the Captivate variant of the Galaxy S?
dkcldark said:
Personally, I recommend the NILFS2 File system. I've searched some infomations.
I'm not a good developer, as I already said on my post, so I'm not sure it'd also be nice for SGS but it sounds good to me. Actually, I'm using NILFS2 and it's bloody fast!
Click to expand...
Click to collapse
on which firmware do u recommend to use it?
I'm actually on JM6 but tomorrow i want to try the JM7....
(Any battery drain? )
andars05 said:
How difficult would this be to adapt to the Captivate variant of the Galaxy S?
Click to expand...
Click to collapse
It's not difficult at all.
My kernel is originally from Unhelpful's idea so, people who use his kernel will easily be able to do it. All you need is just remove the zImage and redbend_ua files in the update.zip. Every kernel which supports Unhelpful's rules about /system/etc/init.d will be OK. Or, you can simply modifiy the scripts inside.
One more, if you use Unhelpful's kernel, you don't need the modules any more.
Narcissus85 said:
on which firmware do u recommend to use it?
I'm actually on JM6 but tomorrow i want to try the JM7....
(Any battery drain? )
Click to expand...
Click to collapse
Any firmware should be OK. I'm using JM2 at the moment but I'll try the JM7 as well. So as the result, I'm going to come up with JM7-based pure kernel, although I believe there won't be big differences between JM2 and JM7.
And the battery.. I'm sorry I haven't tested it yet since I've got 4 batteries. I'm not bothered by them lol.
dkcldark said:
It's not difficult at all.
My kernel is originally from Unhelpful's idea so, people who use his kernel will easily be able to do it. All you need is just remove the zImage and redbend_ua files in the update.zip. Every kernel which supports Unhelpful's rules about /system/etc/init.d will be OK. Or, you can simply modifiy the scripts inside.
One more, if you use Unhelpful's kernel, you don't need the modules any more.
Any firmware should be OK. I'm using JM2 at the moment but I'll try the JM7 as well. So as the result, I'm going to come up with JM7-based pure kernel, although I believe there won't be big differences between JM2 and JM7.
And the battery.. I'm sorry I haven't tested it yet since I've got 4 batteries. I'm not bothered by them lol.
Click to expand...
Click to collapse
4 batteries? ahah cool i'll test it tomorrow with my only one battery! :>
thanks for ur lagfix..
mmm just another question...my english isnt so good (i'm italian)....with this "I'm going to come up with JM7-based pure kernel, although I believe there won't be big differences between JM2 and JM7." do u mean that u are going to update ur lagfix with another kernel? so another version comes out soon?
thanks...
ivan
dkcldark said:
It's not difficult at all.
My kernel is originally from Unhelpful's idea so, people who use his kernel will easily be able to do it. All you need is just remove the zImage and redbend_ua files in the update.zip. Every kernel which supports Unhelpful's rules about /system/etc/init.d will be OK. Or, you can simply modifiy the scripts inside.
One more, if you use Unhelpful's kernel, you don't need the modules any more.
Click to expand...
Click to collapse
So, I should flash unhelpfuls kernel. I then next remove the zImage and redbend_ua files from the update.zip, install it, and then run the sl4a script?
Narcissus85 said:
4 batteries? ahah cool i'll test it tomorrow with my only one battery! :>
thanks for ur lagfix..
mmm just another question...my english isnt so good (i'm italian)....with this "I'm going to come up with JM7-based pure kernel, although I believe there won't be big differences between JM2 and JM7." do u mean that u are going to update ur lagfix with another kernel? so another version comes out soon?
thanks...
ivan
Click to expand...
Click to collapse
Yes, I am. Will Just come with a new kernel. Every else is the same.
andars05 said:
So, I should flash unhelpfuls kernel. I then next remove the zImage and redbend_ua files from the update.zip, install it, and then run the sl4a script?
Click to expand...
Click to collapse
In order to reuse after modifying the update.zip, you need to sign it again. If you want to use a plain kernel, I can make it which is not a big deal.
dkcldark said:
In order to reuse after modifying the update.zip, you need to sign it again. If you want to use a plain kernel, I can make it which is not a big deal.
Click to expand...
Click to collapse
That would be most helpful! Thanks for your work! I can't wait to test it out on my captivate
Edit:
I figured out how to resign the update.zip. I'm running the sl4a script now. I'll post the results shortly.
Edit 2:
It appears to back up the data partition, but upon reboot its still rfs.
You may want to make some other modifications I've since learn are needed. Specifically, the stock init will overwrite the MBR, removing any changes you've made to the partition table, and will then write some data to mmcblk0p2 if it does not find a valid RFS filesystem. You might not even see anything wrong at first, but with enough reboots, this will eventually corrupt your reformatted /data partition.
The edit I'm using will be in my next kernel release, and is very simple - open the init binary in a hex editor, find the string "/dev/block/mmcblk0" (make sure there's a NULL after the 0 so that it's not a substring of some longer string) and replace the "m" with a NULL. Init will then fail to rewrite the partition table (because it tries to open "/dev/block/", which is a directory). Then you simply need to change the partition table - you can use exactly the same region of the disk, you won't even need to reformat, just remove the existing partition 2 and make a new partition 3 or 4. Partitions 3 or 4 won't be checked by init on reboot.
Unhelpful said:
You may want to make some other modifications I've since learn are needed. Specifically, the stock init will overwrite the MBR, removing any changes you've made to the partition table, and will then write some data to mmcblk0p2 if it does not find a valid RFS filesystem. You might not even see anything wrong at first, but with enough reboots, this will eventually corrupt your reformatted /data partition.
The edit I'm using will be in my next kernel release, and is very simple - open the init binary in a hex editor, find the string "/dev/block/mmcblk0" (make sure there's a NULL after the 0 so that it's not a substring of some longer string) and replace the "m" with a NULL. Init will then fail to rewrite the partition table (because it tries to open "/dev/block/", which is a directory). Then you simply need to change the partition table - you can use exactly the same region of the disk, you won't even need to reformat, just remove the existing partition 2 and make a new partition 3 or 4. Partitions 3 or 4 won't be checked by init on reboot.
Click to expand...
Click to collapse
I really appreciate for this information!! Just wondering about one thing.
Should I replace the "m" to NULL once in "/dev/block/mmcblk0" or its friend "/dev/block/mmcblk0p2" as well?
Unhelpful said:
You may want to make some other modifications I've since learn are needed. Specifically, the stock init will overwrite the MBR, removing any changes you've made to the partition table, and will then write some data to mmcblk0p2 if it does not find a valid RFS filesystem. You might not even see anything wrong at first, but with enough reboots, this will eventually corrupt your reformatted /data partition.
The edit I'm using will be in my next kernel release, and is very simple - open the init binary in a hex editor, find the string "/dev/block/mmcblk0" (make sure there's a NULL after the 0 so that it's not a substring of some longer string) and replace the "m" with a NULL. Init will then fail to rewrite the partition table (because it tries to open "/dev/block/", which is a directory). Then you simply need to change the partition table - you can use exactly the same region of the disk, you won't even need to reformat, just remove the existing partition 2 and make a new partition 3 or 4. Partitions 3 or 4 won't be checked by init on reboot.
Click to expand...
Click to collapse
Yeah more like curios setup.
What needs to be done in order to adapt this to the Captivate?
I deleted the zImage and redbend_ua files and resigned the zip. I tried both of the lagfix scripts included and neither one worked. It backed up /data and rebooted. It doesn't reformat the fs, and it is still rfs. There doesn't appear to be a /system/etc/init.d directory. I'm running Unhelpful's kernel (v1.2).
I'm rooted and have busybox installed.
If only supercurio can adapt your method of editing the ramdisk inside the stock kernel, it would be awesome! As he already knows how to go back to rfs! We would then have a complete fix!
Development continues here: http://forum.xda-developers.com/showthread.php?t=881837
Universal lagfix kernel project.
This project is aimed at multiple audiences.
If you think you're an end user read on.
For lagfix and kernel developers check the second post.
Download, changelog, bugs and other links can be found at the third post.
Credits
ChainFire for the original cf-root initramfs
hardcore for the speedup hacks
nikademus for the compiled jfs utils
neldar for BackLightNotification
newmail for some kernel modules
RyanZA for OCLF and for being helpful
supercurio for Voodoo
ykk_five for being helpful (and for the memory tweaks)
z4ziggy for z4mod
and for everyone else I might have missed. (like myself - I'm an egoist you know... and for all the people that helped the guys I credited above. And for the people who helped the guys that helped the guys credited above. And for XDA of course.)
If you only care about points
OhmygodIcanget2kpointsatquadranttoobadI'vealreadysoldSGSbecauseitonlyhas300MBraminsteadof512asadvertisedandboughtadesirebecauseilikehowitcrapsatmultitouch.
For the rest of the people
What is this about?
This project has multiple aims:
A JPM based kernel with ext4, jfs, tun and BLN support
An init script which supports multiple lagfix schemes
Init.d support (without early script support)
A modified ClockWorkMod that
Has better support for some features of the SGS-I9000
Includes support for rooting the device
Includes support for switching the lagfix schemes
Has some tweaking options
Various additions that might help the other lagfix/kernel developers
How does this work?
Simply flash the kernel to any JPM/JP6 based, unlagfixed ROM. By default it won't apply any lagfix scheme, so you might use it as a simple ROM, with built in ClockworkMod + rooting support. If you have a complete ROM package (with dbdata.rfs and an older csc file (it won't work with some of the newer csc files) ) you can also flash it with the other parts, just replace the zImage in the PDA.tar with the one supplied. The ROM was tested with the original JP6 and JPM ROMs, and with my Multinational 3.0 ROM.
How can I use the extra features?
Reboot your phone to recovery mode. Under "Advanced ULK", there are some new options:
Reboot to download: switches to download mode
Run 2e recovery: Switches to 2e recovery
Install superuser: installs busybox and superuser to the phone
Lagfix options: switch between various lagfix schemes
Tweak options: switch between various startup tweaks
BLN options: Turns BackLightNotification on or off
Reset permissions: Resets permissions to the same state as init does
What are the lagfix schemes?
They are ways on how to format and bind the various filesystems. You can chose how you want to format the partitions (data,dbdata and cache), whether you want to use an extra loop device or not, and whether you want to bind some directories from /data to /dbdata.
There are also 8 included pre-defined schemes:
OCLF: /data stays at rfs, but has an ext2 loop device on top of it
Voodoo: /data is ext4, all others are kept at rfs
JFS Voodoo: /data is jfs, all others are still rfs
No-RFS Standard: /data is rfs+ext2, all other partitions are ext4
No-RFS Advanced: all partitions are ext4
No-RFS Advanced JFS: all partitions are jfs
No-RFS Overkill: turns on all options: everything is ext4+ext2 and /data/data is bound to /dbdata
No-RFS Overkill JFS: turns on all options: everything is jfs+ext2 and /data/data is bound to /dbdata
(If using the overkill scheme using the bind option is dangerous if using too much apps, so you should disable it in the advanced menu.)
Although I used the names OCLF and Voodoo, the ROM is not compatible with any of them, it's just a naming convention I used. Hope RyanZA and supercurio won't mind
Which one should I use?
You decide. OCLF or Voodoo might seem simple but they are actually working great (but for those you can actually use the originals, they are probably much more stable), while NO-RFS Overkill might seem cool, it is clearly an overkill.
What happens after I chose a lagfix scheme?
If the chosen one is different from the active one the kernel will reformat your device the next start. Before reformatting it will create a nandroid backup, reformats the device then restores the data from your backup.
Is this ROM safe
alpha 0.2 means no. Switching between lagfix schemes might break, and data loss (mostly database corruption) can happen if you're using a lot of loop devices. And this kernel isn't thorougly tested anyway.
How to switch to another kernel/ROM
After disabling the lagfix everything should be fine (except for the possible data corruption). You can always flash another complete ROM package over this using Odin, you'll lose all your data however.
I've found a bug
And you'll find more of them. I'll try to collect them and answers to them at post #3
Internal workings.
In this post I'll try to describe how this works, and how it might be useful for other people.
The Kernel uses both the pre-init trick and the bootlogos trick to load up, and do it's stuff. In the pre-init phase it does the following:
initializes the devices
checks the actual state of the partitions, and decides which lagfix scheme is active
checks the config (resides in /system/etc/lagfix.conf), and if they differ runs the converter application
if they don't differ then it starts to mount the devices, and let's init run.
if during the mounting a fatal error occurs, it prints the log, waits for a couple of seconds and reboots the device.
It does the filesystem checks by mounting and checking whether mounting succeded or not. To defend against samsung's init's reformatting, it simply removes the fat.format command.
In the post-init phase it removes some files (mainly the symlinks to busybox, so they won't interfere with the busybox installed on the system). It also reinstalls fat.format, because it might be needed later.
The lagfixer is built inside clockworkmod, which has the following advantages:
Can use nandroid backup
Can use the framebuffer to show the progress (this makes it much easier to debug problems)
Besides the lagfixer there is also a "graphsh" application, which will run a specified command and prints its output to the framebuffer (the reasons for this are the same: it's much easier to debug this way than to check a log file copied to the sdcard). If a fatal error occurs this command is run so the end-user can see some logs. (all of this is still pre-init). The only problem with using the framebuffer is that core android won't boot up properly if the framebuffer was initialized beforehand (it switches to QVGA with overlapped screens... it's actually quite fun to try using android that way). That's why I always reboot after using either 'graphsh' or 'lagfixer', except for recovery modes, because CWM is using the same framebuffer anyway.
The initramfs is "ro.debuggable=1" so if anything happens one can connect to the phone in adb root mode, to check for errors. Adb is enabled by default in both CWM and base android mode. I don't know the drawbacks of using debuggable=1.
CWM was modified in order to be able to handle the various lagfix schemes. If it tries to mount, unmount or format /data,/dbdata or /cache, it asks for the lagfixer to do the actual mount, unmount or format. Therefore if one saves or restores a backup it will always see and use the actual files, and not the loop device file.
There were some other minor modifications, like binding the home button too to the enter key, using /mnt/sdcard instead of /sdcard, and the ability to back up the efs partition too. (/efs won't be restored however).
There is also a small modification in how the updates work. If there is an update, the init will always run samsung's 2e recovery, if not it will use CWM (you can use CWM's menu to run an update using CWM if desired). This is to maximize compatibility with updates.
About the compiled files:
I had a hard time getting the binaries to work, even when compiling in static mode. All of the binaries are either compiled by me using bionic (AOSP), or used from other sources (but they seem to be using bionic too). The main advantage is that the recovery binary is actually only around 700k, but has a working busybox implementation, a working recovery and some other small stuff. The main problem is with the other binaries (mainly with e2fsprogs). If I could cut from the size the whole initramfs might fit into an official kernel, so it could be used by anyone.
Links
Da kernel 0.3 + BLN 2.2: http://forum.xda-developers.com/showpost.php?p=9157498&postcount=738
Da kernel 0.3: http://android.sztupy.hu/dl/Universal_lagfix_kernel_JPM_0.3.tar
Da kernel 0.2: http://android.sztupy.hu/dl/Universal_lagfix_kernel_JPM_0.2.tar
Da kernel 0.1: http://android.sztupy.hu/dl/Universal_lagfix_kernel_JPM_0.1.tar
Source of the modified CWM: http://github.com/sztupy/android_bootable_recovery
Source of vendor/samsung/galaxys: http://github.com/sztupy/android_vendor_samsung_galaxys
Kernel sources I'm using: http://github.com/sztupy/universal_lagfix_kernel
Bionic port of jfsutils: http://github.com/sztupy/android_external_jfsutils
The contents of the initramfs: http://github.com/sztupy/universal_lagfix_kernel_initramfs
Changelog
Version 0.3
- before the lagfix gets applied there are now multiple options to chose from:
-- backup+restore (the original way)
-- backup, but don't restore (this eventualy results in a factory reset)
-- no backup (this also results in a factory reset)
-- go to recovery mode (to debug)
-- erase config file (to get back to the old options)
- the screen glitch in the first screen is now gone (because the kernel got smaller)
- jfsutils are ported to bionic (takes less space)
- there is a new option that will do the same restore permissions run, as the init script does
- I also added a few fixes to the CWM fix_permissions script, although I don't tested them yet (so it might brick the phone)
- Added two more rooting option:
-- the old one simply copyes busybox, superuser and su to the phone and adds symlinks to busybox
-- the new ones will also remove some old toolbox commands, so if you use the shell a lot, they won't interfere. The first mode only removes the base utils, like ls,mkdir,rm or ln
-- the second mode removes every toolbox command that has an equivalent busybox command (like mount, lsmod, rmmod, etc.)
- Adeed an option to get back to 2e recovery from CWM
Remarks
It seems that formatting dbdata as rfs only works, if you use the 512 PIT file (more exacty it only works if you have used the 512 PIT file the last time you've ticked re-partition in odin). This is probably due to the fact thet the 512 and 803 pit files reserve different space for the dbdata and for the system partition (the 803 pit file reserves 40 units less for the dbdata than the 512 pit file)
Version 0.2
- efs is not backed up automatically during lagfixing (but it's still backed up during ordinary backups)
- added jfs support and some more lagfix schemes using jfs
- added backlightnotification support, with the option to turn it on and off
- added startup script tweaks support, with options to turn them on and off
- removed ext2 support for the base mounts (might be put back into later)
- bind now only binds /data/data (should use less space)
- some minor bugfixes relating
Remarks
- If Updating from 0.1 to 0.2: If binds were turned on you have to turn them off before updating. After the update has finished you can turn them back on if desired.
Known bugs
After the lagfix conversion is done the phone reboots and the lagfix conversion starts over again
This means that the conversion took place, but the result is not the same as was desired. You should reboot into recovery mode and remove the config file.
After rebooting I have a lot of FC's - After switching lagfix schemes I have a lot of FC's
This is probably because of a database corruption. Try loading an earllier backup.
Can't download anything from market
Some configurations might have this problem, I'm still trying to find out why this happens.
Can't download some apps, like angry birds from the market
Retry, it should work after a while. If it still fails remove the external sd.
Shutdown fails on some configurations
Until I find a way to hook onto the shutdown script this might happen on more complex configurations (like the NO-RFS overkill)
Can't get back to rfs on /dbdata
Reverting the lagfix on /dbdata only works if you used the 512 pit file the last time you checked re-partition in odin.
I for one am excited
Dan
Can't wait to see this.
I am waiting too ++++
Lol 100% teasing ^^
gingerbread?
shahadat said:
gingerbread?
Click to expand...
Click to collapse
would be a bit early
Fantastic
Testing now on a very stripped JP6...
very interresting i think i will give it a try hehehe
any feedback?
Would it be unsavory to say that I got a little motion in my pants after reading that first post?
Nah, I think we all did
Sounds great! And I'll wait for a few more version points on that alpha before I try it... but I'm tempted!
wonderful,i'll try it
Sztupy is this kernel and method usable with your multilingual rom v3.0?
Thanks
kurudisease said:
Sztupy is this kernel and method usable with your multilingual rom v3.0?
Thanks
Click to expand...
Click to collapse
check first post. Tested with JPM, JP6 and Multinational 3.0
Test drive
I just used it, I had no issue. Everything worked fine and there is no lag at all, still too soon to say it's faster than voodoo though(which I was very happy with). All data is still there and no problem! Im using JP6 with NO-RFS Extended. Quadrant score is ~1900 for anyone that want to know .
looks great! gonna try this
ist it possible to add in that also??
Startup script speed tweaks
http://forum.xda-developers.com/showthread.php?t=813309
I applied the no-rfs advanced fix and everything worked fine. No issues so far.
Thanks!
****** Information *****
I will no longer develop this kernel, for the lack of development on Z4Mod source.
If you like my work you can try this kernels:
DamianGTO Ultimate Kernel
DamianGTO Steam Kernel
You can also try my tweak program:
Damian tweak
I will continue to support this tread so long its needed.
If you want to change kernel you MUST remove all lagfix first.
*****************************************
The kernels I will post here is now based with Samsungs JPX source code.
The Froyo version is 2.2.1. in this source code.
This make a big change in performance on the samsung Galaxy S.
All this kernel I make will have Zmod in them so you can use Zmod app to convert the file system to ext2.
This will make the phone lagfree and the tweak I put in these kernels will improve things and add things that not supported in stock firmware.
The first kernels I have made(DamianGTO_JPX_1A) have this:
345MB Ram.
Optimized kernel tweaks
Alter minfree strict settings.
Deadline schedueler
Support for bootanimation.zip (custom boot animation)
Initramfs from JPY kernel( So it works on all new firmware)
The kernels has two versions. 256HZ and 500HZ versions.
File system:
Ext2
Rfs
The second kernel I have made(DamianGTO_JPX_2B) have this:
346MB Ram.
300HZ
Optimized kernel tweaks.
Cleaned the kernel from unused services.
Alter minfree strict settings.
Deadline schedueler( change some settings to balance it more)
Support for bootanimation.zip (custom boot animation)
Initramfs from JPY kernel( So it works on all new firmware)
File system:
Ext2
Rfs
This kernels is also an app so you can install it without ODIN.
Make sure you are rooted and you have Busybox 1.17 installed.
Always have a backup when you install other kernels if something happens that I cant predict.
If you come from other kernels then these kernels make sure you have flashed original kernel first so you know your phone is okey.
Do to restriction on file size I cant upload it here.
So I put it on freedrive. I hope it will work.
If any have a better way to do it for free i will look into that.
DamianGTO_JPX_1A.apk is the app with both 256HZ and 500HZ kernels.
DamianGTO_JPX_2B.apk is the app with 256Hz, 300Hz and 500Hz kernels.
I will put all kernels and program on my freedrive that i will make now.
All kernels and program I make from now I will put them on my Freedrive.
Downloading from there is easy. Works both on the computer or your phone.
************** OLD NEWS ***************
The base for these kernels is samsungs jpm source file.
So its NOT based on sztupy setup/kernel.
This kernel is NOT affected by the corruption bug that Supercurio did find.
The goal is to have a clean kernel so you can use z4mod app and change the file system. It will also have some tweaks thats useful for all.
It will always be close to stock kernel, so it will be an option to stock kernel.
If you want more tweak and other stuff there is allot of other kernels.
I will make different kernels with different things in them when I do have time to test them out and be sure they are good and stable.
Z4mod has changed they way to do things and I drop old kernels and use the new way.
I also drop all support for different file system.
Ext2 is a fast file system and its stable.
Most of the other file system use to much overhead and is slower or instable.
This make the kernel smaller to
To root the phone use Z4Root(included below)
To change file system use z4mod(included below)
If you have an old kernel from me and you want to upgrade you must
convert back to rtf first.
If you come from an other custom kernel undo all tweaks and lagfix.
Do also flash an original kernel to see your phone will boot up and work.
After that you can flash one of these kernels.
All zImage_z4mod kernels has this:
342MB Ram tweak.
Optimized kernel tweaks.
Hash 3.
File system:
Ext2
Rfs
The different in the zImage_z4mod kernels is the HZ value.
Lower HZ value can make the phone to drain battery less, but can make the phone less responsive.
Higher HZ value can make the phone drain battery more, but can make the phone more responsive.
DamianGTO_v3 kernel has this:
342MB Ram tweak.
Optimized kernel tweaks(more).
Hash 3.
Alter minfree strict settings.
I/O scheduler is deadline.
Support for bootanimation.zip (custom boot animation)
File system:
Ext2
Rfs
To use custom boot animations you need to download a bootanimation.zip and put that in your data/local folder.
you can find bootanimation.zip on this site or you can go to market and look for a program that help you with that.
If you don't want to use the bootanimation.zip you just remove it from the folder and the original boot animation will be used.
I also made a custom kernel for JPU firmware(DamianGTO_JPU_v1).
This IS JPU kernel with tweaks. Its NOT based on the old JPM kernel.
If you need to root you must use this SuperOneClick root.
This JPU kernel is also patched with Z4mod.
But you need to install the latest busybox from market if you want to convert to EXT2 file system.
This kernel also support boot animations.
DamianGTO_JPU_v1 kernel has this:
339MB Ram.
Optimized kernel tweaks(more).
Alter minfree strict settings.
Support for bootanimation.zip (custom boot animation)
File system:
Ext2
Rfs
DamianGTO_JPU_v2 kernel has this:
If you downloaded this then download V1 or V3. V2 dont work right.
DamianGTO_JPU_v3 kernel has this:
339MB Ram.
Optimized kernel tweaks(more).
Alter minfree strict settings.
Deadline schedueler.
Support for bootanimation.zip (custom boot animation)
Sdcard fix when mounting it in windows so you can write to it. It will not mount like a CD anymore
File system:
Ext2
Rfs
I have made an app for the DamianGTO_JPU_V4 kernel.
This will flash the kernel WITHOUT odin
Just make sure you are rooted before you use it.
Is you dont get superuser access, restart you phone and make sure you are rooted.
This DamianGTO_JPU_V4 kernel is little more tweak on deadline scheduler.
So it should be smother.
This kernel has:
339MB Ram.
Optimized kernel tweaks(more).
Alter minfree strict settings.
Deadline schedueler(More tweak).
Support for bootanimation.zip (custom boot animation)
Sdcard fix when mounting it in windows so you can write to it. It will not mount like a CD anymore
File system:
Ext2
Rfs
I have made an app for the DamianGTO_JPY_V1 kernel.
This DamianGTO_JPY_V1 kernel has:
339MB Ram.
Optimized kernel tweaks(more).
Alter minfree strict settings.
Deadline schedueler
Support for bootanimation.zip (custom boot animation)
File system:
Ext2
Rfs
z4root-1.3.0.apk is to root the phone. use that before you convert the file system.(NEW)
z4mod.0.9.3.apk is to convert file system.
zImage_z4mod_12_01_v1_500hz.zip Is the kernel with 500HZ value.
DamianGTO_v3_300hz.zip is the kernel with bootanimation and 300hz value.
DamianGTO_JPU_v1.zip is the JPU kernel with bootanimation and some tweaks.
DamianGTO_JPU_v3.zip is the JPU kernel with bootanimation, tweaks and usb storage fix.
DamianGTO_JPU_V4.apk is the new kernel with a installer.
DamianGTO_JPY_V1.apk is the new kernel with a installer.
Thanks all that has helped me to sort out problems.
Before you try this kernel out, make sure you have a backup on you system.
How to Install it? =)
borjaag said:
How to Install it? =)
Click to expand...
Click to collapse
Use Odin to flash the kernel. Use only PDA. no pit file and no re-pertion.
Then copy the update file to the sdcard. rename it to update.zip.
Start the phone in recoverymode and applay the update file.
Before do a backup and read about this things if you dont know what it is.
Edit: this was the old way, so read the first post.
why no EXT4?! Thanks.
hacksome said:
why no EXT4?! Thanks.
Click to expand...
Click to collapse
I think ext2 do work better and its faster then ext4.
I can compile a version with ext4 for you if you want that.
I will make support for most filsystem in the new z4mod system when it works good.
Sent from GT-I9000 jpm My own kernel for z4mod and with 341MB Ram
DamianGto said:
I think ext2 do work better and its faster then ext4.
I can compile a version with ext4 for you if you want that.
I will make support for most filsystem in the new z4mod system when it works good.
Sent from GT-I9000 jpm My own kernel for z4mod and with 341MB Ram
Click to expand...
Click to collapse
z4mod should work 100% with EXT2/EXT3/EXT4/JFS filesystems already, as long as support is compiled into the kernel.
So if you use a kernel with support, it should just work.
RyanZA said:
z4mod should work 100% with EXT2/EXT3/EXT4/JFS filesystems already, as long as support is compiled into the kernel.
So if you use a kernel with support, it should just work.
Click to expand...
Click to collapse
True. But i did not enable more support;-)
My point is that the new system is out and i have to make that work.
I have seen a couple of error on that. So i wait to realese that version. Z4ziggy is looking into the errors.
But i did this kernel and using it myself right now and it works great.
Ofcorce i want the new system to work. I spend my time to figure out what's wrong, but i guess i/we will solve that soon.
Sent from GT-I9000 jpm My own kernel for z4mod and with 341MB Ram
Thx for ur great work .
Just flashed it and it seems to work great. Before that I used a normal JPM Kernel with z4mod EXT2 without any kernel tweaks
DamianGto said:
I think ext2 do work better and its faster then ext4.
I can compile a version with ext4 for you if you want that.
Click to expand...
Click to collapse
Thanks!. I am trying out ext2 and it doesn't seem bad
Thanks.
I shall try to get it better and with more system support.
Sent from my GT-I9000 using XDA App
I would like a JPA kernel with ext4 on on all partitions also system. Thanks.
Sent from my GT-I9000 using XDA App
DamianGto said:
The goal is to have a clean kernel so you can use z4mod and use the filesystem you want.
Click to expand...
Click to collapse
Is anyone trying YAFFS/YAFFS2? As far as I know it would outperform EXT4...?
mclad said:
Is anyone trying YAFFS/YAFFS2? As far as I know it would outperform EXT4...?
Click to expand...
Click to collapse
Have not seen anybody use it.
Ext4 is not the fastest system either.
Its safe and better then stock system.
Sent from my GT-I9000 using XDA App
mclad said:
Is anyone trying YAFFS/YAFFS2? As far as I know it would outperform EXT4...?
Click to expand...
Click to collapse
YAFFS2 can't be used on /data since no interface is available. Doesn't seem like it can be done on BML either, because they're a bit freaky. (It probably can be done, I have no idea how you would though, they're non-standard.)
There is no real need though, as YAFFS2 is NOT a fast filesystem. It's filesystem designed to be safe for the underlying media, and performs decently, but it's not EXT2/HFS+/UFS speed. I think. It's hard to test since it is difficult (impossible maybe?) to port.
At any rate, since /data accounts for 99% of disk I/O, it's mostly waste of time...
As to converting over other partitions besides /data, the problem is that stock clockworkmod doesn't detect it then. Going to try work on making a 'smart' clockworkmod that can detect and mount the correct filesystems.
I' am happy with EXT2, its the most fast one and not really unsave. But would be great to have it on all partitions. Or just EXT2 on /data (for speed) and EXT4 on the other partitions
I may be (probably am) WAAAAAY out of my depth here, but you might want to grab sztupy's modified CWM - the one he uses for his ULK. I believe that would achieve the results you desire.
I think...
RyanZA said:
As to converting over other partitions besides /data, the problem is that stock clockworkmod doesn't detect it then. Going to try work on making a 'smart' clockworkmod that can detect and mount the correct filesystems.
Click to expand...
Click to collapse
Well, I will be short on this one:
Ext2 is NOT a good choice, why? No counselling, so in case of a crash, the chance of filesystem is just too big. Certainly since there is no filesystem checking utility... So this IS faster but very dangerous.
Jaffs or any other flash filesystem is a bad idea too, why? Sd does wear levelling in itself, double it and you will not benefit at all. So totally useless. More on this... On google
Sent from my GT-I9000 using XDA App
harrydg said:
Well, I will be short on this one:
Ext2 is NOT a good choice, why? No counselling, so in case of a crash, the chance of filesystem is just too big. Certainly since there is no filesystem checking utility... So this IS faster but very dangerous.
Jaffs or any other flash filesystem is a bad idea too, why? Sd does wear levelling in itself, double it and you will not benefit at all. So totally useless. More on this... On google
Sent from my GT-I9000 using XDA App
Click to expand...
Click to collapse
That is all very theoretical, but in practical usage of EXT2 on my day to day device for months now, I have not had any issues. And this is with deliberately pulling out the battery to try and break it.
The huge need for journaling on spinning media comes from just how unsafe spinning media can be. Flash storage is inherently a lot safer, since it writes in large chunks controlled by the disk controller, rather than playing with magnets. Not to say that it's 100% safe - and no filesystem is 100% safe when crashed - but it's really not a big issue in practice. The speed benefit makes up for any theoretical data safety issues many many times over for me, personally (and there really is a large speed benefit).
Also, e2fsck appears to do a decent job at checking for errors/metadata consistency.
Ahm,
Not really, journals are used to make writes safer, if you interrupt a write, your filesystem will be inconsistent, so you could loose your entire disk. But you are right, it's not as bad as with spinning disks, but I would never recommend it as safe... There is a reason that ext3 and 4 have been developed as successor..
Ps. Sent by my phone so my responses are short..
Sent from my GT-I9000 using XDA App
harrydg said:
Ahm,
Not really, journals are used to make writes safer, if you interrupt a write, your filesystem will be inconsistent, so you could loose your entire disk. But you are right, it's not as bad as with spinning disks, but I would never recommend it as safe... There is a reason that ext3 and 4 have been developed as successor..
Ps. Sent by my phone so my responses are short..
Sent from my GT-I9000 using XDA App
Click to expand...
Click to collapse
Not really. Journals are just additional metadata such as 'I am about to write to block X' 'I have finished writing to block X', etc. When the system crashes, this helps the system recover and work out what it was busy doing - it's not a silver bullet that magically stops data loss. If a file was being resized, then without journals the metadata would show that the file had been resized - even though the data inside would be garbage as it wasn't written yet. In the journaled case, it's possible to tell that this has happened, and the file can be deleted instead.
So with journaling you'd end up with the old file, and without you'd end up with a corrupt file. In either case, try not to crash your system, since an out of date file can be bad too (but not as bad as a corrupt one).
At any rate, the actual chances of managing to hit the power at just the right time (between a metadata entry and actual file entry) is VERY slim on the SGS, because the MoviNAND has a capacitor backed operation queue which generally prevents this from happening in many cases.
If dev is interested in migrating to this FS, Here is a kernel with UBIFS support, I have disabled ext3 since it don't fit the kernel but you can use ext2 with it. If we get full UBIFS support then I can disable yaffs.
i tried it several month ago but i did not manage to format the nand with that fs...
i tried in this way:
flash on nand
install data and system on sd (so i have free access to nand partitions)
try to format but i get errors...
(i'm sorry but i don't have the file and the logs anymore)
I also tried a few months ago, compiling the kernel with UBIFS support was the easy bit, it was altering the initrd as L1q1d has said which caused problems. I couldn't get the NAND partitions formatted so that android would boot for some reason. I gave up on it in the end because i didn't have the time to spend on it and still don't unfortunately. It does look like a promising file system though so if you can get it working Clemsyn, fair play to you The other thing was for it to work properly it needed the UBIFS tools package compiled into the kernel or included in the initrd which made the file size too large.
I've tested this and it works. I only have a class 2 SDcard, so my testing shows it's really slow, a faster card would probably help.
With just this class 2 SD card, the boot-from-sd process is really only useful to see if the ROM being tested will straight-up brick your device or not.
Edit!
A class 6 card works fabulous! I'm posting from a tweaked version of mmarz's port of ath3nos' port of cm7 running from my brand-new class 6 card right now.
This process is hacked together from multiple other devices' howtos here on xda, sorry I don't know who to credit for the bits and parts. All of it is pretty generic, actually, and might well be applicable to other devices when tried as a whole.
For the moment, I'm only posting a brief skeleton how-to without specific walkthroughs for the steps, and I don't really want to upload many files until more of the bugs are swatted.
The following info should be enough for you, the savvy dev, to put the ROM of your choice on your SD card and boot it (or watch it fail to boot) without risk of bricking your device!
noobs, don't you dare, bricking is always a risk if you don't know your way around fastboot and adb!
Of course, savvy dev or not, a fresh nandroid backup is MANDATORY before hacking at your phone like this.
Standard disclaimer:
There is always a possibility of bricking your phone when messing with adb and fastboot.
If you're not willing to take that risk, don't try this at home (or at work, or school....)
Here goes:
The basic plan I followed was:
1) make and format 3 extra ext2 partitions after the default fat32 on the SD card, in this order: data (at least 180Mb) , system (170Mb to match stock), and cache (102Mb stock).
2) split up the boot.img from your chosen ROM so you can mod the ramdisk.
edit: turns out this next step in the quote is not required, there is an easier way.
A nifty command called devwait for init.rc
3) compile a modified init, adding a "pause (5);" after the ANDROID text. It goes on line 569 in the gingerbread init.c from a recent repo of google source.
use the newly compiled init in place of the init from the ramdisk.
since getting the android source uses so much time and bandwidth, I'm being nice and attaching a modified gingerbread init. If you test it with a froyo ROM and it doesn't work, don't blame me. If it does work with froyo ROMS, let me know!
Click to expand...
Click to collapse
3) change your init.rc from the ramdisk as follows:
replace the "mount yaffs2 [email protected] /system" , cache, and data lines with
Code:
devwait /dev/block/mmcblk0p3
mount ext2 /dev/block/mmcblk0p3 /system nodev noatime nodiratime
mount ext2 /dev/block/mmcblk0p3 /system nodev noatime nodiratime ro
devwait /dev/block/mmcblk0p2
mount ext2 /dev/block/mmcblk0p2 /data nodev nosuid noatime nodiratime
devwait /dev/block/mmcblk0p4
mount ext2 /dev/block/mmcblk0p4 /cache nodev nosuid noatime nodiratime
be sure to comment out any other mounts which go to /system anywhere, like the "mount squashfs [email protected]/system/blahblah/blah.sqf /blah/blah" lines in the aospCmod init.rc
4) repack your boot.img, with the correct cmdline ("mem=477M console=ttyMSM2,115200n8 androidboot.hardware=thunderc" works,) etc.
5) prepare the ext2 /system partition with your target ROM /system files.
How to load the ROM:
steps a) to f) done on your PC. step g) is done on the phone.
a) Unzip the ROM on your PC, to get at the files to copy to the new /system directory in adb, and allow you to modify the updater-script.
b) Mod that ./META-INF/com/google/android/updater-script as follows:
As an example, I removed the following from the aospCmodOV-5-16-11 updater-script:
everything except the "ui_print" "symlink" and "set_perm" lines, including the "unmount" line at the end of the script.
I thinned it down because the update-binary wants to write to MTD partition for /system, and I didn't want or need that to happen.
I did need it to install the symlinks and permissions, though.
Without those, the keyboards kept FCing, and the phone couldn't connect to the network.
c) rezip the ROM with the modified updater-script.
d) boot phone into recovery and connect to PC with cable.
e) adb push or otherwise copy the modified ROM.zip to your sdcard.
f) next, copy /system from the unzipped ROM to the new partition with adb
Code:
adb shell
mount -t ext2 /dev/block/mmcblk0p3 /system
exit
adb push /path/to/unzipped/ROM/system /system
g) on phone, in recovery: install .zip from sdcard
select the new ROM.zip you reassembled and pushed to the SD card
select yes, you really want to install the .zip
this should write the /system symlinks and permissions to the new /system partition.
Click to expand...
Click to collapse
6) back on your PC, still connected to phone with cable in recovery;
Code:
adb reboot bootloader
fastboot boot /path/to/boot.img
Step 6 is important!
this will boot from your modified boot.img without actually flashing it into the phone's NAND, so a reboot (or restart after battery pull in case of issues) just goes to your regular installed ROM in the phone.
That's about it for now. It's pretty much a hack as yet, but it's cool in a geeky way to be able to do this.
<reserved for future use>
Thanks! This should be very helpful to devs and those of us who are adventurous with our phones!
Very interesting concept, I'd love to see how many uses this could have!
bump...
with a class 6 card, ath3nos/blarf cm7 runs great off sd.
even feels a little snappier than running from the phone mtd partitions.
I must benchmark soon to verify.
I'm really surprised no-one seems interested, I guess this is too old-hat, like a debian chroot
bigsupersquid said:
bump...
with a class 6 card, ath3nos/blarf cm7 runs great off sd.
even feels a little snappier than running from the phone mtd partitions.
I must benchmark soon to verify.
I'm really surprised no-one seems interested, I guess this is too old-hat, like a debian chroot
Click to expand...
Click to collapse
This is good work, but I think people require a bit more hand holding. How about publishing some of the modded files?
I personally still have problems recompiling a ramdisk.
mmarz said:
This is good work, but I think people require a bit more hand holding. How about publishing some of the modded files?
Click to expand...
Click to collapse
I can post files one rom at a time, because the ramdisk and kernel will be a bit different for each rom, and so will the permission/symlink updater-script.
first, I'll have to get rom-dev permission, because they get modded, and also cause it's nice to have permission.
I personally still have problems recompiling a ramdisk.
Click to expand...
Click to collapse
fastboot provides a fantastic shortcut for that, if you cpio-gzip the ramdisk together after editing it to your specs
from http://android-dls.com/wiki/index.php
in a command line linux shell, from the directory containing your unpacked ramdisk,
Code:
find . | cpio -o -H newc | gzip > ../newramdisk.cpio.gz
will put newramdisk.cpio.gz in the directory above the one containing your ramdisk
Click to expand...
Click to collapse
fastboot can make the boot.img for you and either dump it into the phone (assuming your shell current directory contains your kernel (zImage) and ramdisk (newramdisk.cpio.gz))
Code:
fastboot -c "mem=477M console=ttyMSM2,115200n8 androidboot.hardware=thunderc" flash:raw boot zImage newramdisk.cpio.gz
or boot your phone from the assembled image without actually flashing it in.
Code:
fastboot -c "mem=477M console=ttyMSM2,115200n8 androidboot.hardware=thunderc" boot zImage newramdisk.cpio.gz
those fastboot lines assume an optimus v (or s.)
looking at all the great work you've posted on the forums, I'm surprised you have trouble handling anything to do with these phones!
I'm slowly working up to a modded recovery to install-to-sd directly and avoid all this hacking.
Nice, thanks for that. I had no idea fastboot could do that.
mmarz said:
Nice, thanks for that. I had no idea fastboot could do that.
Click to expand...
Click to collapse
happy to share.
I only learned fastboot could do that when I seriously started in kernel testing after finally getting one to compile without errors. I didn't feel like bricking my phone to test the fresh kernel, and researching fastboot showed me its capabilities... I could've just typed fastboot with no arguments and that makes it list its parameters.
it's really helpful for this mod, because you can just reboot into your stock rom without having to reflash anything.
plus it's nice to just tweak the ramdisk and let fastboot do the work making a new boot.img for you when testing weird stuff like this.
bigsupersquid said:
happy to share.
I only learned fastboot could do that when I seriously started in kernel testing after finally getting one to compile without errors. I didn't feel like bricking my phone to test the fresh kernel, and researching fastboot showed me its capabilities... I could've just typed fastboot with no arguments and that makes it list its parameters.
it's really helpful for this mod, because you can just reboot into your stock rom without having to reflash anything.
plus it's nice to just tweak the ramdisk and let fastboot do the work making a new boot.img for you when testing weird stuff like this.
Click to expand...
Click to collapse
Very cool i loved this idea when it was executed in a way over at Ubuntdroid for the intercept when i was doing alpha testing. Very convenient for many of the scarier tests when i wanted to keep my existing system intact. The big difference was that on the intercept the bootable partitions were written into the kernel. Downside you couldn't use it to test kernels but could switch kernels from the phone and flip-flop between completely isolated systems on the go without a computer. Which was great when i wanted to test a new ROM on the way to work but i needed my phone when i got there and had to have a painless method of switching to my usual running system. So i'd flash a "non SD" kernel and i was back up and running in just a minute or so.
I'm excited to play with this when i have some free time.
Thanks dude!
you could easily use an update.zip for each of the sd-boot and regular phone boot.img files and swap between working systems with those in recovery.
before getting the fast sd card, I was looking at this more as for testing foreign roms than two-system operation, but now I see that would work too.
for a second-system option I was looking at a market-enabled rom on sd since I don't use g-apps on my daily driver.
note: the GB rom I'm running on won't 'see' a card with more than four partitions properly, and won't mount the vfat partition with vold, although you can manually mount and access the first four partitions including the vfat. android just won't admit it's there. and I couldn't get at a fifth partition through the phone os, even though my pc could see it fine (to get 5 partitions I had to use an extended partition to contain most of the virtual partitions)
android could read virtual partitions in an extended partition just fine as long as the total number on the card didn't exceed four.
I learned a neat trick today.
going through the init.rc from the stock rom, I noticed a section at the beginning which was labeled 'on emmc' which would imply running from a card if the device hardware lacked nand flash memory.
I'd read on xda while researching this concept of boot-from-sd about an unspecified wait-for-device command in init.rc, but most of the info I've gotten on init scripting language has come from picking apart init scripts, as google has not documented the available commands very well.
long story short, I tried using devwait with the regular init and it worked just fine to mount the ext partitions. yay!
first post edited to reflect the improved method.
I've also been testing a recovery mod. if recovery.fstab is modified in the recovery ramdisk (or a fakeflash recovery) then the recovery will copy a tweaked rom.zip to the ext /system partition with some minimal modifications to the updater-script and a few commands in the adb shell.
the recovery with the modded recovery.fstab can also back up from and restore to the sdcard ext /data and /system partitions.
I will update the first post with more specific instructions as I hammer them into something consistent.
soon I'll be ready to release a modded fakeflash recovery to make experimentation easier, as well.