Develop Bugs

[stopped] by formatting the internal /data partition

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!

Kaiser Kernel Thread - ONLY FOR KERNEL AND BUGS

I start this new thread because i want highlight only kaiser changes
Before posting use search button and look in this thread.
This is the kernel thread so all problem like "how to install","i can't install", "miss module", ecc ecc are not allowed. If you need to ask this probably you didn't read correctly the guide in atools.
Atools is multyplatform and need python.
2.6.32 kernel changelog
nand fixed
irq problem is now fixed
TODO:
finish battery support
rewrite camera driver
speed up gps
Latest releases are here
Atools thread

Maybe now kernel development will be a little easier to keep track of. I had a random freeze in the kernel before with a message i've never seen before. Didn't think about exporting the logs. I will upload if I see it again.
It was with the 11-29 .32 kernel and only happened after I just switched to it, installed my barebones build and rebooted for the 1st time. I have never seen it since so it could have been an anomaly. Like I said, it was an error I have never seen before and will catch a log if I ever see it again.

It would be helpful if someone could make a list of which types of problem are kernel related, which are build related and which could be either.
I am fairly new to android and not at all clear on what does what .

I belive it's kind of dificult to explain properly whats a kernel bug, and whats a build bug. At least with a few lines of text anyway...
We probably will have to deal with _no_kernel_related_ questions, but we must stick to the topic. If it's not kernel related, point to another thread. Or perhaps instruct to open a new one.
Also, it would be nice to have this stickied again, and if those asking questions would be so nice to inform about device ; kernel version+builddate ; type of instalation (nand VS sd img file VS sd partion VS whatever) ; radio, it would probably make it easier to understand why is the user facing issues.
IMHO of course

Ipv6 support in kernel
Hi Liquid,
Could you please include ipv6 support in kernel? It's needed by some apps, like google goggles, i compiled my own kernel with ipv6 and worked fine.
I hope there is enough kernel space to include ipv6 in the current kernel version
thanks

i try to compile a ipv6 6 month ago but i have some problems with wlan.
I change some part so i'm going to do new test on it

Question, not directly kernel related, but must start here.
If data using Yaffs is so unstable... why not another FS ?

I noticed that 2.6.25 kernel doesn't mount the partitions on relatime. Is there any chance we could do the same for 2.6.32 (which defaults to relatime). In 2.6.32, I tried to put it to atime but it doesn't work and just defaults to relatime. Could this possibly be the reason we have an unstable data partition in 2.6.32?

clemsyn said:
I noticed that 2.6.25 kernel doesn't mount the partitions on relatime. Is there any chance we could do the same for 2.6.32 (which defaults to relatime). In 2.6.32, I tried to put it to atime but it doesn't work and just defaults to relatime. Could this possibly be the reason we have an unstable data partition in 2.6.32?
Click to expand...
Click to collapse
Could you point me where are the partitions mounted ? normaly i would search /etc/fstab, but i fearin droid they're mounted elsewhere.
One thing i found in kerneltrap is nice...
"It's also perhaps the most stupid Unix design idea of all times. Unix is really nice and well done, but think about this a bit: 'For every file that is read from the disk, lets do a ... write to the disk! And, for every file that is already cached and which we read from the cache ... do a write to the disk!'"
Click to expand...
Click to collapse
This is explaining why relatime is better than atime. But if we could force a write to the disk on every access...

daedric said:
Could you point me where are the partitions mounted ? normaly i would search /etc/fstab, but i fearin droid they're mounted elsewhere.
One thing i found in kerneltrap is nice...
This is explaining why relatime is better than atime. But if we could force a write to the disk on every access...
Click to expand...
Click to collapse
its on /system/bin/userinit.sh

clemsyn said:
its on /system/bin/userinit.sh
Click to expand...
Click to collapse
You sure ? i only find a remount there ... to fix su

Has anyone recently synchronized our yaffs2 tree with the main one on www.yaffs.net? I noticed there are quite a few differences. I'm testing, too soon to tell if there are any notable differences.

I think scooter synchronised it a little over a month ago? I know its been about that long.

