Webtop on ics/JB - Motorola Droid Bionic

Hi there thanks for the reply, I have not tried this particular rom yet, but I have installed the .233 ics on 4.0.4 and I have found that the webtop had been converted from the webtop linux version to an app, that is probably why most of you guys running custom roms are not getting webtop to work. The bionic webtop.img or /dev/block/mmcblk1p24 is now only holding a 150 MB of memory and they are mostly just the webtop.apk's
here is a link to a rooted webtopv2 if you want to try to get it to mount and run for webtop you will also need almost all the original scripts that launch the webtop when an hdmi cable is connected from version 5.904 or 838 or what ever the versions were before ics. but here is a link to a rooted webtop if you are on a rom before ics you can do dd if=/sdcard/webtop.img of=/dev/block/mmcblk1p24 and get a rooted full ubuntu desktop version of webtop, I do not know how this will work if you overright the current webtop because there is no scripts to mount the webtop.img or /dev/block/mmcblk1p24 currently. if someone gets webtop to work correctly this could really make a hudge difference in the new jellybean roms.
Webtop v2 rooted for bionic ubuntu with apt-get, firefox installed
Click to expand...
Click to collapse
http://www.4shared.com/zip/txsvRdah/webtopimg.html
Also I have found that our bionic has alot of free space now because of the updates shown below:
vendor has 1.3 GB memory, 156 Mb used, this is linked to webtop or /dev/block/mmcblk1p24
Webtop is not like webtop 1, or webtop 2 this is just an app version not a ubuntu based webtop
Cache has 696 or so memory maybe 50 Mb used.
Preinstall has 283MB 50-100 megs used, you can delete most of these apps though, and videos
I have added swap on my cache partition of 512Mb, I would like to see original webtop v2 rooted like the link I posted above on webtop, and maybe Vendor.img to be shrunk to 200 MB and add the excess 700 megs to /data to increase data to over 4GB or add 700 megs to sdcard-ext, either way there is alot of room for improving the free space on our device shrink webtop if you cant add original webtop, and shrink cache because there probably won't be any more updates and cache is only really used for updates.
shrink cache 500 megs would be about 200 Mb after shrunk
shrink webtop/vendor or re-add Linux based webtop should only be about 175 Mb after being shrunk
shrink preinstall 200 Mb should be 25-50 Mb after shrink
add this 1Gb - 1.5Gb to data, or sdcard-ext
to do this you would need to use fdisk
WARNING THIS IS NOT A TUTORIAL, using fdisk on a running system can ruin/brick your phone this would should only be used by devs, and hopefully rom creaters to better our phone in custom roms.
fdisk /dev/block/mmcblk1
mbmloader mmcblk1p1
mbm mmcblk1p2
mbmbackup mmcblk1p3
ebr mmcblk1p4 this is the extended partition for the rest of the partition table
bploader mmcblk1p5
cdt.bin mmcblk1p6
pds mmcblk1p7
lbl mmcblk1p8
lbl_backup mmcblk1p9
logo.bin mmcblk1p10
sp mmcblk1p11
devtree mmcblk1p12
devtree_backup mmcblk1p13
bpsw mmcblk1p14
boot mmcblk1p15
recovery mmcblk1p16
cdrom mmcblk1p17
misc mmcblk1p18
cid mmcblk1p19
kpanic mmcblk1p20
system mmcblk1p21
cache mmcblk1p22
preinstall mmcblk1p23
webtop mmcblk1p24 has been linked to vendor on ICS and up
userdata mmcblk1p25
emstorage mmcblk1p26
sgpt mmcblk1p27
then change the start point of each partition and end point of each partition adding the excess memory to either data or sdcard-ext
Would like help to bring back the original webtop for bionic on jellybean and ics not to use the webtop3 wich is based on apk's not linux like it was before

anyone try this on 4.2.2 ASOP for bionic?

If you wanted a custom kernel download the jelly bean source for the bionic compile your custom kernel as long as its compiled on an x64 machine with the stock jelly bean source you should be able to use dd command in cwm or touch recovery from adb on your computer
First you need to create a boot.img from your zimage you can Google that I believe its mkboot from koush make the boot.img then copy if to your sdcard then once you have your custom kernel in a bionic jelly bean stock boot.img on your sdcard from recovery type in adb shell.
adb shell:
#dd if=/sdcard/boot.IMG of =/dev/block/mmcblk1p15
Were the boot.IMG is your custom kernel compiled from bionic jelly bean source
Here is link to source
http://sourceforge.net/projects/droidbionic.motorola/files/droidbionic/9.8.2O-72_VZW-22/
If you get this far add swap/zram in the config.gz its one line
CONFIG_SWAP=y
CONFIG_ SWAP_PREFETCH=y
You don't need prefetch its just supposed to help with read speed.

