Database Users

Quick Idea about permanent root

I'm no expert when it comes to the topics of rooting and getting access to the emmc and all of that good stuff. I more specialize in ROMs and themes and stuff, the less complexed stuff lol
Someone has posted an idea in the general forums in relation to permanent root, I'm not sure if he posted it here or not. So here's what he wrote....and is it possible? Or does it have to be done manually first before this idea can happen?
Originally Posted by deliberate187
In order to unlock the phone, we have to figure out what the protected sectors are first and all related flags. If an Android app could be made to have direct read access to the eMMC filesystems (including write protect flags) and save a log to the SD card detailing these items, this would be ideal.
Then all that would remain is a program to undo the write protection (and re-do it if necessary to unvoid warranty)
If anyone is willing to create these programs, I would be more than happy to test them out on my own G2.
However, I think the keys to the mystery may lie in the recovery image, and/or in the bootloader itself. Has anyone disassembled these yet?
Click to expand...
Click to collapse

Sorry to have to tell you but this is all old information stuff we already know just are unable to do anything about it. Its harder then just coming up with an idea of something. Now if we knew a person that programed the g2 in htc factory then all would be good but as of now we just dont have the information we need to do anything

thanks
Thanks for the idea. Some people will be mad you didn't post in the root thread though.

File under "I'm no expert but..."

Here is one observation I have noted in my exploration. The root filesystem and system partition are mounted with the flags "-o ro,relatime" but in addition the /system partition has ",errors=continue" leading me to believe that this change is in fact written to the release configuration rather than to the eMMC itself. Can anyone try to get a permanent write to the fstab and see if this can net us permanent root? Possibly take a temp root session and remount the system and / filesystems read/write to see if writes stick... just an idea.
The errors=continue flag allows the ext3 filesystem to continue working even if there was a read/write error.

I've been able to get the system to change to r/w a couple times while wandering through root explorer. I have made subtle changes to certain folders such as moving txt files but nothing has ever been permanent. I can't really tell you how I did it either seeing as I can't replicate it on demand...I'm assuming it still gets written to cache despite being in the /system
Sent from my T-Mobile G2 using XDA App

heyy, I'm not punchie, I've got what the doctor calls a relaxed brain

I am thinking there should be a set of adb commands to unlock the nand. I am definitely thinking a nand dump and full disassembly of the bootloader and recovery image could be absolutely crucial in discovering what needs to be done. Just a thought, has anyone done a nandroid backup of the G2 yet? I'm pretty sure TMob doesn't have HTC encrypt its bootloaders...

deliberate187 said:
I am thinking there should be a set of adb commands to unlock the nand. I am definitely thinking a nand dump and full disassembly of the bootloader and recovery image could be absolutely crucial in discovering what needs to be done. Just a thought, has anyone done a nandroid backup of the G2 yet? I'm pretty sure TMob doesn't have HTC encrypt its bootloaders...
Click to expand...
Click to collapse
if you can figure it out, go for it and i wish you luck

deliberate187 said:
Here is one observation I have noted in my exploration. The root filesystem and system partition are mounted with the flags "-o ro,relatime" but in addition the /system partition has ",errors=continue" leading me to believe that this change is in fact written to the release configuration rather than to the eMMC itself. Can anyone try to get a permanent write to the fstab and see if this can net us permanent root? Possibly take a temp root session and remount the system and / filesystems read/write to see if writes stick... just an idea.
The errors=continue flag allows the ext3 filesystem to continue working even if there was a read/write error.
Click to expand...
Click to collapse
If it were only this easy.
Re-mounting /system as r/w is part of the rooting process. This does not result in changes written to eMMC. In fact, the controller "lies" to Linux that the change has been synced. From then on, Linux holds the changes in its cache which, when dropped or rebooted, reverts changed files to their original state (because they were never written in the first place.)
The ext3 continue on errors thing is merely a way to skip fsck in the event that the read-only system has issues in the journal (very unlikely to happen, since nothing can write to it.) Presumably, this only covers an oversight in OTA updates (where the journal of the image provided by the OEM is dirty for some odd reason.) Again, since nothing can write to /system, it's all but an impossible scenario (nothing can write to the journal either...)
As for marking "sectors" as write-protected or not, that's also easier said than done. Entire partitions are locked, and half of the space is mysteriously "missing." It's difficult to see what's really going on from userland, as the device is deceptive as to what is and is not being written, or what is even stored on the eMMC in the first place.
The real solution is to exploit either the boot-loader or eMMC (re)/initialization somehow to allow a) unsigned firmware to be loaded and/or b) allow booting without write protection, allowing us to c) flash rooted rom to the phone and/or d) disable said protection. The unlock procedure will likely be similar to Unrevoked, as that is essentially the same situation (aside from the controller issue.)
All of this is covered in the wiki and various threads - check those out, if you find a way around it everyone would be glad to hear it.

