# GearBoot Documentation

GearBoot is a very simple program which can run executables during boot dynamically.
GearBoot supports four different boot stages.

• init
• post-fs
• post-fs-data
• boot-post
• boot-comp

GearBoot is very lightweight and superfast. It assigns each of the executables with a unique PID.

The logfile is /gearlock/tmp/gearboot.log

During GearBoot runtime PATH variable is set to:

/gearlock/bin:/sbin:/bin:/system/bin:/system/xbin:/system/vendor/bin

If GearLock came pre-installed in your system then gearboot dir can be found at /system/ghome
If it was a manual installation then it should be at /data/ghome

For most developers boot-comp stage should be fine and shouldn't mess with other stages unless you know what you're doing!

Use the custom-core package to work with gearboot scripts

To be honest, the first three stages ( post-fs post-fs-data and boot-post ) are passed real quick but there are some key changes in between.

Below I will try to explain what and how each of the gearboot stages that matter.

This is basically valid before you see the early console-tty blinking after grub has loaded your kernel and is about to switch on the secondary-ramdisk. In this stage android-system won't be running or active. Not a good idea to think of hooking into it unless you know what you're doing.

There are actually a few more *early stages before post-fs to be completed when android-x86 switches to the secondary ramdisk. Now you might be wondering why don't we just hook those stages also ?

In simple words, it's literally unnecessary and not really a good thing to do. Even hacking into something over the post-fs stage also seems quite rare though.

As much I can understand, this stage can be marked when you get to see the OS hostname blinking in the early tty screen (command line). This is also two steps before you see the bootanimation to be appearing.

This is obviously after post-fs stage. During this stage, build.prop and most of the system modules are already loaded. The bootanimation comes after this stage.

This is the beginning of bootanimation and is valid till android-x86 enter the graphical interface.

This is after bootanimation then you see something like Android is loading... in graphical interface.
To be noted that this is basically the final stage and no more stages are to come after this.
For most cases it's suggested to target this stage for your executable.

gearboot.log is present in /gearlock/tmp which holds the records of what executables were run during each boot-stage. So if you want to write something over your executable name in the log then you can use write_gblog in your gearboot-executable.

So, let's say my-cool-program3 was your gearboot-executable and then gearboot.log was like

# Start of boot-post stage @ Wed XYZ
  123456:12:44  :  boot-post  :  my-cool-program
  123456:12:45  :  boot-post  :  my-cool-program2
  

# Start of boot-comp stage @ Wed XYZ
  123456:12:47  :  boot-comp  :  my-cool-program3
  123456:12:48  :  boot-comp  :  my-cool-program4

Now, if you do this in my-cool-program3 (bash):

write_gblog "Opps, something wrong"

gearboot.log will be like:

# Start of boot-post stage @ Wed XYZ
  123456:12:44  :  boot-post  :  my-cool-program
  123456:12:45  :  boot-post  :  my-cool-program2
  

# Start of boot-comp stage @ Wed XYZ
  123456:12:47  :  boot-comp  :  my-cool-program3 : Opps, something wrong
  123456:12:48  :  boot-comp  :  my-cool-program4

If you want to re-execute the boot executables without rebooting as a user then you can do it easily. (Not recommended)

From gearboot --help

Usage:   gearboot <boot-stage>

Example: gearboot s2 # For executing post-fs-data executables

<Boot-Stages>

    s1 : post-fs
    s2 : post-fs-data
    s3 : boot-post
    s4 : boot-comp

• GearProp can be useful while changing props during boot
• Check GearBoot Executables section in GetStarted page
• Take a look at environment variables
• Must check out GearLock Dev Utilities