Database Info

Need help with vold.conf for cupcake apps to sd

I am trying to work with haykuro to get apps on sd for his cupcake roms, but I ran into a problem. They replaced mountd with vold, and there is no known documentation on how to format the config file. This does not seem to be the same vold that is used on SUN or other unix operating systems. If anyone has any useful info, please share it with me so I can look into this further.

Maybe this will get you started...
*EDIT* didnt read your post correctly... Didnt see that it was not related to the Sun version.
Darkrift,
Maybe the vold.conf in the android system is similar to the vold.conf in my Solaris 10 Sparc Server.....
Code:
> > For Solaris 8, you have to fake a change on the vold.conf
> > configuration file, otherwise the HUP signal is ignored:
> >
> > touch /etc/vold.conf
> > + pkill −HUP vold
>
> I stopped vold & commented out the one /etc/vold.conf line:
> # use rmdisk drive /dev/rdsk/c*s2 dev_rmdisk.so rmdisk%d
If you want vold to automatically mount an usb mass
storage device on a reboot (or a re−start of vold, or the above
mentioned touch / SIGHUP sequence), you have to make sure to remove
the comment character from the "use rmdisk" line in /etc/vold.conf.
Study some of the Sun Solaris docs I have listed below and maybe you will find the right recipe you are looking for...
Sun Solaris USB Flash Drive Mount Command
Solaris 10 - System Administration Guide - Devices and File Systems
Hope this helps...
I'm on Gtalk as AndroidSamurai if you have any questions.
While I'm at it, this is the command to mount a floppy in Solaris...
Code:
mount -f pcfs /dev/diskette /mnt
/mnt is the mount point

Here is what is currently in the file:
Code:
## vold configuration file for Sapphire
volume_sdcard {
## This is the direct uevent device path to the SD slot on the device
media_path /devices/platform/msm_sdcc.2/mmc_host/mmc1
emu_media_path /devices/platform/goldfish_mmc.0/mmc_host/mmc0
media_type mmc
mount_point /sdcard
ums_path /devices/platform/usb_mass_storage/lun0
}
I tried adding:
Code:
volume_apps {
## This is the direct uevent device path to the SD slot on the device
media_path /dev/block/mmcblk0p2
media_type mmc
mount_point /system/sd
}
with no luck. And yes, I tried doing the media_path in the same format as the first one, which also did nothing.

Would the "mount_point" not be "/sdcard"?
I cannot work the terminal on my G1 bc of the keymapping error preventing me from using "/"...
Would it not be:
Code:
media_path /dev/block/mmcblk0p1
seeing that a fat partition(vfat) would be "p0" ?
Have you tried looking at "vold/mmc.c and vold/mmc.h" ?
Also try looking at the following:
Code:
vold/volmgr_ext3.c
vold/volmgr_ext3.h
vold/volmgr_vfat.c
vold/volmgr_vfat.h
If you would please e-mail me the vold.conf in a zip archive so I can play around with it a little...
Sorry, my resources are a little bare at the current time due to a surge knocking out all my equipment.
Email Me
or find me on GTalk under androidsamurai.....

No, i am trying to add apps to sd, which go in /system/sd/app. this would mount my second partition (ext2) /system/sd

Let me also state that the top part is working. that is what loads the sdcard to /sdcard. what I am trying to do is load the second partition to /system/sd by adding a *second* block to the file, which is not working.

Hi Darkrift,
I don't have a second partition on my sd card nor have I installed any of the cupcake builds so I can't test my thoughts myself but thought I'd share them with you...
Have you tried browsing to the directory referenced by the original vold.conf? I was just wondering how this structure compares to a device using a partitioned sd card? Maybe a comparison would give us some clues as to how the new volume manager works.
Mine looks like this:
sys/devices/platform/msm_sdcc.2/mmc_host:mmc1/mmc1:d516
With no other similarly name directories below the msm_sdcc.2 level.

Why don't we use Fat32 partition as extra memory? why can't we run application from a Fat32 partition?

#1 FAT32 doesn't support case-sensitivity, and that is enabled on the internal FS's
#2 extfs is way better than FAT
#2 FAT sucks

@wellsie: I think the problem is the name I am giving it "volume_apps {
" but if i change it to volume_sdcard { like the first one, it adds those config options to teh top block. Also I have tried adding all different versions of the media path (in /dev, in /system/devices and more) with no luck.
@funbacon: Joushou's ideas make sense, but neither of those are the reason. Each application installed on the G1 has an owner, group and set permissions. That is part of the "sandbox" that keeps apps from accessing each others files. Fat has no permissions, so an app on fat would not be able to have the needed permissions to be used.

Oh yeah, permissions aswell
I have been too long in unix, so i just expect that to be there
But i believe that fits under the "FAT sucks" category

I agree with that one

C'mon. I know someone has gotta have some ideas or maybe know how to browse the source and figure stuff out more than I could. I tried checking out the source but its fairly foreign to me. I know a little scripting, but not much as far as coding goes. I really would like to help get apps-to-sd working in cupcake but this is a major stumbling block for that.

I just want to say that even i am not proficient on this type of stuff i voluntere to test whatever setup you come up with.
I really apreciate your work on this as this is the only reason I have not moved to haykuros or anybodys cupcake build.
So thanks tanks to every body for pitching in.
oh by the way, If you set it up i will donate to the cause!!!!!

I'll try and look at the code over the weekend...family time comes first though so it may have to wait until next week when I'm at work ;-)

I think the main problem is the naming convention for a new "block". sdcard is already in use, and adding a second one just adds to the first one. I think there might be "sdcard2" or something else that it is expecting. I tried just naming it whatever I wanted hoping that would work but it didnt seem to.

im with carlos im not a good with all that code stuff, but im down to test whatever u come out with,
also for i heard haykuyo is coming out with a fix for the physical keyboard soon

If you are speaking about "Keyboard Fix" in the terms of the Keyboard Mapping being messed up, then chack out the first post of the Sapphire/Magic G1 Port thread... Keyboard mapping has been fixed.
I honestly cannot believe that Google hasn't had any hits on the android site about this problem yet...

Instead of partitioning, maybe we can try this other method for apps to sdcard.
http://forum.xda-developers.com/showpost.php?p=3402719&postcount=683
http://forum.xda-developers.com/showpost.php?p=3402947&postcount=687
This method creates an ext2 filesystem object as a file under the fat32 filesystem so there would be no need to partition.
I'm doing my taxes today, but if I get a chance to play around with it, I'll try to implement this tomorrow. Looks pretty straightforward.

well, nobody would know about this problem unless they are breaking the rules. A, having a rom which we should not have, and B, making changes to the OS and "hacking" it to read apps somewhere its not supposed to. Android should not have 2 partitions, so this is not something they would even answer.

Ext4 fs?

Just a quick thought - I was trying to figure out if I might get somewhat better filesystem performance out of ext4 rather than ext3 for the user data partition. As a first pass, I compiled a kernel with ext4 enabled, and tried to change my boot partition init.rc to mount /data as an ext4 partition rather than an ext3 - my understanding is they should be mount-compatible even without repartitioning.
The result of this was a bootloop. Had to reflash back to a working boot.img. Didn't do anything bad to my /data partition though.
Any ideas why this might be happening? Is there a way to grab dmesg from a boot looping kernel on Android?

