Since the bootloader is bypasased, is it possible to change the partition layout of the internal storage?
Shaumux said:
Since the bootloader is bypasased, is it possible to change the partition layout of the internal storage?
Click to expand...
Click to collapse
may i ask why exactly?
btw... wrong section...
why is not a good question, for android,
a partial answer would be because its possible on other phones.
i thought this is related to android devlopment and the bootloader dev so this would be the right section
i'm sorry if its not.
anyway the question is still unanswered
Shaumux said:
why is not a good question, for android,
a partial answer would be because its possible on other phones.
i thought this is related to android devlopment and the bootloader dev so this would be the right section
i'm sorry if its not.
anyway the question is still unanswered
Click to expand...
Click to collapse
i am not sure if it will work... are u thinking about changing sizes of internal partitions or something like that?
can u guide me to the links where they have changed partition layout on other androids? will read up on the advantages/etc...
Here http://alpharev.nl/ and
here http://forum.cyanogenmod.com/topic/10726-how-to-increase-desire-internal-storage/
The biggest advantage i can think of would be to reallocate wasted space to where its really need, which will depend on the user i guess.
This brings up another interesting thing to my mind.
Changing the filesystem.
It is possible in android, can't say about X10 though.
maybe just for the fun of it or maybe another filesystem may give better performance.
What about support for ext2 filesystem ? That would help wont it ?
Sent from my X10 TripNMiUI
Shaumux said:
Here http://alpharev.nl/ and
here http://forum.cyanogenmod.com/topic/10726-how-to-increase-desire-internal-storage/
The biggest advantage i can think of would be to reallocate wasted space to where its really need, which will depend on the user i guess.
This brings up another interesting thing to my mind.
Changing the filesystem.
It is possible in android, can't say about X10 though.
maybe just for the fun of it or maybe another filesystem may give better performance.
Click to expand...
Click to collapse
Just became a little slow on fs ques. I hope it is possible.
Sent from my X10 TripNMiUI
@realunited123: well i can't say if ext2 will really help or not, its quite outdated now and i also don't think that it would be a good choice for fs on flash.
But btrfs or ext4 would be different.
btrfs specially has many features for flash memory.
But the main question is can these things be really done since the bootloader isn't cracked just bypassed, so would it still search the original partitions?
Lol i meant ext4. Damn swiftkey changes it automatically.
Sent from my X10 TripNMiUI
And also certain parts of nand can not be accessed/written without bricking the device. So there is a big chance it is not possible.
Sent from my X10 TripNMiUI
ext4
Shaumux said:
Since the bootloader is bypasased, is it possible to change the partition layout of the internal storage?
Click to expand...
Click to collapse
that would be big performance boost for our device.
with samsung galaxy s my mate using ext4, and file system performance went hight!
i am waiting for a sollution to change from ext2 (old very old) to ext4 !
anyway : i am using linux as desktop, and server , and PHONE! and only my pgone is locked to ext2....
actually currently we are on yaffs2 and not ext2
tiborprogmed said:
that would be big performance boost for our device.
with samsung galaxy s my mate using ext4, and file system performance went hight!
i am waiting for a sollution to change from ext2 (old very old) to ext4 !
anyway : i am using linux as desktop, and server , and PHONE! and only my pgone is locked to ext2....
Click to expand...
Click to collapse
We are not on ext2. The reason the SGS sees such an improvement is because the original filesystem sucks. The X10's is yaffs2, which is good to begin with, so we would only see minimal gains, if any. zdzihu has had those modules for a long time and doesn't waste our time with them for that reason.
ext4 is not a good idea. While performance under ext4 may be better, yaffs2 is optimized for wear leveling and error correction under flash memory. Those people running ext4 on their internal flash are wearing out their NAND storage at up to twice as fast, possibly faster. Their phone will die much quicker.
This is possible yes. But we would need to have a modified flashtool to support it, and we would need a modified recovery build and some other firmware files for the modified flashtool to use. This is because we cannot access the boot partition or the kernel via recovery, so we can't run a fancy script like the brilliant CustomMTD script/patcher (for example - mainly for HTC phones if I remember correctly).
While I'm nearly certain that's the rough idea of what has to be done, I could still be wrong because it's beyond my ability.
jonusc said:
ext4 is not a good idea. While performance under ext4 may be better, yaffs2 is optimized for wear leveling and error correction under flash memory. Those people running ext4 on their internal flash are wearing out their NAND storage at up to twice as fast, possibly faster. Their phone will die much quicker.
This is possible yes. But we would need to have a modified flashtool to support it, and we would need a modified recovery build and some other firmware files for the modified flashtool to use. This is because we cannot access the boot partition or the kernel via recovery, so we can't run a fancy script like the brilliant CustomMTD script/patcher (for example - mainly for HTC phones if I remember correctly).
While I'm nearly certain that's the rough idea of what has to be done, I could still be wrong because it's beyond my ability.
Click to expand...
Click to collapse
Yeah but we may still use UBIFS or whatever.
The main thing here is that the users gets a choice and i don't see any problem if its through flashtool atleast for now.
and i think the ability to resize the partitions would also be a very useful thing since the rom partiitons seems to be excessively sized than required especially with custom roms.
Related
Will this ever be possible?
Like probably not a actual app... but like dual boot?
where you can go into 2 different roms back and forth with no problems....
No sorry to burst your bubble
Dual booting a phone is really hard i mean dual booting a pc is already difficult but a phone will be more hard
Sent from my SGH-T959 using XDA App
i boot two systems ,i had to partitoin my internal memory on my own with partiton magic ,i can run ext4 system and rfs but everytime you want to run another rom u have to flash it to it so it takes 3 min out of Your daily schedule and if you go back another 3 .
but thats the filesystem, since you said ext4 and rfs i'm talking about actual ROMS since our phones have so much memory...
yes one partition EXT4 PARTITION! is one system (apss and whatever you have on it) , another partition is RFS PARTITON ! (with all apps u have put there) switchin back and forth the roms does not wipe setting u appiled to another rom so u switch back beatwen systems not losing your apps and stuff ( you can run different roms they dont have to match anyhow)
Crystal clear ?
You know fat32 fat ext4 jfs rfs are partitons right AND THERE IS ABOUT 8 MORE YOU CAN FORMAT YOUR MEMORY OR EXTERNAL SD
p.s if no1 is correcting me on this that means i am right?
If the data was indexed in a system exclusive method then it could be possible, but consider this how many 2009 Honda parts can you remove and put in a 1011 car........... not many, builders of the phone both hardware and software will never agree so.......... dual boots will be ported methods...... until some awesome dev here figures it out for the rest.........
dual boot worked for me try it out .
+1
Someone else posted about this the other day. Someone has written a bootloader that allows for dual booting different roms but I think it was for an HD2 or something. I'll try to find a link to it.
CrazyCharlie said:
Someone else posted about this the other day. Someone has written a bootloader that allows for dual booting different roms but I think it was for an HD2 or something. I'll try to find a link to it.
Click to expand...
Click to collapse
Here it is http://www.xda-developers.com/android/new-dual-boot-now-for-the-hd2/
If you can dual boot Windows Phone and Android on one device surely it's possible to have two different Android ROM's on the same device.
Samsung recently announced the new F2FS file system https://lwn.net/Articles/518718/, Im going to get the ball rolling on this, i have compiled a kernel that supports the new file system based off of fauxs source. im only posting the zimage for people who know what they are doing. For this to be usable a new recovery needs to be built to support formatting to F2FS. and possible the bootloader(not currently possible). so the best approach at this point is to build a new recovery and format only system and data to f2fs leaving boot as ext4. Im looking into it but im not very famlier with recovery. modifications need to be made to the android build system but they are trivial. Im ataching a compiled zimage and the patch files to add to any kernel. patches 01 and 16 dont apply so they will need to be done by hand. everything else applies clean.
This looks very intriguing, I haven't heard of it until now and it looks like it could bring some definite speed advantages. I can't wait to give this a whirl on my Android devices and my Arch Linux install which runs off of an SSD.
its going to be a challenge to get it runnig under android, its going to take some collaboration and time
Looks interesting. I may try to help when I get time but I haven't built an n7 kernel. Shouldn't be hard. Also need to add kernel support for the filesystem and at least add the mkfs tool to recovery so it can be formatted via adb shell.
Sent from my Galaxy Nexus using Tapatalk 2
tiny4579 said:
Looks interesting. I may try to help when I get time but I haven't built an n7 kernel. Shouldn't be hard. Also need to add kernel support for the filesystem and at least add the mkfs tool to recovery so it can be formatted via adb shell.
Sent from my Galaxy Nexus using Tapatalk 2
Click to expand...
Click to collapse
The largest change that needs to happen right now is recovery, which I'm not very familiar with
Sent from my PG86100 using Tapatalk 2
The bootloader doesn't need to know anything about the filesystem, it loads the kernel directly a preset offset.
That's why you flash a kernel, and not mount the boot partition and unzip it.
So, all that's needed to support a new filesystem is adding the code to the kernel, and enabling it in the defconfig, and then you can use userspace utilities to format partitions to that new filesystem.
F2FS is still immature, they haven't released a fsck tool for it yet, and the mkfs binary they provided is probably x86, so there's no way you can use it on the Nexus 7 now.
Just checked out their sourceforge project, check below post, they have provided source for mkfs.
Also, the recovery needs to be modified only if the default format of the partitions is being changed, and that'll need changes in the fstab as well to mount the filesystem as something other than what it was set to by default.
Nothing will need to be changed in the Android Build System as well, unless you wan't to generate f2fs system images.
f2fs-tools-1.0.0.tar.gz includes source, not binaries.
http://lkml.indiana.edu/hypermail/linux/kernel/1210.2/00005.html 1.5 to 2 times faster, Im going to look into this again it seems very worthwhile
I don't know much about this stuff, more of a user over here, but I sure know when to get excited about something. :victory:
I've read a few things about the new file system and was particularly impressed with the benchmark performance. I really hope to see this becoming a standard feature of android. Please keep up the work. You've found yourself an early adopter.
Thanks again and kudos!
aaronpoweruser said:
http://lkml.indiana.edu/hypermail/linux/kernel/1210.2/00005.html 1.5 to 2 times faster, Im going to look into this again it seems very worthwhile
Click to expand...
Click to collapse
Hi, I also think this seems very worthwhile, maybe even porting it to maguro. This thread was a nice start, I've created a thread on my device's general section, but no replies pushing forward yet.
I looked into it the best option for now would be to format an external SDcard, but that would make it un mountable by a pc. In order to make it work with an internal storage the android build tools will need to be reverted reworked as well as recovery
Sent from my Nexus 7 using Tapatalk HD
aaronpoweruser said:
I looked into it the best option for now would be to format an external SDcard, but that would make it un mountable by a pc. In order to make it work with an internal storage the android build tools will need to be reverted reworked as well as recovery
Sent from my Nexus 7 using Tapatalk HD
Click to expand...
Click to collapse
thanks, that's what i thought too, build tools/recovery, a few touches here and there xD
f2fs would be unreadable by a pc... by a Windows pc.
Hi,
I recently got to know, that my tab is using UBIFS as file system...what are the advantages compared to the normal ext2-ext4?
I thought about migrating to the ext filesystems, but if someone tells me that UBIFS is better, I'd stay on UBIFS...
Regards
Hi,
TheSSJ said:
Hi,
I recently got to know, that my tab is using UBIFS as file system...what are the advantages compared to the normal ext2-ext4?
I thought about migrating to the ext filesystems, but if someone tells me that UBIFS is better, I'd stay on UBIFS...
Regards
Click to expand...
Click to collapse
the problem running ext2/3/4 on flash is - sooner or later you will kill the flash. One might not notice it say, on a USB stick, when data is just copied from one place to another occasionally, but things look different if you use it as your root file system where things get written onto it all the time.
I am sure there are more of them around, I am only familiar wit JFFS2 and UBIFS, both are designed for flash media and implement wear leveling routines to make sure that the flash lasts longer.
JFFS2 is somewhat old now, UBIFS is newer and from what I know - better.
I use devices with UBIFS at work and it proved itself very robust, during development I often simply plug off mains without a clean shutdown and I still never ran into a file system corruption or anything like that. So, good to know that our tablets use it
Kind regards,
Jin
Thanks for the clarification. Another question:
Does any kernel support UBIFS or do I normally need to insmod the corresponding module?
TheSSJ said:
I recently got to know, that my tab is using UBIFS as file system...what are the advantages compared to the normal ext2-ext4?
I thought about migrating to the ext file systems, but if someone tells me that UBIFS is better, I'd stay on UBIFS...
Click to expand...
Click to collapse
Different things, different usages.
UBIFS, YAFFS2 etc are file systems for NAND flash devices. Those memories are not block devices.
EXT3, EXT4, VFAT etc are file systems for block devices, and can not use non block devices such as NAND flash devices.
To be able to use a block device file system on a NAND device, you'll need a Flash Translation Layer (FTL). In every USB memory stick, SSD, SDcard etc, you are viewing the NAND flash via such a translation integrated into the device itself, hence you are able to format is using an ordinary file system such as FAT or EXT4. In GNU/Linux (hence Android as well), you've got such a translation layer in the MTD device (look in /proc/mtd).
TheSSJ said:
Thanks for the clarification. Another question:
Does any kernel support UBIFS or do I normally need to insmod the corresponding module?
Click to expand...
Click to collapse
Theoretically it should be doable if you compile the ubifs modules for your kernel, I did not try that yet, when I was using it for some non tablet ARM9 boxes I simply compiled it into the kernel:
CONFIG_MTD_UBI=y
CONFIG_MTD_UBI_WL_THRESHOLD=4096
CONFIG_MTD_UBI_BEB_RESERVE=1
CONFIG_UBIFS_FS=y
CONFIG_UBIFS_FS_XATTR=y
kuisma said:
Different things, different usages.
UBIFS, YAFFS2 etc are file systems for NAND flash devices. Those memories are not block devices.
EXT3, EXT4, VFAT etc are file systems for block devices, and can not use non block devices such as NAND flash devices.
To be able to use a block device file system on a NAND device, you'll need a Flash Translation Layer (FTL). In every USB memory stick, SSD, SDcard etc, you are viewing the NAND flash via such a translation integrated into the device itself, hence you are able to format is using an ordinary file system such as FAT or EXT4. In GNU/Linux (hence Android as well), you've got such a translation layer in the MTD device (look in /proc/mtd).
Click to expand...
Click to collapse
It turned out that TrekStor Ventos 9.7 tablet uses ext4 file systems, does that mean that this is because of the way how they integrated the flash?
As far I know that for USB sticks / SDcards you can not get around the FTL, would be interesting if this is also the case for the Ventos tablet or if switching to UBIFS would be possible there. Main problem with FTL in my opinion is, that it is usually optimized for specific use cases and mostly those use cases do not include write patters that you have when the device is used as a root file system. That's where UBIFS does a much better job at preserving the flash.
Jin^eLD said:
It turned out that TrekStor Ventos 9.7 tablet uses ext4 file systems, does that mean that this is because of the way how they integrated the flash?
Click to expand...
Click to collapse
Somewhere you'll need the FTL. If using MMC technology, it's in the memory device itself.
Jin^eLD said:
As far I know that for USB sticks / SDcards you can not get around the FTL, would be interesting if this is also the case for the Ventos tablet or if switching to UBIFS would be possible there.
Click to expand...
Click to collapse
If FTL in software, such as in the MTD case, this would be possible, yes.
Jin^eLD said:
Main problem with FTL in my opinion is, that it is usually optimized for specific use cases and mostly those use cases do not include write patters that you have when the device is used as a root file system. That's where UBIFS does a much better job at preserving the flash.
Click to expand...
Click to collapse
Android places its root file system in RAM, not in flash.
The FTL is what differs the flash memory (SSDs, MMCs etc) vendors from each other. Some manufacturers priorities read speed, other write speed, and yet other random access etc. Some uses more spare chips extending the life of the device, at the cost of a more expensive unit. Other throttles the write speed to guarantee the functionality during the warranty period. Basically you'll get what you pay for.
kuisma said:
Android places its root file system in RAM, not in flash.
Click to expand...
Click to collapse
Oh.. OK, I did not know that, I'm still quite new to Android. So far I've been playing around with ARM9 devices, building root file systems with OpenEmbedded, but just starting with Android now.
kuisma said:
The FTL is what differs the flash memory (SSDs, MMCs etc) vendors from each other. Some manufacturers priorities read speed, other write speed, and yet other random access etc. Some uses more spare chips extending the life of the device, at the cost of a more expensive unit. Other throttles the write speed to guarantee the functionality during the warranty period. Basically you'll get what you pay for.
Click to expand...
Click to collapse
-> "Basically you'll get what you pay for."
That's what I fear I had very positive experiences with UBIFS so I'd rather rely on it doing the job than on an FTL, which I know nothing about, that is used in my el-cheapo tablet.
Jin^eLD said:
Oh.. OK, I did not know that, I'm still quite new to Android. So far I've been playing around with ARM9 devices, building root file systems with OpenEmbedded, but just starting with Android now.
Click to expand...
Click to collapse
Also, once booted, it remounts root as read-only, so I wouldn't worry too much about wear leveling.
Jin^eLD said:
-> "Basically you'll get what you pay for."
That's what I fear I had very positive experiences with UBIFS so I'd rather rely on it doing the job than on an FTL, which I know nothing about, that is used in my el-cheapo tablet.
Click to expand...
Click to collapse
Sure, if you know what you are doing, controlling the FTL, and you can optimize the performance for the particular task you are using the device for. Buying a ready-to-use device using an integrated FTL, and the manufacturer have no other choice than adjusting the FTL parameters for the average customer usage. Still, in most cases I would say this is good enough and the risk of manually creating an even worse profile is quite likely for a noob such as myself.
kuisma said:
Different things, different usages.
UBIFS, YAFFS2 etc are file systems for NAND flash devices. Those memories are not block devices.
Click to expand...
Click to collapse
Oh, this explains why I got a corrupted recovery by dumping /dev/block/mtdblock3 on my uImage/ubifs powered tab...It worked when I dumped /dev/mtd/mtd3 though...
Thanks for the explanation!
need help !!!!!!!!!!!!!!!!!!!!!!!!!!!
hey bro
how can i take backup of my ubifs rom
and flash ubifs rom on my mt6572 ( in case needed)
TheSSJ said:
Hi,
I recently got to know, that my tab is using UBIFS as file system...what are the advantages compared to the normal ext2-ext4?
I thought about migrating to the ext filesystems, but if someone tells me that UBIFS is better, I'd stay on UBIFS...
Regards
Click to expand...
Click to collapse
Hey bro, you said youll migrate to ext4 if it is better. How can you that? Ive been searching for a way to format my ubifs phone to ext4. I hope you can help me
Disclaimers :
#i am no-developer.im just a geek xperian..like many of u.i have created this ,my first ever thread typing on my mob keypad.so forgive me for short words and untidy post.
#links included below is noway related to me.respective links are included as per my findings to support the main moto of this thread.im thankfull to all of them who have tried to scratch on this through their posts and threads
#with all do respect,this thread is intended for our devs who can take this as pre-requsites for development.
#its a humble request for devs to put there effort on this.
#i request all xperians...from devs to simple users...whoever thinks this post worth discussing/developing,ur valueable words on this are highly appreciated.
#and please no trollers
Click to expand...
Click to collapse
I was doodling around today,i got my eyes poped-up wen i encounterd this
[samsung kernel flashing from cwm zip] -> http://forum.xda-developers.com/showthread.php?t=1301756 and this
[samsung general cwm kernel updater] ->http://forum.xda-developers.com/showthread.php?t=2132208
It all began then when i had to be far from my pc.then flashing new kernls for new custom roms began to be a problem.i presume their are a lot of users like me who cant access pc with as ease as many can.or simply to them who dont want to connect to pc just to flash kernels.if this would be success,just imagine how ease it would be?
But before starting to dream lets put together what i have come across till now.
Then i started digging more...on google & found this Tutorial [many devs might be intrestd &could help xperia users& start to run xperiment in our xperia ] --> http://www.modaco.com/topic/360180-howto-build-and-update-kernel-using-cwm/
In my findings i did aknowledge that this matter has/have/had been left out in corner just for some taboos/nerms like our xperia doesnt ship with normal recovery partition or like our custm recovry doesnt support some disk formats.
But whatsoever, i was little arosed by above things....then came a point whereafter i was too excited,wen i found this in our very xperia forum,xperia p forum ->> http://forum.xda-developers.com/showthread.php?t=2409021
Here the dev has created a zip with updatr script writng the kernel image,which stays inside the boot.img file .i couldnt dig more on this zip,as it was not so popular thread.i dont even know for it works or not,all i know is there are devs wanting to build,which is the main moto of this thread to let devs rethink the possibilty.
And yes, its a convincing reason for acceptance that our xperia doesnt have recovry partition like as other vendors device..and what we get as a recovry is hard coded to ramdisk.but like as ,A xperia s user,i too want to question an enlightning point on this...like using recovry fota partition,wich gets blokd and remains unusable aftr bootloader unlockd....why not use that...if not what about repartitioning empty space in device for recovry usage partition... http://forum.xda-developers.com/showthread.php?t=2163643
i too presume, even though we dont have that heavy intrnl space,but i guess we have enough for just a recovry partition.i guess so.correct me.
FOTA partition :
The FOTAKernel partition is used by Sony to do FOTA updates when updating the boot image. Unlocked devices can't take Sony FOTA updates so using this partition for storing the recovery ramdisk seems like a good idea. Unlocked users aren't able to use this partition anyway and the FOTAKernel partition is effectively the "recovery" partition on Sony devices.
Kernel changes : extract_elf_ramdisk setup in kernel
if some body wants a detailed info it can be found here (( **thanks to @officiallysonyrebel ,for the supportive conversation.above words are his ** )) -- http://forum.xda-developers.com/showpost.php?p=38640389&postcount=2
*** Summing up in total ***
It may b a horizon-touching dream..but as a geek user, like me,we dream of it.
Our charming devs can unlock bootloaders/root/giv us custm roms/give us a taste with unimaginable upgrowing ever, android version updates in roms/ ports.these all would also be impossible without their immense hardwork/researchs/xperimnts...i do aknowledge its a lot to ask for this.but with all do respect i wish devs get ther hands on it.
I predict most of xda-ians might already know abt all this,if yes do enlighten us more...ur comments and findings are most needed thing currently.
but truely saying i really dream of using cwm @ its maximum capacity,as of its easeness,isnt it? Different vendors like samsung,zte,etc evn can get rooted simply from cwm only...even most htc can. So why cant our xperia?is it coz of less devs in our xperia?i humbly request all devs to put some work on this so that me,like users who cant access pc with ease/dont want to,can easily get the work done.i also presume there r a lot of xperians,who want this.it cant be more handy than this...can it?
Hope in near future ,we xperians could getwith like these features as others.(rootng/flashng kernels from cwm).
Cheers!!
Xperia-lover!!
Most Xperia kernels are probably including CWM by default in the boot image. About a month ago Dees_Troy submitted some changes to the CyanogenMod repos that were accepted. Newer builds of CM include a special extract_elf_ramdisk utility that Dees_Troy wrote to read and extract a recovery ramdisk from the FOTAKernel partition instead of using the ramdisk that is included in the boot image. If the ramdisk in the FOTAKernel partition is a stock Sony ramdisk or not present, then the existing ramdisk in the boot image is used instead. This setup allows users to choose which recovery they want to keep installed.and whole a lot possibilites
but my major concern is if after unlocking bootloader FOTA partition gets blocked then how can we access it ..
so, first we have to acess FOTA partion then we can start dreaming on
officiallysonyrebel said:
Most Xperia kernels are probably including CWM by default in the boot image. About a month ago Dees_Troy submitted some changes to the CyanogenMod repos that were accepted. Newer builds of CM include a special extract_elf_ramdisk utility that Dees_Troy wrote to read and extract a recovery ramdisk from the FOTAKernel partition instead of using the ramdisk that is included in the boot image. If the ramdisk in the FOTAKernel partition is a stock Sony ramdisk or not present, then the existing ramdisk in the boot image is used instead. This setup allows users to choose which recovery they want to keep installed.and whole a lot possibilites
but my major concern is if after unlocking bootloader FOTA partition gets blocked then how can we access it ..
so, first we have to acess FOTA partion then we can start dreaming on
Click to expand...
Click to collapse
Ya i had read in the link u dirctd...i got to know that aftr unlockng bootloadr, that partition becomes unusuable/inaccessble.if that could be attained...then we can hope...isnt it?if i undrstud... wish devs could wave their magicstick soon.
Sent from my Xperia Ray using xda premium
I'm not sure but what about installing the recovery in /system?
Then we could write a script that detects if the recovery is installed in /system and it will choose the /system recovery over the kernel recovery while booting in recovery. Then we could try mounting the kernel partition and flash the boot.img. Then you flash a zip to remove the /system recovery and boot the new kernel
Not sure if that's possible, and don't have any idea how to do that. It was just an idea :good:
Sent from my Nexus 4 running Android 4.3
mihahn said:
I'm not sure but what about installing the recovery in /system?
Then we could write a script that detects if the recovery is installed in /system and it will choose the /system recovery over the kernel recovery while booting in recovery. Then we could try mounting the kernel partition and flash the boot.img. Then you flash a zip to remove the /system recovery and boot the new kernel
Not sure if that's possible, and don't have any idea how to do that. It was just an idea :good:
Sent from my Nexus 4 running Android 4.3
Click to expand...
Click to collapse
we can't do it in /system basicially we have to do this thing using only FOTA partition ..but our main concern is when we unlock our bootloaders that partition becomes inaccesible for us...
if we somehow gets access to FOTApatition then script will do work..
mihahn said:
I'm not sure but what about installing the recovery in /system?
Then we could write a script that detects if the recovery is installed in /system and it will choose the /system recovery over the kernel recovery while booting in recovery. Then we could try mounting the kernel partition and flash the boot.img. Then you flash a zip to remove the /system recovery and boot the new kernel
Not sure if that's possible, and don't have any idea how to do that. It was just an idea :good:
Sent from my Nexus 4 running Android 4.3
Click to expand...
Click to collapse
Nope...You are still using the same kernel....just booting from different ramdisk when "installed in /system"...
We need to boot from a "second" kernel which can be used to flash the primary kernel ...Most other phone can boot into two kernels ,one stock and one recovery ,hence they can be used to flash kernels via recovery and use flash_image to install recovery in system ...
The problem is not where kernel/recovery is installed
The problem is how to boot the secondary kernel after installation ...It's very difficult to do that ...
lets say I dd the recovery.img to /mmcblk0p4 which is the fourth partition in an SD card
How do I instruct the bootloader to boot the device from /mmcblk0p4(or fota 1 or whatever) instead of /boot ...Thats the problem ...
Okay that's sad
But what about checking the partitions and if we know which blocks contain the Fota partition, could we try to mount it?
The problem would be how to tell the bootloader to boot the recovery or the 2nd kernel right?
Sent from my Nexus 4 running Android 4.3
Still the same problem ,how to instruct the bootloader to boot from fota 1 instead of /boot !!
Check that. It's exactly the same what we want to do, right?
Okay not exactly but we could use that too. But I'm not sure if he is able to install another kernel in the recovery...
Sent from my Nexus 4 running Android 4.3
mihahn said:
Check that. It's exactly the same what we want to do, right?
Sent from my Nexus 4 running Android 4.3
Click to expand...
Click to collapse
Exactly ...we can use Multi partitioned SD card but thats extremely wishful thinking ...Also we need a lot of devices to brick :rofl:
Edit: He can use recovery to install kernels since ,the S1 boot boots LK from mmcblk0p4 (equivalent to /boot) which in turn gives an option to boot to fota1(which is recovery ) or the mmcblk016(which is the new place from which the system boots)
karandpr said:
Exactly ...we can use Multi partitioned SD card but thats extremely wishful thinking ...Also we need a lot of devices to brick :rofl:
Edit: He can use recovery to install kernels since ,the S1 boot boots LK from mmcblk0p4 (equivalent to /boot) which in turn gives an option to boot to fota1(which is recovery ) or the mmcblk016(which is the new place from which the system boots)
Click to expand...
Click to collapse
But later in OP they said it could be possible to reflash the stock rom to restore the partition table. So if we don't touch fastboot and flashmode partitions we should be able to recover the phone
I wrote the OP a PM if he could help us, let's see what happens
Sent from my Nexus 4 running Android 4.3
mihahn said:
But later in OP they said it could be possible to reflash the stock rom to restore the partition table. So if we don't touch fastboot and flashmode partitions we should be able to recover the phone
I wrote the OP a PM if he could help us, let's see what happens
Sent from my Nexus 4 running Android 4.3
Click to expand...
Click to collapse
Unlike them we aren't modifying partitions ...we can use multi SD card but then we need to get SD card mounted by LK ...
There is a fundamental diffrence in two phones ,that they are using an emmc+ext4 and we are using a raw nand/yaffs device . i think the difference is night and day ...I dont think we can modify partitions easily ...
If however we get to mount SD card with LK then it's a different story ...
karandpr said:
Unlike them we aren't modifying partitions ...we can use multi SD card but then we need to get SD card mounted by LK ...
There is a fundamental diffrence in two phones ,that they are using an emmc+ext4 and we are using a raw nand/yaffs device . i think the difference is night and day ...I dont think we can modify partitions easily ...
If however we get to mount SD card with LK then it's a different story ...
Click to expand...
Click to collapse
So you mean we partition the sdcard and use a partition as the recovery partition?
I read about that with multiboot for xperia play (I guess). So maybe it could work for us too?
Sent from my Nexus 4 running Android 4.3
mihahn said:
So you mean we partition the sdcard and use a partition as the recovery partition?
I read about that with multiboot for xperia play (I guess). So maybe it could work for us too?
Sent from my Nexus 4 running Android 4.3
Click to expand...
Click to collapse
it's more logical(and safer) than editing nand ...AFAIK ,the partition setup of nand is included in kernel ...we can partition SD card to whatever we want and is more feasible
karandpr said:
it's more logical(and safer) than editing nand ...AFAIK ,the partition setup of nand is included in kernel ...we can partition SD card to whatever we want and is more feasible
Click to expand...
Click to collapse
Okay so how to start? What could we do to get the project to a higher level?
We have to find out how to get the bootloader to boot the 2nd kernel/recovery partition, right?
Sent from my Nexus 4 running Android 4.3
mihahn said:
Okay so how to start? What could we do to get the project to a higher level?
We have to find out how to get the bootloader to boot the 2nd kernel/recovery partition, right?
Sent from my Nexus 4 running Android 4.3
Click to expand...
Click to collapse
Not really ....we can attempt/try/wish to do what the Xperia T folks did ,flash a bootloader at /boot instead of boot image ...
First thing we really need to know how actually LK works and can it be made to boot a kernel stored in a memory card ,
Editing a nand partition is currently out of question imo ,there is no free space for two kernels...
Edit : TBH ,We should look at HTC HD2 development more than anything since that section has "Android SD development" and Nand development ..
Even saying that we might just be scratching the surface :/
karandpr said:
Not really ....we can attempt/try/wish to do what the Xperia T folks did ,flash a bootloader at /boot instead of boot image ...
First thing we really need to know how actually LK works and can it be made to boot a kernel stored in a memory card ,
Editing a nand partition is currently out of question imo ,there is no free space for two kernels...
Edit : TBH ,We should look at HTC HD2 development more than anything since that section has "Android SD development" and Nand development ..
Even saying that we might just be scratching the surface :/
Click to expand...
Click to collapse
Yes the HTC HD2 has great development support and I already worked with a HD2 of a friend, but I have actually no idea how to use the method they are using for the HD2 for our devices. I think I will dive into it when I'm back at home from my vacation trip
Sent from my Nexus 4 running Android 4.3
maybe at deeper lok of possibiltes
i was searching on sd card booting nd found this
http://glasskeys.com/2011/06/27/how...-card-running-cyanogenmod-for-the-nook-color/
we need to make a seprate partition and kernel to use triggers to boot like we always do but it will call from SD card..
i think it may not work cause calling a kernel from SD card
officiallysonyrebel said:
maybe at deeper lok of possibiltes
i was searching on sd card booting nd found this
http://glasskeys.com/2011/06/27/how...-card-running-cyanogenmod-for-the-nook-color/
we need to make a seprate partition and kernel to use triggers to boot like we always do but it will call from SD card..
i think it may not work cause calling a kernel from SD card
Click to expand...
Click to collapse
Ehh...no it won't work ...the S1boot boots only from /boot...
The thread you cited is too old and worked probably due to an exploit in nook color ...
I think something like LK should work ,provided it waits for sd card to mount...
officiallysonyrebel said:
we can't do it in /system basicially we have to do this thing using only FOTA partition ..but our main concern is when we unlock our bootloaders that partition becomes inaccesible for us...
if we somehow gets access to FOTApatition then script will do work..
Click to expand...
Click to collapse
Correct me if i m wrong.its a noobish thought.
Can we access fota partition before bootloader is unlocked?if we can so what r we waiting for?
lets rehearse for the magick show,do what u have thought of.
(I presume when device is still locked....or if we revert back to locked state from unlocked... we could acces that partition.. .we get space for secondry kernel...if still quesn is letting bootloader know we want to boot from that,then again we r far behind)
Sent from my Xperia Ray using xda premium
I've created a single primary Ext2 partition in my phone's external SD card but Android refuses to mount it automatically. Whenever I attempted to mount it manually it kept throwing the error "mount operation not supported on transport endpoint".
How can I mount it?
Using (SlimKat) Android 4.4.2.
EDIT: I'm now able to mount it only manually but have to specify ext4 as its filesystem -- why and will it make a difference since ext2 is non-journalled? Also, I tried adding a mount entry in /fstab.smdk4x12 but it was deleted upon reboot; does this mean no manual entries are allowed in that file and I will instead have to hack my own /init-xx.rc file to manually mount the partition at boot time?
miguelg_ said:
I've created a single primary Ext2 partition in my phone's external SD card but Android refuses to mount it automatically. Whenever I attempted to mount it manually it kept throwing the error "mount operation not supported on transport endpoint".
How can I mount it?
Using (SlimKat) Android 4.4.2.
EDIT: I'm now able to mount it only manually but have to specify ext4 as its filesystem -- why and will it make a difference since ext2 is non-journalled? Also, I tried adding a mount entry in /fstab.smdk4x12 but it was deleted upon reboot; does this mean no manual entries are allowed in that file and I will instead have to hack my own /init-xx.rc file to manually mount the partition at boot time?
Click to expand...
Click to collapse
Why not just reformat to ext4?
es0tericcha0s said:
Why not just reformat to ext4?
Click to expand...
Click to collapse
Ultimately that's what I'll need to do but was hoping to use the non-journalled ext2. Is it not supported by Android or it the case that only some versions support it (in which case, what idiocy!)?
Have to say I'm beginning to truly hate Android. They might as well build their own kernel such that Linux (and by implication UNIX) is removed from the mix for they have completely butchered this OS. I suppose this is what happens when egos larger than the world are responsible for designing software; NIH syndrome.
Answering myself: if anyone is wondering how to automount a partition at boot time, you'll have to create your own init script and place in /system/etc/init.d/.
Well, realistically, the amount of people that have any use for mounting ext2/3/4 etc partitions is a very small % of users. Most people with android phones don't even know what Linux is, much less know about different kinds of partitions and what they are used for - or have a need for it. 99% of things you would NEED to do on a phone would be covered by the fat32 and exFat types. Of course, here on XDA, you'll find plenty of posts, guides, complaints about it, etc but there's obviously a certain type of user that seeks out or finds XDA and are more inclined to know of or have use for more technical things like this.
As far as auto-mounting the script on boot, you have to be rooted with init.d enabled and not all phones have full /system RW capabilities to even add stuff like that even when rooted. This is rare, but there's some HTCs and others like that. Often times there are ways around, but just saying, it's not a universal thing.
es0tericcha0s said:
Well, realistically, the amount of people that have any use for mounting ext2/3/4 etc partitions is a very small % of users. Most people with android phones don't even know what Linux is, much less know about different kinds of partitions and what they are used for - or have a need for it. 99% of things you would NEED to do on a phone would be covered by the fat32 and exFat types. Of course, here on XDA, you'll find plenty of posts, guides, complaints about it, etc but there's obviously a certain type of user that seeks out or finds XDA and are more inclined to know of or have use for more technical things like this.
Click to expand...
Click to collapse
That doesn't excuse the fact that they've deliberately crippled the OS. As an example, the FAT filesystems don't support symbolic links, which means that if you want to move any data outside of internal storage for whatever reason, you pretty much need an extX partition. Besides, those people (the vast majority) who don't know and don't care about the internals of their devices aren't the ones creating software for said devices in the first place. We are. And so these technical aspects matter and are relevant to us, not the masses.
es0tericcha0s said:
As far as auto-mounting the script on boot, you have to be rooted with init.d enabled and not all phones have full /system RW capabilities to even add stuff like that even when rooted. This is rare, but there's some HTCs and others like that. Often times there are ways around, but just saying, it's not a universal thing.
Click to expand...
Click to collapse
Didn't know about that limitation. Can you not remount the rootfs with RW privileges? And do you mean to say that some devices don't even support init.d; if so, what mechanism do they have in place?
miguelg_ said:
That doesn't excuse the fact that they've deliberately crippled the OS. As an example, the FAT filesystems don't support symbolic links, which means that if you want to move any data outside of internal storage for whatever reason, you pretty much need an extX partition. Besides, those people (the vast majority) who don't know and don't care about the internals of their devices aren't the ones creating software for said devices in the first place. We are. And so these technical aspects matter and are relevant to us, not the masses.
Didn't know about that limitation. Can you not remount the rootfs with RW privileges? And do you mean to say that some devices don't even support init.d; if so, what mechanism do they have in place?
Click to expand...
Click to collapse
Well, cripple might be a bit of hyperbole considering it's not something most people would need. I get your point though, it is weird that it's not native since it works with Linux generally. You can link symbolically to FAT systems while rooted with something like this:
https://play.google.com/store/apps/details?id=com.devasque.fmount
And yes, the tech people are creating software for these devices, but they are made for the general public, because that's who buy 90% of these things.
Could you please clarify what you said earlier on the read-only init.d and even some devices not supporting it? Again, thanks for your input, es0tericcha0s.
miguelg_ said:
Could you please clarify what you said earlier on the read-only init.d and even some devices not supporting it? Again, thanks for your input, es0tericcha0s.
Click to expand...
Click to collapse
Sure. Most android devices, actually I can't think of any of the top of my head, don't come with native init.d support or even have init.d that is not accessible. It's just not there. It's enabled in almost all custom roms, or you can add it yourself to many stock roms via a couple different ways like this:
https://play.google.com/store/apps/details?id=com.androguide.universal.init.d
As far as the system RW issue, some phones, like many newer HTCs, have the system protected so that you can make changes to the /system while booted, no problem, but once you reboot, all the changes will get undone. Very annoying. Example:
https://www.youtube.com/watch?v=KV3YaMBnEYI