Node installer

The TrinityX node installer, lpart, provisions a node from two settings held in Luna: the install mode, which says what should happen to the node's operating system, and the disk layout, which describes the node's disks. Both are set on the group and can be overridden per node. A node that runs from RAM needs no disk layout at all; a node installed to disk is driven entirely by it. Hand-written partition scripts are no longer needed for a local disk, a mirror or a RAID set.

The installer shows its progress on the node's console: the node's identity as Luna knows it, the hardware it discovered, the phases it runs through, the storage it resolved and the commands it runs.

Install mode

The mode is the headline decision. auto is the default and does the sensible thing without supervision; the other modes exist for when you want to be explicit.

auto, sync, full and local use the disk layout. memboot consults it only for data sets. sanitize and legacy ignore it.

# luna group change compute --install-mode auto
# luna node change node001 --install-mode full

What the modes guarantee:

• A data set is wiped only by an explicit full, never by auto or sync.
• A set marked persistent is never partitioned, formatted or written by any mode except sanitize. It is only mounted.
• sync never destroys existing data. On a broken or mismatched disk it halts.
• auto may recreate the OS set, which carries no user data. A broken data set halts.
• A declared OS layout that cannot be satisfied — no disks, too few, none matching — halts and reports. The node does not silently fall back to RAM.

Disk layout

A disk layout is a set of sets. A node has at most one OS set, where the system is installed, and any number of data sets for local storage. Each set says which disks to use and how to arrange them, and lists the volumes to create on them.

The layout is written in YAML (JSON is accepted too) and stored on the group or the node:

# luna group change compute --disklayout            # opens $EDITOR
# luna group change compute -qdl /root/layout.yaml  # loads a file
# luna group showdisklayout compute
# luna node showdisklayout node001

A layout set on a node replaces the group's layout as a whole; fields are never merged.

Choosing the disks

With selection: discover, the installer finds the disks at boot and matches them by tag and size, so one group layout fits a fleet whose disks sit in different slots or differ in size. Every disk is tagged automatically from what the kernel reports: rotary for a spinning disk, ssd for any solid-state disk, and nvme in addition for NVMe disks. A match may combine:

• tags: the disk must carry every tag listed;
• min_size and max_size: either may be left out;
• model: the disk model name must contain this text.

An omitted match accepts any disk. From the matching disks the set takes as many members as its RAID level needs (or the count given), smallest first.

With selection: manual you list the exact device paths under devices. Paths under /dev/disk/by-path/ or /dev/disk/by-id/ are stable across reboots; /dev/sdX names are not.

A discovered set can be pinned: with save: true the first install writes the disks it resolved back to the node as a manual layout, and every later boot reproduces exactly those disks. Clearing the node's layout returns it to the group's recipe.

Arranging the disks

Volumes

A volume is one mountpoint within a set, backed by a provider of partition or lvm, with a filesystem (vfat, xfs, ext4 or swap) and a size. The common OS volumes have defaults, so they can be written as bare mountpoints:

Any other mountpoint defaults to xfs on lvm and needs a size. A supplied value always wins over a default.

A complete layout for one disk, found at boot, therefore reads:

version: 2
sets:
  - role: os
    match: {min_size: 20G}
    volumes: [/boot/efi, /boot, /]

luna group showdisklayout shows the layout with every default filled in, which is also what the node receives. More shapes — mirrors, stripes, RAID data sets, persistent data next to a RAM OS — are in Disk layouts: worked examples.

What the group's scripts must not do

The partscript and postscript of a group still run, before the installer's own partition and post phases. The stock compute group's partscript mounts a tmpfs on /sysroot for diskless booting; left in place on a group that installs to disk, it puts the installation in RAM and nothing reports it. On a group or node that uses a disk layout, set both to a no-op:

# luna group change compute -qpart 'true' -qpost 'true'

Requirements and limits

• UEFI only. The installer writes GRUB in UEFI mode and registers the NVRAM boot entry, for x86_64 and aarch64 alike. Legacy BIOS and CSM are not supported and are refused.
• The image must carry the installer. The lpart tools ship with the luna2-client package inside the image. When an image lacks them, the node reports the status install.lpart_unavailable and falls back to the classic installer; the disk is then whatever the partscript produced. Update the client in the image, or set install_mode: legacy on the node to stop asking for it.
• Validation happens twice. Luna rejects a malformed layout when it is stored — wrong version, unknown field, bad value — and the node checks the topology rules (member counts, the OS-set RAID restriction, a missing /boot/efi or /) before touching a disk.

Where things are on the node

The installer writes its logs to /tmp/install_files/logs/ during the install, one file per tool and phase, and its resolved inputs to /tmp/install_files/runtime/. The console shows the same commands as they run.