HamNCheese said:
If it were only this easy.
Re-mounting /system as r/w is part of the rooting process. This does not result in changes written to eMMC. In fact, the controller "lies" to Linux that the change has been synced. From then on, Linux holds the changes in its cache which, when dropped or rebooted, reverts changed files to their original state (because they were never written in the first place.)
The ext3 continue on errors thing is merely a way to skip fsck in the event that the read-only system has issues in the journal (very unlikely to happen, since nothing can write to it.) Presumably, this only covers an oversight in OTA updates (where the journal of the image provided by the OEM is dirty for some odd reason.) Again, since nothing can write to /system, it's all but an impossible scenario (nothing can write to the journal either...)
As for marking "sectors" as write-protected or not, that's also easier said than done. Entire partitions are locked, and half of the space is mysteriously "missing." It's difficult to see what's really going on from userland, as the device is deceptive as to what is and is not being written, or what is even stored on the eMMC in the first place.
The real solution is to exploit either the boot-loader or eMMC (re)/initialization somehow to allow a) unsigned firmware to be loaded and/or b) allow booting without write protection, allowing us to c) flash rooted rom to the phone and/or d) disable said protection. The unlock procedure will likely be similar to Unrevoked, as that is essentially the same situation (aside from the controller issue.)
All of this is covered in the wiki and various threads - check those out, if you find a way around it everyone would be glad to hear it.
Click to expand...
Click to collapse
Listen to this dude. Absolutely correct.

Archos gen8 bootloader crack (disable signature check)

" PWNED " :-D
As you know, Archos bootloaders check digital signatures of init and recovery kernels, so you need to install SDE to use custom kernels, and it somehow "watermarks" the device.
Good news everyone! I've disassembled both bootloaders, found the code which checks signature, and replaced it (first instructions of verify_hash function) with "return 0" which is "mov r0, #0; bx lr" in ARM assembly. It's much the same hack as on Archos 5, thanks EiNSTeiN from archos.g3nius.org for reverse engineering previous generation.
Archos gen8 boots using OMAP boot ROM from internal eMMC card. Primary bootloader ("boot0") is in 0x20000 bytes after the first sector of internal flash (i.e. at 0x200) and secondary bootloader is written into rawfs, /mnt/rawfs/avboot. boot0 contains image size and loading address in first 8 bytes.
So, here is the patch:
1) boot0: replace 8 bytes at 0x7520 from the beginning of mmcblk0 from 7F402DE9003091E5 to 0000A0E31EFF2FE1.
2) avboot: replace 8 bytes at 0x14424 in avboot from 7F402DE9003091E5 to 0000A0E31EFF2FE1 (same patch). 0x14424 from avboot beginning is usually 0x14824 from the beginning of mmcblk0p1 (avboot comes first in rawfs, just after 2 blocks of header).
Of course you need root to do it. I've done it on my Archos 101, then changed 1 byte in recovery image - it boots into recovery without problem (before the hack it didn't boot into this 1-byte changed recovery).
And of course do it with caution and at your own risk DO NOT replace the bytes if you find other original data at these offsets! Bad boot0 or avboot means bricked Archos. There must be some sort of test point (something connected to OMAP SYS_BOOT5 pin) to boot from USB, or a boot UART interface, so debricking the device must be possible, but it would require some effort to find it, find a proper bootloader and use it.
If someone wants to see IDA database, I'll send my.
P.S: I do not have enough messages to post inside Development subforum, so I'm posting here.

Great work! With this base, can yout get something like CW to run?

I'm so waiting for him to come back and say April fools.

I'm gonna screw him up if this was an april fool

First, if this is an April fools, I will find you and hurt you.
Second, what does all that mean anyway? Does that mean Cyanogen on Gen8 is near? Does it have anything to do with roms?

vitalif said:
P.S: I do not have enough messages to post inside Development subforum, so I'm posting here.
Click to expand...
Click to collapse
Maybe you should increase that number of post by explaining how you did this.

)))) No it isn't an April fool, my device now really has a modified recovery. Ridiculously modified (1 byte changed), but that's the proof!
Check the patch by yourself )) all you need to write to mmcblk0 is a standard linux dd tool... which is included into standard Archos busybox...
wdl1908 said:
Maybe you should increase that number of post by explaining how you did this.
Click to expand...
Click to collapse
In fact, it was not hard, and if I knew ARM assembly language before, it would be even easier... All I had to do is to find bootloader on the flash (boot0 is obviously in its beginning, and avboot is on /mnt/rawfs), copy it to computer, download IDA, feed bootloader to it and find functions similar to ones described on archos.g3nius.org (BigInteger_ModulusEnter, RSADecipher, etc). It also could be simpler, as BigInteger_ModulusEnter is mentioned inside an ASCII string inside data section... But I've found them by text search also there is a magic "ZMfX" in first 4 bytes of avboot and some other magic inside init and recovery... One also could use them to find interesting points in bootloader.
At first I've started disassembling with the wrong base address, but bootloader has code which copies itself to the correct one in the very beginning, so I've changed it and started over. In fact, it has size and address in first 8 bytes, so this also could be simpler...
So the hack is done, what needs to be done by now - utilize it and create some custom ROM or simply flash urukdroid without SDE...
chulri said:
Great work! With this base, can you get something like CW to run?
Click to expand...
Click to collapse
CW == ClockWorkMod recovery? I don't have any experience with CWM porting yet, but in theory yes, the hack gives us the ability to run custom recovery images.

Don't know alot about the bootloader, but what advantage does this have?

SWFlyerUK said:
Don't know alot about the bootloader, but what advantage does this have?
Click to expand...
Click to collapse
Hm. I'll explain... Bootloader is the program which starts up the device, similar to bootloader on your PC signature check in bootloader prevents us installing modified Linux kernel, initial ramdisk and recovery images. So, for example, we can't have netfilter in kernel without installing SDE, we can't have ClockWorkMod recovery on Archos at all, and we can't, for example, change MMC card splitting into 512M mmcblk0 for system + remaining for "internal SD" with data.
With signature check removed, all this is possible.
The underlying idea of all this signature checking is probably protecting f**king DRM... I HATE IT !!!!!! And hate companies promoting it =) When you install SDE on previous generation archos (5it), it removes drm keys from device memory (this is the "watermarking" mentioned on Archos site). It makes device unable to play the content buyed for it anymore... Not a big deal, but unpleasant. I don't know if this is the same on gen8.
In detail: Archos 101 has OMAP3630 processor. The "0-stage" (very-very first stage) bootloader, i.e. program which gains control after processor power-up, is hard-coded into one-time programmable area on the processor itself and is named "OMAP boot ROM" (similar to PC BIOS). The boot ROM can continue device booting process from different devices including SD/MMC card, NAND flash, UART (serial port) or USB interfaces. The boot sequence is determined from physical pin connection configuration. Our Archos boots from internal eMMC card.
So, OMAP boot ROM loads primary Archos bootloader, without checking any signatures or checksums, and simply transmits control to it. Primary bootloader sets up some processor configuration and then reads secondary bootloader (avboot) from flash. Then, it checks its MD5-RSA digital signature using Archos public key. If signature is incorrect, it hangs the device (goes to infinite loop). So if we modify avboot without removing signature check from boot0, device would be bricked. If signature is correct, control is transmitted to avboot. Avboot determines what system we want to start by pressing different keys, loads it, checks signature if system is init (normal system) or recovery, sets up configuration for Linux kernel and transmit control to Linux.
Interesting facts:
* According to the code, boot0 can use rawfs or FAT filesystems for boot partition.
* During boot process, various messages are printed to serial console. avboot even has some code for receiving commands over serial connections.
* OMAP processor boot sequence can be configured via special memory area which remains unchanged after soft reset, and this configuration will override one determined by physical pin configuration. This does not give us much profit, but is also interesting...

Thanks for the explanation, so is it worth doing for a noticable difference in performance etc?

SWFlyerUK said:
Thanks for the explanation, so is it worth doing for a noticable difference in performance etc?
Click to expand...
Click to collapse
Whats being done will have no affect on performance of the device. It will however, allow a lot of work that can contribute to better performance on the device. That is assuming that we can put on a modified clockworkmod recovery on these devices without bricking them.

He says the only way to do this is with root but in order to have root with r/w access at this point is SDE....right? Don't get me wrong custom recovery with the ability to make backups would be awesome but it seems SDE will still be necessary unless a new rooting option comes along.
*on a side note about root has anyone tried using psneuter to gain temp root through ADB? I really am not super knowledgeable about this stuff but this was used on the thunderbolt to aid in getting full root and s-off.
Sent from my ADR6400L using XDA App

