Boot Process

TrinityX core philosophy is that only controller nodes should have stateful and persistent storage, in order to allow its configurations to persist across reboots.

All other machines managed by the controller, such as compute, storage, or login nodes should be diskless and configured to boot from network. The image files required to boot those nodes are stored on the controller and managed by the Luna daemon, which configures the controller to act as a boot server.

See also: for the daemon-internal view of this flow — how base/boot.py assembles the iPXE / node-boot / installer templates, the templ_install segments, and the node-side luna2-client pre-pivot hook — see luna2 daemon architecture.

The boot process works as follows:

  1. Power Up the machine, either the BIOS or UEFI code will be read from ROM, firing up the first-stage bootloader.
  2. Select the network boot option, this will load the code to initialize the Network interface and perform the required DHCP and TFTP operations.
  3. Send a first boot request with DHCP and get the location of the second-stage bootloader (iPXE)
  4. Download the second-stage bootloader (iPXE) with TFTP
  5. Chainload the second-stage bootloader (iPXE) and boot from there
  6. Send a second boot request with DHCP and get the location of the Luna image
  7. Download the Base Luna image containing the kernel, aria2 and essential utilities with HTTP
  8. Boot Base Luna image
  9. Use aria2 to download Full Luna Image
  10. Chroot into Full Luna Image