Related

[MOD] Get more usable space with smaller custom roms

Hello
scroll to the bottom of this post for an update
So, i've been searching now for a while for a guide on how to get more internal space and reduce the /system partition of my sgs3,
since many custom roms are much smaller in size compared to stock.
Since i haven't found any, i've figured i'll try doing it myself.
This requires some linux/unix shell knowledge, so unless you used linux shell and/or adb before, i don't recommend trying this.
Also, i have done this on GT-I9300, the international version. If yours is not the same, the partition layout will probably differ
Requirements:
* parted ( can't post links yet.. )
* adb ( android sdk, platform tools )
* CWM recovery installed
* Custom ROM zip on your PC to upload after the operation.
Alright, so here goes. ( since i already mentioned this is an advanced operation, i'll keep it pretty basic )
1. Reboot into CWM recovery
2. Unmount everything possible (either in CWM or 'adb shell', i used the latter - more reliable i would guess)
3. adb push X:\xx\xx\parted /
4. adb shell
5. chmod +x parted
Now the real fun begins.
6. /parted /dev/block/mmcblk0
This will launch parted. type 'p' and press 'enter', you'll see something like this:
Code:
Number Start End Size File system Name Flags
1 4194kB 8389kB 4194kB BOTA0
2 8389kB 12.6MB 4194kB BOTA1
3 12.6MB 33.6MB 21.0MB ext4 EFS
4 33.6MB 41.9MB 8389kB PARAM
5 41.9MB 50.3MB 8389kB BOOT
6 50.3MB 58.7MB 8389kB RECOVERY
7 58.7MB 92.3MB 33.6MB RADIO
8 92.3MB 1166MB 1074MB ext4 CACHE
9 1166MB 2777MB 1611MB ext4 SYSTEM
10 2777MB 3364MB 587MB ext4 HIDDEN
11 3364MB 3372MB 8389kB OTA
12 3372MB 15.8GB 12.4GB ext4 USERDATA
Now you need to calculate the partition sizes you actually need. Ignoring first partitions up to CACHE not to mess things up.
As far as i know, the CACHE partition is used for OTA, hence it's size - to fit ~ size of the rom. Personally i have no intention of using OTA, so i made the partition 100mb. I'm definitelly no expert in hacking android yet, but personally i haven't noticed myself using /cache more than that.
HIDDEN contains some preloaded apps - not valid in case of custom roms. I made it 1mb.
Not sure what OTA partition is used for, but again, i don't use OTA so i don't really care. 1mb.
As for SYSTEM, this depends how big is your custom rom. I currently use SlimBean which is ~100mb together with gapps, but just in case i've set the size to 300mb.
and the rest goes for USERDATA. I think you can already forsee a few more GBs for internal storage
So, just remove all the partitions that need to be resized and recreate them:
Code:
(in parted)
rm 8
rm 9
rm 10
rm 11
rm 12
then issue 'mkpart' 5 times to recreate the partitions.
When asked for a name, just press enter (we'll set the names later, since mkpart didn't change the names for me anyway)
When asked for type, you can either enter ext4 or simply press enter. We'll format partitions afterwards anyway.
When asked for start, enter the value from last partition's 'End'. For CACHE that would be the end of RADIO, so 92.3MB
For End enter the size you want. 10KB, 20MB, 1GB - annotations accepted.
After you create a partition, issue 'p' to check it's End for the next partition's start.
For USERDATA End just enter what you saw in the beggining, 15.8GB in my case.
exit parted, 'q'
7. format new partitions (except OTA)
Code:
mke2fs -T ext4 /dev/block/mmcblk0p8
mke2fs -T ext4 /dev/block/mmcblk0p9
mke2fs -T ext4 /dev/block/mmcblk0p10
mke2fs -T ext4 /dev/block/mmcblk0p12
For USERDATA i also used an option '-m 0.2' to get those extra 300mb from ext4 reserve.
8. mount /data/ ; mkdir /data/media
9. exit adb ; adb push X:\xx\customRom.zip /data/media
10. Flash new rom in CWM and reboot.
That's pretty much it. At least it was for me.
I may have missed something, but i'm now assured that this is possible.
For reference:
Code:
Before:
Number Start End Size File system Name Flags
1 4194kB 8389kB 4194kB BOTA0
2 8389kB 12.6MB 4194kB BOTA1
3 12.6MB 33.6MB 21.0MB ext4 EFS
4 33.6MB 41.9MB 8389kB PARAM
5 41.9MB 50.3MB 8389kB BOOT
6 50.3MB 58.7MB 8389kB RECOVERY
7 58.7MB 92.3MB 33.6MB RADIO
8 92.3MB 1166MB 1074MB ext4 CACHE
9 1166MB 2777MB 1611MB ext4 SYSTEM
10 2777MB 3364MB 587MB ext4 HIDDEN
11 3364MB 3372MB 8389kB OTA
12 3372MB 15.8GB 12.4GB ext4 USERDATA
After:
Code:
Number Start End Size File system Name Flags
1 4194kB 8389kB 4194kB BOTA0
2 8389kB 12.6MB 4194kB BOTA1
3 12.6MB 33.6MB 21.0MB ext4 EFS
4 33.6MB 41.9MB 8389kB PARAM
5 41.9MB 50.3MB 8389kB BOOT
6 50.3MB 58.7MB 8389kB RECOVERY
7 58.7MB 92.3MB 33.6MB RADIO
8 92.3MB 192MB 99.7MB ext4 CACHE
9 192MB 500MB 308MB ext4 SYSTEM
10 500MB 501MB 1000kB ext2 HIDDEN
11 501MB 502MB 1000kB OTA
12 502MB 15.8GB 15.3GB ext4 USERDATA
So now i have 13.8Gb of usable space on my sgs3 and i'm pretty happy about it.. No need to convert user apps to system apps in titanium any more..
Since i'm not sure about the effects of this for the long term, please provide me feedback if it went ok for you or not.
And if you have any points to make why this is not good i would also appreciate that.
UPDATE:
First of all, parted seems to be included in CMW, at least the cwm-touch-6.0.1.2 version has it ( noticed only after a while )
So no need to look for parted binaries if you're using that.
Second - as mentioned by sorg, this does mess up the partition table and anything that needs odin will not work. Tried myself, messed up the whole thing, but recovery was still half operational.
Anyway, using .pit ( GT-I9300_mx_20120329.pit ) the partition table was restored on my I9300 while flashing official stock, LH8.
So that's all fine. In case you don't want to try .pit method, you could simply restore the partition table using parted. Basically resize the partitions using same method to the original sizes. haven't tried this myself, but i imagine it should work
One last note, since i was too eager to do this all, i didn't notice the 'unit' command in parted. basically you can use 'unit kib', 'unit mib' to get the 'computer' values for sizes, which actually make more sense looking at parted output. the OTA partition is for example exactly 8mb (mib).
To get the 1000s units, use 'unit kb', 'unit 'mb' or 'unit compact' which selects the unit automatically based on partition size.
Alright,you've got some balls dude.I got to give you that!Bravo,really nice work.I don't need it atm (32gb version rocks hard),but I may do it for the fun of it.
Love it!... but there will be someone posting here, crying their eyes out before long (no sympathy from me however).
So much for the 'xda-downloaders.com' mentality and moar powah to the developer!
I salute you.
Very useful man. Thanks!
Sent from my GT-I9300 using xda app-developers app
Nice mod man!
You've got balls of steel trying to do that,i really admire you...
Anyway,excuse me if i'm wrong but i think applications you get form market get downloaded in cache first?
If you shrink that partition won't you have issues with apps?
1024Kb is one MB not 1000. it is 2^10 for a full MB. Great guide though, and VERY nice detailed instructions. Thank you, and you might wanna put a "I am NOT responsible" banner at the top!!!
nfsmw_gr said:
Nice mod man!
You've got balls of steel trying to do that,i really admire you...
Anyway,excuse me if i'm wrong but i think applications you get form market get downloaded in cache first?
If you shrink that partition won't you have issues with apps?
Click to expand...
Click to collapse
You might have issues if you try to download apps that the apk is bigger than the cache partition. Otherwise i don't think there's an issue. And since i don't download anything above 100mb, that's why i made it so. and even then, you can just symlink some folder in /data to /cache and you'll have all the space in the world for you cache..
b-eock said:
1024Kb is one MB not 1000. it is 2^10 for a full MB. Great guide though, and VERY nice detailed instructions. Thank you, and you might wanna put a "I am NOT responsible" banner at the top!!!
Click to expand...
Click to collapse
That's how parted displays it.
Ok, so 1000KB in parted equals 1024KBs or 1MB? Just trying to get this right...
Sent from my GT-I9300 using xda premium
b-eock said:
Ok, so 1000KB in parted equals 1024KBs or 1MB? Just trying to get this right...
Sent from my GT-I9300 using xda premium
Click to expand...
Click to collapse
1MB. In the guide above i have put 501MB for start and 502MB for end for OTA partition for example. That's 1MB in size, but gets displayed as 1000Kb. And 1000MB would be 1GB there.
I guess parted calculates in 10s and actually all of the hard drives are calculated like that on label. So in reality there's 16000000000 of bytes in my SGS3. divide that by 1024 a couple of times and you get lower 'actual' size. then file system format reduces usable space even more, but that's another subject...
Does this not qualify as Original Development .
OP i would PM a mod to ask for inclusion in Original i have .
jje
Well yes i guess. Just didn't have permissions to post there
If a mod reads this, feel free to move the thread. Otherwise i'll pm someone when i get home
Sent from my GT-I9300 using xda app
Hardware uses the industry-standard 10^3=1000 (according to sni: KiB) while software tends to use 2^10=1024 (according to sni: KB)
Sent from my GT-I9300 using xda premium
i made similar changes to my I9000 before, no problems at all
edit forgot to mention that the only thing you have to take care of is how to install newer roms with the new layouts in the future, but i bet with your knowledge in linux it wont be a problem to you at all
Will these changes in parted be saved into PIT structure?
Otherwise ODIN may repartition this if u will flash anything through it. Probably it won't touch data outside flashed part, so in this case it's still possible to flash for example recovery partition (in case if it get corrupted). If ODIN write some marks in all partitions every time then you may corrupt data on later partitions.
Btw, to make this thread useful, here is parted i've found on http://forum.cyanogenmod.com/topic/6433-solved-messed-up-partitions-on-internal-storage/ :
http://www.sendspace.com/file/w6hi6x
sorg said:
Will these changes in parted be saved into PIT structure?
Otherwise ODIN may repartition this if u will flash anything through it. Probably it won't touch data outside flashed part, so in this case it's still possible to flash for example recovery partition (in case if it get corrupted). If ODIN write some marks in all partitions every time then you may corrupt data on later partitions.
Btw, to make this thread useful, here is parted i've found on http://forum.cyanogenmod.com/topic/6433-solved-messed-up-partitions-on-internal-storage/ :
http://www.sendspace.com/file/w6hi6x
Click to expand...
Click to collapse
As far as I know Odin only repartitions the device if you include the correct pit for the device and check repartition.
L
9Lukas5 said:
As far as I know Odin only repartitions the device if you include the correct pit for the device and check repartition.
Click to expand...
Click to collapse
ODIN always read PIT file from device if you don't provide such. You can check ODIN logs. I believe, ODIN does following things:
1) if PIT file not provided, then read it from device
2) check file names assigned to every partition and pick them from supplied TAR file
3) write files directly (after un-sparse img files if required) to flash addresses taken from PIT.
so, if PIT structure in I9300 is not the same as GPT partition table, then you may mess data if you will accidentally flash parts beyond CACHE partition through ODIN.
A little update:
First of all, parted seems to be included in CMW, at least the cwm-touch-6.0.1.2 version has it ( noticed only after a while )
So no need to look for parted binaries if you're using that.
Second - as mentioned by sorg, this does mess up the partition table and anything that needs odin will not work. Tried myself, messed up the whole thing, but recovery was still half operational.
Anyway, using .pit ( GT-I9300_mx_20120329.pit ) the partition table was restored on my I9300 while flashing official stock, LH8.
So that's all fine. In case you don't want to try .pit method, you could simply restore the partition table using parted. Basically resize the partitions using same method to the original sizes. haven't tried this myself, but i imagine it should work
One last note, since i was too eager to do this all, i didn't notice the 'unit' command in parted. basically you can use 'unit kib', 'unit mib' to get the 'computer' values for sizes, which actually make more sense looking at parted output. the OTA partition is for example exactly 8mb (mib).
To get the 1000s units, use 'unit kb', 'unit 'mb' or 'unit compact' which selects the unit automatically based on partition size.
where can i get this "GT-I9300_mx_20120329.pit" if something went wrong ?
fuflo said:
[...] Second - as mentioned by sorg, this does mess up the partition table and anything that needs odin will not work. Tried myself, messed up the whole thing, but recovery was still half operational.
Anyway, using .pit ( GT-I9300_mx_20120329.pit ) the partition table was restored on my I9300 while flashing official stock, LH8. [...]
Click to expand...
Click to collapse
Do you mean that after repartitioning that way, you weren't able to flash e.g. a modem with Odin? Because I tried it just now, and for me it's working fine.
From my understanding about the .pit file, the pit gives informtion about the start and end point for the partitions. After we have repartitioned the device partially, for the changed partitoins the information in the pit file doesn't match anymore, but as kernel, modem, recovery, etc. are stored on the partitons 1-7 and we haven't changed them, Odin pulls the pit from our device and flash to modem e.g. to the place the information in the pit file says. So all flashing actions which only go to the partitions 1-7 shouldn't be problematic, only if you want to flash a whole samsung firmware with Odin you have to tick repartitioning and select the correct pit file in Odin.
And then I have a question regarding doing the same on the S4. The S4 has a protected bootloader as you maybe has heard of. Do you think this method is also usable on the S4 without the danger of a hard-brick? From the recovery all the partitions I want to change ( cache, system, data, ...) are also flashable, only those before are protected, so could/should it work? Invisiblek has written it would brick my phone :
invisiblek said:
DO NOT DO THIS
that link is for an exynos sgs3
our pit is signed. This will brick your device.
Click to expand...
Click to collapse
L
You are most likely correct with the first part of your post. I haven't tried flashing separate parts of a rom at that time, but it would most likely work.
Regarding S4, to be honest i have no knowledge of it. Even more so about signed stuff. From general knowledge, if the signature isn't connected the things you want to modify, it would probably work, but don't take my word for it. You'd better off discussing this in the S4 forums
Regarding GT-I9300_mx_20120329.pit, i later read that it's for 64gb version of i9300. Although it worked fine for me. As for where to get it, just google it.. there are zips all around the net with various versions, including this one.

