FORUMS
Remove All Ads from XDA

[DEV][TEMPLATE] AnyKernel3 - Easily Mod ROM Ramdisk + Pack Image.gz [Flashable Zip]

13,596 posts
Thanks Meter: 29,906
 
By osm0sis, Recognized Developer / Recognized Contributor on 5th March 2014, 02:32 AM
Post Reply Email Thread
3rd January 2015, 11:45 PM |#91  
bsmitty83's Avatar
Senior Member
Flag Detroit
Thanks Meter: 10,392
 
More
Quote:
Originally Posted by Khaon

Okay I'll work on that,np. I'll post my solution so you can comment it and it might help some other users!


You won't make eventually AnyKernelv2 supporting ext4/f2fs devices?

EDIT: In my opinion, Anykernel should support unified ext4/f2fs ramdisk a way or another.

AnyKernel is a template for an update.zip that can apply any kernel to any ROM, regardless of ramdisk.

What is your position on that?

It most certainty does exactly what you ask already . as @osm0sis said , check the examples . you can add an a fscheck to determine what format the partition is in , and it will use the correct fstab .

Please refer to this ,

https://github.com/bsmitty83/DirtyV_...8d0f0aabbe57d1
The Following 3 Users Say Thank You to bsmitty83 For This Useful Post: [ View ] Gift bsmitty83 Ad-Free
 
 
7th January 2015, 05:20 PM |#92  
osm0sis's Avatar
OP Recognized Developer / Recognized Contributor
Flag Halifax
Thanks Meter: 29,906
 
Donate to Me
More
Quote:
Originally Posted by Captain_Throwback

Well sysinit is just a text file called in init, the content of which is posted right in the thread. It should be trivial to create it and have it copied to /system/bin if that option is selected.

I figured adding one file to be copied to system would be a much smaller deal than installing busybox. Are you saying you wouldn't want to include anything that's outside of ramdisk at all?

Quote:
Originally Posted by osm0sis

Ah! Didn't read thoroughly enough! Thanks, I'll look into it.

I do actually prefer to keep things inside the ramdisk when possible, but that's just to avoid conflicting with ROM implementations where possible.

Here's what I've reduced that script you linked to:
Code:
/system/bin/sh -c "for i in `find /system/etc/init.d -type f | sort`; do if [ ! -d $i ] && [ -x $i ]; then logwrapper $i; fi; done;"
Going to have to experiment to see if I can just plop that on a service and have it work, which would be cool, since that would avoid the need for anything external whatsoever. Then the question is when to inject or not; there's no point in duplicating a ROM implementation or previous injection of something similar. Maybe a grep for "run-parts /system/etc/init.d" or "sysinit" would have it covered.. Kinda makes me not like the full injection idea again. Thoughts?


Edit: A rewritten version of this is now available due to new issues in Lollipop+.
The Following User Says Thank You to osm0sis For This Useful Post: [ View ]
7th January 2015, 06:19 PM |#93  
Captain_Throwback's Avatar
Senior Member
Flag The Nothing
Thanks Meter: 22,611
 
10
Donate to Me
More
Quote:
Originally Posted by osm0sis

I do actually prefer to keep things inside the ramdisk when possible, but that's just to avoid conflicting with ROM implementations where possible.

Here's what I've reduced that script you linked to:

Code:
/system/bin/sh -c "for i in `find /system/etc/init.d -type f | sort`; do if [ ! -d $i ] && [ -x $i ]; then logwrapper $i; fi; done;"
Going to have to experiment to see if I can just plop that on a service and have it work, which would be cool, since that would avoid the need for anything external whatsoever. Then the question is when to inject or not; there's no point in duplicating a ROM implementation or previous injection of something similar. Maybe a grep for "run-parts /system/etc/init.d" or "sysinit" would have it covered.. Kinda makes me not like the full injection idea again. Thoughts?

The simplest way to add init.d support to the ramdisk would probably be:
Code:
service sysinit /system/bin/busybox run-parts /system/etc/init.d
   class late_start
   user root
   group root
   oneshot
Any standard implementation of init.d will include "busybox run-parts /system/etc/init.d" because that's how it's processed. Some implementations use logwrapper as well, but I don't believe that's necessary for it to work with the other parameters specified.

The enhanced init.d was just an idea, but no modifications other than to the ramdisk should be necessary for standard init.d scripting to be added.

EDIT: I don't recommend grepping for "sysinit" for the simple reason that I've seen implementations that call it "userinit" instead. The service can really be named anything.
The Following 2 Users Say Thank You to Captain_Throwback For This Useful Post: [ View ] Gift Captain_Throwback Ad-Free
7th January 2015, 06:37 PM |#94  
osm0sis's Avatar
OP Recognized Developer / Recognized Contributor
Flag Halifax
Thanks Meter: 29,906
 
Donate to Me
More
Quote:
Originally Posted by Captain_Throwback

The simplest way to add init.d support to the ramdisk would probably be:

Code:
service sysinit /system/bin/busybox run-parts /system/etc/init.d
   class late_start
   user root
   group root
   oneshot
Any standard implementation of init.d will include "busybox run-parts /system/etc/init.d" because that's how it's processed. Some implementations use logwrapper as well, but I don't believe that's necessary for it to work with the other parameters specified.

The enhanced init.d was just an idea, but no modifications other than to the ramdisk should be necessary for standard init.d scripting to be added.

EDIT: I don't recommend grepping for "sysinit" for the simple reason that I've seen implementations that call it "userinit" instead. The service can really be named anything.

Agreed, I was just suggesting that using logwrapper like the enhanced init.d you pointed me to would allow for ramdisk init.d support without having to add busybox, other binaries, or anything to system.

Hypothetically:
Code:
# Execute files in /system/etc/init.d before booting
service run-parts /system/bin/sh -c "for i in `find /system/etc/init.d -type f | sort`; do if [ ! -d $i ] && [ -x $i ]; then logwrapper $i; fi; done;"
   class main
   oneshot
Which is pretty cool.
The Following 2 Users Say Thank You to osm0sis For This Useful Post: [ View ]
7th January 2015, 06:42 PM |#95  
Captain_Throwback's Avatar
Senior Member
Flag The Nothing
Thanks Meter: 22,611
 
10
Donate to Me
More
Quote:
Originally Posted by osm0sis

Agreed, I was just suggesting that using logwrapper like the enhanced init.d you pointed me to would allow for ramdisk init.d support without having to add busybox, other binaries, or anything to system.

Hypothetically:

Code:
# Execute files in /system/etc/init.d before booting
service run-parts /system/bin/sh -c "for i in `find /system/etc/init.d -type f | sort`; do if [ ! -d $i ] && [ -x $i ]; then logwrapper $i; fi; done;"
   class main
   oneshot
Which is pretty cool.

Really? logwrapper processes the init.d folder? Never heard of that before. I'm going to have to try that now.

Why are you running it with main, if I might ask?
7th January 2015, 06:46 PM |#96  
osm0sis's Avatar
OP Recognized Developer / Recognized Contributor
Flag Halifax
Thanks Meter: 29,906
 
Donate to Me
More
Quote:
Originally Posted by Captain_Throwback

Really? logwrapper processes the init.d folder? Never heard of that before. I'm going to have to try that now.

Why are you running it with main, if I might ask?

logwrapper doesn't on its own, but by looping the contents of init.d out to it from find it should. That's what the enhanced sysinit script you linked does, and I just distilled it down to its core run-parts functionality so I could potentially one-line it as above.

No particular reason I use main I guess, I just always have, and it seems to take effect just before the bootanimation which is when I like my init.d scripts firing.
The Following User Says Thank You to osm0sis For This Useful Post: [ View ]
7th January 2015, 06:50 PM |#97  
Captain_Throwback's Avatar
Senior Member
Flag The Nothing
Thanks Meter: 22,611
 
10
Donate to Me
More
Quote:
Originally Posted by osm0sis

logwrapper doesn't on its own, but by looping the contents of init.d out to it from find it should.

No particular reason I use main I guess, I just always have, and it seems to take effect just before the bootanimation which is when I like my init.d scripts firing.

The problem with using main rather than late start is that on newer OS versions (like Lollipop), you may end up running init.d before data is decrypted. class late_start guarantees that data will be available if any scripts need it. It also may be necessary to specify user and group as root to make sure the scripts run with the proper permissions - it seems SELinux when in enforcing mode may prevent them from running unless specified.

