Related
About the time when further existence of Cyanogenmod was endangered because of Google's legal claims, there happened to be a post from the author of Cyanogenmod:
Since I don't work with any of these closed source applications directly, what I intend to do is simply ship the next version of CyanogenMod as a "bare bones" ROM. You'll be able to make calls, MMS, take photos, etc. In order to get our beloved Google sync and applications back, you'll need to make a backup first. I'm working on an application that will do this for you.
Click to expand...
Click to collapse
The current state is that (supposedly) Cyanogenmod build does not contain any Google apps, BUT in fact to install Cyanogen you should first flash a development image from HTC (DRC83 or so) that contains them, and atop of this Cyanogenmod.
My question is, will the current Cyanogenmod build work without the HTC "base" files, in the way it is described in the message quoted above?
I own a Magic 32A. Could I just flash the latest Cyanogenmod update.zip (and another update.zip with appropriate kernel)?
I DO NOT want any proprietary apps on my phone.
(It will suffice if I have a web browser and a basic contact list application, without syncing.)
If anyone knowledgeable in the affairs of "update.zip" format reads this, I would also like to know if the Cyanogenmod's update.zip does only write some files to existing filesystems, or does it first erase/create new filesystems in some areas of flash memory? And what does the update.zip from HTC do (this one is certainly supposed to erase the root filesystem of the device!)? Would applying just the Cyanogenmod's update.zip leave the HTC files in place if they are already there, and how can I clean the root filesystem?
Not sure if that's how it works. Why don't you just remove the apps after?
If you really want Android without Google Apps, you can also compile from the source Android. That will give you basic functionality (phone, contacts, email) without Google Apps on it. You just need to checkout donut branch, instead of eclair's, since eclair is still on development.
Check: source.android.com and follow the documentation to checkout and compile for dream and sapphire
xaueious said:
Why don't you just remove the apps after?
Click to expand...
Click to collapse
The Google's libraries seem to be hiding in every corner, so that's not really clean.
@dferreira
Right, but it is probably some hassle (and I would duplicate some work of the people who publish their images here), also the download would take a long time with my internet connection. Why do it, if it's already done? A stock Android build from AOSP must be hanging somewhere around... but I haven't seen it yet. All the donut images I've seen on this forum had some silly modifications and were prepared to work with Google packages.
(Or is the source prepared nicely enough to work right if it compiles successfully and is put on the device? How do you put the build in an update.zip to allow flashing to a consumer device with a custom recovery image, but without engineering SPL?)
Donut branch should compile and work without a hitch. Even eclair works out-of-the-box, without camera working and 3D acceleration.
The compiled result will be recovery.img, boot.img, system.img, userdata.img... I've flashed them using fastboot Unless you know how to make a update.zip out of these, you should be all set. The update.zip only works if signed with the right certificates for non-engineering SPL devices.
The update.zip only works if signed with the right certificates for non-engineering SPL devices.
Click to expand...
Click to collapse
I wonder how do some folks from this forum do it then?
I doubt they have relations with google employees!
Do you know which kernel trees are compatible with the 3.22.20.17 radio firmware that is found in stock Magic devices?
AOSP has a kernel project and HTC has put some kernel sources at developer.htc.com, but there's only something called "HTC Magic Kernel Source Code" - no mention for which model.
Well, actually, i might do with some of the kernels that lie around the forum, but do they have any special requirements for initrd and modules, that would require modifying the flash images you get from building the Donut branch?
Seems to me that kernel is in the boot.img. You flashed it and everything works. You have not touched the radio firmware. Correct or not?
kguciek said:
I wonder how do some folks from this forum do it then?
I doubt they have relations with google employees!
Do you know which kernel trees are compatible with the 3.22.20.17 radio firmware that is found in stock Magic devices?
AOSP has a kernel project and HTC has put some kernel sources at developer.htc.com, but there's only something called "HTC Magic Kernel Source Code" - no mention for which model.
Well, actually, i might do with some of the kernels that lie around the forum, but do they have any special requirements for initrd and modules, that would require modifying the flash images you get from building the Donut branch?
Seems to me that kernel is in the boot.img. You flashed it and everything works. You have not touched the radio firmware. Correct or not?
Click to expand...
Click to collapse
Yes, the kernel is in boot.img, and it is the AOSP kernel that comes with the source code There is no radio firmware on AOSP.
update.zip is made by issuing make otapackage.
Hi buddy i thought about something like that few weeks ago and i think MarsDroid has already made some version of Android(Very lite MarsDroid SPL 7) fully without Google apps, so try it..
OK, I've built an image from donut source, coupled it with a kernel from a CyanogenMod port, and it works flawlessly on my phone!
I've uploaded the images to RapidShare, should anyone need them Links are at my website (guciek.net/en/stuff/android_builds).
kguciek said:
My question is, will the current Cyanogenmod build work without the HTC "base" files, in the way it is described in the message quoted above?
I own a Magic 32A. Could I just flash the latest Cyanogenmod update.zip (and another update.zip with appropriate kernel)?
I DO NOT want any proprietary apps on my phone.
(It will suffice if I have a web browser and a basic contact list application, without syncing.)
Click to expand...
Click to collapse
Yes, it works fine if you don't flash the 'defanged' update image first.
unfnknblvbl said:
Yes, it works fine if you don't flash the 'defanged' update image first.
Click to expand...
Click to collapse
But it wouldn't erase the whole system partition, so there could still be some files left.
Now that I realised I can flash images from recovery even without engineering SPL, it seems a safer and cleaner way.
Also, I like to have a second ext2 partition on SD card that is only accessible from a computer, and I wasn't able to do this with CyanogenMod, which instantly filled it with apps2sd data, swap files etc...
kguciek said:
But it wouldn't erase the whole system partition, so there could still be some files left.
Click to expand...
Click to collapse
No, that's why you wipe from recovery before installing.
unfnknblvbl said:
No, that's why you wipe from recovery before installing.
Click to expand...
Click to collapse
Actually wiping only erases the data partition, not the system one.
fastboot erase system -w
carz12 said:
fastboot erase system -w
Click to expand...
Click to collapse
Right, but it isn't possible for users with unmodified SPLs.
Actually, you can just flash a image of an empty yaffs filesystem to system partition (it's just a few blocks at most).
Progress update and INT2SD implementation request form!
With holidays starting, and more free time on my hands, I've decided to revive this project. Having my hard drive fail on me recently, and losing the request log, it has become obvious that I need a new system of handling requests, and it is here. If you have requested a ROM before, please send a request again, via this form.
Please submit all further requests via this form!
---
This is the INT2SD thread for Sense ROMs and their developers and users.
INT2SD thread for AOSP ROMs
What is INT2SD?
INT2SD doesn't use symlinks. It mounts ext partition on your SD to /data, thus eliminating the need for the mtd5 userdata partition. This makes the mtd5 userdata partition unneeded. It is used in conjunction with the fatsys HBOOT (more info later on), allowing most of the vital parts of a ROM to stay on the system partition without the need to symlink half of it to the SD due to memory shortage.
For now, there is only one ROM here, but more will come! If you wish to see INT2SD in your favorite ROM or in your own ROM, please post here!
INT2SD-S - "Speed" (default as of 29th Jun)
Main characteristics:
/data on SD ext, /data/data on internal
/data/data limited to 280 MB (probably enough for more than 100 user apps)
noticeably faster on slower cards
for use with CM7r2 HBOOT
Description:
The new "speed" flavour mounts ext to /data and userdata to /data/data, achieving great speed while still retaining excellent storage capabilities. It's used with the CM7r2 HBOOT. This is now the default flavour, offering great speed while still being able to hold a hefty amount of apps.
INT2SD-M - "Mass" (discontinued)
Main characteristics:
/data on SD ext
number of apps is only limited by ext size
requires a faster card
for use with fatsys HBOOT
Description:
The classic "mass" flavour mounts ext to /data, thus eliminating the need for the mtd5 userdata partition. It has proven to be slow even on some of the faster cards. Due to INT2SD-S being able to hold a very high number of applications, and still being much faster, this flavour is discontinued.
FAQ
For users: How to get this in your favorite ROM
For ROM developers: How to get this implemented in your ROM
Please fill out this form.
Cross-device implementations
For now, no. You may submit requests, but I won't be able to fulfill them for a while. I have quite a lot of real life work on my plate, not to mention a list of Desire ROMs I have to tend to. After that's done, I'll be happy to try blind-porting it to whichever device you wish, but my priority are Desire ROMs, primarily because it's a lot easier to implement INT2SD into ROMs for a phone I already have.
Universal update zips
Also, no. Each ROM is different, and due to the nature of INT2SD, it is simply not possible to make a one-for-all universal update zip. Every ROM requires tending to its peculiarities, especially Sense ROMs, and I would rather not take the change of trying to make one and end up with a flashable bootloop zip.
Why don't you just publish instructions on how to implement INT2SD for devs to use?
Proz0r said:
You can take a look at the modified ROM and you will find 3 new files in /system/etc, dalchk, fsck and sleep. These files are executed by init.rc because of my modifications to it. You can also decompile the boot.img and use a tool such as diff or diffuse (a GUI for diff) and check the differences between it and the unmodified init.rc from Alex's standard, D2EXT ROM. However, his ROM required another init.d script to move weather animations to /data, and modifications to the updater-script to flash everything that would normally be flashed to /data, to be flashed to /sd-ext. Sounds simple enough, right? Well, it's actually not quite as simple. When I have first implemented INT2SD to CyanogenMod 7, all I had to do was edit a few lines and add those three scripts. There was not a single ROM (and there are a few unreleased ones which I've worked on) to which I could apply a "standard" procedure. Each ROM required further modifications on its own and being the one who devised INT2SD, I know what I should look out for in order to avoid catastrophical bugs. ROM developers do not. This is why I do NOT offer support for "homemade" INT2SD implementations. Every ROM has its own peculiarities that need tending to and INT2SD implementations need to be very flexible to allow the ROM to work in conjunction with it. Sure, everything could go great, but INT2SD is extremely easy to implement horribly wrong and have huge bugs and even unbootable systems, and without knowing what the dev did to put it in their ROM, it is next to impossible for me to troubleshoot and fix. It would probably end up with me having to implement it myself either way in most cases and having angry developers and possibly users on my hands being pissed at me for doing a bad job and releasing a ****ty product, when the problem was just a typo in init.rc. That's why I have not nor will I release instructions for devs on how to implement it themselves.
Click to expand...
Click to collapse
Before you download!
Although it is for the best part bug free, INT2SD is still a fairly fresh project so I'm looking for as much input as I can get to fix possible bugs I haven't yet uncovered. If you try a ROM featuring INT2SD, please be sure to comment in this thread on your experience, even if it works great or doesn't work at all. If you wish to further support the project, there is a donate button in my signature. Although a nice sign of support and appreciation, donations are not obligatory!
Due to /data/data being on the SD, a high-class card is recommended.
Another thing is the HBOOT, fatsys. You must flash it before flashing any of the INT2SD Sense ROMs.
fatsys HBOOT
bravo_alphaspl-fatsys.img
MD5: 2272c1cb06f8eb743aa1c0ad4c3fa36b
PB99IMG-fatsys.zip
MD5: 4d6b2e74c241361237df047bfed5ff08
INT2SD Sense ROMs require a special HBOOT, fatsys. This special HBOOT has 427 MB dedicated for /system, 5 MB for /cache and 5 MB for /data and there is probably no ROM without INT2SD that would work on it properly. It was made so that the largest part of Desire's internal memory can be used for quick access to vital system files by storing them in /system instead of symlinking them to /sd-ext, therefore slowing the entire system down. There is still plenty of space for your apps if you make a large enough SD ext partition, since SD ext gets mounted to /data and the real, 5 MB mtd5 userdata partition goes unused. So, /data on SD ext, huge /system and no symlinks! Before flashing a Sense INT2SD ROM, make sure you have flashed the fatsys HBOOT!
Download
Thanks to Ante0 for hosting the files!
INT2SD implemented in:
Alex-V1.8 GB Sense HD INT2SD-M fatsys (Thread | Download)
Alex-V1.8 GB Sense HD INT2SD-S CM7r2 (Thread | Download in a minute)
Runnymede AIO 6.1.1 Beta (Thread)
Current bugs:
-
To do list for the next version:
-
Credits (alphabetically):
Alex-V - providing me with the first Sense ROM to implement INT2SD in
Ante0 - providing proper hosting for the zips
brabo, GShellz admin - huge help with bash scripts implemented in the ROMs
CM - a base ROM for implementing the method in
Droidzone - suggestions, help with HBOOTs
Hacre - massive assistance as well, kicking me to try and realise the main idea and for coming up with names "INT2SD" and "fatsys"
JieeHD - help with compiling/decompiling the boot.img files and his excellent guides on FYA
Pulser_g2 - massive assistance, ideas on the reboot bug and hosting
Richard Trip - making GingerVillain which now has a version featuring INT2SD
snq- - pointing out a huge typo and saving me multiple hours of pointless work
ubuntubhoy - a kick in the arse I needed
... and everyone else in the #villainrom IRC channel for help and mental support! Thank you all, and everyone I forgot to mention (PM!).
Disclamer: I'm not responsible if something goes wrong and wreaks havoc upon you, your phone, your card, any part of your phone, your friends, your family, your close or distant relatives and/or your pet, but I will gladly provide assistance if it does.
I'm not a dev at all, but I think this tool can help you: a too for making coustoms hboot by _thalamus
http://thalamus-hacking.blogspot.com/2011/07/custom-hbootsupdate.html
I have been using for months without any problem
Well, if you manage to learn how to reverse engineer and manipulate hboot, do share.. You might want to ask thalamus. I read that he'd done it.
Edit: Ah blackhawk_LA has already posted that.
@blackhawk_LA, is there an open source version of this tool?
blackhawk_LA said:
I'm not a dev at all, but I think this tool can help you: a too for making coustoms hboot by _thalamus
http://thalamus-hacking.blogspot.com/2011/07/custom-hbootsupdate.html
I have been using for months without any problem
Click to expand...
Click to collapse
Awesome, thanks! Wish there was a Linux version of it, luckily, I have Windows in dual-boot so I'll whip something up in a minute!
Droidzone said:
Well, if you manage to learn how to reverse engineer and manipulate hboot, do share.. You might want to ask thalamus. I read that he'd done it.
Edit: Ah blackhawk_LA has already posted that.
@blackhawk_LA, is there an open source version of this tool?
Click to expand...
Click to collapse
Yeah, I'm interested in how this works too.
Droidzone said:
@blackhawk_LA, is there an open source version of this tool?
Click to expand...
Click to collapse
I don't know, I just found that tool and start using it, I can't do anything more
@blackhawk_LA
Have you ever had any issues with the application? It's making a very important part of the system and if any errors would occur, it would be a catastrophe, which is why I am a bit apprehensive towards this program.
Make HBOOTS with it which have the same sizes as the HBOOTs from Alpharev, compare MD5, if they match, it's probably safe. Then you should be good to go to make a custom HBOOT with it
Never had any issue, I have used it very carefully to make at least 10 different custom hboots, and my phone is still alive
More statistics are needed to say it's completely safe but I think thalamus did a perfect job
I can say the program is very safe... have a dozen of custom hboots with it... no problem at all.
And looking forward to your INT2SD for sense..
here you go..
http://www.multiupload.com/N0B1RHYFPW
I'm very interested too!!! Thanks and keep up the awesome work!
When it'll be available I'll try it into my rom.
msandeep said:
here you go..
http://www.multiupload.com/N0B1RHYFPW
Click to expand...
Click to collapse
Thanks man, have you tested it?
You're not telling me everyone is too afraid to flash it, so everyone hopes someone else tries it to take the risk... -.-
Proz0r said:
Thanks man, have you tested it?
Click to expand...
Click to collapse
yes...its the one i use in my roms...and 40mb real data is really good to add apps like maps (that can updated) to the rom
with kind regards
Chaosz-X said:
You're not telling me everyone is too afraid to flash it, so everyone hopes someone else tries it to take the risk... -.-
Click to expand...
Click to collapse
I need my phone for the next couple of days and therefore cannot try it myself.
Alex-V said:
yes...its the one i use in my roms...and 40mb real data is really good to add apps like maps (that can updated) to the rom
with kind regards
Click to expand...
Click to collapse
Nice. Should real data be reduced to 5 MB or be left at 40 MB then, in INT2SD? Since it won't be needed for symlinks with it, I only see the point in having the 5 MB for the fsck log.
Word of advice.. Before flashing new hboot, use the alpharev downgrader. Otherwise you're screwed if the hboot turns out to be a corrupt file
Sent from my HTC Desire using Tapatalk
Thanks man, could you briefly describe what would happen if I would flash a corrupted HBOOT with and without flashing the downgrader prior?
Proz0r said:
Thanks man, could you briefly describe what would happen if I would flash a corrupted HBOOT with and without flashing the downgrader prior?
Click to expand...
Click to collapse
Well, AFAIK the HBOOT is also the white screen you get when you press Vol Down+Power, and it probably also involves the bootprocess normally, so I would say: broken HBOOT = a very nice brick.
Though I don't know what the downgrader is..
Yup, I know about that, I'm wondering about the downgrader too.
Proz0r said:
Yup, I know about that, I'm wondering about the downgrader too.
Click to expand...
Click to collapse
I'm always use the hboot-downgrade whenever I change hboot no matter whether the previous hboot is a lock hboot or an unlock hboot. It is always best to unlock the hboot before flashing a new one to be on a safe side.
Here is hboot with 427mb/system, 5mb/cache & 5mb/data as you mentioned here
Proz0r said:
Now, we need a volunteer to make the said zero-data HBOOT for 5 MB for /cache, 5 MB for /data and the rest for /system.
Click to expand...
Click to collapse
I tested the hboot by flashing it to my phone.. no problem to go to recovery, no problem to boot to bootloader. but I don't have any ROM which can fit a 5mb data partition to test. The lowest I ever go is 30mb/data.
Note: to change to another hboot.. use the hboot_downgrade first as this is a lock hboot.
Edit : Manage to squeeze the ROM to fit a 5mb/data ... so confirm the hboot works.
conclusion first: it was possible.
i searched for custom mtd info for chacha on google, and i found some info in chinese suggested it was possible to apply custom mtd on chacha.
http://wenku.baidu.com/view/b029ab6027d3240c8447ef67.html
i don't speak chinese, but google translation helped. i used Mikevhl's recovery (http://forum.xda-developers.com/attachment.php?attachmentid=749943&d=1318622558), and also FR-Custom-MTD-v1.5.6-boot.zip (http://115.com/file/aqvgn30z#) and FR-Custom-MTD-v1.5.6-recovery.zip (http://115.com/file/aqvgnzmc#) as the chinese instruction said although i don't know where these files came from (maybe somewhere here?)
the procedure itself was the same as desire (bravo) or any other devices, and after the process, i got;
Filesystem 1K-blocks Used Available Use% Mounted on
tmpfs 214004 32 213972 0% /dev
/dev/block/mtdblock4 5120 1624 3496 32% /cache
/dev/block/mtdblock3 153600 150292 3308 98% /system
/dev/block/mtdblock5 307200 2560 304640 1% /data
yay!!
unfortunately, adlx.xda's v5.0.2.8 didn't work with these patches... sorry, if this info is already around here.
p.s. as usual, this patch automatically mounts /cache to /sd-ext when /cache partition is smaller than 20mb. however, /cache/download won't be created automatically which means vending.apk (market) fails to start. when you set /cache less than 20mb, you'd need create sd-ext partition on your sd card and either add init.d script to create /cache/download ot do it manually.
Interesting, but sorry I don't read chinese :-(. I understand it's for changing the default partition layout on the Chacha.
Isn't it easier to use App2SD?
What are the patches? Do you why it doesn't work with my CWM build (maybe we can improve it so it work).
adlx.xda said:
Interesting, but sorry I don't read chinese :-(. I understand it's for changing the default partition layout on the Chacha.
Isn't it easier to use App2SD?
What are the patches? Do you why it doesn't work with my CWM build (maybe we can improve it so it work).
Click to expand...
Click to collapse
hi adlx.xda,
i don't read chinese, either;-)
it is sure easier for most people to use app2sd or data2sd, but i prefer to keep everything in the internal memory because it is possible if you change the partitions and don't install millions of apps. it is kinda a surprise to me that you didn't know about custom mtd...
anyway, the patches were originally created for htc desire, and adopted to other htc devices with low internal memory capacity like chacha/wildfire/etc.
http://forum.xda-developers.com/showthread.php?t=806321
there were two patches in the package; one for recovery partition and the other for boot partition. the recovery patch allows you to burn a custom rom according to the designated partition info. the boot patch allows you to change the boot image so that the device recognize the new partition info on boot.
when i use your recovery and the recovery patch together to burn a custom rom, chacha does not boot. i guess the patch does not modify something in your recovery correctly. on the other hand, this patch correctly modifies Mikevhl's old recovery. it is strange the patch can be used for the latest recovery for htc desire...
thx for your attention.
qt
could also be the repackaging of the kernel if it's patched. I tried for weeks unsuccessfully to unpackage and repackage a kernel for the status/chacha and had no luck. I was wanting to do some clocking tweaks.
bedwa said:
could also be the repackaging of the kernel if it's patched. I tried for weeks unsuccessfully to unpackage and repackage a kernel for the status/chacha and had no luck. I was wanting to do some clocking tweaks.
Click to expand...
Click to collapse
How do you try to unpack/repack? I wonder why it would fail.
I'll have to look at my setup on my netbook and get back to you. May be a few days. :-\ Kinda swamped ATM.
My Tab makes calls Yo! GT-P6800
i do read chinese, i saw this fews mths back but i dont have time for it... you will left with 24x~26xmb of free space.
I just wanted to update and say that I replied to this thread:
http://forum.xda-developers.com/showthread.php?p=35367602#post35367602
Basically, I'm wondering if the CustomMTD patches might be more compatible with a newer version of CWM compiled for our phone. I built a copy of 6.0.1.5, which mostly works, so if someone wants to give it a try, please do.
I managed to see custom partitions from CWM (not with the patches, but manually altering the recovery). 312MB /system and ~120MB /data (as an example just to try)
Apparently no problem with /system, but /data is not "working":
It appears as Read Only (it shouldn't actually event mount after moving/resizing it). Also not only it mounts, but it appears as 100%full, and won't allow me to do anything. I can't reformat it, remount rw,... I don't know why to be honest.
Now that I think about it, I should check dmesg.
dead links
it looks like all the links are dead.
here are the files you need.
qtotter said:
it looks like all the links are dead.
here are the files you need.
Click to expand...
Click to collapse
I managed to have it working, but I posted on another thread: http://forum.xda-developers.com/showpost.php?p=38029256&postcount=9
adlx.xda said:
I managed to have it working, but I posted on another thread: http://forum.xda-developers.com/showpost.php?p=38029256&postcount=9
Click to expand...
Click to collapse
so what files do we need, and what exactly do we do with them? I'd love to do the same as what you got working.
kronflux said:
so what files do we need, and what exactly do we do with them? I'd love to do the same as what you got working.
Click to expand...
Click to collapse
IIRC I used no files/patch,... It was more a matter of doing the partition table right. I took some notes and made an excel spreadsheet to help me with the conversions.
I'm on holiday starting today, I probably won't be able to review my notes and write anything related to this this month. Ping me again in Septembre so I review my notes and write a post about it .
kronflux said:
so what files do we need, and what exactly do we do with them? I'd love to do the same as what you got working.
Click to expand...
Click to collapse
it came from this thread originally http://forum.xda-developers.com/showpost.php?p=8578368&postcount=1, and it is very common among HTC Desire users.
it is quite easy to change partition sizes, and all the files you need are the three files that i uploaded.
recovery_chacha.img: Mike's old recovery that is compatible with this method. Don't use other recoveries!!
FR-Custom-MTD-v1.5.6-recovery.zip: This will patch recovery so that it can handle new partition sizes.
FR-Custom-MTD-v1.5.6-boot.zip: This will patch boot (kernel) in NAND so that the system can handle new partition sizes.
Procedure for ChaCha:
Make sure your phone is S-OFFed
**Make a backup in recovery first**
Place FR-Custom-MTD-v1.5.6-recovery.zip & FR-Custom-MTD-v1.5.6-boot.zip on SD card
Create mtdpartmap.txt on SD card with size of system & cache like "mtd 125 5". For example, I wanted to use ajeevlal's cm10.1 with Japanese IME and other system apps built in /system, I needed 330MB on /system and only 5MB on /cache (because I didn't need large /cache to use int2ext+.) So, my mtdpartmap.txt was "mtd 330 5". if you want to do this by shell command, it's gonna be like: echo "mtd 330 5" > /sdcard/mtdpartmap.txt
Flash Mike's old recovery above in fastboot like "fastboot flash recovery recovery_chacha.img"
Reboot into recovery
Wipe system, data, and cache
Flash FR-Custom-MTD-v1.5.6-recovery.zip, this patches recovery to use the new partition sizes
Reboot into recovery
Wipe system, data, and cache again just in case
Flash ROM, or restore from backup, and it will be flashed to NAND based on new partition sizes
Prior to rebooting, flash FR-Custom-MTD-v1.5.6-boot.zip, this patches boot (kernel) in NAND to load with the new partition sizes.
Reboot
unless you change mtdpartmap.txt on SD card, you don't need to repeat 1 - 8 every time. once you have decided your favorite partition sizes, you can start from 9. also, if your backup includes a patched boot image already, you can even skip 12 as well.
if you do this with any other newer recoveries, your phone simply does NOT boot. Mike's old recovery cannot backup sd-ext partition, but you can always do it manually like "dd if=/dev/block/mmcblk0p2 of=/sdcard/ext-bkup.img bs=4096" or something anyway.
kronflux's recovery
by the way, i tried your CWM 6.0.1.5 Built From Adlx http://forum.xda-developers.com/showthread.php?t=1989839, but it does not patch boot correctly. so the phone won't boot.
as i repeatedly keep saying, you need mike's old recovery to do this. i have tried so many recoveries, and this old one is the ONLY that is compatible with these patches.
qtotter said:
by the way, i tried your CWM 6.0.1.5 Built From Adlx http://forum.xda-developers.com/showthread.php?t=1989839, but it does not patch boot correctly. so the phone won't boot.
as i repeatedly keep saying, you need mike's old recovery to do this. i have tried so many recoveries, and this old one is the ONLY that is compatible with these patches.
Click to expand...
Click to collapse
it's also too large to fit in the recovery partition properly I believe. would be great if we could come up with a partitioning table that has enough space for it, as well as a little more space for app/rom storage.
so what are you saying, that we need this other recovery to actually do the partitioning? or that only that recovery will work on a custom partition table?
Adlx was just saying above, he doesn't think he used any custom files or patches. naturally we'll see in september what he has to say about it.
I did it with my recovery, not Mike's, and it worked, but again, I did it manually.
Sent from my Galaxy S4 running CarbonRom "Adlx Edition"
kronflux said:
so what are you saying, that we need this other recovery to actually do the partitioning? or that only that recovery will work on a custom partition table?
Click to expand...
Click to collapse
basically, this process patches recovery and boot to rewrite the partition table. Only Mike's old recovery can do both correctly.
talking about other recoveries, the reason why the phone doesn't boot is either recovery patch failure or boot patch failure. because i know Mike's one works and am not a recovery dev, i didn't even try to find which part is not working.
however, you can easily check it by switching the recovery between patching recovery and patching boot. i guess the former part is not working correctly because the latter part is rather straight forward and simple.
i just don't understand what you want, actually. changing the partition sizes or learning the mechanism of changing partition table??
qtotter said:
i just don't understand what you want, actually. changing the partition sizes or learning the mechanism of changing partition table??
Click to expand...
Click to collapse
Essentially, changing the sizes of partitions to accommodate a larger recovery image(so that my CWM6 could be flashed and work properly), as well as add more space to the system partition so that we don't have to worry about flashing lite versions of Gapps, or slimming down roms so that they fit.
kronflux said:
Essentially, changing the sizes of partitions to accommodate a larger recovery image(so that my CWM6 could be flashed and work properly), as well as add more space to the system partition so that we don't have to worry about flashing lite versions of Gapps, or slimming down roms so that they fit.
Click to expand...
Click to collapse
i have already explained how to do it above... now, my /system is 330 MB, and /cache is 5MB to cooperate with ajeevlal's cm10.1, full gapps, additional system apps and int2ext+. i am quite happy with my chacha setting not worrying about free space of /data, and battery lasts almost forever during sleep.
well, it is such a simple procedure, but i don't need to promote it to other people myself. i simply wanted to share the info that i learned over one year ago with people who want to make /system smaller for stock rom or make /system larger for cm10 and above.
The question has been asked several times. Recently a senior member asked a similar question and was told to read post two of a thread. That post did not answer the question but created more doubt. So Im going to steal some information from various posts to hopefully clarify this. Please if I get anything wrong let me know so I can correct it. But most of this will be stripped from various posts.
What is a partition?
A partition is an area of allocated space, a division of the whole overall area of space. In this case our partitions on the Epic 4G are /System, /Data, as well as /Cache. All with set permanent sizes.
What is a partition map?
A partition map is the configuration of our partitions, it's what in a vagueness sets our required sizes for the divisions of our nand also known as flash memory. A partition or partition map should not be confused with a file system. An example would be BML and MTD.
What is a file system?
A file system resides on the partition map and governs the data being read/wrote/moved/etc by the Operating System, in this case Android. Changing a file system is less complex than an overall change in partition mapping. They again, are not the same thing.
What is MTD?
MTD is an Open Source Partition map. It allows those who are using it control over how their partitions are sized and how much space is allocated here and how much space is taken away from there. Currently on MTD we have 689 megabytes of space allocated to our /data partition allowing more to be downloaded from the market as an example. MTD as a partition config has YAFFS2 as a file system residing on it governing how data is transferred and the speed of which it is done. EXT2 through 4 aren't possible on the MTD platform, just as YAFFS2 may not be possible on the BML proprietary platform.
What is BML?
BML like MTD is a partition map, however it is proprietary in nature, Close Source if you will. The size for /System /Data /Cache is set and permanent and makes opening up space more of a task for Developers. Stock the Epic 4G comes on BML, and is running RFS as it's file system, once rooted you can leave RFS for EXT4 (Journaled or Un-Journaled) as long as the kernel you use allows for EXT4. But in the end, changing a file system on BML does not lessen or enhance the control you have over your partitions.
What does it mean for me as an end user?
As an End User, MTD is an opening to a new life for the Galaxy S 4G. Things like ICS, more space in data or system, are more within our reach and grasp due to the nature of Open Source MTD is immersed in. We're closer to the Captivate, Fascinate, Vibrant, and Galaxy S international by being on MTD, we have that new freedom they've had for a long time. Not to say things like ICS aren't possible on BML but with this we're at a better standing point.
Click to expand...
Click to collapse
Basically, the internal storage on your phone is a flash device.
BML and FSR (aka XSR) acts as a software-based FTL (Flash Translation Layer).
This allows you to put filesystems like fat or ext4 on a flash device.
Hardware FTLs are everywhere. Look at your memory stick for instance. There is an FTL between the usb device controller and the nand flash chips that actually store the data. You can format your memory stick with ext4, btrfs, ntfs, whatever...
Samsung decided to go further down the rabbit hole with RFS, which is basically a modified version of FAT(32?) with ACLs and Journalling. IMO, silly.
BUT, fsr/rfs are proprietary modules and are built with a kernel that has a set of symbols exposed. If I disabled debugging (like I did) and something in one of those fsr/rfs modules depended on it, then the fsr/rfs modules wouldn't load (unless you trick it).
Moving to controlling the flash on the phone (in which the flash type on this phone isn't nand, but OneNAND-Flex) with MTD gets us away from the proprietary modules, but introduces a new problem. Can't use ext4 for /system, /data, and /cache anymore. Instead you have to use a flash filesystem, like yaffs2 (which is what the CM supported Samsung phones use). I would like to see a test on this phone with UBI/UBIFS though. I think that might have better performance then yaffs2 or jffs2 (but almost everything, including my grandma is faster then jffs2... seriously).
Click to expand...
Click to collapse
Mtd is the open source partition system used by aosp. Doing so allows more flexibility in porting roms and building from source. The proprietary stuff can be removed and get away from having to keep things like VVM for voicemail **.
This also moves us more towards vanilla android experience. Getting rid of proprietary file systems and and apps and various things to work properly.
Stolen from this thread and this post.
**note Antonx has found a way to remove the requirement for VVM. But is still working out if removing the code will break VVM for those people that use it.
I suggest we put BML to MTD and MTD to BML guides in the stickies. I know this info exists, but having it in the stickies will save many noob disasters and questions as this is getting more and more popular.
Sent from my SGH-T959V using xda premium
itzik2sh said:
I suggest we put BML to MTD and MTD to BML guides in the stickies. I know this info exists, but having it in the stickies will save many noob disasters and questions as this is getting more and more popular.
Sent from my SGH-T959V using xda premium
Click to expand...
Click to collapse
BML -> MTD will be a non-issue now since as of the latest commits I made to the CM7 update system (and whatever MTD roms base themselves off of that) we will be able to flash using only the rom.zip. You no longer need to fiddle with the efs backup/restore since the rom.zip will take care of it for you. The basic procedure will be
Reboot to RED cwm
Flash rom.zip
You will be rebooted to BLUE cwm
Flash rom.zip again
I just tested this myself from a completely stock KJ6 install and got onto a working CM7 install using a build I just made (with working IMEI/network/data) using those exact steps.
EDIT
Going back to BML will require a one-click for the time being until we can find a better solution, preferably one that involves CWM
One thing I didn't understand - why do we need a separated one click flash just for bootloaders? Can't it be done on the same time?
2nd, do we really need the bootloaders flash if we move from GB MTD to GB BML?
I assume I can odin just the kj1 kernel after the stock one click, just to get root. Do we have an odin version of AntonX's 1.1.0 kernel?
Sent from my SGH-T959V using xda premium
Well the bootloaders aren't a problem if the person is already on gingerbread. I had been messing with flashing bootloaders via CWM a while back but that just got my phone bricked. Until someone with unbrickablemod helps me test this or I get my own phone ubm'd, we'll have to do it this way.
No, you don't need to flash bootloaders all the time. The only times you need bootloaders are from GB -> Froyo or Froyo -> GB.
You should look into making your own custom one click, it's as easy as opening the .jar file in a program like 7-zip and extracting the files within, then you can recompress them. You can customize exactly what gets installed. I say you start with bhundven's kj6 one click and replace the kernel with your favorite custom one.
The files that get flashed from a one click are these:
one-click.jar/com/AdamOutler/HeimdallOneClick/resources/ROMPackage/HeimdallPackage.tar.gz
If you open that, you'll see all the files that get flashed, particularly zImage and zImage-1.
zImage gets flashed into the KERNEL partition
zImage-1 gets flashed into the RECOVERY partition
As it stands now, both zImage and zImage-1 should be identical since we don't have any recovery images and we have to use a kernel image instead.
Alright, noob here. Since I cannot post in the PACMAN development thread (http://forum.xda-developers.com/showthread.php?t=2164406) I will put this here.
- Problems installing PACMAN ROM
- After receiving "Errors Flashing", failures, downgraded recovery to TWRP 2.3.3.0
- 2.3.3.0 displayed "Error 7"
- Searching on error 7 led me down the path of the assert checks
- updater-script assert command in PACMAN ROM package is checking for model "ville".
- My HTC One S Special edition returns "villeplus" from "adb shell getprop ro.product.device"
My understanding is that the North American S4 and the Special Edition share identical hardware, only differing in drive size (16 vs. 64GB), so I am assuming any ROM designed for the ville will work on my phone.
Assuming it will I should be able to edit the "updater-script" file, but when I extract it windows is telling me that 23 files are duplicates. I'm not sure if this is because its windows vs. Linux that I'm extracting it on?? In any case, I don't seem to be able to modify the file without adversely affecting the integrity of the archive. Also would assume replacing the file will affect the MD5 hash which I believe TWRP checks when loading the ROM?
So first off, can someone confirm that this ROM will be compatible with my phone and 2, any suggestions on modifying the updater-script file within the archive?
Update
I was able to modify the updater-script file tonight using file X-Plore and text edit, so now the script is looking for "villeplus" rather than ville. My phone is S-OFF which I read means that it does not do signature checks... however, I'm not sure if that also means it bypasses MD5 checksums - I suspect not since I'm pretty sure I saw it verifying MD5 previously. So, since I tampered with the ZIP it still may not work.
My real question now that remains is even if it will work, do I want to flash a ROM built for the ville to my villeplus. The more I read about custom ROMs the more it appears that they are extremely specific to models.
I am still extremely curious to try it... rumor has it that curiosity didn't work out so well for the cat though. :-/
merovingian_a51 said:
I was able to modify the updater-script file tonight using file X-Plore and text edit, so now the script is looking for "villeplus" rather than ville. My phone is S-OFF which I read means that it does not do signature checks... however, I'm not sure if that also means it bypasses MD5 checksums - I suspect not since I'm pretty sure I saw it verifying MD5 previously. So, since I tampered with the ZIP it still may not work.
My real question now that remains is even if it will work, do I want to flash a ROM built for the ville to my villeplus. The more I read about custom ROMs the more it appears that they are extremely specific to models.
I am still extremely curious to try it... rumor has it that curiosity didn't work out so well for the cat though. :-/
Click to expand...
Click to collapse
Unfortunately, i have to fully disappoint you.
The villeplus is having the exact same hardware as the ville. Theoretically ideal. Unfortunately, HTC decided to make it a "/data/media" device unlike its brother, the ville.
Explained: the Ville has a partition for the SDCard and its mounted with its own mountpoint, /sdcard.
The Villeplus has a partition for the SDCard too, but its mounted inside the /Data partition as /data/media. This means a lot of problems from every imaginable aspect.
I spend a week together with Torxx from ViperOneS to get Viper to run on it and we found out that a.) the Kernel needs to be adjusted and b.) some libs and etc. which is real dev work and which no dev in the OneS section has time for.
Later i spent another two weeks with Philz and mdmower trying to at least get recovery to mount the sh.it thing as USB, which turned out to be impossible at this time as it is only possible through the MTP protocoll, which no recovery supports as of yet.
Since i am a n00b myself i did not entirely understand the nature of the problem, but it seems to be very complex.
At some point i suggested to actually rewrite the partitions on the phones so they would work the same way as on the ville. I even tried myself and flashed a Ville RUU to my Villeplus (it works, doesnt break anything) but with the same effect as custom roms: my SD was then in Data/media and the internal apps memory and RAM were shifted to somewhere else with not enough space so the phone kept running out of space and crashed often. Also all system components trying to access stuff on the SD failed to find their stuff and crashed.
Since we don't actually have means to change the chip controller programming so it offers the partitions differently to the ROM we cannot go that way either (Zarboz tried to explain it to me but i failed understanding it, somehow the device pathes are put into the actual chip and not part of any RUU, so to change them one would need to have some special software tool like we could have done on the HD2 back then).
The only viable way would be to adjust ROM modules and Kernel to this structure, which won't happen as no dev has this device and there are like maybe 5 active users here.
You are out of luck my friend. Sorry. I too was full of hope and gave it up when all devs i contacted signalled that there is no benefit for them and they wouldn't waste their time basically.
Sneakyghost said:
Unfortunately, i have to fully disappoint you.
The villeplus is having the exact same hardware as the ville. Theoretically ideal. Unfortunately, HTC decided to make it a "/data/media" device unlike its brother, the ville.
Explained: the Ville has a partition for the SDCard and its mounted with its own mountpoint, /sdcard.
The Villeplus has a partition for the SDCard too, but its mounted inside the /Data partition as /data/media. This means a lot of problems from every imaginable aspect.
I spend a week together with Torxx from ViperOneS to get Viper to run on it and we found out that a.) the Kernel needs to be adjusted and b.) some libs and etc. which is real dev work and which no dev in the OneS section has time for.
Later i spent another two weeks with Philz and mdmower trying to at least get recovery to mount the sh.it thing as USB, which turned out to be impossible at this time as it is only possible through the MTP protocoll, which no recovery supports as of yet.
Since i am a n00b myself i did not entirely understand the nature of the problem, but it seems to be very complex.
At some point i suggested to actually rewrite the partitions on the phones so they would work the same way as on the ville. I even tried myself and flashed a Ville RUU to my Villeplus (it works, doesnt break anything) but with the same effect as custom roms: my SD was then in Data/media and the internal apps memory and RAM were shifted to somewhere else with not enough space so the phone kept running out of space and crashed often. Also all system components trying to access stuff on the SD failed to find their stuff and crashed.
Since we don't actually have means to change the chip controller programming so it offers the partitions differently to the ROM we cannot go that way either (Zarboz tried to explain it to me but i failed understanding it, somehow the device pathes are put into the actual chip and not part of any RUU, so to change them one would need to have some special software tool like we could have done on the HD2 back then).
The only viable way would be to adjust ROM modules and Kernel to this structure, which won't happen as no dev has this device and there are like maybe 5 active users here.
You are out of luck my friend. Sorry. I too was full of hope and gave it up when all devs i contacted signalled that there is no benefit for them and they wouldn't waste their time basically.
Click to expand...
Click to collapse
Wow, Sneakyghost, I can't thank you enough for your prompt (I just PM'd him last night folks) and very thorough response.
I'm wondering why HTC did this - thinking maybe to prevent/protect users from tampering with the device - perhaps other ROMs wouldn't run on it in a stable fashion.. or they just don't want people messing with custom ROMs. Perhaps this was a new architecture for them (wondering if the One and One X followed this same design?).
In any case, looks like I'll be sticking to looking at launchers and custom widgets. I'm actually quite happy with 4.1.1 and Sense (maybe because I'm new to Android, not sure), I mainly wanted to try experiment with custom ROMs, and learn about how all this stuff works. At least till the M4 comes out anyways..
Thanks again so much for your response, it is much appreciated and well explained.
Sneakyghost said:
... Unfortunately, HTC decided to make it a "/data/media" device unlike its brother, the ville.
Click to expand...
Click to collapse
Oh the irony, the (unreleased) 4.2 update for ville actually reformats partitions for data media. I don't think the update will ever be officially available to US users, but it is funny nonetheless.
This, my friend, is indeed ironic, if not even sad.
Considering what it means, I come to understand that porting ROM's from Ville to Villeplus would have gotten much easier then. Only that it is too late.
Torxx and I gave up due to the amount of work attached to the previous system structures, but if the Ville turns into a datamedia device with that update, many ROM devs and chefs would have to deal with it plus HTC would have done the most difficult part already anyway...
What a shame that this comes so late now and doesn't even get released probably...
mobile post