daedric said:
You sure ? i only find a remount there ... to fix su
Click to expand...
Click to collapse
you can add this to userinit.sh
busybox mount -o remount,rw,nouid,nodiratime,nodev /data
I think it depends on the rom but my ROM have those options. I'll upload my userinit.sh
Here is a copy of my userinit.sh
BTW, I added noatime on 2.6.25 kernel (which is suppose to be stable) and I got a Reboot and data corruption. I think if we mount 2.6.32 like 2.6.25's default mount, it could be better but it has to be done in the kernel itself coz 2.6.32 defaults to relatime.

aceoyame said:
I think scooter synchronised it a little over a month ago? I know its been about that long.
Click to expand...
Click to collapse
I synchronized my yaffs sources yesterday. It survived several battery-pulls yesterday with no corruption, but one single clean shutdown modified email settings for one account and made Maps FC. A dalvik clear cured maps but not the email settings.
Yaffs has data recovery capabilities, as proven by the battery pulls that gave no corruption at all.
So i think yaffs is good and nand is good. The data corruption problem lies outside the kernel and is a subject for a different thread.
Sent from my Android on HTC Kaiser/Kaiser/Polaris using XDA App

n2rjt said:
I synchronized my yaffs sources yesterday. It survived several battery-pulls yesterday with no corruption, but one single clean shutdown modified email settings for one account and made Maps FC. A dalvik clear cured maps but not the email settings.
Yaffs has data recovery capabilities, as proven by the battery pulls that gave no corruption at all.
So i think yaffs is good and nand is good. The data corruption problem lies outside the kernel and is a subject for a different thread.
Sent from my Android on HTC Kaiser/Kaiser/Polaris using XDA App
Click to expand...
Click to collapse
I read this quote about atime since you had problems with email on reboot
1. atime – This option causes Linux to record the last (or latest) time when a particular file was accessed. This information is particularly helpful for sysadmins or some programs (specially mail programs) to know when a particular file was last used/accessed.
So I think here is were atime option would help (email programs)

clemsyn said:
I read this quote about atime since you had problems with email on reboot
1. atime – This option causes Linux to record the last (or latest) time when a particular file was accessed. This information is particularly helpful for sysadmins or some programs (specially mail programs) to know when a particular file was last used/accessed.
So I think here is were atime option would help (email programs)
Click to expand...
Click to collapse
I think you're confused... the e-mail problem n2rjt was having was complete random. He had problems in e-mail and maps.. could be browser and settings. It's random.
Now:
1. atime – This option causes Linux to record the last (or latest) time when a particular file was accessed. This information is particularly helpful for sysadmins or some programs (specially mail programs) to know when a particular file was last used/accessed.
2. noatime – This option stops recording the last file access time when the file is just read. The noatime option eliminates all the writes to the disk each time a file was just read which previously used to happen with atime. However a write is made to a disk in case if a file is being changed/written.
3. relatime – A filesystem mount with this option causes the access time to be updated if they are (before the update has occurred) earlier than the modification time. This significantly cuts down the writes caused by atime updates. However not many people use this option because they are simply not aware of it.
source: http://linux.koolsolutions.com/2009...sb-part-4-noatime-and-relatime-mount-options/
Click to expand...
Click to collapse
Indeed relatime is the most usefull option for us.
Yet... reading this for the 2nd time:
Yaffs has data recovery capabilities, as proven by the battery pulls that gave no corruption at all.
So i think yaffs is good and nand is good. The data corruption problem lies outside the kernel and is a subject for a different thread.
Click to expand...
Click to collapse
Could it be... a proc atempting to unmount /data or remount,ro that causes a defect ?
One other thing... you're sync'ing to yaffs.net, would it be too bad/dificult to use the yaffs2 provided with usual HTC sources ?
I'm looking at Supersonic... it uses our 2.6.32 kernel....

daedric said:
One other thing... you're sync'ing to yaffs.net, would it be too bad/dificult to use the yaffs2 provided with usual HTC sources ?
Click to expand...
Click to collapse
The yaffs in the kernel at the minute is from the official android source, so what all other HTC devices are using

I tried the yaffs.net latest just as a comparison. It didn't change anything one way or the other.
Sent from my Android on HTC Kaiser/Kaiser/Polaris using XDA App

Trying to setup 2.6.32 kernel over 2.6.25 on my tytnII with Warm Donut on board.
Using Atools. Doing everything step-by-step, but when i reach this steps:
33 then flash from sd (gray)
34 reset device when it finished
it's booting from sd, (gray), show "Loading.." and never complete :-(
have wait more than hour.
What's possible reason?
Using zImage-11-27-10 from l1qu1d sourceforge.net site.
Thanks in advance for help.

[Script][A2SD]Darktremor 2.7.5.3 Beta 04 [DesireZ] (01/29/2011)

Introducing...
Darktremor Apps2SD 2.7.5.3 Beta 04
Date of Release: January 29, 2011
Download Current Version
Instructions - Change Log - Commands - ROM List - Developer's Guide
Darktremor Apps2SD Fan Page ----
Darktremor Apps2SD Development Group
Are you installing Darktremor Apps2SD on your phone? Here are the instructions to help you: Facebook
Are you a developer wanting to include Darktremor Apps2SD in your latest ROM? Here is the Developer Guide: Facebook
Click to expand...
Click to collapse
Update on Beta 4
It seems I'm getting mixed results with these betas. I'm not sure why this is occurring, some people have been able to get this working right while others have had a hard time with it.
Currently, I'm rebuilding the entire program. This takes a while because I have to figure out how to pack all these options into the program but make it small enough to where it will run correctly.
I will say that some of the beta features are coming back out...one of them is the search for a partition code. I suspect that code may be leading me into issues with certain platforms, so I'm going back to the 2.7.5.2 method of mounting (mmcblk0p2 or mmcblk1p2).
Also, parts of the code will use Busybox Ash (the only code that won't will be starta2sd, which will still use Bash for the time being). The startup code will definitely use Busybox Ash.
Until then, here are the links to the the last two betas and the last official release:
Version 2.7.5.3 Beta 04 - http://www.darktremor.info/files/a2sd/dtapps2sd-2.7.5.3-beta04-signed.zip
Version 2.7.5.3 Beta 03 - http://www.darktremor.info/files/a2sd/dtapps2sd-2.7.5.3-beta03-signed.zip
Version 2.7.5.2-1 - http://www.darktremor.info/files/a2sd/dtapps2sd-2.7.5.2-1-signed.zip
And, if you want past versions, you can view the repository: ftp://dtuser:[email protected] (ignore the smiley face...that's XDA doing that.)
Click to expand...
Click to collapse
Beta 04 took longer than I expected to release. I have done major changes to the code:
1. New commands: convert-ext4 - This will convert your EXT3 partition into EXT4. Just a friendly reminder on this command: Not every rom supports EXT4, so it is possible to go into a boot loop if you switch roms. Use with caution.
2. Reworked convert-ext3 (convert-ext4 gets similar code)...now a flag file is set before the reboot (no conversion is done before the reboot). At load time, the conversion is performed. This takes longer in the reboot process and you may think your phone has locked up...wait about five minutes before doing anything with the phone.
3. Repair is rebuilt...now it uses existing commands to repair the setup (reinstall, remove, cachesd, cachepart, nocache, datasd, nodata). Definitely shrinks the code.
4. Added fix_permissions program to the package. This may help with Superuser issues when using the datasd feature. It is used in reinstall, remove, datasd and nodata.
5. a2sd install is back!!! Both a2sd install and a2sd reinstall do the exact same thing.
6. Dalvik heap code has been shrunk and now creates a file called dalvikheap. Actually, the code has been doing this all along (since about 2.7.5.2, I think), but I never put the code in to use the file.
7. Low Memory Killer code has also been shrunk and uses a file caled dtset_lowmem to set the low memory killer parameter.
8. Replaced Busybox PS function with Toolbox PS. The issue with Busybox PS is that it gives a false reading when I look for android.process.acore (which is the main program when the GUI starts up). If that is present, the program thinks you are trying to run Darktremor without any command line parameters. This was because Busybox would report the process was there when, in reality, it wasn't (validated this when my phone was boot looping.) Toolbox's PS reports the correct setting. This should fix the bootlooping issues some people are experiencing.
9. New commands: usedtbusybox and usedefaultbusybox - these commands may help in diagnosing issues that is may be related to the native Busybox on your rom. a2sd usedtbusybox will use the Busybox that is packaged with Darktremor. a2sd usedefaultbusybox will turn back on the scan behavior of the program introduced in Beta 03.
10. Support for Darktremor Apps2SD version 2.7 and earlier has been discontinued. To upgrade correctly from one of those versions, use version 2.7.5.3 Beta 03b or earlier.
11. Finally fixed stalled boot issues (or at least my tests with several roms says so.)
See the change log for additional details.
You will notice that if the program runs repair and finds a problem, it will correct the issue and reboot. You will see a second reboot when the dalvik-cache clears (this is to fix timing issues with CyanogenMod...I can't control that startup as well as I can other roms). This only happens if repair is ran or you flash a new rom (as repair will realign all data). If you are upgrading from a previous version of Darktremor, you should not see the reboots.
Click to expand...
Click to collapse
This is Darktremor Apps2SD, a multipurpose program that primarily allows a user to execute applications created for the Android OS on their Secure Digital card (with the proper setup...more on that later). But, Darktremor Apps2SD is all about stability. The goal is to be able for all users of the Android OS to be able to take advantage of a method to run their applications from a secure digital card.
But just because the Darktremor Apps2SD is all about stability, doesn't mean it isn't packed with features:
- Move applications (both free and paid) to the Secure Digital card.
- Move Dalvik Cache to run either from your Secure Digital card or from your cache partition and clears the cache on demand.
- Boot Loop Protection: prevents the phone from boot looping in the event the SD card could not be mounted.
- Dalvik JIT for faster performance on Roms which support it.
- User selectable sizes for the Dalvik heap sizes, allowing a user to freely optimize their system.
- Activate a swap partition on your SD card and sets how often the swap partition is utilized.
- Automatically fixes configuration issues.
- Users can check the free space on their SD card and check the installation to make sure all is setup correctly.
- Runs ZipAlign on demand...this makes your programs load faster.
- Built in help system for easy reference of commands.
- All features can also be reversed without repartitioning your Secure Digital card.
- New logging features assists in troubleshooting issues.
- Commands to set the Low Memory Killer feature at boot time. Great for those people who are the "set it and forget it" type.
- And more...
Darktremor Apps2SD is not the same as Froyo Apps2SD. Froyo Apps2SD creates a secure folder on the FAT32 section of your SD card (this is the section that you see when you mount your phone to your computer) and stores the programs there. This is nice as you don't have to do anything special with the phone, but it isn't backwards compatible with older versions of Android (Cupcake, Donut, Eclair) and, because of the way Froyo works, older programs not designed for Froyo will automatically stay on your internal storage (unless you install a program that forces the move to your SD card).
Darktremor Apps2SD takes a different approach. Based on the original CyanogenMod works, Darktremor Apps2SD uses symbolic linking to force Android into moving your applications to the SD card. Because Android will not allow anything to be ran from the FAT32 partition on your SD card (and, in Froyo, it will only allow you to run programs from a special folder), Darktremor utilizes filesystems called EXT2, EXT3 and EXT4. Each one of these filesystems is native to Linux (the operating system running Android), which allows you to run programs from them (same as, say, a computer running Ubuntu). This method is completely compatible with all versions of Android, including Froyo. In fact, you can run both the Darktremor Apps2SD and Froyo Apps2SD at the same time.
Check out the list of Roms that either have Darktremor Apps2SD installed or are compatible with Darktremor Apps2SD. Click on the link labeled ROM List at the top of this message.

What?! Thanks darktremor, used this with my slide, will be testing and update this post asap with feedback.
Just curious though, is this meant for froyo based roms or should it work with gingerbread also?... guess I could test and see. Also do we still need to used the 'a2sd reinstall' and 'a2sd cachesd' commands to install it?
Sent from my T-Mobile G2 using XDA App

will this also work with sense roms?

g1junky said:
will this also work with sense roms?
Click to expand...
Click to collapse
Not sure, that's why we are testing it.

I can't get it to work on CM7 nightly 11 ( That I know of).
Used Clockworkmod to set up the ext partition (which doesn't specify which filesystem so i'm guessing either ext2 or ext3); set partition to 512mb and swap to 0mb.
Card partitioned successfully according to CWM; upon flashing the app2sd.zip the installation goes through all steps and posts that the install was successful even though the little check box by install successful is the only one that is starred. I noticed that during the install the script mounts /system and /data to write to them...not sure if that is affected by GB. I thought I read somewhere that this script was designed to check for ext4.
Hell, idk lol. I nandroided and went for it, these are my findings.
scratch that, there's a part two i missed that involves command line functions in the terminal emulator app. It looks like it's working to me.
Edit2: From what ive moved to /sd-ext so far everything seems to be working. Moved my apps, app data, dalvik cache and /data/data.
So far I havent experienced any data loss when moving /data/data.

There's no reason it shouldn't work with Gingerbread, other than the usual suspect of the rom doesn't launch scripts at boot or doesn't have EXT support.
As for the commands, you shouldn't have to rerun those commands if you are upgrading.
KCRic said:
What?! Thanks darktremor, used this with my slide, will be testing and update this post asap with feedback.
Just curious though, is this meant for froyo based roms or should it work with gingerbread also?... guess I could test and see. Also do we still need to used the 'a2sd reinstall' and 'a2sd cachesd' commands to install it?
Sent from my T-Mobile G2 using XDA App
Click to expand...
Click to collapse

Yes, it should. I'm running a Sense UI rom on my Evo and it has 2.7.5.3 Beta 02.
g1junky said:
will this also work with sense roms?
Click to expand...
Click to collapse

I can honestly say that so far everything seems to be working well on my end. Dropped ~100megs of internal space usage and sent it to the sd.
The phone does seem a bit snappier, does this style of app2sd stress the card more than usual?

hmm.
I'm running cm 7 nightly 11, set 512mb, 0mb swap and I think I got everything right. Strangely enough, I keep getting reboots every time i run a command in terminal.
edit: a2sd command*

SWEEET..........
I too can confirm that this works with CM7 Nightly "Gingerbread" sweet, installed the zip file from recovery, QUICK NOTE: Had to mount /system and mount /data in recovery before installing the zip file from sdcard. This is great apps2ext that works with any rom. Now in my titanium back ups it shows three seperate storge locations: internal, SD card and SDCard(a2sd) plus it restored apps I previously had on my ext.2 partition from when I was running Enoms Rom....sweeeeeet.
Also dont forget to run the command in adb shell:
Code:
/system/bin/a2sd cachesd
if you want to move dalvik cache to sd.
UPDATE: internal memory free reads out of 1.37GB Avail. there is 1.28GB FREE and Ive got 77 apps installed right now and about too install a lot more..........
FYI im runnning a 16gb class 10 sd card with a 1024mb ext.2 partition

Most of the code is similar to the previous version. I think the snappiness may be that your SD card is faster than internal storage.
stevencpoynter said:
I can honestly say that so far everything seems to be working well on my end. Dropped ~100megs of internal space usage and sent it to the sd.
The phone does seem a bit snappier, does this style of app2sd stress the card more than usual?
Click to expand...
Click to collapse

Did you type su before you run an a2sd command?
zarskee seven nine said:
I'm running cm 7 nightly 11, set 512mb, 0mb swap and I think I got everything right. Strangely enough, I keep getting reboots every time i run a command in terminal.
edit: a2sd command*
Click to expand...
Click to collapse

Just so everyone knows (may want to add this to the OP you know, so you don't get a million ?'s) these are the commands you HAVE to enter after flashing it in recovery.
Code:
su [ENTER]
cd /system/bin [ENTER]
sh a2sd cachesd [ENTER]
Your phone will reboot and will take a bit to complete - be patient because it's moving all your apps and the dalvik cache.
Notes: Your memory will still drop (not by much) over time because the apps will still store cached memory on the phone. To deal with this use the 'datasd' command to move that info to the sdcard also. Also, use the 'a2sd help' command to find all the functions you can perform with this. If you've used this before then all of this is irrelevant

Was so excited about this , It worked perfectly on CM7 nightly builds but when I went to update the Nightly build from 11 to 12, problems, keep getting reboot, since all my apps including titanium were on EXT, I could not access them, so the modification didn't stick from build to build, had to full data wipe, so I guess I'll be coming back to this when CM7 stable is realeased.

Yah I did. It's a beta on a nightly rom...I'm not surprised that something would be weird. I know it worked sending my dalvik cache to sd for sure, but as far as my apps being reinstalled on sd..im not sure. I followed the directions to the t and i know i didnt skip steps cause i used to use this on my nexus one

joemm said:
Was so excited about this , It worked perfectly on CM7 nightly builds but when I went to update the Nightly build from 11 to 12, problems, keep getting reboot, since all my apps including titanium were on EXT, I could not access them, so the modification didn't stick from build to build, had to full data wipe, so I guess I'll be coming back to this when CM7 stable is realeased.
Click to expand...
Click to collapse
You may have to remove the script in terminal, reinstall the rom than rerun the zip script. I think that should work if you want to keep using this on nightlies

If you change roms (including moving between different nightly builds), you will need to reflash Darktremor.
The only time you don't have to do that is if Darktremor is already added on the rom you are loading. Since CM7 doesn't have Darktremor installed as part of its package, you'll have to reflash each time you change nightly builds.
If you still don't have access to your programs, type a2sd reinstall
My apologies.
zarskee seven nine said:
You may have to remove the script in terminal, reinstall the rom than rerun the zip script. I think that should work if you want to keep using this on nightlies
Click to expand...
Click to collapse

after several days nothing new in this android development section, today i saw something new here, keep your good work, gonna try it when i get home

This is about three months overdue. Unfortunately, job, family and the holiday season got the best of me.
fajarep said:
after several days nothing new in this android development section, today i saw something new here, keep your good work, gonna try it when i get home
Click to expand...
Click to collapse

For me it seems that it doesn't stick. I tried it with cm7, flashed it in recovery and when I booted up to run the commands in terminal they weren't there. No a2sd at all. Guess I could shove all in the ROM prior to flashing and see if that works.

[BUILD] [GingerBread] CM7 from Neopeek!! **Dev Preview** ClockworkMod!

Hey all,
Wanted to post CM7 here for everyone to enjoy.
Neopeek has been working hard to get this build up and running, he's been doing great work!
Neopeek's Original Post - if you wish to see Neopeek's original post about the CM7 topic.
Also, since now I am using his new ClockWordMod method - CWM Recovery thread
As is stated in the title, this is mainly for devs/testers. Lots of things are broken, and there will be frequent updates.
There are two methods to using this build:
1) ClockWorkMod (requires 3 separate ext2 partitions)
2) Loop'd system.ext2 image (like XDAndroid) [In progress]
The benefit of #1 is a dedicated system/data partition, and *partial* USB mass storage support.
The benefit of #2 is, it's easier .
I still have to work to get #2 up, but I wanted to post #1 ASAP. Lots of work to flesh out the post to, be patient!
I've been holding off on releasing this CWM version of CM7, because I'm still having a lot of bugs with it. Still needs quite a bit of work, but it's getting late for me tonight - I am going to release it, let me know if you guys make improvements, I'd love to incorporate them!
Main issues seem to be related to my durn CDMA device. Need to break into some logs to see what's goin on, it may be a little while! I think GSM folk will be fine. Let me know!
Downloads
Download #1
How-to
Method #1 (ClockWorkMod)
****WARNING****
If you setup dedicated partitions using this method, normal XDAndroid builds will think that you want to use dedicated partitions. I had to modify the init to get it to work correctly (I basically broke the partition detection in the init). It's not pretty, but I don't know of a better way to resolve that issue - let me know what ideas you guys have!
Setup:
You will need to create three (3) ext2 partitions on your SD card. This is not extremely simple, but by no means impossible .
If you're using Windows, I like the Mini Partition Tool. If you're in Linux, I usually use gparted.
This takes a little bit of planning - but in total, I would say you need a minimum of 450mb of space for all three ext2 partitions. So work out how much free space is left (if you want a bigger data partiton, or system partition account for it!) and make that the first partition - FAT32. Make sure all the partitions are "primary", not "logical"! See the partition layout below:
1 - FAT32 Primary (remainder of card)
2 - ext2 Primary (at least 150mb, system partition)
3 - ext2 Primary (at least 250mb, data partition - I wouldn't go over 1gb here)
4 - ext2 Primary (at least 50mb, cache partition)
Don't worry about putting anything in these ext2 partitions, everything is populated by Android and CWM. The FAT32 partition is used to kick off Android, while system, data and cache are all ext2 partitions. Reason for this is, hopefully if things go haywire we can blast out cache, not data . Also, it should be easier to update using this method than previously.
Extract the file. Look at the folder it created (npkboot). Copy the entire npkboot folder to the root of your SD (for now this is required - the init assumes there's a /sdcard/npkboot/tmp folder). There will also be an update.zip, in this case update-cm-7.0.0-neopeek.zip. Put this at the root of your SD card (this makes finding it in the menu much easier!)
Copy the appropriate startup.txt from the STARTUPS folder.
Find haret.exe in th npkboot folder. Run it, and watch the boot process carefully! It will ask you to hold the vol down button to enter recovery, and you have 10 seconds to do so.
Assuming you manage to do this correctly (I had some trouble at first ) you should see an icon like a hat. Wait for the menu.
Buttons:
End key - back (back button seems to do this as well...)
Send key - enter
Vol up - up
Vol down - down (menu button seems to do this as well...)
If this is the first install, go to "install zip from sdcard". Then "choose zip from sdcard" This will install the system image to the system partition from the update.zip.
If you need to wipe the data partition, you can do that under "mounts and storage". You shouldn't need to do this unless you're going from gb -> froyo or visa-versa. Froyo -> froyo should 'just work', as always YMMV.
There are A LOT of options in replimenu. The only ones I have used are install, format /data, /system or /cache and Reboot. According to Neopeek, there are several things that should not be used:
Neopeek said:
* Don't use "factory wipe" in CWM (you have been warned )
* Don't use "format sdcard" unless you know what you do (you have been warned )
* Don't use "partition sdcard" unless you know what you do (you have been warned )
Click to expand...
Click to collapse
Once you've installed Android, go back to the main menu and "reboot system now" There are some bugs, for example "reboot recovery" and "power off" all just reboot the phone to WinMo.
Boot haret again, but this time don't hold the vol down to enter recovery - boot as normal!
#2: Much simpler method, similar to XDAndroid builds.
Extract the file to your desktop. Go into the CM7 folder, look for the STARTUPS folder - grab the appropriate startup.txt, move it to where haret.exe is.
Copy everything in the CM7 folder to the root of your SD card - if you want to run it from a folder, create a rel_path=CM7 statement in your startup.txt after the set cmdline (if you want a different folder, change the CM7.)
Grab the ts-calibration file attached to this post (for RHOD), or go to this post for a list of ts-calib's. You can also create your own on boot, but may have to revert to an older kernel to do so.
Run haret.exe!

****Not Working****​
CDMA seems broken - still! I did some testing with hyc's RIL and it's still busted, so there's something in the system image messing with it - Airplane mode was checked, and I could not uncheck it.
In addition, phone.apk seems like a forceclosefest. Neopeek did point this out in his original thread...
Mobile data - broken (Fixed soon)
Wifi - broken (Fixed soon)
System needs optimization for RHOD - was originally build with DIAM in mind - so it's a little slow.
Failed wakes seem pretty bad - sometimes it is quite difficult to wake the phone.
Boot animation seems to be not present - I'm looking into fixing it, probably graphics libs if anything that's broke it.

Dev Content​
This new method should be great for anyone who wants to make their own updates - you can easily peek into the system image and make changes at will, then just install the new system image! You can even rolll updates instead of an entire system image if you wish.
The script language in ClockWorkMod is called "Edify", see this thread to learn about the syntax. This is related to the META-INF folder you see in the update zip.
There's a few differences in the rootfs', the main being the init. There's also some additional files it looks like neopeek added for Recovery specifically.

This is amazing work. Props to all involved.

Does anyone have any feedback on this build?

arrrghhh said:
Long story short, you need a ext2 partition and a fat32 partition - ext2 needs to be between 400-600mb, fat32 can just take the remainder of the card's space.
Click to expand...
Click to collapse
Is there a reason for the 600mb upper limit? If I use 1 gb, will it cause problems or will it not use it and just waste card space?

PM message
Arrrgh,
Disregard the PM I sent you.
I read the instruction and like you said, its not simple. So I will wait until you upload the easy to run load.
Thanks

Ltilt2 said:
Arrrgh,
Disregard the PM I sent you.
I read the instruction and like you said, its not simple. So I will wait until you upload the easy to run load.
Thanks
Click to expand...
Click to collapse
Sorry, I need access to a Linux box to do the 'easy' build... I will when I get home tonight from work, promise .
vinceweis said:
Is there a reason for the 600mb upper limit? If I use 1 gb, will it cause problems or will it not use it and just waste card space?
Click to expand...
Click to collapse
You can make it as big as you want I guess... I'm not sure how neopeek sets up the data partition to be honest, I'd have to ask him.
Edit - in lieu of the post below, I adjusted the first post to say it needs to be at least 400mb .

vinceweis said:
Is there a reason for the 600mb upper limit? If I use 1 gb, will it cause problems or will it not use it and just waste card space?
Click to expand...
Click to collapse
I have 700 mb and is working well,you can use as much as you want
Ltilt2 said:
Arrrgh,
Disregard the PM I sent you.
I read the instruction and like you said, its not simple. So I will wait until you upload the easy to run load.
Thanks
Click to expand...
Click to collapse
Is easy just use mini tool partition wizard,delete the main partition on the sd-card
and do two,one fat32 primary and one ext2 primary,then extract the archive and put the proper startups in npkinstall and in root
from the phone run install.exe
and after the reboot use haret.exe

I wonder if CDMA data is working with this...that is my biggest issue with GB right now...

HELICOPTER88 said:
I have 700 mb and is working well,you can use as much as you want
Is easy just use mini tool partition wizard,delete the main partition on the sd-card
and do two,one fat32 primary and one ext2 primary,then extract the archive and put the proper startups in npkinstall and in root
from the phone run install.exe
and after the reboot use haret.exe
Click to expand...
Click to collapse
yeah easy for you to say, that sounds complicated.
I will wait for the other one.
Do you know the ETA?

i have
- downloaded the file cm7new.tar.gz
- made primary fat32 and ext2 partitions
- extracted the file cm7new.tar.gz to the root of the fat32 partition
- got a lot of linux folders
but i am missing
- npkinstall folder
- startup.txt
- install.exe
- haret.exe
- startup folder
Where are these files?

Tippfehler said:
i have
- downloaded the file cm7new.tar.gz
- made primary fat32 and ext2 partitions
- extracted the file cm7new.tar.gz to the root of the fat32 partition
- got a lot of linux folders
but i am missing
- npkinstall folder
- startup.txt
- install.exe
- haret.exe
- startup folder
Where are these files?
Click to expand...
Click to collapse
Still need to upload, sorry!

Tippfehler said:
i have
- downloaded the file cm7new.tar.gz
- made primary fat32 and ext2 partitions
- extracted the file cm7new.tar.gz to the root of the fat32 partition
- got a lot of linux folders
but i am missing
- npkinstall folder
- startup.txt
- install.exe
- haret.exe
- startup folder
Where are these files?
Click to expand...
Click to collapse
I was looking at that too when extracted the files and didn't see what you are also missing.

Sorry about the confusion guys, I probably shouldn't have put the download link up before I was done .
I just fixed it, so #1 is good to go! I'll get #2 up later, thanks.

Another noob question, but the rootfs, kernels, oc, etc from the xdandroid builds will work the same on these?

(...solved...)

it's necessary create a swap partition?
What works in this build?

fishingmedic said:
Another noob question, but the rootfs, kernels, oc, etc from the xdandroid builds will work the same on these?
Click to expand...
Click to collapse
The rootfs is more or less collapsed in these.
Kernels are straight from XDAndroid repo.
OC is the same, startup.txt is fairly similar .
Quincux said:
it's necessary create a swap partition?
What works in this build?
Click to expand...
Click to collapse
Swap is not necessary.
Most things that work in XDAndroid work in here. Lots of other things are broken here tho .

Okay, downloaded and installed without problems.
First impressions:
Absolutely great build in terms of response!
No delays in menus, etc.
Also, this looks like the first build that may have little or no clock delay, so no need for clocksync !!! (to be confirmed since I did not use it very long, die to issues below)
However...
1) No WIFI
2) No Mobile data (2G/3G)
3) camera not working (could be just blackstone)
- maybe other issues, decided to wait for more feedback before continuing, without market access there's little point...
Device: Blackstone
Kernel: extensive testing with provided one (1276), later switched to 1277, to fix audiostuttering, no wifi or mobile data in either...
As a reference, used many NeoPeek / XDAndroid builds, generally got WIFI/Mobile data working until now...
Love to hear if someone else (blackstone?) got WIFI/2G/3G working...
Oh, well, as I understood, this was an early "developer" release, still plenty of room for improvements!
Cheers,
Robbert

[DEV][Proof-of-Concept] Boot from SD on Optimus V

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.