Welcome to XDA

Search to go directly to your device's forum

Register an account

Unlock full posting privileges

Ask a question

No registration required
Post Reply

Getting rid of constant repacking

OP Xmister

22nd February 2013, 02:07 PM   |  #1  
OP Senior Member
Thanks Meter: 1,729
 
809 posts
Join Date:Joined: Jul 2010
Donate to Me
More
Hi guys!

I think the need of repacking and repacked images for every kernel-rom combination is a huge nuisance.

What would be if ROMs would contain their ramdisk on the system partition, and the kernels would just contain a minimal ramdisk that loads the ROMs ramdisk?

One idea:
My first idea would break compatibility with system recovery zips, so a little modified:

There would be a new "ramdisk" directory on system partition, that would containt all the ramdisk files a ROM should have, except the system folder.
So it would contain:
bin
etc
data
...
init.rc
...
and so on.

The init in the actual ramdisk would mount system first, and then make the links:
/bin -> /system/ramdisk/bin
/etc -> /system/ramdisk/etc
/data -> /system/ramdisk/data
...
and then we would include init.rc from /system/ramdisk.

Of course all the ROMs would need to change, but after that, there would be no need for repack. Also for the old ROMs, factory ROM, some could still repack.
Last edited by Xmister; 22nd February 2013 at 03:38 PM.
The Following 14 Users Say Thank You to Xmister For This Useful Post: [ View ]
22nd February 2013, 03:06 PM   |  #2  
Member
Thanks Meter: 36
 
59 posts
Join Date:Joined: May 2012
That's a nice idea! I thought a little bit about it and here are my thoughts (a novice, please don't laugh at me ):

if I understand your idea correctly, your intention is to store the specific ROM's ramdisk in the rootfs, and make a global, generic ramdisk which will be stored in all the kernels.
Upon loading the kernel's ramdisk, it will know to take the ROM's ramdisk from the rootfs (upon mounting it?) and run whatever is in it, thus eliminating the need for repacking.

Do correct me if I'm talking absolute rubbish, but wouldn't this be a security risk?
Currently with S-ON, you actually can't change the kernel's ramdisk, but if the ramdisk will be stored in a writeable filesystem...?
22nd February 2013, 03:12 PM   |  #3  
OP Senior Member
Thanks Meter: 1,729
 
809 posts
Join Date:Joined: Jul 2010
Donate to Me
More
Re: Getting rid of constant repacking
Quote:
Originally Posted by Freezeil

That's a nice idea! I thought a little bit about it and here are my thoughts (a novice, please don't laugh at me ):

if I understand your idea correctly, your intention is to store the specific ROM's ramdisk in the rootfs, and make a global, generic ramdisk which will be stored in all the kernels.
Upon loading the kernel's ramdisk, it will know to take the ROM's ramdisk from the rootfs (upon mounting it?) and run whatever is in it, thus eliminating the need for repacking.

Do correct me if I'm talking absolute rubbish, but wouldn't this be a security risk?
Currently with S-ON, you actually can't change the kernel's ramdisk, but if the ramdisk will be stored in a writeable filesystem...?

On s-off phones ramdisk can be changed on the fly with repacking, and reflashing the kernel if rooted. There is no more security risk in this, than that. And system is ro mostly, so file corruption isn't something to be afraid of either.

Sent from my HTC One X using xda premium
22nd February 2013, 03:53 PM   |  #4  
Member
Thanks Meter: 36
 
59 posts
Join Date:Joined: May 2012
Quote:
Originally Posted by Xmister

On s-off phones ramdisk can be changed on the fly with repacking, and reflashing the kernel if rooted. There is no more security risk in this, than that. And system is ro mostly, so file corruption isn't something to be afraid of either.

Sent from my HTC One X using xda premium

I agree, other than the fact that repacking+reflashing the kernel on S-ON devices can only be done manually, by a person (which is the device owner, most of the time), and most of the One X's out there are S-ON and not S-OFF...
Sure, a malicious coder can write evil code in the kernel, but that's relatively less threatening since most kernels have their sources published.
If the ramdisk will be placed on a rw fs (or a ro, but it matters not because of the user elevation rooted users can achieve easily), we are adding the risk of malicious code accessing and changing that ramdisk, without the user's knowledge.

Still, this seems like a nice programming challenge, so I'm up for the task. Will start reading the init's code and see how to do it
22nd February 2013, 07:50 PM   |  #5  
Recognized Contributor / Recognized Developer
Flag Swansea
Thanks Meter: 7,147
 
5,547 posts
Join Date:Joined: Mar 2009
Donate to Me
More
Guys i would like this thread kept with minimal off topic please, i have already deleted three posts here...

thanks

-Lloir, Section mod
22nd February 2013, 08:00 PM   |  #6  
TripNRaVeR's Avatar
Senior Member
Flag Stevensweert
Thanks Meter: 12,585
 