[HELP]Problem resizing partitions

I have a problem. I have try to resize the partition using nvflash. I have use guide from modaco and also the preconfigured files. The problem is that /system is always at ~360mb (stock size). All other partitions are resized propertly.
Any help?
doctoralex said:
I have a problem. I have try to resize the partition using nvflash. I have use guide from modaco and also the preconfigured files. The problem is that /system is always at ~360mb (stock size). All other partitions are resized propertly.
Any help?
Click to expand...
Click to collapse
I'm facing the same problem. I think I know what the problem is but I cannot solve it!
I currently have installed Stefan 28G ics rom (2nd edition) and my goal is to add about 100mb to the system partition, reducing internal /sdcard.
If I use fdisk command from adb shell I find out that the partion IS actually resized, but the file system on it isn't!!
So: partition now is 650Mb, but file system on it is 550Mb!
That's because nvflash simply makes a dd of the system.img (which has the old partition size) to the partition so in my opinion there are two solutions:
a) open system.img in a linux environment, add some stuff to reach 650Mb on it and repack it with the new size
b) backup system data, formata the partition (which is already resized) to get 650Mb file system and then restore your system data
I think that all "resizing guide" doesn't talk about this second step because in that case the system.img has always the right size.
Any ideas?
Raffaele80 said:
I'm facing the same problem. I think I know what the problem is but I cannot solve it!
I currently have installed Stefan 28G ics rom (2nd edition) and my goal is to add about 100mb to the system partition, reducing internal /sdcard.
If I use fdisk command from adb shell I find out that the partion IS actually resized, but the file system on it isn't!!
So: partition now is 650Mb, but file system on it is 550Mb!
That's because nvflash simply makes a dd of the system.img (which has the old partition size) to the partition so in my opinion there are two solutions:
a) open system.img in a linux environment, add some stuff to reach 650Mb on it and repack it with the new size
b) backup system data, formata the partition (which is already resized) to get 650Mb file system and then restore your system data
I think that all "resizing guide" doesn't talk about this second step because in that case the system.img has always the right size.
Any ideas?
Click to expand...
Click to collapse
I solved my problem!
As explained before I have just added some stuff to the system.img file and then resized the file system:
dd if=/dev/zero bs=4096 count=35328 >> system.img
e2fsck -f system.img
resize2fs system.img
PS: bs and count depend on the partition size that you have set before in the .cfg file
Then NVFlashing again solve the problem!
doctoralex said:
I have a problem. I have try to resize the partition using nvflash. I have use guide from modaco and also the preconfigured files. The problem is that /system is always at ~360mb (stock size). All other partitions are resized propertly.
Any help?
Click to expand...
Click to collapse
Backup your rom with cwm.
Format /system in cwm.
Restore your cwm backup.
Sent from my LG-P990 using xda app-developers app