JBO1018 said:
He says the only way to do this is with root but in order to have root with r/w access at this point is SDE....right? Don't get me wrong custom recovery with the ability to make backups would be awesome but it seems SDE will still be necessary unless a new rooting option comes along.
*on a side note about root has anyone tried using psneuter to gain temp root through ADB? I really am not super knowledgeable about this stuff but this was used on the thunderbolt to aid in getting full root and s-off.
Sent from my ADR6400L using XDA App
Click to expand...
Click to collapse
Archangel will give you temp root without using SDE.

He said root with r/w access. Archangel won't do that, the file system is still protected.

pbarrett said:
He said root with r/w access. Archangel won't do that, the file system is still protected.
Click to expand...
Click to collapse
Nope r/w access is not needed the only changes to be made are on /dev/mmcblk0p1 which is mounted on /mnt/rawfs the read-only is on the root file system so they are seperate. Archangel will do just fine for this.

wdl1908 said:
Nope r/w access is not needed the only changes to be made are on /dev/mmcblk0p1 which is mounted on /mnt/rawfs the read-only is on the root file system so they are seperate. Archangel will do just fine for this.
Click to expand...
Click to collapse
To be correct, there is no write protection on internal MMC at all, there is readonly rootfs which is mounted from a squashfs archive (squashfs is compressed readonly filesystem commonly used on Linux Live CDs), so you can't modify _files_ on it while it is mounted. But, nothing stops you from updating it as a whole.

Urukdroid
Someone should give a shout out ro $auron, creator of the Urukdroid project about this, he might find it useful.

So, if your hack is confirmed, that would give us the possibility to port CW recovery and Cyanogen to Gen8 devices... am I right ?

shrewdlove said:
Someone should give a shout out ro $auron, creator of the Urukdroid project about this, he might find it useful.
Click to expand...
Click to collapse
I think he has already seen this thread but you can ask him
lechuckthepirate said:
So, if your hack is confirmed, that would give us the possibility to port CW recovery and Cyanogen to Gen8 devices... am I right ?
Click to expand...
Click to collapse
Yes you are^^ but the thing is you have to port cyanogen to our gen8^^ and this must be done by a or more devs
i heard the biggest problem is that our touchscreen is connected by an usb controller inside the archos thats why the honeycomb port by luisivan is not recognize our touchscreen ( but when the source code is released, finally, we will get a hc port )

Lennb said:
i heard the biggest problem is that our touchscreen is connected by an usb controller inside the archos thats why the honeycomb port by luisivan is not recognize our touchscreen ( but when the source code is released, finally, we will get a hc port )
Click to expand...
Click to collapse
this isn't a problem for cyanogen (v7 = Android 2.3.3) because we have the source.

[IDEA] Implement Firerat's Custom MTD Partition for HD2

Hi. Maybe few words about me first. I'm not a developer, I don't know how to do it and I have to ask more experienced users. Ok that's it, to the point now. Ah, and I didn't know if this thread was proper to be posted in Development sub-forum, so it's here. If it was possible, if the thread meets requirements to be there, maybe it's possible to move it there? I'm not sure how many devs visit those section, so obviously there is greater chance for finding an answer there, but again, I wasn't sure if it was right.
While I was a G1 user one genius known as "Firerat" created very nasty script - it allowed users to manually, by simply creating a .txt file on sdcard with proper values and running a .zip from recovery, resize partitions like /system, /data and /cache on the phone. I don't know if you're familiar with G1 stuff, but previous there was only one way to chage partitions and it was achieved by custom SPL called Haykuro SPL. This modification (MTD part hack) was created because of need for even more space on /data and allowed to shrink /system and /cache to smallest value possible, so /data took up as much space as it was possible. Here is source thread in G1 Development section:
http://forum.xda-developers.com/showthread.php?t=717874
There you can dive in details, because my knowledge and understanding in this things end very quickly .
On HD2, we have come a great way. From pure Windows Mobile, it was possible to run Linux kernel from sdcard by HaRET.exe, then run Android. After few month team of gods gave us MAGLDR, a tool that allows us to replace Windows Mobile from NAND with Android system. Then after few more weeks someone made Clockworkmod Recovery possible, giving us posibilty to create partitions on sdcard, do a nandroid backup/restore. But one MAJOR thing wasn't done as it should. Recovery in theory should give us possibility to flash ROMs from sdcard without need of computer. And theoretically it's possible, but... Yes, you have to have proper partition configuration flashed by DAF.exe with PC before. Imagine what a great obstacle it is for diagnosed with ORD!
Now you realise what I'm talking about? Combine these two things and bam! I'm just asking, just giving you an idea. Maybe it is possible to adapt those scripts to HD2 and replace old habits (flashing recovery by DAF.exe on PC) with simple script and one .txt file!
Again, maybe it's not possible since we are still using old SPL from WM times. Maybe MAGLDR is build in such way that those scripts are not possible. Maybe there is a thousand reasons... but I've never seen such an idea.
So please, is there one person who are good in this stuff and can explain me wether it's possible or not?
So maybe I can rest assured that I have to cure my ORD
OR
we can move on to work on making this idea reality .