I'm going to try your script right now and see if it works (with the changes I just mentioned).
The Following User Says Thank You to Captain_Throwback For This Useful Post: [ View ] Gift Captain_Throwback Ad-Free
7th January 2015, 07:28 PM |#98  
osm0sis's Avatar
OP Recognized Developer / Recognized Contributor
Flag Halifax
Thanks Meter: 29,906
 
Donate to Me
More
New commit with the recent requests...

AnyKernel 2.0: shell update-binary, new features
- rewrite update-script as a shell script update-binary replacement, making the zip architecture independent (tools are still dependent)
- add fall-back to included zImage to allow for ramdisk-only injections

https://github.com/osm0sis/AnyKernel...c50ed836cace4f

Ramdisk-only injections are a cool idea for adding ramdisk features (init.d, Synapse, etc.) without having to switch the kernel zImage. Also, no more need to have a custom compiled update-binary anymore, so the zip itself is now good for all Android architectures; only the tools (mkbootimg and unpackbootimg) need to be compiled for the target architecture now.

Quote:
Originally Posted by osm0sis

Pull Requests for non-standard device support - that'll include Samsung's old headerless images, Samsung's new broken-standard-headered images, Sony's ELF images, MTK devices, and any device that uses MTD instead of EMMC. Someone's already submitted one, and it occurred to me that what would be cool is to abuse the way the Pull Request system works and leave it open, so that way anyone wanting to fork the repo can go ahead and then pull in the request for the non-standard device they may want it for as well. So everyone feel free to fork for support and leave me those requests so we can indirectly support as many devices as possible without complicating the standards supporting devices.

The Following 6 Users Say Thank You to osm0sis For This Useful Post: [ View ]
8th January 2015, 06:16 AM |#99  
ak's Avatar
Senior Member
Flag Ak Land Valley
Thanks Meter: 69,895
 
Donate to Me
More
Quote:
Originally Posted by osm0sis

New commit with the recent requests...

AnyKernel 2.0: shell update-binary, new features
- rewrite update-script as a shell script update-binary replacement, making the zip architecture independent (tools are still dependent)
- add fall-back to included zImage to allow for ramdisk-only injections

https://github.com/osm0sis/AnyKernel...c50ed836cace4f

Ramdisk-only injections are a cool idea for adding ramdisk features (init.d, Synapse, etc.) without having to switch the kernel zImage. Also, no more need to have a custom compiled update-binary anymore, so the zip itself is now good for all Android architectures; only the tools (mkbootimg and unpackbootimg) need to be compiled for the target architecture now.



Sent from my A0001
20th January 2015, 01:52 AM |#100  
Captain_Throwback's Avatar
Senior Member
Flag The Nothing
Thanks Meter: 22,611
 
10
Donate to Me
More
Quote:
Originally Posted by osm0sis

Agreed, I was just suggesting that using logwrapper like the enhanced init.d you pointed me to would allow for ramdisk init.d support without having to add busybox, other binaries, or anything to system.

Hypothetically:

Code:
# Execute files in /system/etc/init.d before booting
service run-parts /system/bin/sh -c "for i in `find /system/etc/init.d -type f | sort`; do if [ ! -d $i ] && [ -x $i ]; then logwrapper $i; fi; done;"
   class main
   oneshot
Which is pretty cool.

So I've tried this, and it seems to be working okay. I think it might be good to add as an option .
The Following User Says Thank You to Captain_Throwback For This Useful Post: [ View ] Gift Captain_Throwback Ad-Free
20th January 2015, 08:05 AM |#101  
Senior Member
Flag Louvain-la-Neuve, Belgium
Thanks Meter: 1,681
 
Donate to Me
More
Hello just wanted some advises from you guys.

Remove live seems to remove first occurrence but it doesn't remove every linrd.

So I thought a simple solution would be to loop until no occurres lef number. I wanted to show you my solution and get sme feedback whether it's it's good or not

#remove__all_lines

remove_all_lines() {

If [ ! -z "$(grep "$2" $1)" ]; then

Sed -i "/${2}/d" $1;

fi;

}

Ty



Sent from my Xiaomi MI2s
The Following User Says Thank You to Khaon For This Useful Post: [ View ] Gift Khaon Ad-Free
Post Reply Subscribe to Thread

Tags
anykernel, flashable zip, kernel, scripting, template

Guest Quick Reply (no urls or BBcode)
Message:
Previous Thread Next Thread
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes