When you put a kernel from one rom to another, you have to keep in mind the following:
Most custom roms rename the secondary init.cm.rc file with their custom name. That file is called by the main init.rc during boot and is responsible for several vital functions, such as sysinit/init.d; cpu frequencies; ril, dalvik and adb functions. So, if you put DU kernel in CM rom, the main init would call for init.cm.rc, but your boot image has no such file. Instead, you have init.du.rc. Your device will still boot, but permissions won't be set, services won't start and some functions won't work.
The proper way to change kernels is to decompile the new boot image and replace ramdisk,cpio with that from your rom where init.rc calls the proper file.
Related
Hello,
wich are the components from an android on a HTC HD2.
There are different types like Kernel, Moduls, etc...
But where can I find it and understand how they work together.
What I found:
zImage includes the Kernel for the complete system
startup.txt includes the parameter how to start the system
CLRCAD.EXE is used for the sound in android
HaRet.exe is used to start/boot the android
Is this correct? What I can't assign is:
the ROM on which the release based - can I see the files on my SD or is this included in other files?
the modules like WiFi and so on (maybe here /system/lib/modules)?
The next questions would be:
Could I use a new kernel with an existing system (Only with changing the existing zImage-File and unsing a modified startup.txt)?
Could I update seperate moduls without install new system? (new version for WiFi or GPS or else)
The kernel is the core of any linux based os, some base drivers are included in kernel and other linkes as modules, if you install a new kernel that don't need any external module you can simple copy zImage, if new kernel need new modules you have to copy into /system/lib/modules directory. Modules are related to kernel you cannot update modules without apdate kernel.
Hi,
When you want to perform some scripts at boot-time, there is two possibilities :
- modify init.rc, but it requires to reflashing the rootfs image (modification in / does not hold after a reboot),
- using an android app like script manager, which will load your scripts at java/dalvik platform boot-time.
I've managed to find a way based on activating tf-daemon, which is a script called by the asus/ventana initrc, but disabled at boot-time. Basically, we're re-enabling this daemon by setting the property tf.enable to yes, and then creating a script called tf-daemon and put it in /system/bin. Since this script is called by init.ventana.rc as root, you can put whatever you want inside this script.
I don't know what is the original purpose of this daemon, but probably it's used by the asus team for internal and debugging purpose.
Be aware that in the next firmware update, this possibility could disappear.Let's hope the asus team does not read this post. Or at least they could allow power users to call custom scripts at boot-time.
As a case study, you will find as attachment a script for loading nfs modules at boot-time.
PS: damn, can't upload. Here is a temporary link : http://dl.free.fr/hwTZ0YBq2
Untar the archive, then su, and sh install.sh
At reboot, you should have nfs modules loaded.
Good find:
I gave this a try just to load a couple of my own modules that work with the kernel I'm using. Works fine -- Thanks, -
Another method is to make a script and just call it in the init.rc. After a firmware update you only have to add the "exec myscript.sh" line to init.rc. I personally prefer this method because it allows me to control when the script is executed, whereas the tf-daemon method is always executed at the same point(AFAIK). Good research though, always nice to know all the boot calls.
Modifying the init.rc was my first shot, but the problem is that init.rc lies in ramdisk. So when trying to modify, the modification does not hold
after reboot. So a real modification involves to reflash rootfs with nvflash, too much hassle for me. The method I'm providing is for lazy ones. ;-)
nice find, but the link is dead, could you please provide a new link for the script?
also, how do I load nfs module for there is none under /lib/modules, compile the kernel myself?
Smoothest Rom recently got a new update with a better new kernel. However; if you are familiar with it Smoothest Rom, you should know that smoothest rom gives you the option of choosing your own kernel. So If I were to update Smoothest Rom with a new kernel, would I have to factory reset before flashing? Or what would I have to do?
Thank you!
TL;DR No need to factory reset. YMMV, so take a complete Nandroid backup before you begin. You won't be sorry for doing that.
The most compatible kernels are distributed as just the kernel zImage file, and rely on the installer to pick apart the existing boot image (kernel+ramdisk), and then re-assemble it back into a boot image (new_kernel+old_ramdisk) for flashing. Almost nothing changes - except perhaps features available in the kernel.
For better or for worse though, some kernels are distributed as both a kernel and a new ramdisk - a complete boot image. This is done because the dev wants to alter the userspace activity taking place in the early phase of booting; things like setting default values by writing tweak parameters into the /sys filesystem, or perhaps setting a property (e.g. in /default.prop), or plumbing a new device node into the /dev tree, launching oneshot services, or making sure that the init process launches scripts in /system/etc/init.d as the very last thing it does.
That means that any dependency that a given ROM (files in /system) has on activities taking place as a result of dev customizations placed into the ramdisk are at risk of being snuffed out when you flash a full boot image for a "different kernel".
Moral of the story? Take a backup. If stuff goes to ell in a handbasket, you can go back to where you were.
Hi, I'm trying various kernels on my rom.
Therefore I'd like to backup my existing kernel.
I know TWRP can easily do this.
However for information I'd like to know manual adb method, or terminal commands.
Or is there a Zip file which I can run to automate the process
why not just keep the kernel zip file in your storage?
as a hobby, i test kernels, trinity kernel to be exact. i probably have 20-30 kernels in my storage at all times. when im want to run my favorite again, i just reflash it. i cant imagine why id want to back up a kernel.
MyMinds_Kernel_Swap
===================
Based on AnyKernel, but pretty much rebuilt in every way so that it will actually work. So, many thanks to Koush for the idea.
The Idea and What It Does...
=======================
Some but not all of this script has been snippets here and there from ArchiKitchen and DSIXDA Kitchen.
This has allowed me to formulate a zip as such without the need to technically build from scratch saving me LOADS OF HOURS.
It currently uses my static compiled mkbootimg, unmkbootimg, and mkbootfs binaries to allow editing, and rebuilding of the boot.img.
Some serious modifications were made to get this to work successfully with MUCH DEBUGGING. If you change something and it breaks another function then that is on you!
# IT IS CURRENTLY STABLE!
1. It will pull your current boot.img using dd.
2. It will search for the Android! header in the boot.img and remove the unnecessary junk before it if needed to.
3. It will split the boot.img in to the kernel and ramdisk.
4. It will unpack the contents inside the ramdisk.
5. It will modify the default.prop file giving you insecure ADB. If you already have it then this will not affect you.
6. It will modify the init.rc file to give support for init.d. If you already have it then this will not affect you.
7. It will write to sysinit and install-recovery.sh for the completion of init.d support. If already done, then this will not affect you.
8. It will make the init.d folder under /system/etc on your device with required permissions.
9. It will place an init.d script to test to see if init.d is fully working. If it works, you will find a file called, HAS_INIT, located in the /dev directory of your device.
10. It will swap out the original kernel with a new prebuilt kernel upon rebuilding the new boot.img
11. It will repack you a new ramdisk using mkbootfs to be applied to your new boot.img upon rebuilding it.
12. It will remove your old modules and push your new modules that came with your new prebuilt kernel.
13. It will write your new boot.img to your boot partition using dd.
14. Hopefully, more to come!
MAKE SURE YOU CHANGE...
=======================
"$BOOT_PARTITION" ACCORDING TO YOUR DEVICE BEFORE USING THIS SCRIPT!!!!!!
How to use it...
==============
1. Place your prebuilt kernel in the prebuilt folder and insure it is named, zImage.
2. Place kernel modules in the modules folder.
3. Zip, and flash in TWRP recovery.
If you have any suggestions then let me know. My ears are open to them.
https://github.com/ModdingMyMind/MyMinds_Kernel_Swap
Sent from my C525c using Tapatalk