I've found the following procedures to be helpful in debugging custom kernels.
First, remove the fbcon.c patch in the kernel source (you can just edit the one line that gets modified and uncomment it):
Code:
nano drivers/video/console/fbcon.c
Search for "navy", then uncomment the line:
Code:
update_screen(vc);
Rebuild your kernel. Now you'll have the ability to get a framebuffer console, if your kernel command line arguments are correct. You have to supply custom kernel command line arguments when using mk-boot-img. I use the following when using mk-boot-image:
Code:
mkbootimg --kernel zImage --ramdisk initrd.gz --cmdline "[email protected] [email protected] vmalloc=192M video=tegrafb console=tty0,115200 fbcon=rotate:1 fbcon=font:VGA8x8 usbcore.old_scheme_first=1 cpuid=200102 devicetype=1002 btmac=9c5ed6131a00 tegraboot=nand mtdparts=tegra_nand:[email protected](misc),[email protected](recovery),[email protected](boot),[email protected](system),[email protected](cache),[email protected](bootbmp),[email protected](logodata)" -o boot.img
The important part there is changing the console parameter from the default ttyS0 to tty0.
I make separate boot images when debugging - one that executes a shell in the initial ramdisk, and one that doesn't. To get a shell in the initrd, which you'll want to do in this case to figure out your mount issue, is change the above mkbootimg --cmdline parameter:
Code:
mkbootimg --kernel zImage --ramdisk initrd.gz --cmdline "break=top [email protected] [email protected] vmalloc=192M video=tegrafb console=tty0,115200 fbcon=rotate:1 fbcon=font:VGA8x8 usbcore.old_scheme_first=1 cpuid=200102 devicetype=1002 btmac=9c5ed6131a00 tegraboot=nand mtdparts=tegra_nand:[email protected](misc),[email protected](recovery),[email protected](boot),[email protected](system),[email protected](cache),[email protected](bootbmp),[email protected](logodata)" -o boot.img
Notice the "break=top". This will give you a command shell before anything in initrc has been executed. You could also use "break=bottom" or "break=init" to get you to different spots in initrc.
Hope that helps! Happy hacking!

Oh, and I forgot to mention that a usb keyboard is very handy after you get a shell

jersacct said:
I've found the following procedures to be helpful in debugging custom kernels.
First, remove the fbcon.c patch in the kernel source (you can just edit the one line that gets modified and uncomment it):
Code:
nano drivers/video/console/fbcon.c
Search for "navy", then uncomment the line:
Code:
update_screen(vc);
Rebuild your kernel. Now you'll have the ability to get a framebuffer console, if your kernel command line arguments are correct. You have to supply custom kernel command line arguments when using mk-boot-img. I use the following when using mk-boot-image:
Code:
mkbootimg --kernel zImage --ramdisk initrd.gz --cmdline "[email protected] [email protected] vmalloc=192M video=tegrafb console=tty0,115200 fbcon=rotate:1 fbcon=font:VGA8x8 usbcore.old_scheme_first=1 cpuid=200102 devicetype=1002 btmac=9c5ed6131a00 tegraboot=nand mtdparts=tegra_nand:[email protected](misc),[email protected](recovery),[email protected](boot),[email protected](system),153728[email protected](cache),[email protected](bootbmp),[email protected](logodata)" -o boot.img
The important part there is changing the console parameter from the default ttyS0 to tty0.
I make separate boot images when debugging - one that executes a shell in the initial ramdisk, and one that doesn't. To get a shell in the initrd, which you'll want to do in this case to figure out your mount issue, is change the above mkbootimg --cmdline parameter:
Code:
mkbootimg --kernel zImage --ramdisk initrd.gz --cmdline "break=top [email protected] [email protected] vmalloc=192M video=tegrafb console=tty0,115200 fbcon=rotate:1 fbcon=font:VGA8x8 usbcore.old_scheme_first=1 cpuid=200102 devicetype=1002 btmac=9c5ed6131a00 tegraboot=nand mtdparts=tegra_nand:[email protected](misc),[email protected](recovery),[email protected](boot),[email protected](system),[email protected](cache),[email protected](bootbmp),[email protected](logodata)" -o boot.img
Notice the "break=top". This will give you a command shell before anything in initrc has been executed. You could also use "break=bottom" or "break=init" to get you to different spots in initrc.
Hope that helps! Happy hacking!
Click to expand...
Click to collapse
Hey jersacct, so I've tried this (recompiled with your suggested patch, then made new boot image with the last set of params you mentioned) and I absolutely see the framebuffer scrolling by rapidly right after the Viewsonic Birds display. However, I never get the break into console - the FB scrolls by very quickly, then I get the GTabDevs boot image for about 2 seconds, then I boot loop again.
Any ideas? I have tried both the break=top and break=init variants of that mkbootimg command line with no success.
EDIT: I tried with a known-good ramdisk image too. The boot.img boots fine, but again I never get dropped to console.

Hmm, I suspected the issue might be that the default config has a pesky setting called CONFIG_CMDLINE="" that could be force-overriding any command line passed to the kernel from the boot image. Tried again with that line commented out, and still didn't have any luck getting the break= command to do anything.
I could probably try forcing the command line from CONFIG_CMDLINE but not sure why that would be different from passing it in mkbootimg...
EDIT: nope, I tried that too. Doesn't make a difference. So I assume it's receiving the CMDLINE just fine. For some reason break=top isn't giving me a console. I also tried it with my USB keyboard already plugged in to see if that was making a difference with the input devices, and still no console.

Still no luck on the debug console. At my wit's end on that. All I can say is that on a regular boot with ext3 mounting my /data partition I see that the partition is dirty and the first mount attempt fails. Second attempt seems to succeed. Says I need to fsck my data partition - which I'd do, but our busybox doesn't seem to support fsck.
Anybody know where I can find a busybox binary that properly supports fsck for ext2/3 and also has mkfs.ext4? I know the Archos guys seem to have one and that's an ARM v9 device so it should work, but I'm having trouble finding it (I even downloaded the "SDE" firmware from the Archos site).
I think the reason the ext4 driver is probably just that it's dirty, though I can't confirm that without the damned debug console.
If I can get an up-to-date busybox on here, I suspect this will just start working magically, without further ado. Ideas are appreciated, either on busybox binaries or on getting the initramdisk console stuff that jersacct posted to work.

These guys can help you:
http://forum.xda-developers.com/showthread.php?t=895599
And it makes a HUUUUGE difference...

rcgabriel said:
Still no luck on the debug console. At my wit's end on that. All I can say is that on a regular boot with ext3 mounting my /data partition I see that the partition is dirty and the first mount attempt fails. Second attempt seems to succeed. Says I need to fsck my data partition - which I'd do, but our busybox doesn't seem to support fsck.
Anybody know where I can find a busybox binary that properly supports fsck for ext2/3 and also has mkfs.ext4? I know the Archos guys seem to have one and that's an ARM v9 device so it should work, but I'm having trouble finding it (I even downloaded the "SDE" firmware from the Archos site).
I think the reason the ext4 driver is probably just that it's dirty, though I can't confirm that without the damned debug console.
If I can get an up-to-date busybox on here, I suspect this will just start working magically, without further ado. Ideas are appreciated, either on busybox binaries or on getting the initramdisk console stuff that jersacct posted to work.
Click to expand...
Click to collapse
You know, I didn't think to mention that I was using the Karmic ramdisk image - I bet our stock ramdisk image doesn't have breakpoints setup in initrc. You can grab a copy of a stock initrd image here:
http://www.retardedrobot.com/karmic-initrd-orig.gz
Then just use it instead of the stock ramdisk image when using mkbootimg. Please note, I hardcoded mine to get root to work off the SD card. I think this is an unmodified initrd, so it may work straight out of the box (and boot android if allowed). You might have problems with it though, and may need to unpack it, edit some scripts (for mounting root, etc) and repackage it.
Hope that helps.

stanglx said:
These guys can help you:
http://forum.xda-developers.com/showthread.php?t=895599
And it makes a HUUUUGE difference...
Click to expand...
Click to collapse
Yeah, I've seen the thread before.
I think I was just exhausted and bleary eyed earlier and completely frustrated.
Now that I'm a little more clear-headed, things are much easier.
I've snagged the busybox build out of the Archos initramfs. It indeed does all the ext4 stuff.

jersacct said:
You know, I didn't think to mention that I was using the Karmic ramdisk image - I bet our stock ramdisk image doesn't have breakpoints setup in initrc. You can grab a copy of a stock initrd image here:
http://www.retardedrobot.com/karmic-initrd-orig.gz
Then just use it instead of the stock ramdisk image when using mkbootimg. Please note, I hardcoded mine to get root to work off the SD card. I think this is an unmodified initrd, so it may work straight out of the box (and boot android if allowed). You might have problems with it though, and may need to unpack it, edit some scripts (for mounting root, etc) and repackage it.
Hope that helps.
Click to expand...
Click to collapse
Ahh, this explains why it doesn't work. Thanks so much, I'll take a crack, but hopefully I can clean up my /data partition into a proper ext4 partition with busybox and get it mounting now. I'll see tomorrow, too tired tonight.

Ba...ZING! Finally got ext4 driver working properly. Figured out what was causing the bootloops before, I think - or at least localized the issue.
Running an e2fsck and disabling inandop.sh seems to have done the trick. I think one of the checks in inandop.sh was triggering a reboot. My init.rd now successfully mounts /data as an ext4 partition, mount reports the partition as ext4.
What I need to do now is try to clean up inandop.sh so it properly uses the right binaries to set up the partition as a true ext4. Currently just mounting an ext3 partition with the ext4 driver.
So far no significant performance boost in Quadrant, it's within 50 points of where it was before. But I'm not done yet.

rcgabriel said:
Ba...ZING! Finally got ext4 driver working properly. Figured out what was causing the bootloops before, I think - or at least localized the issue.
Running an e2fsck and disabling inandop.sh seems to have done the trick. I think one of the checks in inandop.sh was triggering a reboot. My init.rd now successfully mounts /data as an ext4 partition, mount reports the partition as ext4.
What I need to do now is try to clean up inandop.sh so it properly uses the right binaries to set up the partition as a true ext4. Currently just mounting an ext3 partition with the ext4 driver.
So far no significant performance boost in Quadrant, it's within 50 points of where it was before. But I'm not done yet.
Click to expand...
Click to collapse
will it incorporate in the future Vegan release? I know we have to do complete format, and goto ext4?
Will love if we can get ext4.

Are you using internal or external (sd card) for the test? The internel storage is very very slow compared to most class 4 sd cards.
rcgabriel said:
Ba...ZING! Finally got ext4 driver working properly. Figured out what was causing the bootloops before, I think - or at least localized the issue.
Running an e2fsck and disabling inandop.sh seems to have done the trick. I think one of the checks in inandop.sh was triggering a reboot. My init.rd now successfully mounts /data as an ext4 partition, mount reports the partition as ext4.
What I need to do now is try to clean up inandop.sh so it properly uses the right binaries to set up the partition as a true ext4. Currently just mounting an ext3 partition with the ext4 driver.
So far no significant performance boost in Quadrant, it's within 50 points of where it was before. But I'm not done yet.
Click to expand...
Click to collapse

One would think that Viewsonic will atleast put class 4.. It does appear to be slow at times when you use SDCard for cache to browse..

stanglx said:
Are you using internal or external (sd card) for the test? The internel storage is very very slow compared to most class 4 sd cards.
Click to expand...
Click to collapse
Using internal SD card. I don't have an extra microSD handy here, just the one in my Nexus One, which is 16GB class 2 so probably too slow to be useful for that.
Still I'm fairly convinced that I should be able to get better results with the internal SD card.

Take a look.. See if your getting the same results with ext4..
Here is the output of a test:
http://forum.xda-developers.com/showpost.php?p=10239762&postcount=2
As you can see a Class
rcgabriel said:
Using internal SD card. I don't have an extra microSD handy here, just the one in my Nexus One, which is 16GB class 2 so probably too slow to be useful for that.
Still I'm fairly convinced that I should be able to get better results with the internal SD card.
Click to expand...
Click to collapse

stanglx said:
Take a look.. See if your getting the same results with ext4..
Here is the output of a test:
http://forum.xda-developers.com/showpost.php?p=10239762&postcount=2
As you can see a Class
Click to expand...
Click to collapse
I'll do more testing later, but right now I've managed to bootloop my G Tablet and I don't have my USB cable here, it's at the office (snow day today). I can boot to recovery but it seems like ClockworkMod recovery 0.8 doesn't want to mount my external MicroSD card from my N1 to copy over a working update.zip to re-flash.
So unless I find another USB cable lying around the apartment somewhere, my G Tablet is out of commission until Monday or until I hit the nearest Radio Shack this weekend.

Status update: I am waiting on a class 6 SD card from Newegg so I can try more stuff out and perfect this without continually screwing up my internal SD card and having to repartition, reformat, etc.
In the meantime, I have tried adapting Chenglu's data2loop method to use an ext4 filesystem in the loop device files rather than an ext2 filesystem as he uses, using a kernel with ext4 enabled.
The good - I'm getting even higher Quadrant benchmarks than with the baseline data2loop. Up to around 3470, averaging around 3400 with a couple of runs. I was, with the same kernel and Chenglu's data2loop patch, getting in the 3200s to 3300s, so the difference seemed somewhat significant to me.
Unfortunately, it seems to puke out every time I reboot. The data must get screwed up somehow in the /data/ext4 files, and my G Tab goes schizo and won't even finish the bootup process - screen flickers from the "Vegan" logo during boot, and then screen shuts off. Have to hard shut-down then hard reboot to recovery and wipe data to get things working again.
The /misc/inandop.log file seems to report that data-to-loop was successfully enabled, so I'm not sure exactly why it's puking out in such epic fashion. Have to work more on this later.

