Boot Configurations#

The scyld-install script creates a basic boot configuration named DefaultBoot that references the initial DefaultImage and is initially associated with all compute nodes. After installation, you can customize that configuration and/or create additional boot configurations and compute node images.

Modify configuration fields using the scyld-bootctl tool. For example, you can change the name and description of the newly created boot configuration on a freshly installed system using the update argument:

scyld-bootctl -i DefaultBoot update name="NewName" description="New description"

The kernel and initramfs are also set using the same command, although their paths must be prefixed with @ (which signifies that what follows is a local file path). For example:

scyld-bootctl -i DefaultBoot update kernel=@/boot/vmlinuz-3.10.0-862.el7.x86_64

Other database objects (nodes, images, etc.) are modified using similarly named tools (scyld-nodectl and scyld-imgctl). Each node is associated with a specific boot configuration through its _boot_config attribute. Like other attributes, this field may be inherited from an attribute group (including the global default attribute group) or set directly on the node. Learn more about manipulating node attributes in Interacting with Compute Nodes.

Boot configurations also contain two more fields: release and boot_style. The release field is not editable and is populated by the system whenever the kernel file is uploaded, based on the Linux file command output. The boot_style dictates how the nodes receive the root file system, although it can be overridden by the _boot_style attribute set at the node level or in any attribute groups used by the node. See Reserved Attributes for details. The possible values for boot_style are rwram (default), roram, iscsi, disked, live, next, and sanboot.

  • rwram is the default value. It instructs the system to download the compressed image into compute node RAM where the mount_rootfs script unpacks it during the boot process.

  • If the roram option is provided, the script downloads a squashfs image into compute node RAM, combines this with a writable tmpfs via overlayfs, and boots using that combined file system.

  • The iscsi option instructs the node to mount a read-only image via iSCSI and apply a writeable overlay.

  • The disked option allows a node with local storage to both employ a node-local persistent cache to retain downloaded images and unpack images onto a node-local partition. Using a cache avoids the need to download images at boot time, and booting from a local partition frees the RAM that would otherwise hold the compute node image. See Booting From Local Storage Cache for details.

  • The live and next options are most useful when kickstarting locally installed nodes. The live option can be applied to a boot configuration that points to a repo based on an uploaded Rocky or RHEL ISO. Nodes booted live from such a configuration use the kernel and initramfs from the ISO with an inst.repo kernel option to boot into the ISO's Anaconda-based installer. Given access to the node console, you can manually install to the local disk, thereby generating a kickstart file that can be used to reinstall this or similar nodes at a later time. The BIOS of such kickstarted nodes should be configured to boot from the network and then from local disk. In this configuration the next boot style should cause the compute node(s) to initially attempt to PXE boot, but then fail and try to boot their local disk. See Using Kickstart for details about kickstarting locally installed nodes.

    When booting a compute node into either a kickstart or live configuration, certain Anaconda options can be provided on the command line through the cmdline field in the boot config or node. For example, if the inst.sshd option is included on the cmdline when a node uses a boot configuration made from an ISO-based repo, then you can log into the node during a "live" boot or during the node kickstart process. Be aware that there is no root password required by default, but it can be set in a kickstart file.

    Similarly, the inst.vnc Anaconda argument tells the booting node to start a VNC server to monitor the kickstart process or click through a manual install.

    See https://anaconda-installer.readthedocs.io/en/latest/boot-options.html for documentation and additional options.

  • Depending on BIOS details, some locally installed systems will not properly handle the next boot style and will halt instead of failing over to another boot device. In that case, the sanboot option can be used to trigger booting of the first partition of the first disk. The sanboot option behavior is customized using the _ipxe_sanboot attribute described in Reserved Attributes.

You can override the boot_style setting for an individual or group of nodes by assigning a _boot_style attribute. Similarly, to avoid overlayfs and use the rwtab approach to providing write capabilities to read-only root file systems, set the _boot_rw_layer attribute of a node or attribute group to rwtab.