-
Notifications
You must be signed in to change notification settings - Fork 3
Initramfs overlay
See this file to know exactly how it works https://github.com/mkaluza/Samsung_STE_Kernel/blob/3.0.101/usr/u8500_initramfs_files/init
But in plain english it goes like this:
- check if we should boot android or recovery and select either boot.cpio or recovery.cpio internal image
- extract internal archive from #1 into /
- check /efs dir for boot.cpio.gz or recovery.cpio.gz (this is gzipped in contrast to the internal one!) and extract it to / with overwriting (cpio -i -u)
- regardless of #1 result extract internal lvm.cpio archive if it exists
- check for /etc/lvm.cpio**.gz** and extract it to / overwriting any existing files 5.(TODO for r5.2) create a more generic interface to load /efs/initramfs/*.cpio.gz
- check for /stage1/extra.sh file and run it if it exists
- remove /stage1 dir and run /init
Thanks to the boot sequence described above you can modify initramfs without actually flashing it - it's quite useful for testing:)
To change something in android initramfs, add additional/modified files to a boot.cpio.gz archive (cd my_dir; find . | cpio -o -Hnewc | gzip -9 > ../boot.cpio.gz
) and place the archive on the /efs partition. There's not much free space there, but for ramdisks it should be enough (if it's too small for you, you're probably doing something wrong).
The image will be loaded at next reboot.
Similarly, creating recovery.cpio.gz will modify recovery ramdisk only.
Avoid modifying both images at once - if something goes wrong, you won't be able to boot your phone. If only one image is modified, you can start the other one and remove the problematic archive.
Original ramdisks are here: https://github.com/mkaluza/ste-ramdisk-vanir
As this ramdisk is for 4.4, it probably won't work on older/other versions. But if you can copy the original ramdisk's contents into boot.cpio.gz archive and place it in /efs, it should boot (but no promises - I didn't test it). Success/failure reports are welcome.
Recovery should always boot as it is rom-independent, so if something goes wrong, you can try and fix it from there (or flash original kernel).
It can be used to allow using f2fs for (probably) any paritition (remember to include f2fs module there!), but since there are many things that can go wrong during and after conversion to f2fs, I won't describe the procedure in details here. If the description above doesn's spark any ideas in your head, you probably shouldn't touch f2fs as it'll bite you sooner than later.
If you try anyway, don't forget to check /sys/block/mmcblk0/device/preferred_erase_size and adjust -s accordingly (segment is 2MB in size).
TODO