2,379 posts
Join Date:Joined: Jun 2010
Donate to Me
More
Is anyone really seriously responding to this?
What would be the advantages of modifying Android layout for 1 device only, its so annoying to see this stuff here when even a s-off thread is locked.. currently when all the sources are going to a way whereas all the basic files are device independent makin this even more.. timewasting effort and still we have the same issues. You just lock every rom dev to a ramdisk instead of a kernel dev to a ramdisk.

This is only usefull with a locked bootloader. I never implement this, another reason is that i spend more time getting my stuff aligned with the mainline that is giving me more succes then randomly adding stuff the a system partition.

Oh and btw when youre system partition gets messed up or altered or whatever you wish you had a decent ramdisk. Not to forget the huge amount of users ending up like that and flooding the forums with questions.
Last edited by TripNRaVeR; 22nd February 2013 at 08:02 PM.
The Following User Says Thank You to TripNRaVeR For This Useful Post: [ View ]
22nd February 2013, 08:07 PM   |  #7  
OP Senior Member
Thanks Meter: 1,729
 
809 posts
Join Date:Joined: Jul 2010
Donate to Me
More
Quote:
Originally Posted by TripNRaVeR

Is anyone really seriously responding to this?
What would be the advantages of modifying Android layout for 1 device only, its so annoying to this stuff here.. when all the sources are going to a way whereas all the basic files are device independent.

Adding 1 directory is not an "android layout modification". They are moving there, yet it isn't independent between the ROMS even on the same phone.

Quote:

This is only usefull with a locked bootloader.

That's what 99% of us have.

Quote:

Oh and btw when youre system partition gets messed up or altered or whatever you wish you had a decent ramdisk. Not to forget the huge amount of users ending up like that and flooding the forums with questions.

If your system messes up you are probably can't boot android either. What the r=1 user do this time? Goes to recovery, wipe, if that doesn't help, reflash.
Since we have different kernel and ramdisk for recovery, this is not a problem.
22nd February 2013, 08:11 PM   |  #8  
TripNRaVeR's Avatar
Senior Member
Flag Stevensweert
Thanks Meter: 12,585
 
2,379 posts
Join Date:Joined: Jun 2010
Donate to Me
More
Quote:
Originally Posted by Xmister


That's what 99% of us have.

Lol 99% of us DOESNT have this, if we did we cant flash custom roms.


Adding 1 directory is changing Android layout, Google doesnt have it, you want it on /system you alter the layout. Plain simple.

Also if anyone, like me, doesnt like to include youre mod users still need to repack between roms who contain that dir and roms who dont have that dir. That repacking also requires the same kernel edits so basicly you just move the repacking arround.
22nd February 2013, 08:18 PM   |  #9  
OP Senior Member
Thanks Meter: 1,729
 
809 posts
Join Date:Joined: Jul 2010
Donate to Me
More
Quote:
Originally Posted by TripNRaVeR

Lol 99% of us DOESNT have this, if we did we cant flash custom roms.

Sorry, I was reading S-ON in my mind, I don't know why.
But then it's not only useful for locked devices. It helps just in what it says in the title.


Quote:

Also if anyone, like me, doesnt like to include youre mod users still need to repack between roms who contain that dir and roms who dont have that dir. That repacking also requires the same kernel edits so basicly you just move the repacking arround.

Yes, it can only work if there are enough ROMs taking the change.

And right, call it a layout modification. Why is adding 1 directory bad for anything? It won't break compatibility over anything.
22nd February 2013, 08:28 PM   |  #10  
TripNRaVeR's Avatar
Senior Member
Flag Stevensweert
Thanks Meter: 12,585
 
2,379 posts
Join Date:Joined: Jun 2010
Donate to Me
More
Quote:
Originally Posted by Xmister

Sorry, I was reading S-ON in my mind, I don't know why.
But then it's not only useful for locked devices. It helps just in what it says in the title.




Yes, it can only work if there are enough ROMs taking the change.

And right, call it a layout modification. Why is adding 1 directory bad for anything? It won't break compatibility over anything.


I dont want to call it bad, i just dont think this developer discussion, as we all know, and probably you also, this kinda stuff is only stuff to think about. As long as the whole community isnt adopting this it will never happen.

As you also state, it only works when enough roms are using it.. THAT is my problem here, currently we need to repack because of compat. issues sometimes.

Cool that sucks i know, you come up with this idea, without proper thinking people say cool lets do that.

When building roms, some devs like this and some devs dont like this, that will happen you can count on that. If you have 3 devs that dont use it you could end up doing MORE repacking then we need to do now.. that is what i'm trying to explain..

Therefore i said cant believe this is seriously looked into at a high mod level dev section. Hope i made my point clearer now
Last edited by TripNRaVeR; 22nd February 2013 at 08:29 PM. Reason: typos

Post Reply Subscribe to Thread
Previous Thread Next Thread
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes