MayteraOS Deployment Notes

This page is a high-level summary of how MayteraOS builds are deployed to test machines; the full internal runbook is maintained internally.

Boot flow

MayteraOS boots via UEFI. The firmware loads the bootloader (BOOTX64.EFI) from a FAT32 EFI System Partition, and the bootloader in turn loads the kernel image (/boot/kernel.elf) from the same partition. Deploying a new build therefore amounts to copying a freshly built kernel image onto the boot partition of a test machine or VM, along with any required assets.

Boot splash images

The boot experience uses two splash stages, both driven by a single bitmap (BOOT.BMP) stored at the root of the boot partition:

• First splash: a simple spinner shown during early boot (gfx_boot_simple)
• Second splash: a verbose boot-log display (gfx_boot_splash) that renders the same image Both stages intentionally use the same BMP so branding stays consistent through boot. A deployment is only complete when the splash bitmap is present alongside the kernel; a missing image falls back to plain output.

Versioning and verification

Every kernel build embeds a version string and an incrementing build number, which the desktop displays after boot. Checking that number is the standard way to confirm that the newly deployed kernel, and not a stale copy, is actually running.

Backups

The project keeps timestamped backups of the source tree and build artifacts around every significant change, so any deployed configuration can be reproduced or rolled back. Details of the backup and recovery procedure are maintained internally.