[Q] How big is system partition

I see from a few Android ROMS that it says it requires a certain larger size system partition. I've already installed one android ROM (jcsullins CM10), but was wondering how I can tell how big a partition that got created and if it is big enough for these other ROMs.
Thanks.
Did you use ACMEInstaller2 or 3?
Or, type "df" in a terminal emulator.
bananagranola said:
Did you use ACMEInstaller2 or 3?
Or, type "df" in a terminal emulator.
Click to expand...
Click to collapse
I'm pretty sure I used ACMEInstaller3.
Totally forgot about the easy way with df. This is what it says.
/boot 31M
/system 387.4M
/data 1.5G
/cache 193.7M
Found a nice WebOS tool called Tailor that tells me the size.
system = 400M
cache = 200M
date = 1.5G
I guess my partition sizes are ok.
Thanks.

[GUIDE][HOWTO] Multi-boot Android systems on Xperia TX

FIRST OF ALL, we should say thanks to @alvinhochun 's work on porting kexec hardboot patch to Xperia M. His original thread is here: http://forum.xda-developers.com/showthread.php?t=2568151
And @Tasssadar who has ported kexec hardboot patch on MSM chips. Original thread is here: http://forum.xda-developers.com/nexus-4/orig-development/kexec-hardboot-patch-t2472316/post46223952
As for the kernel patch and kexec binary for TX, they are here: http://forum.xda-developers.com/showthread.php?t=2747215
OK let's begin our tour on TX...
0. Disclaimer
This is a rather dangerous hack. I'm not responsible for data loss, broken SD cards, dead internal storage or bricked phones. Try this at your own risk. Proceed only when you know what you are doing.​
1. Requirements
a. ROM with “kexec hardboot” patched kernel. My OmniROM build will do the job. Since Alx31Tse is also using my kernel source for TX, the Carbon builds for TX may be capable of handling this as well. This ROM should be installed into internal storage : just flash it in recovery as usual.​b. External MicroSD card which is big enough for your ROMs. One ROM takes up ~4GB space.​c. Some basic knowledge of partitions, device nodes, ramdisk modding(check this thread by letama: http://forum.xda-developers.com/showthread.php?t=2418893).​
2. Partitioning the external sdcard
a. Plan the partitions​
Each ROM need three partitions : system, data and cache. You need at least 1.4GB system + 2GB data + 400MB cache for stock ROMs. The system partition for third-party ROMs can be shrinked to ~900MB. Of course you can set your own data partition size if 2GB does not suit your needs. The space left can be used for storing data just like a normal sdcard.
For example, I'm using a 16GB card and going to install two stock ROMs (9.1.B.1.67 + 9.2.A.0.295). So I have to create at least 6 partitions for them:
1.4GB system for 295
2GB data for 295
400MB cache for 295
1.4GB system for 67
2GB data for 67
400MB cache for 67
There is ~8GB left after all these partitions. This can be used as a normal sdcard. Just create another partition for it.​
b. Go partitioning it!​
Everyone has his own way of doing this. I prefer using a USB card reader and Disk Utility that comes with Ubuntu.
Erase the card and initialize it with GUID Partition Table (GPT). Of course you can use MBR, but I didn't test it. Be careful in the following steps if you choose MBR.
Create the “normal sdcard” partition. In my example, create a 8GB partition here and format it with FAT32. THIS PARTITION SHOULD BE THE FIRST ONE ON THE CARD! Otherwise Android system may not be able to recognize it.
Create the partitions for guest systems. There are no particular order for the partitions. Just make sure you remember their order. DO NOT FORMAT them for now.
In my example:
PART 1: 8GB, FAT32
PART 2: 1.4GB unformatted
PART 3: 2GB unformatted
PART 4: 400MB unformatted
PART 5: 1.4GB unformatted
PART 6: 2GB unformatted
PART 7: 400MB unformatted​
3. Kernel mods for guest systems
For each guest system:
a. Unpack its kernel.​
If you are going to install a full stock ROM, please choose a corresponding kernel with recovery built-in in Android Development section.
If you are going to install a third-party ROM (OmniROM, CM etc) or customized stock ROM (Rockers etc), chances are that their kernels have recovery built-in already and you can proceed.
Now unpack the kernel.
We have zImage(sec0.bin), ramdisk(sec1.bin) now. The rest can be ignored.​
b. Modify the mount entries in fstab (and other files)​
fstab is the file that suggests the real device for the /system, /data and /cache mount points. Modding it will make it possible to mount the partitions other than the ones in internal storage on /system /data and /cache, so that we can separate different systems into different partitions.
Now you have to be clear about “how the partitions on external card will be presented in your phone” (their device nodes). In my example (GPT with 7 partitions):
PART 1: 8GB → /dev/block/mmcblk1p1
PART 2: 1.4GB → /dev/block/mmcblk1p2
PART 3: 2GB → /dev/block/mmcblk1p3
PART 4: 400MB → /dev/block/mmcblk1p4
PART 5: 1.4GB → /dev/block/mmcblk1p5
PART 6: 2GB → /dev/block/mmcblk1p6
PART 7: 400MB → /dev/block/mmcblk1p7
As has been mentioned above, mmcblk1p1 is for normal file storage, p2~p4 is for 295, p5~p7 is for 67.
Files that need modding:
(sec1.bin/sbin/ramdisk.cpio) /fstab, /fstab.qcom, /init.target.rc
Click to expand...
Click to collapse
(sec1.bin/sbin/ramdisk-recovery.cpio) /fstab, /fstab.qcom, /etc/recovery.fstab, /etc/twrp.fstab
Click to expand...
Click to collapse
The fstabs are easy to deal with. Just change the block device name for /system /cache and /data to /dev/block/mmcblk1p* accordingly. The init.target.rc has only one line that should be modded. For example,
FOR 9.1.B.1.67 in my example:
ramdisk.cpio/fstab:
/data ext4 /dev/block/mmcblk1p6
/cache ext4 /dev/block/mmcblk1p7
/boot/modem_fs1 raw /dev/block/platform/msm_sdcc.1/by-name/modemst1
/boot/modem_fs2 raw /dev/block/platform/msm_sdcc.1/by-name/modemst2
Click to expand...
Click to collapse
ramdisk.cpio/fstab.qcom:
/dev/block/mmcblk1p5 /system ext4 ro,barrier=1,discard wait,check
/dev/block/mmcblk1p6 /data ext4 nosuid,nodev,noatime,barrier=1,noauto_da_alloc,discard wait,check,encryptable=footer
/dev/block/mmcblk1p7 /cache ext4 nosuid,nodev,noatime,barrier=1,discard wait,check
/dev/block/platform/msm_sdcc.1/by-name/SDCard /mnt/int_storage ext4 nosuid,nodev,barrier=1,noauto_da_alloc,discard wait,check
Click to expand...
Click to collapse
ramdisk.cpio/init.target.rc:
(SEARCH FOR /system)
on post-fs
mount ext4 /dev/block/mmcblk1p5 /system ro remount barrier=1
Click to expand...
Click to collapse
Just do the same for ramdisk-recovery.cpio. For example:
ramdisk-recovery.cpio/etc/recovery.fstab
/boot emmc /dev/block/mmcblk0p4
/system ext4 /dev/block/mmcblk1p5
/cache ext4 /dev/block/mmcblk1p7
/data ext4 /dev/block/mmcblk1p6 length=-16384
/sdcard ext4 /dev/block/mmcblk0p15
/external_sd auto /dev/block/mmcblk1p1 /dev/block/mmcblk1
Click to expand...
Click to collapse
And replace mmcblk1p5~p7 with p2~p4 then do it all again for 9.2.A.0.295's ramdisk.cpio & ramdisk-recovery.cpio
NOTE: All these fstab and rc files should be rw-r—r-- and owned by root:root. Otherwise the system may fail to boot.
Now repack the ramdisk.cpio, ramdisk-recovery.cpio and then the whole ramdisk.​
4. Installing the guest systems
Take notice of the texts in red. Change them to fit your needs.
a. Preparing the guest systems​If you are installing full stock ROM (FTF format), you can use Flashtool to dump the system image (Flashtool > Tools > Sin Editor, load system.sin from FTF archive and dump data). Then write the image to the sdcard by “dd if=system.ext4 of=/dev/sdb2“ on the computer.
If you are installing ROMs in ZIP format, you need to modify updater-script and replace all (for 9.1.B.1.67 in my example)
/dev/block/mmcblk0p12 or /dev/block/platform/msm_sdcc.1/by-name/System to /dev/block/mmcblk1p5
Click to expand...
Click to collapse
/dev/block/mmcblk0p13 or /dev/block/platform/msm_sdcc.1/by-name/Cache to /dev/block/mmcblk1p7
Click to expand...
Click to collapse
/dev/block/mmcblk0p14 or /dev/block/platform/msm_sdcc.1/by-name/Userdata to /dev/block/mmcblk1p6
Click to expand...
Click to collapse
And
remove /dev/block/mmcblk0p4 or /dev/block/platform/msm_sdcc.1/by-name/Kernel formatting/writing lines
Click to expand...
Click to collapse
Then repack the ROM and push it into phone's internal sdcard.​
b. Boot the guest kernel/system​Remember we have zImage and modded ramdisk for each guest system? adb push them to /data partition. The kexec binary is needed as well. Now you can use the kexec binary(check the beginning of this thread) to boot your guest kernel and then recovery.
For example:
I pushed 295 kernel zImage to /data/boot4.3/zImage-stock, modded ramdisk to /data/boot4.3/initrd-stock, and kexec binary to /data/kexec. Now execute as root:
Code:
cd /data
chmod 755 kexec
busybox sync
busybox mount -o remount,ro /system
busybox mount -o remount,ro /cache
busybox mount -o remount,ro /data
busybox sync
./kexec --load-hardboot [COLOR="Red"]./boot4.3/zImage-stock[/COLOR] –initrd=[COLOR="Red"]./boot4.3/initrd-stock[/COLOR] --mem-min=0x85000000 --command-line="`cat /proc/cmdline`"
busybox sync
./kexec -e # phone reboots and guest kernel (295) starts
NOTE: the guest kernel's cmdline may not be exactly the same as the host one. However, it doesn't matter much. 67 and 295 both boot fine using the same cmdline as OmniROM. Since bootloader will append some parameters to the command line, using guest's sec3 without appending these parameters manually is not a good idea.​
c. Preparing filesystems and installing ROMs in ZIP​After the phone reboots, press Vol buttons at purple LED to go into recovery. Now you are in the recovery for your guest system (295).
FORMAT (not wipe) /data and /cache there. For ZIP ROMs you need to format /system as well.
Then install the modded ZIP file if needed. You can also flash SuperSU or anything else to this guest system in the recovery (remember to check if there are wrong block device paths in updater-script).
After finishing the installation of one guest system, reboot and you will go into the host ROM. Execute the commands again and specific the next guest system's zImage and ramdisk to boot into the next guest system. Then do the formatting and flashing things as described above.​
5. Boot into guest systems
Once you finish installing all the guest systems, reboot. Then in the host ROM you can execute the commands in Step 4 again to boot into the corresponding guest system. Don't press any key after the reboot. If there's nothing wrong, you will see the bootanimation and then the Android system. Since external sdcards may not be as fast as internal storage, the first boot may take very long time. If you see the bootanimation, just be patient and it will boot up finally.​
===========================================================
I know I can't speak English well and it's hard to make myself clear. So if you feel confused, please post your questions here so that everyone who knows the answer will be able to help.
And if you are skilled in Android things, you can choose your own way to achieve the goal:
Partition the sdcard → Mod fstsb and rcs to mount partitions on sdcard to /system etc → Mod the ROM installation script → Boot into guest recovery to format(initialize) data & cache &system and flash ROM → Boot into the guest Android OS
Click to expand...
Click to collapse
This is a little bit complicated. But I do hope this will add more fun to our device
Thanks for your sharing
got it
Although this is labeled for the Xperia TX, after reading through everything, it looks like this works on all devices, you just have to change a few things. Good job putting this together! (Even though I don't have an Xperia TX)
r3pwn said:
Although this is labeled for the Xperia TX, after reading through everything, it looks like this works on all devices, you just have to change a few things. Good job putting this together! (Even though I don't have an Xperia TX)
Click to expand...
Click to collapse
Yeah, it seems that the guide applies to all devices with patched kernels
updateing said:
Yeah, it seems that the guide applies to all devices with patched kernels
Click to expand...
Click to collapse
This guide is nice, full of content, and detailed, but wouldn't it have been easier, though, to just make a MultiROM port?
r3pwn said:
This guide is nice, full of content, and detailed, but wouldn't it have been easier, though, to just make a MultiROM port?
Click to expand...
Click to collapse
I have thought of porting MultiROM, but I'm running a tight schedule...sorry
Whether this Xperia V can also be made from ??
Mircinko96 said:
Whether this Xperia V can also be made from ??
Click to expand...
Click to collapse
It's applicable to Xperia V in theory. But you need a kernel with kexec hardboot patch, which hasn't appeared yet (as far as I have seen). If you know how to compile a kernel, you can try patching the kernel yourself.
.........
do I need linux to unpack kernel?

Safestrap & unused Webtop partition

tried to use the webtop partition as system partition with timangus' altpart-safestrap, unfortunately the partition has a size of 0 MB
tried also Mentor's Modified safestrap, where (logically) the data partition has 0 MB
tried to repair the file system as recommended by Mentor, but unsucessful
I started from a new stock rom (4.1.2 flashed via SBF)
Any help on how to repair the webtop partition is appreciated

Categories

Resources