Most likely experiencing some corruption in the cache.... add the sync command to the mount and see if that helps stability using the loopback device.... Also when you create the file system are you using
mkfs.ext4 -O ^huge_file ....
I have read you need to turn off huge_file as it causes some issues (dont remember where I read it though)
rcgabriel said:
Status update: I am waiting on a class 6 SD card from Newegg so I can try more stuff out and perfect this without continually screwing up my internal SD card and having to repartition, reformat, etc.
In the meantime, I have tried adapting Chenglu's data2loop method to use an ext4 filesystem in the loop device files rather than an ext2 filesystem as he uses, using a kernel with ext4 enabled.
The good - I'm getting even higher Quadrant benchmarks than with the baseline data2loop. Up to around 3470, averaging around 3400 with a couple of runs. I was, with the same kernel and Chenglu's data2loop patch, getting in the 3200s to 3300s, so the difference seemed somewhat significant to me.
Unfortunately, it seems to puke out every time I reboot. The data must get screwed up somehow in the /data/ext4 files, and my G Tab goes schizo and won't even finish the bootup process - screen flickers from the "Vegan" logo during boot, and then screen shuts off. Have to hard shut-down then hard reboot to recovery and wipe data to get things working again.
The /misc/inandop.log file seems to report that data-to-loop was successfully enabled, so I'm not sure exactly why it's puking out in such epic fashion. Have to work more on this later.
Click to expand...
Click to collapse

So just to update this thread, I did get ext4 working stably on the /data partition. The trick is doing everything from recovery mode - making the ext4 filesystem via adb push and adb shell, then flashing an update.zip from recovery that packages a kernel that supports ext4 with a ramdisk/init.rc that mounts /data as ext4 and skips the inandop.sh step entirely since that was the source of bootloops (stock inandop.sh expects /data to be ext3 and pukes if it's not).
You can see my detailed instructions over here: http://forum.xda-developers.com/showpost.php?p=10489732&postcount=23
The bad news is really no significant performance bump from ext4 in the standard 2gig partition. But I expect it to be stable as hell. Still need to experiment more with ways to speed things up (safely).

[Q&A] Mounts2SD - Storage & Memory Management

Mounts2SD - Storage & Memory Management
The Opening Post (OP) has been moved to a new DevDB Section
This Thread has been assigned as an Q&A.
You should see a new pane above where you can navigate this project.

About dalvik-cache? It remains in phone memory?

Hi I cant understand How to use it ! any guide ?!

denzel09 said:
About dalvik-cache? It remains in phone memory?
Click to expand...
Click to collapse
dalvik-cache remains, so does all of the app related data. Only the APK's is moved.
Taki2011 said:
Hi I cant understand How to use it ! any guide ?!
Click to expand...
Click to collapse
First of all you need a custom rom. If you have a stock rom it will not work since you need a rom that will allow custom scripts during boot.
You will also need to know how to use ADB (An android tool for communicating with your phone. It is used to enter the android shell and also to transfer files to and from the phone, among other things).
And last, you will need at least 2 or 3 partitions on your sdcard (Otherwise it's a waste of time, although the script is build to adapt for these scenarios). One as a regular fat32 sdcard partition, one for the sd-ext and one for the cache. (Use ext2 for the last two. ext3 will eat your card to fast)
Here is the steps (You need to have ADB working on your computer).
Copy/Paste the script content into a file editor and safe the file with the name "99mounts2sd"
Plug your phone to your computer using a usb cable (Select charge only on your phone))
Open a terminal on your computer (In windows use "run" and type "cmd")
Type in shell: "adb shell mount -o remount,rw /system"
Type in shell: "adb push <path to script> /system/etc/init.d/"
Type in shell: "adb shell chmod a+x /system/etc/init.d/99mounts2sd"
Reboot your phone
The first time you boot your phone using the script it will take some time, because the script needs to copy all of your APK's from internal storage to the sd-ext partition.

The script has been rewritten. Better checks and more options has been added.

Great script
Sent from my GT-S5570 using Tapatalk

It didn't work for me, I made the files made sure they were in the right place and rebooted but booted normally. No delay on first boot and still seems to not be using the other two partitions on my sd card. i used cwm4 to partiton my SD card and it is partitioned correctly (3 partitons). I see the script says "log" I don't know where the log is stored or how to view it. Thanks.

To see the log, type in the terminal: "logcat | grep mounts2sd". Download a terminal or use ADB.
Also run the command "df -h" to see what is mounted where.
Sent from my HTC Desire using xda premium

thanks for the share.

#7 @dyehya
It seams that logcat has a very limited lifetime. In order to get the log info, you would have to get it during boot.
Instead I have updated the script to do this itself. Update your script and config file content with the new above code.
In the config file set VAR_DEBUG="yes" and reboot your phone. Now enter a terminal and type "cat /var/mounts2sd.log | grep mounts2sd" which will show you all the messages from the script, and possible errors, if any.

I am not sure what is going on in boot. I just saw your replies and haven't had a chance to update the script and mess with the phone. I do know that when I was playing with it before it kept using the busybox minimal that was in the kernel loaded in sbin I tried copying your version of busybox into bin and xbin (and now reverted back) but it would still use the one in sbin. What I would really like to do and would recommend is you design the script where you can put busybox in a certain location and the script will use that version over any other versions. I am still learning with all this and despite being able to create the files throw them in the correct places I don't know the code well enough to do this myself. Thanks again for all your help.

Ok i have changed the script so that it now forces the usage of /system/xbin/busybox or /system/bin/busybox and ignores /sbin/busybox
Place a full busybox version in one of the system bin folders, update the script and see what happends.
Otherwise paste a copy of "df -h" and "cat /data/mounts2sd.log | grep mounts2sd" here so that I can see what it does during boot.

Thanks for this. Just flashed the ICS beta 0.1 with your a2sd embedded. Just a suggestion, I added $CMD_CHMOD 777 $CMD_BUSYBOX at line 260, just after the affectation of CMD_BUSYBOX.
For now, it seems to work very well !

virus2013 said:
Thanks for this. Just flashed the ICS beta 0.1 with your a2sd embedded. Just a suggestion, I added $CMD_CHMOD 777 $CMD_BUSYBOX at line 260, just after the affectation of CMD_BUSYBOX.
For now, it seems to work very well !
Click to expand...
Click to collapse
That I don't get? $CMD_CHMOD is undefined at line 260 and why use busybox to change permissions on itself?

dk_zero-cool said:
That I don't get? $CMD_CHMOD is undefined at line 260 and why use busybox to change permissions on itself?
Click to expand...
Click to collapse
Sorry, I'm tired... :-\
In fact, I just wanna be sure that the busybox in /system/bin was executable as I pushed it into the rom zip. And as chmod was already used upper, I was thinking it could be a good idea. However, I'm not a script writer! ;-)
Sent from my Desire running ICS

Hello Cool,
trying ICS with your script. Here is the output of logcat an df -h command:
Code:
# cat /data/mounts2sd.log | grep mounts2sd
cat /data/mounts2sd.log | grep mounts2sd
12-14 13:05:12.905 V/mounts2sd( 96): Initiating Mounts2SD (v:1.1.1)...
12-14 13:05:12.985 V/mounts2sd( 101): Including configuration file...
12-14 13:05:14.897 V/mounts2sd( 212): Searching for sdcard...
12-14 13:05:15.277 V/mounts2sd( 231): Searching for sd-ext partition (/dev/block/mmcblk0p2)...
12-14 13:05:16.198 V/mounts2sd( 254): sd-ext partition was mounted successfully...
12-14 13:05:16.728 V/mounts2sd( 278): Moving /data/app to /sd-ext/app...
12-14 13:05:17.049 V/mounts2sd( 297): Moving /data/app-private to /sd-ext/app-private...
12-14 13:05:17.209 V/mounts2sd( 305): Searching for the sd-cache partition (/dev/block/mmcblk0p3)...
12-14 13:05:18.050 V/mounts2sd( 326): sd-cache was mounted successfully...
12-14 13:05:18.280 V/mounts2sd( 335): A device is already mounted at /cache. Umounting it...
12-14 13:05:18.420 V/mounts2sd( 341): Moving /cache to /sd-cache...
12-14 13:05:18.440 V/mounts2sd( 342): Done!
df -h
Filesystem Size Used Available Use% Mounted on
tmpfs 202.9M 32.0K 202.9M 0% /dev
tmpfs 202.9M 0 202.9M 0% /mnt/asec
tmpfs 202.9M 0 202.9M 0% /mnt/obb
/dev/block/mtdblock3 250.0M 165.0M 85.0M 66% /system
/dev/block/mtdblock5 147.6M 62.4M 85.2M 42% /data
/dev/block/mmcblk0p2 960.7M 1.2M 959.4M 0% /sd-ext
/dev/block/mmcblk0p2 960.7M 1.2M 959.4M 0% /data/app
/dev/block/mmcblk0p2 960.7M 1.2M 959.4M 0% /data/app-private
/dev/block/mmcblk0p3 295.9M 168.0K 295.8M 0% /sd-cache
/dev/block/mmcblk0p3 295.9M 168.0K 295.8M 0% /cache
/dev/block/vold/179:1
6.2G 4.6G 1.6G 75% /mnt/sdcard
/dev/block/vold/179:1
6.2G 4.6G 1.6G 75% /mnt/secure/asec
This looks good, can you please confirm?
Also, why is /data not on ext partition but on phone memory?
Thanks for the script though!
Cheers, keep up the good work.

jukyO said:
This looks good, can you please confirm?
Also, why is /data not on ext partition but on phone memory?
Thanks for the script though!
Cheers, keep up the good work.
Click to expand...
Click to collapse
That looks as it should.
The whole /data is not moved to the /sd-ext for that simple reason that there are no hboot out there with 0mb /data.
I have options in my script to move both the .apk files (The applications) and the dalvik-cache which are the biggest things in the /data partition. If I moved everything to sd-ext, there would be nothing using the remaining space available on the internal data which is a waste of good space. It's like having an extra room in your house that is not used for anything at all. If we have to have it, we might as well use it
BTW:
You don't have dalvik-cache aktivated. So if you ever need more space on /data, activate it in /system/etc/mounts2sd.conf

dk_zero-cool said:
BTW:
You don't have dalvik-cache aktivated. So if you ever need more space on /data, activate it in /system/etc/mounts2sd.conf
Click to expand...
Click to collapse
Could you provide an example mounts2sd.conf file, so that all settings could be established at first boot. This would make it much easier when updating ROMS.

uzi2 said:
Could you provide an example mounts2sd.conf file, so that all settings could be established at first boot. This would make it much easier when updating ROMS.
Click to expand...
Click to collapse
You don't need a .conf file now - it's not used. You simply install the zip and then use the m2sd commands in terminal to make changes (see instructions in OP - type m2sd help for more info)

uzi2 said:
Could you provide an example mounts2sd.conf file, so that all settings could be established at first boot. This would make it much easier when updating ROMS.
Click to expand...
Click to collapse
The config files is deprecated and replaced with the "m2sd" command, as said above. Settings is saved to /data/.m2sd which means that it keeps your settings when you flash new ROM's as long as you don't wipe data.

FIX: extsd2internalsd broken after Verizon 4.1.2 OTA

Loong time lurker, first time poster. I couldn't post a reply in the development forum, obviously. Maybe someone can link to this in relevant threads over in development.
This is a guide for those who are/were using the extsd2internal to swap storage which no longer works after the 4.1.2 OTA or want to do take advantage of this mod: http://forum.xda-developers.com/showthread.php?t=1849860 OR it MIGHT work for other ROMs which want to use this method for the Galaxy S3.
After the OTA, and getting back up and running, I could not get the script to work correctly with this error: "no such file or directory" and doing some sleuthing, it seems Verizon (in their infinite wisdom) changed the mounts, or maybe it did this because gremlins/gnomes, maybe because Vzw/Samsung knows about the swapping method, who knows. Anyways, here is the fix that worked for me:
PreReqs:
Stock ROM 4.1.2 OTA
Rooted (duh)
BusyBox
SManager ads
Terminal Emulator
Root Explorer in R/W mode
extsd2internalsd mod installed/script in the correct place!
BACKUPS!! Make a nandroid backup before you do ANY tinkering people, and copy it to a safe place like your computer.
Let me be clear, for the love of bits and bytes, do not just keep one copy on the sdcard in the phone!!
1) To find the /dev/block/vold for the external sd card, open Terminal Emulator and run this command. Grant it root access when prompted:
Code:
su ls /dev/block/vold
Write down or make a note of the numbers. (For me there were only 2, 179:32 and 179:33) Now run these commands:
Code:
adb shell
cat /proc/mounts
There will be a whole lot of text that shows up, you are looking for "/dev/block/vold/179:xx" and in the same line there is "/storage/extSDCard"
Alternate method, after you are in shell run command and look for mmcblk1p1:
Code:
cat /proc/partitions
The number in the "minor" column, that's the new number!
Double-check that the blocks are right for the sd card's partition size.
Note: I tried using mmcblk1 and it didn't work, then tried mmcblk1p1 and VIOLA! Yay, trial and error.
2) In SManager, edit the extsd2internal script, and replace the 179:97 to 179:*new number* (again, for me it was 179:33)
3) Reboot or just "run" the script in SManger and wait a few moments, then check Settings>Storage.
Here is what my script looks like:
Code:
#!/system/bin/sh
#extsd2internalsd is a modification that allows to switch internal sd to external sd and viceversa. With this you can use default internal sd only for app storage #and the external sd to store all apps resource and all others stuff. The resut is a very big increase of installable apps on gs3
#All credits to Mattiadj of xda forum for the idea and script and to mike1986 for the cmw zip.
#xda thread url at http://forum.xda-developers.com/showthread.php?t=1772234
#Script Modified for U.S. Galaxy S3s by Zedomax at GalaxyS3Root.com to be compatible when sdcard is not inserted.
busybox mount -o remount,rw /
busybox mount -t vfat -o umask=0000 /dev/block/vold/179:33 /mnt/sdcard
busybox mount -t exfat -o umask=0000 /dev/block/vold/179:33 /mnt/sdcard
if busybox mount | busybox grep vold/179:33; then
busybox mount -o bind /data/media /mnt/extSdCard
fi
If this didn't work for you, I am a complete n00b, so I will do my best, but don't expect much.
Things to double check:
Permissions on the extsd2interal script in Root Explorer should have all the boxes checked EXCEPT the last 3 at the bottom.
SManager script should be set to "Su" and "Boot"
OTA Headaches? Use this guide to keep root and boot unlocked worked PERFECTLY: http://forum.xda-developers.com/showthread.php?t=2186574#8 I did a nandroid restore to pre-OTA since it borked the first go-around, and then used this method.
Take home message: MAKE BACKUPS!
Credits / Current Build of this mod:
http://forum.xda-developers.com/showthread.php?t=1772234
This mod does work, and just replacing the old with the new (still have to add it in SManager) will get the job done. The new script is significantly different, and I am sure there are reasons, but without a changelog...
Forum Community: Created the thread here because I couldn't find another thread specific to this environment with all the relevant information in one place. If anyone has seen any errors of my ways, please, please reply with what's up.

