Llama Sweet Kernel Tweaks

[kessaras]

Hi @kessaras, thanks for your work!

I have a quick question: my AOSP-based rom already has a script called "90userinit" in the init.d folder, is it still ok to use your scripts?

yeap. 90userinit is from superuser

 

[marn3us]

yeap. 90userinit is from superuser

thanks!

I have tried using your 90balanced tweak but after boot it doesn't do anything, kernel remains at its stock values

I have tried doing the commands in terminal but it says "mount: '/system' not in /proc/mounts" and fails.

So i tried using my file manager and i did the following: copy 90balanced into init.d, set 755 permissions and root:shell but after reboot nothing happens. Could you please help me?

 

[kessaras]

thanks!

I have tried using your 90balanced tweak but after boot it doesn't do anything, kernel remains at its stock values

I have tried doing the commands in terminal but it says "mount: '/system' not in /proc/mounts" and fails.

So i tried using my file manager and i did the following: copy 90balanced into init.d, set 755 permissions and root:shell but after reboot nothing happens. Could you please help me?

Clean flash.
Something doesn't let the kernel execute init.d on boot.
It's like you don't have init.d support.
Clean flash and flash busybox too. If the rom doesn't have busybox pre-installed, you definitely need it.
Also disable mount superuser separately in settings. Flashing supersu sometimes interrupts init.d but enables you to use the su.d.
/system/su.d is like init.d. it executes scripts on boot.

 

[lectricas]

I have 90userinit and 00banner in my initD folder. Is it ok? Put 90less in init.d folder and reboot. Don't know for sure if the script was installed. Also, was unable to

mount -o rw remount /system

it says that /system not found.
other commands executed just fine

 

[kessaras]

I have 90userinit and 00banner in my initD folder. Is it ok? Put 90less in init.d folder and reboot. Don't know for sure if the script was installed. Also, was unable to

it says that /system not found.
other commands executed just fine

Install busybox and use the same command with busybox in front. Busybox mount -o....
Most roms besides RR don't have busybox pre-installed

 

[Jirrick]

Hi, I'm having some troubles on latest Lineage weekly and latest Llama kernel with busybox installed and root set to adb only:

After I put the 90less script in init.d folder it seems to properly execute only some lines. I guess that scrpit can change /sys/* values, but cant change /proc/sys/* values as demonstrated by example from adb shell:

cat /proc/sys/net/ipv4/tcp_congestion_control
cubic
cat /proc/sys/vm/swappiness
60
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
alucard

When I run the script from root adb shell manually, the /proc/sys/* values get changed:

cat /proc/sys/net/ipv4/tcp_congestion_control
westwood
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
alucard
cat /proc/sys/vm/swappiness
0

But also some errors pops up (28C6-E3F8 is my sdcard):

h815:/system/etc/init.d # ./90less
./90less
./90less[46]: can't create /sys/devices/system/cpu/cpu4/cpufreq/scaling_governor: No such file or directory
./90less[48]: can't create /sys/devices/system/cpu/cpu4/cpufreq/scaling_max_freq: No such file or directory
mount: mounting /mnt/media_rw/28C6-E3F8 on /mnt/runtime/write/28C6-E3F8 failed: Invalid argument

 

[kessaras]

Hi, I'm having some troubles on latest Lineage weekly and latest Llama kernel with busybox installed and root set to adb only:

After I put the 90less script in init.d folder it seems to properly execute only some lines. I guess that scrpit can change /sys/* values, but cant change /proc/sys/* values as demonstrated by example from adb shell:
When I run the script from root adb shell manually, the /proc/sys/* values get changed:

cat /proc/sys/net/ipv4/tcp_congestion_control
westwood
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
alucard
cat /proc/sys/vm/swappiness
0

But also some errors pops up (28C6-E3F8 is my sdcard):

h815:/system/etc/init.d # ./90less
./90less
./90less[46]: can't create /sys/devices/system/cpu/cpu4/cpufreq/scaling_governor: No such file or directory
./90less[48]: can't create /sys/devices/system/cpu/cpu4/cpufreq/scaling_max_freq: No such file or directory
mount: mounting /mnt/media_rw/28C6-E3F8 on /mnt/runtime/write/28C6-E3F8 failed: Invalid argument

init.d executes scripts as root. the changes are done on boot.
the last one i don't get it. you have disabled the big cores ? ill just add a command to enable the big cores before it sets those parameters. it wont affect the hotplug.
you will see the update tomorrow.

EDIT:
update is there. see changelog.
As for the mount commands for media, it won't work on all devices and sd cards. The remount with those flags will only work on stock formats. Internal partitions must be EXT4, F2FS cannot get those flags and external sdcard must be a specific format VFAT.
I will not change the defaults formats with my script, that will cause problems. The format must remain the same as it was on boot.

 

[Jirrick]

init.d executes scripts as root. the changes are done on boot.
the last one i don't get it. you have disabled the big cores ? ill just add a command to enable the big cores before it sets those parameters. it wont affect the hotplug.
you will see the update tomorrow.

EDIT:
update is there. see changelog.
As for the mount commands for media, it won't work on all devices and sd cards. The remount with those flags will only work on stock formats. Internal partitions must be EXT4, F2FS cannot get those flags and external sdcard must be a specific format VFAT.
I will not change the defaults formats with my script, that will cause problems. The format must remain the same as it was on boot.

Thank you for the fix. I can see that the cpu core error on my second (manual) script execution was caused by them being offline after the first run.

But my first issue is still present. I've done a little test: Changed permission to 600 and verified the script was not run (checked that governor was interactive), then changed the permissions to 700 to ensure that the script was executed as root (checked governor alucard). However, traffic congestion and swappiness were still default (cubic and 60) rather than tweaked (westwood and 0). Kind of weird behavior...

 

[Jirrick]

I couldn't find the log for init.d scripts so I've enhanced the script a bit in order to be able to view it in logcat. Found out that about half of commads are failing...

Both scripts and results are here https://gist.github.com/jirrick/62365c4ac8ee5c0b51245c06d2f2ef5e hope it helps you because this is the point where my knowledge ends...

EDIT: I've added the output of script when run from root adb shell into the gist. The execution log is very different. It seems like the structure isn't initialized at boot time...

 

[kessaras]

I couldn't find the log for init.d scripts so I've enhanced the script a bit in order to be able to view it in logcat. Found out that about half of commads are failing...

Both scripts and results are here https://gist.github.com/jirrick/62365c4ac8ee5c0b51245c06d2f2ef5e hope it helps you because this is the point where my knowledge ends...

EDIT: I've added the output of script when run from root adb shell into the gist. The execution log is very different. It seems like the structure isn't initialized at boot time...

That helps. I'll check it tomorrow that I have time . Wait for update on Sunday

EDIT:
i don't see any problem there. Only nr_requests didn't get set. Now they will.

 

[Jirrick]

That helps. I'll check it tomorrow that I have time . Wait for update on Sunday

EDIT:
i don't see any problem there. Only nr_requests didn't get set. Now they will.

It executes almost flawlessly when run manually after completing boot from adb shell (as seen in output2), but what about the first automatic execution from master init procedure (the first output) which is just failing?

I understand that this can be dependent on ROM+kernel version combination. Have you tried put my version of the script in your init.d folder and then use the logcat command to get result of your execution?

 

[kessaras]

It executes almost flawlessly when run manually after completing boot from adb shell (as seen in output2), but what about the first automatic execution from master init procedure (the first output) which is just failing?

I understand that this can be dependent on ROM+kernel version combination. Have you tried put my version of the script in your init.d folder and then use the logcat command to get result of your execution?

its not rom ernel combination. its clearly kernel.
llama has init.d support. the only thing you have to do is follow the op and set the right permissions and owner:group.
if those are not correct , it won't execute .
the only thing that maybe interfere with init.d but rarely is the systemless su from chainfire not magisk.

did you double check that you have 755 permissions to the init.d folder and scripts ?
root:root on init.d folder and root:shell on the script ?
If everything is correct there is just no way to not execute.

 

[Jirrick]

its not rom ernel combination. its clearly kernel.
llama has init.d support. the only thing you have to do is follow the op and set the right permissions and owner:group.
if those are not correct , it won't execute .
the only thing that maybe interfere with init.d but rarely is the systemless su from chainfire not magisk.

did you double check that you have 755 permissions to the init.d folder and scripts ?
root:root on init.d folder and root:shell on the script ?
If everything is correct there is just no way to not execute.

I feel like we don't understand each other. The script itself in init.d folder gets executed properly, no issues there. The permissions and ownership doesnt really matter as long as root have execute permissions, tried succesfully both with 755 (-rwxr-xr-x) and 700 (-rwx------). If the permissions were wrong I wouldn't have any log from that script, right?

The problem is that some particular commands written in the script just doesn't work at the time of boot (but gets executed properly afterwards).
Take a look at this command:

for file in /proc/sys/net/ipv6/conf/*/disable_ipv6; do echo 1 > $file; done

and respective entries in my two logcat captures:

CASE 1: When run automatically by OS from init.d folder, the FOR loop is not able to expand the asterisk (probably the virtual paths arent initilized yet, or something else is broken) and the command fails.

ERROR: echo 1 > /proc/sys/net/ipv6/conf/*/disable_ipv6

CASE 2: When I run the script manually after full boot, the asterisk in FOR loop gets properly expanded and the same code produces this output:

PASSED: echo 1 > /proc/sys/net/ipv6/conf/all/disable_ipv6
PASSED: echo 1 > /proc/sys/net/ipv6/conf/default/disable_ipv6
PASSED: echo 1 > /proc/sys/net/ipv6/conf/dummy0/disable_ipv6
PASSED: echo 1 > /proc/sys/net/ipv6/conf/lo/disable_ipv6
PASSED: echo 1 > /proc/sys/net/ipv6/conf/r_rmnet_data0/disable_ipv6
PASSED: echo 1 > /proc/sys/net/ipv6/conf/r_rmnet_data1/disable_ipv6
PASSED: echo 1 > /proc/sys/net/ipv6/conf/r_rmnet_data2/disable_ipv6
PASSED: echo 1 > /proc/sys/net/ipv6/conf/r_rmnet_data3/disable_ipv6
PASSED: echo 1 > /proc/sys/net/ipv6/conf/r_rmnet_data4/disable_ipv6
PASSED: echo 1 > /proc/sys/net/ipv6/conf/r_rmnet_data5/disable_ipv6
PASSED: echo 1 > /proc/sys/net/ipv6/conf/r_rmnet_data6/disable_ipv6
PASSED: echo 1 > /proc/sys/net/ipv6/conf/r_rmnet_data7/disable_ipv6
PASSED: echo 1 > /proc/sys/net/ipv6/conf/r_rmnet_data8/disable_ipv6
PASSED: echo 1 > /proc/sys/net/ipv6/conf/rmnet_data0/disable_ipv6
PASSED: echo 1 > /proc/sys/net/ipv6/conf/rmnet_data1/disable_ipv6
PASSED: echo 1 > /proc/sys/net/ipv6/conf/rmnet_data2/disable_ipv6
PASSED: echo 1 > /proc/sys/net/ipv6/conf/rmnet_data3/disable_ipv6
PASSED: echo 1 > /proc/sys/net/ipv6/conf/rmnet_data4/disable_ipv6
PASSED: echo 1 > /proc/sys/net/ipv6/conf/rmnet_data5/disable_ipv6
PASSED: echo 1 > /proc/sys/net/ipv6/conf/rmnet_data6/disable_ipv6
PASSED: echo 1 > /proc/sys/net/ipv6/conf/rmnet_data7/disable_ipv6
PASSED: echo 1 > /proc/sys/net/ipv6/conf/rmnet_ipa0/disable_ipv6
PASSED: echo 1 > /proc/sys/net/ipv6/conf/sit0/disable_ipv6
PASSED: echo 1 > /proc/sys/net/ipv6/conf/teql0/disable_ipv6
PASSED: echo 1 > /proc/sys/net/ipv6/conf/wlan0/disable_ipv6

Are we on the same page? Some commands in the script behave differently at boot-time and after complete boot, that's all.

 

[kessaras]

I feel like we don't understand each other. The script itself in init.d folder gets executed properly, no issues there. The permissions and ownership doesnt really matter as long as root have execute permissions, tried succesfully both with 755 (-rwxr-xr-x) and 700 (-rwx------). If the permissions were wrong I wouldn't have any log from that script, right?

it does matter. its the same as su.d. su.d needs 700 or it won't execute. Same goes for init.d.
2nd even if you show me the bug , since i can't reproduce it and everything works here,i can't really fix it. It's a problem on your side and maybe anyone who has done the same mistake whichever it is.
yesterday too i updated my rom since i had to update for a long time and the script still works because its kernel related and the kernel doesn't have any change since months.

The easiest way to test if you did everything right is to open a terminal and do :

. ./system/etc/init.d/<script name>

if permissions and owner:group are right you will see it execute normally and set everything as it should.
if something gives error it will say "access denied", because those folders don't originally have write access unless we give write access.
so if you get access denied , ok thats something i can fix, but if some commands don't set on boot but get set later..... thats something i can't fix.
If you didn't do anything wrong, which propably you did, you must report it to genesix to take a look at it. if you are right , he will find the error in his kernel, if you are wrong he won't find any error to fix.

~EDIT: only genesix can fix it. we don't have access in Llama github and we don't know when it's the last time he synced. Llama is only managed from genesix.

 

[kessaras]

From now on, those who flash llama sweet kernel, have magisk flashable zip ready for flashing too, otherwise you won't have root.

 

[kessaras]

-added better mount point flags for f2fs partitions.
Only one of the mount commands will work on your device.
If you use f2fs , then only the flags for f2fs will be added.
If you use ext4 , then only the flags for ext4 will be added.
The other command will just fail, you can ignore it.

-i changed the way the mount points get set, now you don't need busybox if you don't want to.

-bigger timer rate for interactive governor for the balanced tweak, balanced can conserve battery now too.

*Soon ill add one script for all stock kernels. With proper tweaking we don't really need to flash anything. Stock is great too if we know what to do.
It will be added in su/su.d to work with systemless root or in a module in magisk.

 

[kessaras]

Added instructions in the op too.
Llama Sweet Kernel (lineage based only. for stock i haven't test it yet)
- Those that use supersu root method, they can use alternative path to /su/su.d/ to execute their scripts. Set permissions to 700 and ownership to root:root for both the folder and file.
- Those of you that use magisk as a root method, you can also use alternative /magisk/.core/service.d or /magisk/.core/post-fs-data.d. The difference is in the execution time. Service.d will execute a little bit later during boot, but the result is the same. My scripts execution times are best for service.d, in post-fs-data.d it will execute too soon and the kernel will later set the default values so you won't tweak anything.

Lastly in a few days ill make one good script for both stock lineage kernel and stock based LG kernel. Using magisk or supersu is now possible to do everything init.d does without the need of init.d support.

 

[kessaras]

Even higher timer rates and downclocking a bit the big CPU cores.
Higher touch responsiveness to decrease lag.

changelog

 

[raptorddd]

Added instructions in the op too.
Llama Sweet Kernel (lineage based only. for stock i haven't test it yet)
- Those that use supersu root method, they can use alternative path to /su/su.d/ to execute their scripts. Set permissions to 700 and ownership to root:root for both the folder and file.
- Those of you that use magisk as a root method, you can also use alternative /magisk/.core/service.d or /magisk/.core/post-fs-data.d. The difference is in the execution time. Service.d will execute a little bit later during boot, but the result is the same. My scripts execution times are best for service.d, in post-fs-data.d it will execute too soon and the kernel will later set the default values so you won't tweak anything.

Lastly in a few days ill make one good script for both stock lineage kernel and stock based LG kernel. Using magisk or supersu is now possible to do everything init.d does without the need of init.d support.

i have latest magisk. stock baseed. so this zip in 2nd post shopuld work on stock based and any kernel.?
question is theres no magisk path you mention.? what create it.?
does this disables cores or just changes frequencies.? thanks

 

[kessaras]

i have latest magisk. stock baseed. so this zip in 2nd post shopuld work on stock based and any kernel.?
question is theres no magisk path you mention.? what create it.?
does this disables cores or just changes frequencies.? thanks

Yeah script from the 2nd post is 100% working on stock and on any stock based and even on lineage stock.
The path is there if you flashed magisk and installed magisk manager. Magisk can't work without it.
Check again.
Did you install magisk manager from play store too ?
Reboot and check again.