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

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

Related

[MOD]Auto Swap Extention

What you need:
1. Swap Capible ROM with Root Access (see list below)
2. A third Partition on your SD card, known as Linux-swap set between 16-32MB (Easiest way to achieve that for free if you don't have linux with gparted is to download the Ubuntu ISO disk and install it on your system, all for free. can even be installed through Windows or run straight off the disk. you can also follow the link Here.)
3. Research
4. Terminal or ADB
5. Thumbs
What to do:
1. download the attached file and copy it to your sdcard, unmount sdcard from computer.
2. in terminal or adb shell type:
don't type things in ().
Code:
$su (terminal only)
#mv /sdcard/userinit.sh /system/sd/
#chmod 775 /system/sd/userinit.sh
#sh /system/sd/userinit.sh
This should do it, no reboot required. if you want to verify that you have your swap space running now or after a reboot simply type:
Code:
#free
you should see total memory to the right of "Swap" be filled in with the number of bytes you set.
A little bit about Swap on the G1:
Swap partitions are currently completely seperate from ROMs. all ROMs should be able to do this, however I'm not specfically certain and don't have the time or patience to try in or do research for it.
YOU DO NOT NEED TO FLASH YOUR ROM AT THE SAME TIME TO GET THIS TO WORK. In fact, you will have to do this everytime AFTER you do a new flash or wipe. I'm getting mixed reports about this, I myself didn't have to redo this after flashing CM 3.5.3, however it is possible that some are not mounting /system before pushing/copying the file over, which makes thier effort pointless and explains the confusion!
Other Notes:
This script was written by Dwang, I had no part in it, I'm just trying to make it easier and seperate it from Cyanogens mod threads.
Also please understand that Linux does ./sdcard/ and /sdcard/ in linux, nor is there any difference from /sdcard/tmp/ and /tmp/ when you prompt to /sdcard/ (ie, typing cd /sdcard or cd sdcard)
Also, please do not set up your linux swap over 32MB, you're asking for trouble.
Swap Capible ROMs (Dev's PM me if you incorperate this into your ROM):
Cyanogen's MOD 3.5.2 + higher
JACHero w/ http://forum.xda-developers.com/showpost.php?p=4054111&postcount=19
Thank you.. will give this a try and let you know.
A small .bat file would be nice for this since it has to be done after every flashing
We might need a .bat file for all the .bat files i'm collecting.
Wasnt this experimental in CM's rom and it ran "sluggish"?
Unsure, and it runs fine. as far as a .bat.... why? it's all .sh. does .bat even work in linux?
Denkai said:
What you need:
YOU DO NOT NEED TO FLASH YOUR ROM AT THE SAME TIME TO GET THIS TO WORK. In fact, you will have to do this everytime AFTER you do a new flash or wipe.
Click to expand...
Click to collapse
I thought userinit.sh on /system/sd would survive a flash an/or wipe?
Also you might add that mkswap should be run once on a newly created swap partition.
looking over the userinit.sh...........
What exactly does this, .sh, do??
bkmo said:
I thought userinit.sh on /system/sdcard would survive a flash an/or wipe?
Click to expand...
Click to collapse
/system/sdcard doesn't exist. it's /system/sd and no, it doesn't it gets copied over.
Mikey1022 said:
looking over the userinit.sh...........
What exactly does this, .sh, do??
Click to expand...
Click to collapse
first part checks to find the 3rd partition and sets it up as linux swap. the second script checks for media files meant for ring tones and seperates them so that the file doesn't show up twice in your music player.
Denkai said:
/system/sdcard doesn't exist. it's /system/sd and no, it doesn't it gets copied over.
Click to expand...
Click to collapse
Sorry system/sd ...I was editing the post to correct it when you replied. I re-flashed cyanogen 3.5.2 without a wipe and userinit survived.
Denkai said:
/system/sdcard doesn't exist. it's /system/sd and no, it doesn't it gets copied over.
Click to expand...
Click to collapse
/system/sd doesn't get copied over on a flash - that's why userinit.sh is placed there, so users can put custom commands in a location where the ROM (just CM, AFAIK) will know to execute them.
If you aren't running CM 3.5.2 or greater you'll need to set this up somehow so that it is run on boot. Cyanogen has a line added to his A2SD script that will do that.
Now.. Any advice on how to create my swap partition if I don't have a memory card reader to use on a PC w/ Ubuntu? I tried a gparted live cd on my GF's Thinkpad, but the card reader wasn't detected. I'm sure there's some way to do it at the command line, but my linux-fu is out of practice and I never did mess with partitions much.
BTW, thanks for posting - I saw this in the CM experimental thread but kept forgetting to install, until I saw this post. Doing it now
Saiboogu said:
Now.. Any advice on how to create my swap partition if I don't have a memory card reader to use on a PC w/ Ubuntu? I tried a gparted live cd on my GF's Thinkpad, but the card reader wasn't detected. I'm sure there's some way to do it at the command line, but my linux-fu is out of practice and I never did mess with partitions much.
Click to expand...
Click to collapse
Gparted was not detecting my SD reader on my Dell until I installed the newest Gparted from source on Ubunty Jaunty.
bkmo said:
Gparted was not detecting my SD reader on my Dell until I installed the newest Gparted from source on Ubunty Jaunty.
Click to expand...
Click to collapse
OK -- I should have tried a Jaunty disk anyway, I just got sidetracked by the gparted disk not working. I'll try the newer Gparted version with that. Thanks.
Thanks for making a separate thread. You should probably put the post I wrote on how to make a swap partition in your first post.
http://forum.xda-developers.com/showpost.php?p=4029519&postcount=145
Instead of running it again and again, I would prefer it to be added to runme.sh in boot.img... so that it will be run automatically on every boot...
I am trying it now...
it only gets run once on boot, I believe. will add that post, thanks.
what level swappiness is everyone finding optimal?
i'm on a non class 6 microsd and if i set swappiness over 30, it doesn't take long for the system to get bogged down by IO
alapapa said:
what level swappiness is everyone finding optimal?
i'm on a non class 6 microsd and if i set swappiness over 30, it doesn't take long for the system to get bogged down by IO
Click to expand...
Click to collapse
yeah I think 30 may be a bit too high. I'm using 10 or 20 now.
Try 100 It actually makes the phone super responsive at first, but then it starts getting very laggy after a while.
sangeet.003 said:
Instead of running it again and again, I would prefer it to be added to runme.sh in boot.img... so that it will be run automatically on every boot...
I am trying it now...
Click to expand...
Click to collapse
The script was written for cyanogen's ROMs 3.5.2 or greater.
Those ROMs will automatically execute /system/sd/userinit.sh on bootup. Which means no modifying anything in update.zip
The attached boot image is for JACHERO 2.~r6 I have added the script to the runme.sh to mount swap on every boot i am trying to add the .29 kernel which has multitouch....
The swappiness is set to 80 which I feel Works Great Means +20 than the system Default(60) swappiness...
I have not tested it Coz i cant Partition the Sdcard currently with 1 more partition, Will be testing it later say in 5-6 hours...
Testers are appreciated...
Just extract it on computer & fastboot flash it.... on the boot partition...
Noobs Dont Try It
Saiboogu said:
/system/sd doesn't get copied over on a flash - that's why userinit.sh is placed there, so users can put custom commands in a location where the ROM (just CM, AFAIK) will know to execute them.
If you aren't running CM 3.5.2 or greater you'll need to set this up somehow so that it is run on boot. Cyanogen has a line added to his A2SD script that will do that.
Now.. Any advice on how to create my swap partition if I don't have a memory card reader to use on a PC w/ Ubuntu? I tried a gparted live cd on my GF's Thinkpad, but the card reader wasn't detected. I'm sure there's some way to do it at the command line, but my linux-fu is out of practice and I never did mess with partitions much.
BTW, thanks for posting - I saw this in the CM experimental thread but kept forgetting to install, until I saw this post. Doing it now
Click to expand...
Click to collapse
If you mount the sdcard from the menu bar (USB), it will also mount the ext partition too. From there u should b able to partition from within Ubuntu.

[UTIL] sdparted v0.6 - easy sdcard partitioning, upgrading to ext3/4

this script automates the process of partitioning a sdcard on your android device. it should work fine for all sizes/types of sdcards, but since i can't test all sizes/types of sdcards, we'll have to see.
if you are running into problems with the script, post the log file(located at /data/sdparted.log) when asking for help.
big ups to cyanogen (parted and upgrade_fs) and Denkai (upgrading to ext4).
i welcome all comments, questions & suggestions, related to the script. this is NOT a general q&a.
read the ENTIRE post BEFORE asking questions, please.
to manually partition your sdcard see my other thread.
DISCLAIMER: i take no responsibility for what happens to you, your phone, sdcard, data, sanity, etc if you use this script. remember to backup your sdcard to your pc before you begin. this script has the potential to COMPLETELY WIPE your sdcard!
##########################
shameless promotion:
sdparted can also be found in amon_ra's recovery and natalic's android toolkit.​
##########################
features:
-automated partition of sdcard using parted
-upgrading to ext3/ext4
-downgrading to ext2
-interactive mode
-supports units (M and G)
-supports floating point partition sizes (ie. .5G=512M)
-automatic logging to /data/sdparted.log​
##########################
requirements:
android phone with proper utilities(cm-recovery-1.4, amon_ra's recovery)
sdcard <--class 6 recommended(adata makes good ones...they max out the g1 hw in terms of speed)
adb
fingies​
##########################
Code:
sdparted v0.6 created by 51dusty
if you use this script in your work, please give some credit. thanks.
requirements: cm-recovery-v1.4
usage: sdparted [options]
options:
--fatsize|-fs SIZE[MG] set the size of the fat32 partition to <SIZE>.
default=total sdcard size - (ext + swap)
--extsize|-es SIZE[MG] set the size of the ext partition to <SIZE>.
default=512M
--swapsize|-ss SIZE[MG] set the size of the swap partition to <SIZE>.
if set to 0, no swap partition will be created.
default=32M
--extfs|-efs TYPE set the filesystem of ext partition to <TYPE>.
valid types=ext2, ext3, ext4
default=ext2
--upgradefs|-ufs TYPE upgrades existing ext partition to <TYPE>.
this operation will NOT wipe your sdcard and
cannot be used with any partition creation options.
valid types=ext3, ext4
--downgradefs|-dfs TYPE downgrades existing ext partition to <TYPE>.
this operation will NOT wipe your sdcard and
cannot be used with any partition creation options.
valid types=ext2
--interactive|-i interactive mode
--help|-h display this help
--printonly|-po display sdcard information
--silent|-s do not prompt user, not even initial warning.
examples:
sdparted creates swap=32M ext2=512M fat32=remaining free space
sdparted -efs ext4 creates swap=32M ext4=512M fat32=remaining free space
sdparted -fs 1.5G -efs ext3 creates swap=32M ext3=512M fat32=1536M
sdparted -es 256M -ss 0 creates no swap ext2=256M fat32=remaining free space
sdparted -ufs ext4 upgrades ext partition to ext4
##########################
need to backup your ext partition?
the following commands will backup/restore your ext partition to/from a folder named sdbackup in your current directory. these must be run while phone is booted, not recovery.
to backup your ext partition: adb pull /system/sd/ %CD%\sdbackup
to restore back to sdcard: adb push %CD%\sdbackup /system/sd
##########################
to run from computer:
1. download sdparted.txt below to computer
2. connect g1 via usb
3. boot into cm-recovery-v1.4, goto console(alt-x)
4. at your windows cmd prompt type: adb push /path-to/sdparted.txt /sbin/sdparted
5. then type: adb shell chmod 755 /sbin/sdparted
6. to run type adb shell and hit enter.
7. you can now run script (ie. sdparted -efs ext4).​
to run w/o computer:
1. download sdparted.txt below to root of sdcard. (get downloadcrutch if needed*thnx lycoln)
2. boot into cm-recovery-v1.4, goto console(alt-x)
3. at # prompt type: mount /sdcard
4. then, mv /sdcard/sdparted.txt /sbin/sdparted
5. then, chmod 755 /sbin/sdparted
6. you can now run script (ie. sdparted -efs ext4).​
you CANNOT run this script from terminal app.
##########################
if the script crashes or you receive an error:
immediately pull the log to your computer(using adb pull /data/sdparted.log sdparted.log), b/c the log will not be there after a reboot. send me the log when reporting errors, please.
##########################
changelog:
changes in v0.6
*new feature=interactive mode
*tweak user abort function for those with itchy fingers
changes in v0.5.3
*remove initial warning(kinda pointless if there is another before you wipe)
*clean partition table handling code
*general code cleanup/consolidation in anticipation of new features
changes in v0.5.2
*handling of "partition 1 may not be aligned to cylinder boundaries", fixing "sh: -gt: argument expected" and related phenomena (ie. sdparted trying to partition using negative numbers ) reported by midtoad
changes in v0.5.1
*slight change to logging(so slight it only gets a .1), fixing "/sbin/sdparted: line 5: .//sbin/sdparted: not found"
changes in v0.5
*new feature=floating point partition sizes
*new feature=downgrade ext filesystem (ext3->ext2 ONLY, for now)
*fix some crappy programming
changes in v0.4
*unmount all partitions before operations, fixing "Error: Partition(s) on /dev/block/mmcblk0 are being used".
*remove some useless code
changes in v0.3
*new feature=logging
*new feature=units
*new feature=print card info
changes in v0.2
*add cm-r-v1.4 check to prevent running in 1.3.1
##########################
todo items:
-downgradefs support for ext4
##########################
Excellent!
One of the easiest things Ive done in a while. Worked great!
great.
i'm new to android, so i have a question.
I'm guessing when you go to settings and eject SD card, it only unmounts the FAT32 partition, right?
So does that mean the only safe way to eject the card is shutting down?
great job!
SyXbiT said:
great.
i'm new to android, so i have a question.
I'm guessing when you go to settings and eject SD card, it only unmounts the FAT32 partition, right?
So does that mean the only safe way to eject the card is shutting down?
great job!
Click to expand...
Click to collapse
That depends which ROM you are running and how it's set up. CyanogenMod for example, will automatically use the Ext partition for Apps-to-SD if it finds one. Ejecting a card while the phone is using it as part of its internal memory would be a Bad Thing™.
If you are running the stock firmware, it would be safe to remove the card after ejecting it in settings.
Could anyone at their convenience post directions for using this with console,
and where to place text attached? Funny, I've done this the manual way but don't know the simple things.
Thanks in advance for your work and patience. =)
Figured this one out!
Can you tell me how exactly to run this script? I ran this in recovery and i get sdparted not found.
sacredsoul said:
Can you tell me how exactly to run this script? I ran this in recovery and i get sdparted not found.
Click to expand...
Click to collapse
where did you place the file? did you run chmod?
excellent! Great job dusty
sacredsoul, Make sure you have the latest Cyanogen's Recovery Image, which I used 1.4. I got the same error using 1.31. I then updated to 1.4 and it worked perfectly. great Post 51dusty.
i am tryin to do this...hw do i get in recovery mode and wat exactly im i typin?..i hav a 4gig
Just wanted to chime in and say this script worked beautifully for me on a 16gb card.
Thanks!
I don't get it, am I mounting first, placing the file on the SD, then rebooting into recovery? The instructions make it sound as if I can just boot into console and pull it off my machine. Many people might find that confusing.
ctheory83 said:
I don't get it, am I mounting first, placing the file on the SD, then rebooting into recovery?
Click to expand...
Click to collapse
...i don't say to mount anything.
ctheory83 said:
The instructions make it sound as if I can just boot into console and pull it off my machine.
Click to expand...
Click to collapse
actually, you can...but you push instead.
51dusty said:
to install from computer, download, boot into cm-recovery-v1.4, goto console, and adb push /path-to/sdparted.txt /sbin/sdparted, then adb shell chmod 755 /sbin/sdparted. you can now run the script from adb(in recovery) or from g1 recovery console.
Click to expand...
Click to collapse
i will edit post to make installation less "confusing"...done.
Hey dusty i been struggling with this for like a week now and finally decided to post! so i got the adb thing running on my pc, windows 32-bit and it finds my device when i put the command "adb devices", so that far im fine but then your instructions tell us to boot the phone into recovery console and the type "adb shell" the result comes up "no adb found", at this point i have tried it with my phone plugged into the pc and unplugged without mounting it from the G1... please help what am i doing wrong im really confused! thanks!
The script is great i finally figured it out how to work this thing, but i just a bit of an issue now, when i keep installing apps my internal storage is also getting reduced a bit, i have installed about 100mb of apps and my internal storage reduced to 67 from 70mb, i have already cleared cache, using the app to move it to sd card, and also turned my phone off and took out the battery and rebooted, but its standing at 67mb... does this possibly have anything to do with protected apps??? please help!!
adb not found
hi,
it says adb not found, what am i doing wrong ?.
so my problem is that im not quite sure on what you mean by the path in the following command
adb push /path-to/sdparted.txt /sbin/sdparted
i know that you mean where ever the file is located but, for instance i just put mine in the c drive, so it should be adb push /c drive/sdparted.txt /sbin/sdparted
what is the correct way that should look?
edit: ok so i found my problem, i tried to install it from the adb shell, that was wrong, and this is the string in windows cmd i used for sdparted located just on the c drive
"adb push %cd%\sdparted.txt /sbin/sdparted" it then says the speed it was written, etc. does that mean it is correctly installed? from here, im not too sure how to go about setting up my partitions, again im very new to this.
you can now run the script from adb(in recovery) or from g1 recovery console.
Click to expand...
Click to collapse
Everything went okay, only the last stap with running from adb i dont understand.
What command is that ?
CoopZor said:
Everything went okay, only the last stap with running from adb i dont understand.
What command is that ?
Click to expand...
Click to collapse
i have edited first post to clarify how to run.
to run, from adb:
1. boot into cm-recovery-v1.4, goto console(alt-x)
2. at windows prompt, type adb shell and hit enter.
3. once connected via adb, you can now run script (ie. sdparted -efs ext4).
Click to expand...
Click to collapse

[HOW-TO] ROM-HACKING: init.rc ext2-auto-mount / ROM Signing / ROM Kitchen

AS MENTIONED IN THE INTRODUCTION TEXT THIS HAS ONLY BEEN TESTED ON AMON RA ROM 1.6.2 BUT SHOULD REALLY WORK ON ANY ROM THAT HAS NO EXT2 AUTO-MOUNT. AND YEAH THIS WHOLE PROCESS HAS BEEN DONE ON A 32a BOARD. FOR THOSE THAT TRY THIS ON OTHER ROMS LET ME KNOW HOW IT GOES.
I've searched and shuffled through the entire forum and made inquiries to ROM authors without much light being shed on this issue. I doubt I am the only one who has been looking for a way of doing this so I decided to do a small HOW-TO. Here I will explain step by step as to how you can implement a script to be part of your ROM that will auto mount an ext2 partition on boot up if such partition is present. I have included all the tools I've used in order to pull this off, and as the title suggests this has only been done on Amon Ra's latest 1.6.2 ROM. In order to follow these instructions you are expected to allready have set up an adb enviroment on your linux box and for the signing process to work you must have sun-java present, the gnu java wont work. And of course a microSD card with an ext2 partition
1. Download install.sh to your home directory
Code:
wget http://www.grindhouse.no/androidtools/install.sh
chmod a+x install.sh
2. Now execute the install.sh script which will create a directory to work in and download a tool and script package and unpack it.
Code:
./install.sh
When the install.sh script is done you need to move the mkbootimg preferebly to your tools directory of your SDK.
Code:
mv toolstomove/mkbootimg <path/to/sdk/tools/mkbootimg>
3. Unpack the RA1.6.2 ROM into a directory in your home dir. In this HOW-TO we will use directory name "ra1.6.2" as an example through out the entire process.
4. Copy the boot.img from ra1.6.2 to the ROM-cooker dir
Code:
cp $HOME/ra1.6.2/boot.img $HOME/ROM-cooker/boot.img
cd $HOME/ROM-cooker
5. Use unpack.pl to extract the ramdisk from the boot image. I've modified the script a little so it automates the entire process and decompresses the ramdisk to a directory
Code:
./unpack boot.img
6. Now you can either replace the init.rc file here with the one I've included in this package or you can add these lines by yourself. In wich case do the following
Code:
cd boot.img-ramdisk
pico init.rc
Press CTRL+w and then CTRL+t and input 27. hit enter. This will take you to line 27 of init.rc so you can add a line right before the init process remounts the rootfs in read-only mode. Add following line:
Code:
mkdir /sdext2 0771 system system
Now scroll down to the end of the init.rc file and add the following:
Code:
service mountsdext2 /system/bin/mountsd
user root
group root
oneshot
7. You have now edited (or replaced) your init.rc file and prepared it to execute a script on boot that will detect an ext2 partition and boot it if there is one to be found. Now you have to make the mountsd script a part of the ROM. Do the following:
Code:
cd $HOME/ROM-cooker
mv toolstomove/mountsd $HOME/ra1.6.2/system/bin/mountsd
rm -rf toolstomove
8. Now that the init.rc file is sorted out and mountsd has been placed in /system/bin of the ROM so it is time to re-pack the boot.img:
Code:
cd $HOME/ROM-cooker
./repack boot.img-kernel boot.img-ramdisk boot.img
rm $HOME/ra1.6.2/boot.img
mv boot.img $HOME/ra1.6.2/boot.img
9. Your ROM now has a new boot image with an updated init.rc and the /system/bin dir has the script needed to auto-mount the microsd ext2. Now you must re-zip the ROM and sign it. Do the following:
Code:
cd $HOME/ra1.6.2
zip -r update.zip *
mv update.zip $HOME/ROM-cooker/update.zip
cd $HOME/ROM-cooker
./sign.pl update.zip
10. The ROM is now signed and you now have a file called update-signed.zip. Connect the phone to your computer and execute thus:
Code:
./push update-signed.zip
11. Now you are ready to flash the modified ROM which will auto-mount an ext2 partition on your microSD. There is no need to wipe before flashing. If you have no prior experience with ROM flashing or whatever just backup your current install. If you're using OpenHOME or anything similar, nothing will be changed or damaged but if you're using MontAlbert's themes with the ROM you will have to flash them again after flashing this modified ROM.
Code:
adb reboot recovery
12. Flash from choose zip and of course choose update-signed.zip. Reboot. After the system boots up again you can now check whats what with either one of the commands:
Code:
[email protected]:~$ adb shell mount | grep sdext2
/dev/block/mmcblk0p2 on /sdext2 type ext2 (rw,noatime,nodiratime,errors=continue)
[email protected]:~/boot$ adb shell busybox df -h | grep sdext2
/dev/block/mmcblk0p2 893.7M 13.0K 846.0M 0% /sdext2
13. Voila! Your RA 1.6.2 ROM now detects and mounts your microSD ext2 partition on boot. Woohoo?
I hope the HOW-TO was easy reading and that you have succeeded in hacking up your ROM. I know that certain ROMs have this as a built-in function but Amon Ra's does not. But since alot of people including myself use his ROM because of the high speed and stability I thought I should contribute to his project and add a cool (and missed?) function to it.
Mind you that you can use the ROM-cooker set to further adjust and hack up the ROM as you see fit. Happy learning!
Very nice!
Now the question many people will ask : why would you automount ext2 if you don't use apps2sd ?
I personally have ubuntu on my ext2 And besides this approach can be used for a number of things, people who have had the need, or wanted to experiment with init.rc doing things on boot, the mountsd script can easily be altered to do what ever needed.
For me its been a learning curve finding these things out, so by sharing it I may spare some people breaking their backs over this whole init.rc thing. people may want to modify init.rc for whatever reason, so I'm sure people wont have a problem finding a way of putting this to use, and its a subject that isnt all that covered on the forum .. and hey .. at least they get a rom kitchen out of the whole shabang
Very interesting! Thank you.
I used your unpack-program to unpack a recovery-image. It seems to work fine. What I am trying to do is change the state the recovery-image returns the phone to. Would it be possible to just replace your mountsd-script with, for example, a script that installs apps? Or is there a better way to do what Im trying to achieve?
Cheers,
edit: I noticed that on the emulator it is sufficient to just place an apk-file in "data/app" to get it installed. Could it be possible that this is all I need a script to do? :O or could I hurt my poor phone by doing so you think?
sandis84 said:
edit: I noticed that on the emulator it is sufficient to just place an apk-file in "data/app" to get it installed. Could it be possible that this is all I need a script to do? :O or could I hurt my poor phone by doing so you think?
Click to expand...
Click to collapse
That's indeed all you need to do.
Hi!
So I tried to create a signed update.zip, but it failed. It didnt create a "update-script"-file, so my device refused to install it. I wrote my own "update-script"-file, but then it complained "no digest" for the file. How do I solve this?
post the contents of your script people might see whats up
so is this all on linux?
also where are the script files for your tutorial
thanks for the time to put together
sitimber said:
so is this all on linux?
also where are the script files for your tutorial
thanks for the time to put together
Click to expand...
Click to collapse
Says where its at in the first line : )
Code:
wget http://www.grindhouse.no/androidtools/install.sh
But now that I checked, I have to apologize, I see I have a missed payment with my hosting, I'll fix that within the day. Also sorry I havent been answering the few questions here I've been afk cause of surgery.
sitimber said:
post the contents of your script people might see whats up
Click to expand...
Click to collapse
well, I looked in another "update-script" file and found this:
assert compatible_with("0.2") == "true"
assert getprop("ro.product.device") == "dream" || getprop("ro.build.product") == "dream"
show_progress 0.5 0
write_radio_image PACKAGE:radio.img
show_progress 0.5 10
Click to expand...
Click to collapse
So I figured that nothing was essential other then the line "write_radio_image PACKAGE:radio.img". Also ofcourse I made sure it contained the name of my image-file instead of "radio.img". This gave me the "no digest" message, so now I feel unsure on how to create a working update.zip.
edit:
SOLVED! How silly of me. When you sign the update, a hash of each file is put in manifest.mf. Since I added the update-script after signing the file, ofcourse the digest(hash) was missing. Now everything works alot better and I can proceed... until I get stuck again
Cheers,
edit2:
Just to get a better understanding, what exactly does each line do here? Or where can I read about this?
Code:
service mountsdext2 /system/bin/mountsd
user root
group root
oneshot
edit3:
Ok, so I have experimentet, but I still dont manage to solve those last steps. I tried to edit init.rc and just add "mkdir /testdir 0000 system system" where the other directories were created. I then repacked it, zipped it, signed it, put it on my sdcard, started up a custom recovery, installed the update and rebooted. Everything seems to work fine. But when I start adb and check around, I dont see the "testdir"-directory. Also when I check in init.rc my line is gone. Do you guys have an idea of where I went wrong?
sitimber said:
so is this all on linux?
also where are the script files for your tutorial
thanks for the time to put together
Click to expand...
Click to collapse
it doesnot necesarily have to be linux ...you can also do it in windows using cygwin and dsxda's android rom kitchen

[KERNEL/MOD] [LINUX] [Rootbind] [Native EMMC/all TF101&TF101G/fast/tested] [2-Jul-13]

[KERNEL/MOD] [LINUX] [Rootbind] [Native EMMC/all TF101&TF101G/fast/tested] [2-Jul-13]
UPDATE 2013/11/08: New kernel released with USB and framebuffer fixed. See post #3.
UPDATE 2014/05/16: New Ubuntu 14.04 filesystem. See point #2 below under Installation.
UPDATE 2014/06/03: New kernel released with USB and framebuffer fixed, OC to 1.5 GHz. See post #3 and #326.
UPDATE 2014/07/09: New kernel released with OC to 1.5 GHz fully working, boots every time. See post #3 and #334.
This is a kernel/initrd mod that allows you to run Linux (Ubuntu, Debian, Arch,...) on your TF101 from the internal EMMC (/data partition in Android) without repartitioning your tab.
Disclaimer:
This works on my tablet and I use it daily. However, I am not responsible for any bricks or if you damage your beloved TF. YOU ARE DOING THIS AT YOUR OWN RISK!
Features and advantages:
Fast (and I mean about as fast as it's gonna get on this device). See post #2 for benchmarks.
No need to repartition to get this. Previously TF101 users could run Linux on EMMC but they had to repartition with wheelie/nvflash, but it wasn't available to TF101G users (of which I'm one).
Any free space on your /data partition is available to both Linux and Android. When you delete stuff on either operating system, the free space is available for both again, as they are running off the same partition. Previously, when you re-partitioned e.g. with OLiFE you had to allocate a certain space (8GB by default) for Linux, then this was not available for Android even if you're not using all of it in Linux.
Way faster than loopmount, especially for disk writes.
Way faster than running Linux off a MicroSD card ext4 partition (even with class 10).
Dualboot is achieved just by flashing either the Android or the Linux kernel.
So how does this work?
The kernel/initrd is modded to take an extra parameter "bind=/path/to/linux/rootfs" on the command line. This will then bind-mound that path to the Linux root mount. It works pretty similar to the way a loop-mounted linux image is loaded and set up during boot, except that now bind-mount is used, not a loop-mount. This is possible because both Android and Linux use the ext4 filesystem, so they can actually share the same partition.
N.B. This thread is not a guide on how to get Ubuntu running on your TF101. There are plenty of guides for that, e.g.
http://forum.xda-developers.com/wiki/ASUS_Eee_Pad_Transformer/How_to_install_Ubuntu
http://forum.xda-developers.com/wiki/ASUS_Eee_Pad_Transformer/How_to_install_Ubuntu/Ubuntu_Install
Tubuntu by x3maniac - http://forum.xda-developers.com/showthread.php?t=1995157
Net-Install by NoDiskNoFun - http://forum.xda-developers.com/showthread.php?t=1852702
Transformazing by transformador - http://forum.xda-developers.com/showthread.php?t=2167224
Make sure to read those threads to get an idea of how this works.
READ THESE INSTRUCTIONS CAREFULLY!
Installation:
Take a Nandroid backup, just in case something goes wrong.
Get a Linux root filesystem if you don't already have one.
See this thread for a discussion of various filesystems available for rootbind.
Alternatively roll your own using debootstrap as described by shaola:
http://forum.xda-developers.com/showthread.php?t=1476835
NEW! For a fully working Kubuntu 14.04 image (with graphics acceleration using the Nvidia drivers) see this post: http://forum.xda-developers.com/showpost.php?p=52697775&postcount=303
This is already an image in a tar file so it doesn't need to be mounted, so instead of the code below you can merely do the following:
Code:
mkdir -p /data/linuxroot
busybox chmod 755 /data/linuxroot
cd /data/linuxroot
tar -xpjf /path/to/my/saved/kubuntu-14.04.tar.bz2
Running Android, copy the root filesystem to a directory on your /data partition, preserving the permissions. The easiest is with the "tar" command (see below). The default install assumes that Linux lives in /data/linuxroot under Android.
For a Linux image in a file that is used for loop-mount (assume it is in /sdcard/ubuntu.img, or edit accordingly), run the following in a terminal when running Android (make sure you are root):
Code:
busybox mount -o remount,rw /
mkdir -p /data/linuxroot
busybox chmod 755 /data/linuxroot
mkdir -p /mnt/ubuntu
busybox mount -o loop /sdcard/ubuntu.img /mnt/ubuntu
cd /mnt/ubuntu
tar -cvp * | tar -C /data/linuxroot -xp
cd /
busybox umount /mnt/ubuntu
rmdir /mnt/ubuntu
busybox mount -o remount,ro /
(note in tar command first -c is lowercase, second -C is uppercase)
For a Linux rootfs that lives on a separate partition (e.g. 2nd part. on MicroSD), run the following (assumes linux is in /dev/block/mmcblk1p2, otherwise edit accordingly):
Code:
busybox mount -o remount,rw /
mkdir -p /data/linuxroot
busybox chmod 755 /data/linuxroot
mkdir -p /mnt/ubuntu
busybox mount -t ext4 /dev/block/mmcblk1p2 /mnt/ubuntu
cd /mnt/ubuntu
tar -cvp * | tar -C /data/linuxroot -xp
cd /
busybox umount /mnt/ubuntu
rmdir /mnt/ubuntu
busybox mount -o remount,ro /
Copy kernel modules to your rootfs. Download modules-3.1.10-9.tar.gz to your /sdcard. then:
Code:
cd /data/linuxroot/lib/modules
tar -xzf /sdcard/modules-3.1.10-9.tar.gz
Flash the Linux kernel. Either flash the zip from recovery or copy the kernelblob directly to the staging partition with dd (if you don't know what I'm talking about here, then use the recovery method).
Reboot 'n enjoy! Remember to run "sudo depmod -a" after the first Linux boot, and reboot. Otherwise your modules won't load and wifi, etc., won't work.
To re-boot into Android, simply flash the boot image/kernelblob from your Android ROM.
Notes:
The kernel is compiled from Jhinta's source with a few modifications to the config - http://forum.xda-developers.com/showthread.php?t=1683145
Make sure not to have a /host directory in your Linux rootfs - this interferes with the bind mount!
The Linux rootfs can live anywhere on your Android /data partition (the default is /data/linuxroot). If you want to change this, then you'll have to blobunpack the kernelblob-rootbind, unpack the boot image (kernelblob-rootbind.LNX) with abootimg, change the command line as desired, re-pack the boot image with abootimg, and re-pack the blob for flashing.
The "bind" cmdline argument is the location of your Linux rootfs without the initial "/data". So if your Linux rootfs lives on /data/my/linux/path under Android, then you'd have to change the cmdline parameter to "bind=/my/linux/path".
Make sure, however, not to put the Linux rootfs to the "internal storage" (/data/media) or any subdirectories thereof. This plays havoc with the Android media scanner when re-booting into Android and your tablet may slow down to a crawl.
Under Android your EMMC partitions are /dev/block/mmcblk0p1,2,3,....
Under Linux, this is /dev/mmcblk0p1,2,3....
Thanks to:
lilstevie - for bringing Ubuntu to our tablet
Jhinta - for his 3.1.10 kernel
shaola - for his debootstrap guide
x3maniac - for his Tubuntu installer
transformador - for his mountloop instructions
TomTcom - for all his Ubuntu-related guides on xda
Kingzak34 - for his dualboot guide and general help/discussion
DjDill - for putting together the collection of rootbind filesystem images
(if your name should be here and I have forgotten you, please PM me...)
Benchmarks
Using "fio" (available from Ubuntu repos). All speeds in kB/s.
In the below, loopmount refers to a loopmounted image on internal storage, MicroSD refers to running linux from an ext4 partition off a class-10 MicroSD card, and rootbind refers to the method described in this thread.
Test: sequential read (64 MB)
rootbind 31906
loopmount 29088
MicroSD 15312
Test: random read (64 MB)
rootbind 5605
loopmount 11340
MicroSD 1620
Test: sequential write (8 MB)
rootbind 9694
loopmount 1373
MicroSD 3040
Test: random write (8 MB)
rootbind 4659
loopmount 1102
MicroSD 722
New kernel
New kernel for Linux rootbind:
based on kernel source from @Sni
See here: http://forum.xda-developers.com/showpost.php?p=43203818&postcount=569
N.B. If you use this kernel you will have to copy new firmware for the wifi driver into /lib/firmware. Get it from Sni's post (link above).
USB hotplug fixed and fully working!
framebuffer fixed (Ctrl-Alt-F1 to F6 for console access)
hardware graphics acceleration now fully working with the latest Nvidia Linux-4-tegra drivers. es2gears no longer throws errors.
Two versions: one clocked to standard 1.0 GHz, the other one overclocked to 1.2GHz. Remember to extract the relevant modules to your linux root filesystem. For installation, I have provided a CWM or TWRP flashable zip, or a blob that you can flash directly with dd to the staging partition (if you don't know how to do this, use the recovery method).
I have tried at great length to overclock to higher frequencies but could not succeed. For some reason the TF just froze with a black screen after booting. I tried many combinations of voltages and frequencies. At least it's oc'ed to 1.2 and stable (in my hands), but if you are experiencing problems you can revert to the 1.0GHz or keep using the previous kernel which is oc'ed to 1.6 but USB is broken.
If anyone wants to take a stab at this you are more than welcome
My sources: https://github.com/jmrohwer/TF101-GNU-kernel
EDIT: New kernel 3.1.10-15 overclocked to 1.5GHz. Boots every time! Needs configuration of your overlock speeds with cpufrequtils. Read this post:
http://forum.xda-developers.com/showpost.php?p=54031885&postcount=334
MD5SUM:
3aee8cacf9037dfc3c8ef0363780254f Ubuntu-3.1.10-15-rootbind-oc1.5.zip
Seems to be great, and very very easy to dual boot, as TWTR will be always avaible to flash the kernels.
The reason I left linux behind on my TF is that team EOS has a plenty of updates and I like to keep up with the devs and the dual boot method i used overwrites the custom recovery.
Now it seems to be perfect forme.
Simply amazing, an other victory for TF101 ! And in addition of more speed than mountloop it's even easier to manage.
Thanks once again, I think my mounltoop will became a full install
Forgive my ignorance, but I've googled and searched the TF101 forums to no avail; what is TWTR? With Google I only found a video of someone running what looked like regular CWM touch on a TF101...
Edit: Nevermind, I figured out that it must be referring to the TeamWin recovery, which until now I've only ever seen referred to as "TWRP".
Thanks! I will test this tomorrow.
smokesignals said:
Forgive my ignorance, but I've googled and searched the TF101 forums to no avail; what is TWTR? With Google I only found a video of someone running what looked like regular CWM touch on a TF101...
Edit: Nevermind, I figured out that it must be referring to the TeamWin recovery, which until now I've only ever seen referred to as "TWRP".
Click to expand...
Click to collapse
It is TWRP, but I guess TWTR = Team Win Touch Recovery
---------- Post added at 11:52 PM ---------- Previous post was at 11:23 PM ----------
I am root, but this command says read only file system
mkdir -p /mnt/ubuntu
Made the folder using a file manager instead
Next step
mount -o loop /sdcard/ubuntu.img /mnt/ubuntu
Fails and just gives me a list of possible options for the mount command
*Detection* said:
It is TWRP, but I guess TWTR = Team Win Touch Recovery
---------- Post added at 11:52 PM ---------- Previous post was at 11:23 PM ----------
I am root, but this command says read only file system
mkdir -p /mnt/ubuntu
Made the folder using a file manager instead
Next step
mount -o loop /sdcard/ubuntu.img /mnt/ubuntu
Fails and just gives me a list of possible options for the mount command
Click to expand...
Click to collapse
I had that problem too. Not sure how to fix it on the tablet, I just copied the image I wanted to use (in this case the Arch Linux ARM one -- about which more later) to my Linux box, loop mounted it, tar'd up the files there, copied that to an SD card, and extracted it on the tablet.
However, about Arch Linux ARM, I learned not to bother using the image from the Tubuntu thread and instead just get the latest version from the ALARM downloads page. Use the "NVIDIA Tegra2 TrimSlice" one. The default root password is "root".
The reason not to use the one from the Tubuntu thread is that it is out of date -- Arch has merged /bin and /sbin into /usr, but the image in the Tubuntu thread predates that, and it's a huge pain to upgrade it properly.
smokesignals said:
I had that problem too. Not sure how to fix it on the tablet, I just copied the image I wanted to use (in this case the Arch Linux ARM one -- about which more later) to my Linux box, loop mounted it, tar'd up the files there, copied that to an SD card, and extracted it on the tablet.
However, about Arch Linux ARM, I learned not to bother using the image from the Tubuntu thread and instead just get the latest version from the ALARM downloads page. Use the "NVIDIA Tegra2 TrimSlice" one. The default root password is "root".
The reason not to use the one from the Tubuntu thread is that it is out of date -- Arch has merged /bin and /sbin into /usr, but the image in the Tubuntu thread predates that, and it's a huge pain to upgrade it properly.
Click to expand...
Click to collapse
Thanks for that, at least I know I'm not doing something wrong my end, I was trying the Ubuntu 12.04 netinstall from the Transformazing thread, I`ll no doubt try a few until I find one I like
I don't have a Linux box atm, but a quick fix with a wubi or VM install tomorrow and I`ll give your method a shot
Cheers
Hey jrohwer can you have a look at this ? It may interest you
http://forum.xda-developers.com/showpost.php?p=43203818&postcount=569
A silly question.... But do i need pre installed mountloop?
I am kinda confused though lol.
Kingzak34 said:
Hey jrohwer can you have a look at this ? It may interest you
http://forum.xda-developers.com/showpost.php?p=43203818&postcount=569
Click to expand...
Click to collapse
Looks interesting, I can see whether I can compile his sources, but it will have to wait a while (don't have a lot of time atm).
*Detection* said:
It is TWRP, but I guess TWTR = Team Win Touch Recovery
---------- Post added at 11:52 PM ---------- Previous post was at 11:23 PM ----------
I am root, but this command says read only file system
mkdir -p /mnt/ubuntu
Click to expand...
Click to collapse
Yes, sorry for got to add the step to remount / in rw mode. OP is updated.
Made the folder using a file manager instead
Next step
mount -o loop /sdcard/ubuntu.img /mnt/ubuntu
Fails and just gives me a list of possible options for the mount command
Click to expand...
Click to collapse
Most probably you are using the Android mount command. The busybox mount command has more functionality. I added the OP to explicitly call the busybox mount/umount commands (I have mine aliased by default). Indeed I checked and the Android mount command does not work for loop mount.
vietchinh said:
A silly question.... But do i need pre installed mountloop?
I am kinda confused though lol.
Click to expand...
Click to collapse
No you just need a mountloop image which you can then mount as described in the OP, to copy the files over to /data/linuxroot.
jrohwer said:
Yes, sorry for got to add the step to remount / in rw mode. OP is updated.
Most probably you are using the Android mount command. The busybox mount command has more functionality. I added the OP to explicitly call the busybox mount/umount commands (I have mine aliased by default). Indeed I checked and the Android mount command does not work for loop mount.
Click to expand...
Click to collapse
Thanks, I`ll give this another shot tonight then with the new instructions
jrohwer said:
Looks interesting, I can see whether I can compile his sources, but it will have to wait a while (don't have a lot of time atm).
Click to expand...
Click to collapse
Yup of course take your time I think something good is coming
Tapatalké depuis mon Nexus 4 MIUI !
jrohwer said:
No you just need a mountloop image which you can then mount as described in the OP, to copy the files over to /data/linuxroot.
Click to expand...
Click to collapse
Thanks, but i have new problem. Uh i cant execute this line: tar -xzf /sdcard/modules-3.1.10-9.tar.gz. It give's me this:Tar invalid option bla bla bla ;3 SO CLOSE TO COMPLETING T.T.
vietchinh said:
Thanks, but i have new problem. Uh i cant execute this line: tar -xzf /sdcard/modules-3.1.10-9.tar.gz. It give's me this:Tar invalid option bla bla bla ;3
Click to expand...
Click to collapse
Leave the - off. so it would be
Code:
tar xvf /sdcard/modules-3.1.10-9.tar.gz
Usually works for me.
bfmetcalf said:
Leave the - off. so it would be
Code:
tar xvf /sdcard/modules-3.1.10-9.tar.gz
Usually works for me.
Click to expand...
Click to collapse
In valid tar magic ._.
i assume i need extract manually heh

[DUAL_BOOT]Dual booting an android phone with an extrrnal SD card

So here you come. To read and perform this tutorial, you obviously need a first hand experience on flashing a ROM and/or kernels. Otherwise this tutorial and my efforts to get you a device with two OSes running might end up giving you a bricked device. So, if you're hearing the terms "flashing" or 'kernels' for the first time and thinking it's kinda good food, then bro, just go and taste those first.
Something's to remind before we gonna dig deep into this tutorial->
1> Noone but you will be responsible for what you end up with.
2> The warranty of your device will be voided after this if it isn't already after rooting. For MI users, the good news is that you can reclaim it by just flashing the fastboot ROM for your device.
Enough lectures. Bro let's get to work.
This you'll be needing =>
1> One working Windows PC(because I doesn't know any replacement of bootimg.exe on any other OS. If you know, then let me).
2> A class 10 memory card ( I recommend 32GB for the spaces)
3> A custom ROM and kernel for your phone(the second os)
4> Any custom CWM based recovery installed.(since TWRP is most popular, I will demonstrate using it. You can use any other you want overall process will be the same)
5> ADB, fastboot and the device drivers (easily found in XDA)
PART 1: MODIFYING THE BOOT
At first, how does your device boots up? What are the partitions called /data and /system? The answer is quite simple. It's your kernel that points out the location from where the OS should be picked up. So for booting into the second OS we need some modifications to it at first.
Search and download bootimg.exe on XDA, I'll post a link later. Create two folders. Name them "Internal OS" and "External OS" respectively. Put the zip file of the OS you're currently using to the first one and the OS you're gonna use on the external storage to the second one. Rename the second OS to originalExternalOS.zip. Extract originalExternalOS.zip. Pick the boot.img file from the root of the extracted folder and move it to a new folder named "boot2". Extract the IMG using bootimg.exe. Navigate to the initrd folder and you will get a file named 'fstab".
Basically it's the file that tells the kernel which partition does the OS resides in.
Open the file in your favourite text editor.
Replace every instance of the first line with the second one:
/dev/block/bootdevice/by-name/system => /dev/block/mmcblk1p2
/dev/block/bootdevice/by-name/userdata => /dev/block/mmcblk1p3
/dev/block/bootdevice/by-name/cache => /dev/block/mmcblk1p4
Save the file without giving any extension to it. Repack it using the same tool. You'll have boot-new.img and boot-old.img. Rename boot-new.img to boot.img and replace the one in the root folder with this. Basically what we're doing here is replacing the old boot.img with the modified one.
For your knowledge, blocks are the partitions of any storage you have on your device. For example, your internal storage is partitioned to near about 30 different blocks each starting with prefix "mmcblk0p". We here just told the kernel to load the OS from the blocks mentioned. We'll be creating these blocks in the external SD card next.
PART 2: PARTITIONING THE SD CARD
Connect your device with the memory card inserted to your PC. If you haven't installed fastboot, ADB, and the drivers, do it now.
READ THE FOLLOWING CAREFULLY
Reboot the device to recovery mode. Type the commands in cmd:
Code:
adb shell
parted
unit MB
print
quit
umount external_sd
Read and store the minimum and maximum capacity of your card. Since different cards will have different capacities I will point it as variable MIN_SIZE and MAX_SIZE. You'll need to calculate and put the values in the commands. Now type the following commands on cmd:
Code:
parted /dev/block/mmcblk1
rm 1
//START_BLOCK = MAX_SIZE - 5000
mkpartfs primary fat32 MIN_SIZE START_BLOCK
//SYS_START = START_BLOCK+1
//SYS_END = SYS_START + 1200
mkpartfs primary ext2 SYS_START SYS_END
//DATA_START = SYS_END+1
//DATA_END = DATA_START + 3500
mkpartfs primary ext2 DATA_START DATA_END
//CACHE_START = DATA_END + 1
mkpartfs primary ext2 CACHE_START MAX_SIZE
//We have partitioned the memory card. Let's format them. Ignore all "Do you wish to continue" question in the next commands as we're already mentioning yes.
mkfs yes 1 fat32
mkfs yes 2 ext2
mkfs yes 3 ext2
mkfs yes 4 ext2
quit
//Now they are almost ready. Just make the newly created blocks readable by the OS.
make_ext4fs /dev/block/mmcblk1p2
make_ext4fs /dev/block/mmcblk1p3
make_ext4fs /dev/block/mmcblk1p4
//Now you get where does the blocks come in the kernel right?
exit
//You've covered up the hardest part. Let's get some coffee and cheeerssss.
PART 3: MODIFYING THE NEW OS
You've left the OS extracted in the "External OS" folder right? It's time to do some magic in it. We're gonna tell the OS to be installed in the blocks we created just like the kernel. But wait, where does the OS know before installing where it should get installed? Well, the answer hides in the updater-script in the folder META-INF > com > google > android. Navigate yourself in it. Open the updater-script file in your favourite editor ( I use notepad++ ) and modify it in the same way as the kernel.
Replace every instance of the first line with the second one:
/dev/block/bootdevice/by-name/system => /dev/block/mmcblk1p2
/dev/block/bootdevice/by-name/userdata => /dev/block/mmcblk1p3
Leave the /dev/block/bootdevice/by-name/boot as it's the fundamental block and we can't replicate it. Don't think for the /cache partition as we've already done that in the boot.img file. Now navigate to the root of the folder where you extracted the External OS. Select all files, add them to a zip file using WinRAR. Name the file to newOS.zip. Open newOs.zip and originalExternalOS.zip with WinRAR and compare them if you find any change in the folder tree. They must and they should be exactly the same. You're 80% done.
PART 4: MODIFYING THE RECOVERY
We often flash many zips including very popular Xposed and other mods to our OS right? They also look for the /system partition. So what are we gonna do? Modifying each of them? Nah. Let's modify where they get which one the /system is. The recovery. Extract the img of the recovery you're using with the same bootimg.exe. Modify exactly the same things. I.e.
Replace every instance of the first line with the second one:
/dev/block/bootdevice/by-name/system => /dev/block/mmcblk1p2
/dev/block/bootdevice/by-name/userdata => /dev/block/mmcblk1p3
/dev/block/bootdevice/by-name/cache => /dev/block/mmcblk1p4
in the following files : initrd/fstab.qcom
initrd/etc/recovery.fstab
initrd/etc/twrp.fstab(For TWRP only)
Save them. Repack. And you got your recovery-new.img and recovery-old.img. Put recovery-new.img and newOS.zip in the same folder. Now wake up, it's time for some action.
PART 5 : INSTALLING THE OS
Open cmd in the folder where newOS.zip resides. Reboot the devixe in fastboot mode. Type the following commands:
Code:
adb push newOS.zip external_sd
fastboot flash recovery recovery-new.img
fastboot boot recovery
Now your device should boot up in recovery mode. To check if everything has gone fine mount system using TWRP. Use twrp's built in file manager and navigate to system folder. It's empty? Yup. You've done a great job. Now flash the newOS.zip using TWRP and your device should boot up in the new OS. To cross check again remove the SD card and try to boot. If you're headed towards recovery or bootloop after that then it's a win. Put the SD card back again and watch the new OS to boot.
PART 6: SWITCHING BETWEEN THE TWO
Extract the boot.img from the "Internal OS" zip file and put it together with recovery-old.img. To check if your old system is untouched type the following commands in fastboot mode:
Code:
fastboot flash recovery recovery-old.img
fastboot flash boot boot.img
fastboot boot system
Your device should take you back to the old one. Surprised? Now let's make a switch between the two. There are two methods.
METHOD 1: USING FLASHIFY
Create two folders in your SD card. Put boot.img and recovery-old.img to one and boot-new.img and recovery-new.img to the other. To switch to the external OS, just flash boot-new.img as boot and recovery-new.img using flashify. Ignore reboot now dialog and reboot directly to the system. To go back, first install flashify in the new OS and flash boot.img and recovery-old.img. Easy right?
METHOD 2: USING ZIPS
I'm gonna tell you that tomorrow as I can write no more today.
More to come....
CREDITS:
justzzshadz from MIUI forum for this revolutionary concept. @iamsubhranil for adding TWRP, Flashify support and completely rewriting the tutorial.

Categories

Resources