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

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.

Related

[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

[Guide] How to create EXT4 images.

Since most of the high-end devices are using now EXT4 partitions i decided to make a guide.
I am doing this because this is the easiest way to create an EXT4 image.
This is not my guide I am just adapting and make it clear to everybody; someone showed me how to do this (I will mention him at the end of the guide).
Let's assume that you dumped the system.img from your own device and you want to add something to it.
We will create a new system.img and we will name it system_new.img, the size will be 240 Mb.
Step 1
Linux Machine (I used Ubuntu)
We prepare the directories and copy the system.img in the folder in which we will work.
mkdir system (here we will mount the old system.img
mkdir system_new (here we will mount the system_new.img)
Step 2 – Creation of the actual EXT4.img
dd if=/dev/zero of=system_new.img bs=4k count=60000
Translation of the terms,
bs =blocksize, 4k= the size of the block`s which in this case is 4kb
count=60000, the number of block`s, in our case will result an image of 240 Mb.
The blocksize can be 1k/2k/4k/16k
To get the exact size of the image that you create use simple maths.
60000 * 4 = 240000
Step 3 Formating the system_new.img with EXT4
mkfs.ext4 system_new.img
It will be a question where you will select yes (Y)
We override the file system check (If you don`t do this, the image will not work)
tune2fs -c0 -i0 system_new.img
Step 4 We mount the directories that we previous created.
mount -o loop system_new.img system_new/
mount -o loop system_new.img system/
Step 5 We copy the content from the old system.img in the system_new.img
cp -v -r -p system/* system_new/
We sync the files
sync
Step 6 Unmounting the partitons.
umount system_new/
umount system/
Step 7 Enjoy your new ext4 system.img
Tips:
If you are using Ubuntu just type
sudo su
And you will be root and no more sudo at each command.
You can add new files in the new created system.img but you need to set the permissions and ownership properly, otherwise it will not work.
Credits: arctablet.com administrator.
work perfect!
I managed to create a new system img for huawei phone.
Errors in Step 3 and 4: Unable to proceed
Hi There,
I am getting errors in step 3 and 4.
Step 3 Formating the system_new.img with EXT4
mkfs.ext4 system_new.img
It will be a question where you will select yes (Y) -- after this below error comes
Device size reported to be zero. Invalid partition specified, or partition table wasn't reread after running fdisk, due to a modified partition being busy and in use. You may need to reboot to re-read your partition table.
We override the file system check (If you don`t do this, the image will not work)
tune2fs -c0 -i0 system_new.img -- after this below error comes
Attempt to read block from filesystm resulted in short read while trying to open system.img
Step 4 We mount the directories that we previous created.
mount -o loop system_new.img system_new/ -- after this below error comes
unknown filesystem type 'ext4'
Could you please help.
i whant to create and system.img.ext4 for my android ! ! But i saw that image which is created is just system.img ! I`m using ubuntu and i whant to know what is need it to create that system.img.ext4 ! I don`t see that img to be ext4 file ! Thanks
jabarel said:
i whant to create and system.img.ext4 for my android ! ! But i saw that image which is created is just system.img ! I`m using ubuntu and i whant to know what is need it to create that system.img.ext4 ! I don`t see that img to be ext4 file ! Thanks
Click to expand...
Click to collapse
I'm not sure but it's probably just a matter of file extenstion.
By the way, great tuto. May be someting to add :
Android ext4 don't seem to be the exact standart of linux ext4 file systems.
To make it fully compatible and usable with fastboot, the use of "ext2simg" can be useful.
So it will be something like this :
ext2simg fs2convert.img fsconverted.img
ext2simg can be found in android-tools in debian repository.
I am porting a rom ,i extracted "system.new.dat" into "sytem" folder , applied changes according to this guide to port a ROM -->> http://forum.xda-developers.com/showthread.php?p=65933478#post65933478
can you tell me how to reconstruct the "system.new.dat" from "sytem" folder ?
is mkfs.ext4 applet available to arm devices..??
you can do it faster...
Great if you create a new image, but to edit no need to create all these steps ...
Just copy the system.img to system_new.img and mount that one and edit..
There's no clear instruction!
Hours of researching many places and no good instruction about how to create or edit an EXT4 with or without Linux!
I know this is an old post but I just wanted to try, might get a reply!
Frank2406 said:
Hours of researching many places and no good instruction about how to create or edit an EXT4 with or without Linux!
I know this is an old post but I just wanted to try, might get a reply!
Click to expand...
Click to collapse
what is not clear?
this has been tested by me and it works.
there are more refined ways in doing it, it just depends on what you need to to with the ext4 image.
globula_neagra said:
what is not clear?
this has been tested by me and it works.
there are more refined ways in doing it, it just depends on what you need to to with the ext4 image.
Click to expand...
Click to collapse
Step 1: "We prepare the directories" you said. What directories?
"mkdir system"
"mkdir system_new" which, what or where are they?
Step 2: The whole step 2 for a newbie in Linux like me is bla bla bla except the title "Creation of the actual EXT4.img"!
And the rest of your guide is as the same as step 2 which I mentioned.
And if this guide is for Ubuntu experts then maybe in the beginning you could mention so people don't get their hopes up dear globula_neagra!!
Long story short, I just wanted to try a custom Rom on my Zenwatch 1, but I've forgot to make backup, so the official Rom was gone. Asus itself didn't help to get a copy of the official one, so I tried Anthias custom Rom instead, but that made the watch even worse.
Then I started to research how to fix it, so I found this article.
It s not a step by step guide on how to use ubuntu.
I assume that wheen you want to learn something you do use google too. For this instance i would google in this way "what does mkdir command in ubuntu"
After i understood the purpose of the command and how to use it i would try to apply it using the guide and after that you will see that things will start to make sense.
My guide was written with the idea that if you use android you have an idea of linux too and in this case ubuntu.
The command line in linux is somewhat similar to the one in windows commander there are some extra things that you need to learn but those can t be put in a guide like this.
In regards to your watch. My advice is to find another one and take a system dump from that one and flash it to yours if you have an unlocked bootloader.
Here you cand find some good reads on how to dump the files from the watch. And a bit more details on what is the business with the ext4 creation. Topic is5 years old but still relevant.
http://www.arctablet.com/blog/forum/arnova-7c-g3/arnova-7c-g3-dev-topic/

[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

Universal Android Flasher

From now on, Android rom can be easy to pack. You don't need to worry about the permissions of the files or the symlinks anymore.
What does this package do:
1. Automatically find and recognize the img with patterned name in the same folder of this package.
2. Automatically wipe and flash the system partition when system.img is found.
3. Automatically flash the addon pack without wiping the system partition when addon.*.img is found.
4. Automatically backup efs and efs_gsm partition, on Samsung Duo sim card phones.
5. Be able to flash the unmountable partitions like boot, recovery, modem, etc.
How to pack:
1. Make you rom on on the Phone or Linux. On the Phone? Yes, you can test your patches on your phone.
2. No matter on the Phone or on Linux, cd /system/ or cd <your system folder>, check the permissions and symlinks. Usually I don't check cause I modify directly on a system I dumped from my phone. Yes a dump of system partition is a good idea.
3. You have two optitions: 1. Use the modified dumped system partition dump as system.img. This usually generate a big img to flash, but will flash faster. 2. If you use extracted folder or want to use small files, cd to the system folder in shell and make the folder to a tarball with the command: 'tar --lzma -cf <your tar file> * .[!.]*'. Why use * .[!.]*? This will put the .* files and folders in the tarball.
4. Then rename the dumped image or the tarball to system.img and put it in the same folder of the FLASHER.
5. Want to make an addon? Just make the name like addon.<your name>.img. Don't for get the permissions and ownership of the files and folders.
Future plan:
1. Make a packer/dumper for the system partition.
Github:
https://github.com/maxfu/universal_android_flasher
I will edit this post and post some pictures later.

Lg aristo 2 a2plus and k8plus>>> 64-bit kernel and mount 2nd partition of ext4 sd card at boot and more

howdy folks the mad clown from memphis is back with more goodies for the Aristo 2, Aristo 2 plus and K8plus.
We have a 64bit kernel in the included magisk patched boot image plus a modification made to init.lge.fs.rc that will automatically mount the 2nd partition of your ext4 formatted external sdcard at boot to root folder called linux.
also included in the zip file is a proot binary and two script files. the first script file simply named linux will start a root file system in your linux folder as [email protected] from your terminal emulator the 2nd script resolves any intenet issues getting "apt" working in your linux rootfs distribution.
so heres how to do it.
1st flash the magisk patched boot image using fastboot or twrp. then reboot.
2. install aparted from the playstore and make repartition your external sdcard to have 2 partitions making sure that the first partition mmcblk1p1 is v-fat and the 2nd partition mmcblk1p2 is ext4. the modification made to the rc file will only mount mmcblk1p2 formatted as ext4 plus its rewritable.
3. copy the rootfs of your choice to the new root folder named linux. untar or unzip and paste the inetbutu.sh file as well into the folder.
4. boot into twrp and copy the linux script and proot binary to your system/bin folder and chmod both files 0755 and reboot
5. start your terminal emulator then type
su
linux
and you should see your [email protected] prompt change to [email protected] congratulations it was that easy to start a rootfs such as ubuntu on your device.
6. to get "apt" running properly just type
sh inetbutu.sh
and now you have a fully running and working linux distribution working on your cv1 device that you can use to do what ever you like with and hopefully in the future we can boot that distribution from LAF and have a native working OS boot on your cv1 device.
have fun enjoy and laugh away at all the fun things you can now do so easily. if any one has queations or for some reason needs help feel free to post.

Categories

Resources