[HOWTO] Dual-boot Android ROMs, e.g. CROMI-X and CM

Tired of backup, wipe, flash, backup, wipe, restore, ... just to try a different ROM?
Today we will cook a nice tasty dual-boot for the TF700T. You will have two separate environments with different ROMs, apps and data that share only the common Linux kernel binary.
Difficulty: medium. No programming skills required, but not for noobs.
Ingredients
1 TF700T running a rooted stock-based ROM with busybox and a kernel with preinit support (hint: -that kernels work fine )
1 PC running Linux with a microSD card reader
1 fast microSD card with at least 4 GB
1 CyanogenMod 10.2 nightly ZIP (should also work for other ROMs - post your results)
1 seasoned chef
Time required: about 30 to 45 minutes.
Directions
Preheat oven to 220 degree celsius ... oops, wrong recipe.
If done right, the internal ROM and its data are perfectly safe. But I assume you have a backup nevertheless - don't blame me if anything goes wrong.
Prepare the microSD card
Insert microSD card into PC card reader. Using gparted, create and format 3 primary partitions:
p1: fat32, this will be your external sdcard as before.
p2: ext4, this will become /data
p3: ext4, this will become /system
Make sure to align the partitions to MiB, or even better multiples of 4 MiB. This may improve I/O performance.
In most cases you can simply shrink the existing FAT32 partition and then create the remaining ext4 partitions.
Partition 3 should be 700 to 800 MB - anything bigger is a waste of space, and anything smaller than 500 MB might cause problems.
Partition 2 will be your whole "internal storage" for the second operating system, so size it according to your storage needs for apps, app data and the emulated /sdcard.
I am using a Samsung 16 GB card with the following partition sizes:
p1: ~ 8 GB
p2: ~ 6 GB
p3: ~ 800 MB
Prepare the new ROM
Before installing the second ROM to the microSD card, the ZIP file must be slightly modified. I assume you know how to unpack and repack a ZIP file and how to use a text editor - if not, find a tutorial elsewhere. .
Note: This step can now be automated, see http://forum.xda-developers.com/showpost.php?p=47333729&postcount=31
To do it manually:
First, extract boot.blob and set it aside for later. Then carefully remove it from the ZIP. Second, find META-INF/com/google/android/updater-script and modify it:
Replace all occurrences of mmcblk0p1 with mmcblk1p3. I had 3 occurrences in CM's updater-script - make sure you modify all of them, otherwise your internal ROM might not survive the installation. This change will redirect the installation to the external microSD card. Finally, remove the line that says package_extract_file("boot.blob", ...) near the end - it would overwrite the kernel and we don't want that.
Now we need to add the WiFi modules. These are compiled directly into the CM kernel, but separate modules in the stock kernel.
Get the kernel modules from your running ROM - they are in /system/lib/modules (e.g. using adb pull /system/lib/modules), and copy at least these two into the ZIP into /system/lib/modules:
cfg80211.ko
bcmdhd.ko (note: for TF300, I think you need bcmdhd_29.ko instead)
Finally, repack the ZIP, mount the first partition of your microSD card and copy the ZIP file there.
Extract the ramdisk files
Note: This step can now be automated, see http://forum.xda-developers.com/showpost.php?p=47333729&postcount=31
To do it manually:
Here comes the tricky part. You need to extract the ramdisk from the boot.blob you saved from the ZIP file in the previous step.
To do that, you need tools that may not be in every household, but should be easy to find using your favorite search engine. In case you have trouble finding and/or compiling them, you can find the result of this step in post #2.
First we need to unpack the blob (https://github.com/AndroidRoot/BlobTools):
Code:
blobunpack boot.blob
This will create boob.blob.LNX. This is the boot image, from which we need to extract the ramdisk (https://github.com/huaixzk/unpackbootimg):
Code:
unpackbootimg -i boot.blob.LNX
This will create several files, we are interested in boot.blob.LNX-ramdisk.gz - copy this one to your tablet, e.g. into /sdcard. For example:
Code:
adb push boot.blob.LNX-ramdisk.gz /sdcard/
Prepare the preinit script and the ramdisk files
Note: This step can now be automated, see http://forum.xda-developers.com/showpost.php?p=47333729&postcount=31
To do it manually:
On the tablet, open a shell in a terminal app or use adb shell and become root (su). Run the following commands:
Code:
mount -o remount,rw /system
cd /system
mkdir boot
cd boot
mkdir rootfs_cm
cd rootfs_cm
gzip -d -c /sdcard/boot.blob.LNX-ramdisk.gz | cpio -i
The first line makes /system writable until the next reboot. The next few lines are self-explanatory. The last line uncompresses the ramdisk image we created in the previous step and extracts the contained files. We are doing this on the tablet itself to preserve the file permissions.
Now modify the file fstab.cardhu (one of the files just extracted).
Replace mmcblk0p1 with mmcblk1p3 and mmcblk0p8 with mmcblk1p2.
mmcblk0p2 can stay as it is, it's the /cache partition that is only used to communicate with the recovery.
Next we need to make sure the WiFi modules that we added are loaded at boot time. Edit init.cardhu.rc and find the "on boot" line. Add below (indentation is important):
Code:
insmod /system/lib/modules/cfg80211.ko
insmod /system/lib/modules/bcmdhd.ko
Near the end of init.cardhu.rc is another reference to mmcblk0p8 that needs to be modified to mmcblk1p2 - near "service setup_fs".
Finally create the file /system/boot/preinit with the following content:
Code:
#!/system/bin/sh
# preinit: only /sys and /system are mounted (ro), / is still rw
PATH=/sbin:/system/bin:/system/xbin
# auto-detect rom2sd
if [ -d /sys/block/mmcblk1/mmcblk1p3 ]; then
echo "\nsystem/boot/preinit: mmcblk1p3 detected, setting up for ROM2SD.\n"
cp -a /system/boot/rootfs_cm/* /
fi
Make sure to make it executable:
Code:
chmod 744 /system/boot/preinit
This script is run by the kernel before the real Android init. It. detects if a microSD card with 3 partitions is inserted, and if yes, it copies the files for the CM root filesystem into the ramdisk. The following Android boot procedure will then mount /system and /data to the partitions on the microSD card and the whole operating system will run from the microSD card. If no card is inserted, nothing is modified and the normal internal ROM is started.
Flashing the ROM
Insert your microSD card into the tablet, boot to TWRP and flash your modified ZIP as usual - but disable signature checking because we didn't sign the modified ZIP.
Recovery
The recovery doesn't know about the external ROM, so you can't use the recovery to backup or restore its system or data. I prefer using the PC for that anyway.
Booting
To boot from internal storage, make sure the microSD card is not inserted when you start the tablet (you can insert it as soon as the boot animation appears). To boot from the microSD card, make sure it is inserted before you turn the tablet on.
That's all. Add more microSD cards for triple-boot, quad-boot, etc.

Notes
My kernel currently has not enabled SELINUX in the config, but CM appears to work anyway.
Update: -that6 enables SELinux.
Shortcut
In case you don't want to extract the CM ramdisk from the blob yourself (or you have trouble finding/compiling the tools to do so), you can try using mine - from my unofficial build of cm-10.2-20131024: View attachment boot.blob.LNX-ramdisk.gz
Automated solution
See http://forum.xda-developers.com/showpost.php?p=47333729&postcount=31
(reserved for additions)

_that said:
Tired of backup, wipe, flash, backup, wipe, restore, ... just to try a different ROM?
Today we will cook a nice tasty dual-boot for the TF700T. You will have two separate environments with different ROMs, apps and data that share only the common Linux kernel binary.
Difficulty: medium. No programming skills required, but not for noobs.
Ingredients
1 TF700T running a rooted stock-based ROM with busybox and a kernel with preinit support (hint: -that kernels work fine )
1 PC running Linux with a microSD card reader
1 fast microSD card with at least 4 GB
1 CyanogenMod 10.2 nightly ZIP (should also work for other ROMs - post your results)
1 seasoned chef
Time required: about 30 to 45 minutes.
Directions
Preheat oven to 220 degree celsius ... oops, wrong recipe.
If done right, the internal ROM and its data are perfectly safe. But I assume you have a backup nevertheless - don't blame me if anything goes wrong.
Prepare the microSD card
Insert microSD card into PC card reader. Using gparted, create and format 3 primary partitions:
p1: fat32, this will be your external sdcard as before.
p2: ext4, this will become /data
p3: ext4, this will become /system
Make sure to align the partitions to MiB, or even better multiples of 4 MiB. This may improve I/O performance.
In most cases you can simply shrink the existing FAT32 partition and then create the remaining ext4 partitions.
Partition 3 should be 700 to 800 MB - anything bigger is a waste of space, and anything smaller than 500 MB might cause problems.
Partition 2 will be your whole "internal storage" for the second operating system, so size it according to your storage needs for apps, app data and the emulated /sdcard.
I am using a Samsung 16 GB card with the following partition sizes:
p1: ~ 8 GB
p2: ~ 6 GB
p3: ~ 800 MB
Prepare the new ROM
Before installing the second ROM to the microSD card, the ZIP file must be slightly modified. I assume you know how to unpack and repack a ZIP file and how to use a text editor - if not, find a tutorial elsewhere. .
First, extract boot.blob and set it aside for later. Then carefully remove it from the ZIP. Second, find META-INF/com/google/android/updater-script and modify it:
Replace all occurrences of mmcblk0p1 with mmcblk1p3. I had 3 occurrences in CM's updater-script - make sure you modify all of them, otherwise your internal ROM might not survive the installation. This change will redirect the installation to the external microSD card. Finally, remove the line that says package_extract_file("boot.blob", ...) near the end - it would overwrite the kernel and we don't want that.
Now we need to add the WiFi modules. These are compiled directly into the CM kernel, but separate modules in the stock kernel.
Get the kernel modules from your running ROM - they are in /system/lib/modules (e.g. using adb pull /system/lib/modules), and copy at least these two into the ZIP into /system/lib/modules:
cfg80211.ko
bcmdhd.ko
Finally, repack the ZIP, mount the first partition of your microSD card and copy the ZIP file there.
Extract the ramdisk files
Here comes the tricky part. You need to extract the ramdisk from the boot.blob you saved from the ZIP file in the previous step.
To do that, you need tools that may not be in every household, but should be easy to find using your favorite search engine.
First we need to unpack the blob (https://github.com/AndroidRoot/BlobTools):
Code:
blobunpack boot.blob
This will create boob.blob.LNX. This is the boot image, from which we need to extract the ramdisk (https://github.com/huaixzk/unpackbootimg):
Code:
unpackbootimg -i boot.blob.LNX
This will create several files, we are interested in boot.blob.LNX-ramdisk.gz - copy this one to your tablet, e.g. into /sdcard. For example:
Code:
adb push boot.blob.LNX-ramdisk.gz /sdcard/
Prepare the preinit script and the ramdisk files
On the tablet, open a shell in a terminal app or use adb shell and become root (su). Run the following commands:
Code:
mount -o remount,rw /system
cd /system
mkdir boot
cd boot
mkdir rootfs_cm
cd rootfs_cm
gzip -d -c /sdcard/boot.blob.LNX-ramdisk.gz | cpio -i
The first line makes /system writable until the next reboot. The next few lines are self-explanatory. The last line uncompresses the ramdisk image we created in the previous step and extracts the contained files. We are doing this on the tablet itself to preserve the file permissions.
Now modify the file fstab.cardhu (one of the files just extracted).
Replace mmcblk0p1 with mmcblk1p3 and mmcblk0p8 with mmcblk1p2.
mmcblk0p2 can stay as it is, it's the /cache partition that is only used to communicate with the recovery.
Next we need to make sure the WiFi modules that we added are loaded at boot time. Edit init.cardhu.rc and find the "on boot" line. Add below (indentation is important):
Code:
insmod /system/lib/modules/cfg80211.ko
insmod /system/lib/modules/bcmdhd.ko
Near the end of init.cardhu.rc is another reference to mmcblk0p8 that needs to be modified to mmcblk1p2 - near "service setup_fs".
Finally create the file /system/boot/preinit with the following content:
Code:
#!/system/bin/sh
# preinit: only /sys and /system are mounted (ro), / is still rw
PATH=/sbin:/system/bin:/system/xbin
# auto-detect rom2sd
if [ -d /sys/block/mmcblk1/mmcblk1p3 ]; then
echo "\nsystem/boot/preinit: mmcblk1p3 detected, setting up for ROM2SD.\n"
cp -a /system/boot/rootfs_cm/* /
fi
Make sure to make it executable:
Code:
chmod 744 /system/boot/preinit
This script is run by the kernel before the real Android init. It. detects if a microSD card with 3 partitions is inserted, and if yes, it copies the files for the CM root filesystem into the ramdisk. The following Android boot procedure will then mount /system and /data to the partitions on the microSD card and the whole operating system will run from the microSD card. If no card is inserted, nothing is modified and the normal internal ROM is started.
Flashing the ROM
Insert your microSD card into the tablet, boot to TWRP and flash your modified ZIP as usual - but disable signature checking because we didn't sign the modified ZIP.
Recovery
The recovery doesn't know about the external ROM, so you can't use the recovery to backup or restore its system or data. I prefer using the PC for that anyway.
Booting
To boot from internal storage, make sure the microSD card is not inserted when you start the tablet (you can insert it as soon as the boot animation appears). To boot from the microSD card, make sure it is inserted before you turn the tablet on.
That's all. Add more microSD cards for triple-boot, quad-boot, etc.
Click to expand...
Click to collapse
It is a nice detail instruction for new users like me. I really like it a lot and I can use some information from your post for my system2sd... However, maybe I misread your post. I don't see any information about repack the blob when you are done modifying the fstab.cardhu. I know a little bit of ramdisk and can get around it but that information will help the first time users... Just my opinion and thanks for sharing a valuable information to us...

LetMeKnow said:
However, maybe I misread your post. I don't see any information about repack the blob when you are done modifying the fstab.cardhu.
Click to expand...
Click to collapse
That's because you don't need to repack the blob or reflash the kernel - I wanted to simplify the procedure, so I added preinit support to the kernel's ramdisk a few months ago. You just put some files in /system/boot and the kernel will run your preinit script that modifies the ramdisk at boot time.
Just remember that if you reflash your internal ROM, you have to recreate the /system/boot stuff.

_that said:
That's because you don't need to repack the blob or reflash the kernel - I wanted to simplify the procedure, so I added preinit support to the kernel's ramdisk a few months ago. You just put some files in /system/boot and the kernel will run your preinit script that modifies the ramdisk at boot time.
Just remember that if you reflash your internal ROM, you have to recreate the /system/boot stuff.
Click to expand...
Click to collapse
Oop, I forgot that you use it in your boot folder... It is my bad.. I will give it a try when I am done with my system2sd testing and will ask more questions on the way.. Thanks for the information...
Cheers,
LMK

_that said:
Notes
My kernel currently has not enabled SELINUX in the config, but CM appears to work anyway.
(reserved for additions)
Click to expand...
Click to collapse
You should be fine until I enforce SELINUX. But I haven't finished the policies yet. Still have some issues to iron out with that. Have about 90% of them done, I think.. lol

Just out of curiosity, will this only work with primary partitions?

johnlgalt said:
Just out of curiosity, will this only work with primary partitions?
Click to expand...
Click to collapse
It should also work with logical partitions if you modify the partition numbers accordingly. And please remove the full quote of my guide from your post, we should not emulate an Outlook-style mess in the forum.
Sent from my ASUS Transformer Pad TF700T using Tapatalk 4

_that said:
It should also work with logical partitions if you modify the partition numbers accordingly. And please remove the full quote of my guide from your post, we should not emulate an Outlook-style mess in the forum.
Sent from my ASUS Transformer Pad TF700T using Tapatalk 4
Click to expand...
Click to collapse
Yeah, I quoted it that way b/c I was asking specifically about that part - but it that part works I suppose the rest would too, huh? :silly:

Wow
Thx for this, easy cheesey, Great work, Love the dual boot!!!!

_that said:
Tired of backup, wipe, flash, backup, wipe, restore, ... just to try a different ROM?
Today we will cook a nice tasty dual-boot for the TF700T. You will have two separate environments with different ROMs, apps and data that share only the common Linux kernel binary.
Click to expand...
Click to collapse
Is there any chance *someone with the required skills* could port bootmanager to our device?
BootManager
it would be the best, considering that your method uses the same load-from-sdcard thing.
Just curious thats all.

kali113 said:
Is there any chance *someone with the required skills* could port bootmanager to our device?
BootManager
it would be the best, considering that your method uses the same load-from-sdcard thing.
Just curious thats all.
Click to expand...
Click to collapse
Looks like commercial software, so ask the devs of that app.

Here is an experimental flashable zip file that redirects the TWRP recovery to the ROM2SD environment. It doesn't really install anything to storage, it just reconfigures the device nodes so that the recovery is tricked into accessing the system and data partitions on the microSD card instead of internal storage.
It works so well that after "installing" this, a following ROM install that unmounts and formats /system and installs itself to /system on mmcblk0p1 will actually be installed on the microSD card, so you don't need to replace the partition names in the updater-script any longer (but you still need to comment out the blob flashing line for now or reflash my kernel after the ROM).
It also works so well that after "installing" this, you don't see your internal /sdcard any longer, so put whatever you want to flash on the first partition of the external microSD card.
"Installing" the script again will undo its actions, so you can toggle back and forth between external and internal storage.
Warning: I tested this only once, and the script does not have any error handling - if the inserted microSD is not prepared for ROM2SD, behavior is undefined - most likely the recovery will complain that it can't mount system or data. Use this at your own risk and make sure you have backed up all valuable data and your ROM, just in case.
View attachment dev-rom2sd.zip
The script also contains a nice example how to output text from a shell script to the recovery console. It shows a list of device nodes so you can see what the script did (the device numbers of mmcblk0p1 and mmcblk1p3 are identical).

Can I follow this guide to have paranoid rom on internal and cromi-x rom on microsd?

vnphatbuddha said:
Can I follow this guide to have paranoid rom on internal and cromi-x rom on microsd?
Click to expand...
Click to collapse
I've never tried PA but it may work if you use my kernel and modify the preinit script accordingly (my kernel contains a stock-compatible ramdisk, so you need to copy the PA ramdisk to / if the microSD is *not* inserted).

_that said:
I've never tried PA but it may work if you use my kernel and modify the preinit script accordingly (my kernel contains a stock-compatible ramdisk, so you need to copy the PA ramdisk to / if the microSD is *not* inserted).
Click to expand...
Click to collapse
sorry for such a noob question but how do you compile the zips from the git links to an executable? Or does the bloobtool and unpackbootimg able to run from its extracted zips? slightly new to this...

vnphatbuddha said:
sorry for such a noob question but how do you compile the zips from the git links to an executable? Or does the bloobtool and unpackbootimg able to run from its extracted zips? slightly new to this...
Click to expand...
Click to collapse
You need to compile the blobtools on git. extract the .zip and run blobunpack on the .blob then abootimg -x on the boot.img.to repack: abootimg --create *new-bootimg* - k *zImage* -r *ramdisk*, then repack the .blob
and/or
follow this tutorial from the blob master himself http://forum.xda-developers.com/showpost.php?p=36925180

JoinTheRealms said:
You need to compile the blobtools on git. extract the .zip and run blobunpack on the .blob then abootimg -x on the boot.img.to repack: abootimg --create *new-bootimg* - k *zImage* -r *ramdisk*, then repack the .blob
and/or
follow this tutorial from the blob master himself http://forum.xda-developers.com/showpost.php?p=36925180
Click to expand...
Click to collapse
The problem I'm having is that I do not know how to use git to compile. What are the commands and do I input it in the top search bar of the site?

vnphatbuddha said:
The problem I'm having is that I do not know how to use git to compile. What are the commands and do I input it in the top search bar of the site?
Click to expand...
Click to collapse
You don't use git to compile, you use it to manage the source code.
To compile the source code, you need the appropriate development tools installed (I think it's called "build-essential" on Debian-like distributions) and run "make" in the directory with the extracted source code.

_that said:
You don't use git to compile, you use it to manage the source code.
To compile the source code, you need the appropriate development tools installed (I think it's called "build-essential" on Debian-like distributions) and run "make" in the directory with the extracted source code.
Click to expand...
Click to collapse
Wow this is too complicated to compile, having to setup and run debian on usb. Guess I can't try out rom2sd