cure for ORD....
I DON'T THINK SO.
Flashed from my fingers to your face

On a serious note, though, have you looked at clk? It is supposed to be useable without a pc. Therefore you can configure the partition on your phone. Is my understanding of that correct?
Maybe T-Macgnolia can explain this better than I .
I'm still trying to get my head round it, before I commit to changing over to clk...
Flashed from my fingers to your face

raven_raven said:
Hi. Maybe few words about me first. I'm not a developer, I don't know how to do it and I have to ask more experienced users. Ok that's it, to the point now. Ah, and I didn't know if this thread was proper to be posted in Development sub-forum, so it's here. If it was possible, if the thread meets requirements to be there, maybe it's possible to move it there? I'm not sure how many devs visit those section, so obviously there is greater chance for finding an answer there, but again, I wasn't sure if it was right.
While I was a G1 user one genius known as "Firerat" created very nasty script - it allowed users to manually, by simply creating a .txt file on sdcard with proper values and running a .zip from recovery, resize partitions like /system, /data and /cache on the phone. I don't know if you're familiar with G1 stuff, but previous there was only one way to chage partitions and it was achieved by custom SPL called Haykuro SPL. This modification (MTD part hack) was created because of need for even more space on /data and allowed to shrink /system and /cache to smallest value possible, so /data took up as much space as it was possible. Here is source thread in G1 Development section:
http://forum.xda-developers.com/showthread.php?t=717874
There you can dive in details, because my knowledge and understanding in this things end very quickly .
On HD2, we have come a great way. From pure Windows Mobile, it was possible to run Linux kernel from sdcard by HaRET.exe, then run Android. After few month team of gods gave us MAGLDR, a tool that allows us to replace Windows Mobile from NAND with Android system. Then after few more weeks someone made Clockworkmod Recovery possible, giving us posibilty to create partitions on sdcard, do a nandroid backup/restore. But one MAJOR thing wasn't done as it should. Recovery in theory should give us possibility to flash ROMs from sdcard without need of computer. And theoretically it's possible, but... Yes, you have to have proper partition configuration flashed by DAF.exe with PC before. Imagine what a great obstacle it is for diagnosed with ORD!
Now you realise what I'm talking about? Combine these two things and bam! I'm just asking, just giving you an idea. Maybe it is possible to adapt those scripts to HD2 and replace old habits (flashing recovery by DAF.exe on PC) with simple script and one .txt file!
Again, maybe it's not possible since we are still using old SPL from WM times. Maybe MAGLDR is build in such way that those scripts are not possible. Maybe there is a thousand reasons... but I've never seen such an idea.
So please, is there one person who are good in this stuff and can explain me wether it's possible or not?
So maybe I can rest assured that I have to cure my ORD
OR
we can move on to work on making this idea reality .
Click to expand...
Click to collapse
Hello raven_raven,
This is indeed a good idea and can make our HD2 PC independable. I will support you as much I can.
Though I have some questions for you.
Q1: Is it possible for this script to brick our device?
Q2: Can we choose the partitions which we resize (for example I would like to resize only /system, /userdata and /cache and leave the others as is) and if yes the other partitions /boot, /recovery will be formated or data will be kept as is?
Q3: What the bootloader has to do with it?
Q4: What SPL has to do with it?
For your knowledge in HD2 their are 2 bootloaders, MAGLDR and cLK (cedesmith's Little Kernel) which makes HD2 a native android device.
In MAGLDR partitions are made along with the flashing of CWM with the help of DAF.exe
In cLK partitions are directly managed by the bootloader when flashed.

malybru said:
On a serious note, though, have you looked at clk? It is supposed to be useable without a pc. Therefore you can configure the partition on your phone. Is my understanding of that correct?
Maybe T-Macgnolia can explain this better than I .
I'm still trying to get my head round it, before I commit to changing over to clk...
Flashed from my fingers to your face
Click to expand...
Click to collapse
Tried cLK, but it can't change partitions as you would like it to, you can't change it on the go without PC.
zach.antre said:
Hello raven_raven,
This is indeed a good idea and can make our HD2 PC independable. I will support you as much I can.
Though I have some questions for you.
Q1: Is it possible for this script to brick our device?
Q2: Can we choose the partitions which we resize (for example I would like to resize only /system, /userdata and /cache and leave the others as is) and if yes the other partitions /boot, /recovery will be formated or data will be kept as is?
Q3: What the bootloader has to do with it?
Q4: What SPL has to do with it?
For your knowledge in HD2 their are 2 bootloaders, MAGLDR and cLK (cedesmith's Little Kernel) which makes HD2 a native android device.
In MAGLDR partitions are made along with the flashing of CWM with the help of DAF.exe
In cLK partitions are directly managed by the bootloader when flashed.
Click to expand...
Click to collapse
A1: No, it is not possible. Firerat is genius and he does masterpiece of scripting, those scripts are 100% safe. It will of course break you ROM, but simple nandroid backup/flashing a new ROM will fix it.
A2: We resize /system, /data and /cache. You simply put two values in text files, i.e.:
Code:
mtd 130 2
First number is how many mb you want to spend on /system, second on /cache. Rest of internal memory is used by /data. /boot and /recovery are not touched by this script.
A3: I don't know for sure, just connected it to Haykuro SPL, which also changed partitions back then.
A4: Don't know for sure, I'm simply intermediate in this stuff, just wanted to pass an idea, I don't have required knowledge and experience to make this idea come true.
I know that there are 2 bootloaders, but I don't know how they work and how far you can modify partitions from recovery by using each of them. HD2 obviously isn't a native Android phone and regarding that either this idea may be impossible to implement or has to be completely redesigned. I really don't know .
Just wanted to pass an idea, but I'm terribly dissapointed how little response I received...

Well you would have more people responsed if you were posting in development forum under the label [call for development].
cLK is modified "little kernel" for HD2...
since there is no danger of bricking our device I am going to test it and report.
Sent from my Nexus One using XDA App

zach.antre said:
Well you would have more people responsed if you were posting in development forum under the label [call for development].
cLK is modified "little kernel" for HD2...
since there is no danger of bricking our device I am going to test it and report.
Sent from my Nexus One using XDA App
Click to expand...
Click to collapse
Great thing to see that someone tries. Be warned though, I'm not responsible for any data loss and damages or whatever, as always . Please be sure that you read original thread and understood how this script is working.
Maybe I'll ask a mod to move this thread to Development section...

raven_raven said:
Great thing to see that someone tries. Be warned though, I'm not responsible for any data loss and damages or whatever, as always . Please be sure that you read original thread and understood how this script is working.
Maybe I'll ask a mod to move this thread to Development section...
Click to expand...
Click to collapse
Yeah i did, don't worry about it.
I have read the original thread, i have compared the different devices mount points (as much i could) and conclude that is the same.
What i have also noticed is that kernel must be patch in order for this script to work and the script checks for a specific bootloader? I'm not sure, i need to restudy that thread.
Anyway, I tried using the script but didn't happen anything.
I formated all partitions except /boot and /recovery
I first created the mtdpartmap.txt in SD root and flashed via CWM the script FR-recovery-v1.5.8-CustomMTD_S.zip
Then reboot and again to recovery
Flashed ROM and then flashed FR-boot-v1.5.8-CustomMTD_S.zip
Reboot to ROM worked fine.
I run terminal
#df
Sizes where the same as before

Exactly, first you apply new partition map to recovery, next you install ROM in those new partitions either by flashing or nandroid backup-ing, then patch kernel to work with this new layout.
Huh, it would be too easy to simply run it and bam! it works. Even Firerat made different scripts for different devices. I'm curious what's the problem. Is recovery on a different level than those in native Android devices, which means that it can't change partition size? Or is it just problem of adjusting script to HD2 like it was done for Hero or Evo? I wonder if Firerat would like to investigate, but it would be impossible to achieve it without HD2, and from what I know he does not have one.
What person should I ask to move my thread to another section?

raven_raven said:
Exactly, first you apply new partition map to recovery, next you install ROM in those new partitions either by flashing or nandroid backup-ing, then patch kernel to work with this new layout.
Huh, it would be too easy to simply run it and bam! it works. Even Firerat made different scripts for different devices. I'm curious what's the problem. Is recovery on a different level than those in native Android devices, which means that it can't change partition size? Or is it just problem of adjusting script to HD2 like it was done for Hero or Evo? I wonder if Firerat would like to investigate, but it would be impossible to achieve it without HD2, and from what I know he does not have one.
What person should I ask to move my thread to another section?
Click to expand...
Click to collapse
Well, I guess Firerat need to come by and post a thread in HD2 Dev forum since it is his work.
He could ask what info he needs for the HD2 such as partition layout and filesystem in each partition etc... I am sure many people are willing to help with that.
I also think that SPL is locking the partition tables (not sure) and the way we are flashing just overcome that. Else when i used the script should have f**cked up my partitioning.
You can ask an HD2 moderator to move this thread but first ask for Firerat permission.

Dual Boot,Splitting Partitions

Can you dual boot or any other way to have 2 different roms installed at the same time,so i can switch back and forth?Like windows either at boot or logging in and out of 2 different desktops.
Maybe find a way to split the partitions.Any suggestions would be great.

Duel= 2 roms fighting. Make it dual. Thought it was funny, no malice intended.

lol - duel - dual...
It would be interesting if that was possible. There would have to be another program in there to act as the buffer between both OS's though - that would take control of the start-up, hold on a page that has both options and then would boot the option you want.
Not sure if that's possible since some files are right on the root and in order to have an OS work it can't have files in the same directory - they would just overwrite each other.
But, I too, have wondered if it would ever happen. Be a great way to test new ROM's if you didn't always have to overwrite the existing ROM but rather, you could place a new ROM in a special directory and then run it from that - or partition the internal memory with the new partition available to boot from and store.

partition the internal memory with the new partition available to boot from and store.
Click to expand...
Click to collapse
Thats exactly what i was thinking,partition the system os,i rebuild computers and a little system modding in windows,but this is a linux based os,so it would be a little odd for me.I'm gonna look into this a little more.

You may try to contact the guys who developed boot manager. www.init2winitapps.com they have a listing of supported devices and a request form. Works on the thunderbolt 5 slots for 5 roms, I'm unsure how difficult it would be to add support for the iconia.
Sent from my A500 using XDA Premium App

ibsk8 said:
You may try to contact the guys who developed boot manager. www.init2winitapps.com they have a listing of supported devices and a request form. Works on the thunderbolt 5 slots for 5 roms, I'm unsure how difficult it would be to add support for the iconia.
Sent from my A500 using XDA Premium App
Click to expand...
Click to collapse
Thanks,i submitted the idea,lets see if they will run with it,hopefully they will find interest.

Hello Diabblo,
Any update on that?
I think the idea of dual boot (or 5al boot) is just fantastic!
I have beside my iconia a501 a poor old zt180s and it can triple boot on android, ubuntu and WinCE!
Best,
Inji.

inji75 said:
Hello Diabblo,
Any update on that?
I think the idea of dual boot (or 5al boot) is just fantastic!
I have beside my iconia a501 a poor old zt180s and it can triple boot on android, ubuntu and WinCE!
Best,
Inji.
Click to expand...
Click to collapse
Im guessing that device has a open non encrypted boot loader. The Iconia was encrypted at birth with the 3.2 push they tightened security even more from whqt I have read.So this is likely never happening unless acer changes ttjere boot loader policy.not likely to happen.
hope this helps you understand more of this issue.

I'm dual-booting my A500 right now with ICS and Ubuntu. The method for dual-booting is a replacement recovery.img which contains a Linux kernel and acts as a bootloader for Linux. Ubuntu itself runs from a rootfs.img on the internal storage (there's also recovery.img's available to run from external SD too). If I want to run Android, I just boot my tab normally. When I wanna run Ubuntu, I hold vol+ as I'm turning it on to force the modded recovery to load. It's a pretty cool setup more info in this thread: http://forum.xda-developers.com/showthread.php?t=1158260

Dear Erica Renee and Bloodflame,
Thanks a lot for your answers. Ok, I got it with the encrypted bootloader.
Will try the method described by Bloodflame.
Actually, since I got these tablets my main use of them is flashing new ROMs... I don't really have the use of new ROMs but I think it's so exciting!
Cheers,
Inji.

I don't believe the encryption is the problem.
The current boot loader is available unencrypted in update packages if anyone want to have a look at it.
Replacing the boot loader on the device is done as part of a down grade procedure described elsewhere on this forum.
So unless I'm missing something, the problem is more likely time and interest. Someone need to care enough about it and have the time to make some other boot loader work. Or patch Acer's. Either way it is likely to require quite a bit of time and patience.

So let me see if I have this correct. Acer's hardware bios code is 'locked down' enough to keep the average code manipulator out? A custom boot loader needs to be dev'd that can communicate correctly to be able to handle Android recovery and a linux/android boot screen etc. ? Could someone elaborate more blatantly if I am incorrect...

s4 partitions ??

hy,
could someone please explain to me how many partitions the s4 has, why is it so hard to repartition the internal memory?
is all memory located on one chip and how is the partitioning handled, the partitioning information is surely not stored with the OS, so where is it?
where is the bootloader stored then and why is it so hard to unlock it, its just a piece of memory just like the OS right?, is it coded on a separate chip that cannot be rewritten? or hidden somewhere encrypted within some other process?
please guys some clarification here this cant be so hard!

re: partitions & bootloaders
adrovic.ad said:
hy,
could someone please explain to me how many partitions the s4 has, why is it so hard to repartition the internal memory?
is all memory located on one chip and how is the partitioning handled, the partitioning information is surely not stored with the OS, so where is it?
where is the bootloader stored then and why is it so hard to unlock it, its just a piece of memory just like the OS right?, is it coded on a separate chip that cannot be rewritten? or hidden somewhere encrypted within some other process?
please guys some clarification here this cant be so hard!
Click to expand...
Click to collapse
The partition table is stored in the PIT file (partition information table).
The reason it's so difficult to unlock bootloaders is that samsung and all the other cell phone
companies always try to make it as difficult as possible to do because the cell phone companies
frown upon people like the developers here who usually do succeed in unlocking the bootloaders.
It's getting more and more difficult for the developers to do with most cell phones now-a-days.
They don't like developers or end users messing around with the phones firmware or the bootloader.
Even the slightest modification of the PIT file will cause the phone to fail in
in such a way that only repair shops that has a JTAG burner can repair it. (expensive)
That's why NONE of the custom roms found here in XDA contain any PIT files.
If they did then during the flashing procedure it would over-write the stock one. (bad)
It's similar to the Windows MBR (master boot record) which if even slightly off
Windows will not boot.
In Windows a corrupt or missing MBR is a very easy thing to fix so its not a problem.
If the internal memory was repartitioned differently than stock default the phone would
become a shiny brick which would not even be flash-able with stock or any of the custom
roms or firmwares if the partition table is setup even slightly wrong.
Good luck, I would advise you to try to have more interest in becoming a developer of custom
roms here in xda rather than having so much interest in bootloaders and partition tables. LOL

Misterjunky said:
The partition table is stored in the PIT file (partition information table).
The reason it's so difficult to unlock bootloaders is that samsung and all the other cell phone
companies always try to make it as difficult as possible to do because the cell phone companies
frown upon people like the developers here who usually do succeed in unlocking the bootloaders.
It's getting more and more difficult for the developers to do with most cell phones now-a-days.
They don't like developers or end users messing around with the phones firmware or the bootloader.
Even the slightest modification of the PIT file will cause the phone to fail in
in such a way that only repair shops that has a JTAG burner can repair it. (expensive)
That's why NONE of the custom roms found here in XDA contain any PIT files.
If they did then during the flashing procedure it would over-write the stock one. (bad)
It's similar to the Windows MBR (master boot record) which if even slightly off
Windows will not boot.
In Windows a corrupt or missing MBR is a very easy thing to fix so its not a problem.
If the internal memory was repartitioned differently than stock default the phone would
become a shiny brick which would not even be flash-able with stock or any of the custom
roms or firmwares if the partition table is setup even slightly wrong.
Good luck, I would advise you to try to have more interest in becoming a developer of custom
roms here in xda rather than having so much interest in bootloaders and partition tables. LOL
Click to expand...
Click to collapse
thanks for the answer, but the question is how can this be so sensitive.
lets say for example one would take the pit file from the s4 google edition and put it on the samsung s4.
these 2 phones have identical hardware!
as you say the pit file is part of the FW and is just not being touched during the flashing process, but the pit file is being read out by some other peace of software, so basically that peace of software is the only thing that can verify the pit file, so if you also change that piece of software than everything should work just perfectly.

Misterjunky said:
It's similar to the Windows MBR (master boot record) which if even slightly off
Windows will not boot.
Click to expand...
Click to collapse
MBR and bootloader in the PC world, are two completely different things....

@adrovic.ad: Too many. List of Samsung S4 partitions
Partition information and the bootloader are both at a lower level than the OS, so neither would be stored with the OS. Both would be located in low level storage, which cannot be written without tools and software that cannot be discussed here. The bootloader transfers control of the hardware from the low level firmware to Android, and then sits quiet. As to why it's so difficult to unlock a bootloader, it isn't so long as you don't have a US S4 such as the SGH-I337. In that one, AT&T encrypts the bootloader to prevent modifications to the device. To break the encryption would require more time than the current age of the Universe.
Most Galaxy S4 devices don't have a locked bootloader.
It's harder than you think. It's probably much harder than I think, and I think it's hard.