gbOS86

How it works

From the moment you press the power button to Google's Android init taking over.

UEFI firmware
 └─ EFI/BOOT/BOOTX64.EFI      kernel (android 6.18 + patches) with stage0 built in as its initramfs
     └─ stage0 (busybox shell script)
         ├─ finds the gbos volume: the USB stick (FAT label GBOS) or the NVMe install (GBOSSYS)
         ├─ opens the boot menu (stick only): live / install-or-update / boot installed
         ├─ loads the graphics driver, starts logging to gbos/logs/boot-N/
         ├─ MODE=install: runs gbos/install.sh, never boots Android
         ├─ mounts super.img's read-only erofs partitions (system, vendor, product, ...) with loop + dm-linear
         ├─ runs gbos/hook.sh: every Android-side workaround, plus hardware detection
         ├─ mounts /data and /metadata (NVMe ext4, or RAM for a live boot)
         └─ switch_root into /system/bin/init (Google's Android init, unmodified)

One kernel image, one volume

The firmware boots BOOTX64.EFI from the EFI partition. Everything else lives on the gbos volume: a FAT32 partition holding gbos/ (the Android images, scripts, patched libraries, firmware, kernel modules, audio configs, installer tools, logs). On the stick it is labelled GBOS; on an installed laptop it is the GBOSSYS partition of the NVMe drive.

Why most behaviour is in scripts, not the kernel

stage0 and hook.sh are plain shell scripts on the volume. The workarounds for Google's missing hardware, the driver loading and the audio configuration can be changed without rebuilding the kernel: edit a file on the stick, boot, look at the log. Only the CPU emulator, the graphics patches and the built-in drivers need a kernel build.

The Android partitions

super.img is Google's dynamic-partition image (system, vendor, product, system_ext and the two dlkm partitions, slot A) rebuilt to stay under FAT32's 4 GB file limit. stage0 attaches it as a loop device and maps each logical partition with dm-linear, so Google's own partition layout is used as is. Bind mounts then replace individual files (patched libraries, configs, a hidden service declaration) without altering the images.

The boot menu

With the stick inserted, a 10 second menu offers 1 live from USB, 2 install or update on the internal SSD, 3 boot the installed system (the default when an install exists, otherwise 1). The MODE setting in gbos.cfg can skip the menu.

Installed layout (NVMe)

GBOS_EFI512 MB, the EFI system partition with BOOTX64.EFI.
GBOSSYS8 GB FAT32: the gbos/ files and the per-boot logs.
GBOS_META64 MB ext4: Android's /metadata.
GBOS_DATAthe rest, ext4: Android's /data (apps, accounts, files).

Something wrong or missing? Tell us or ask in the forum.