The Red Hat Enterprise Linux and Fedora installation program, Anaconda, brings many improvements in its most recent versions. One of these improvements is enhanced customizability. You can now write add-ons to extend the base installer functionality, and change the appearance of the graphical user interface.

This document will explain how to customize the following:

Also note that this document applies only to Red Hat Enterprise Linux 8 and Fedora 17 and later.

The Boot menu is the menu which appears after you boot your system using an installation image. Normally, this menu allows you to choose between options such as Install Red Hat Enterprise Linux, Boot from local drive or Rescue an installed system. To customize the Boot menu, you can:

An installation media consists of ISOLINUX and GRUB2 boot loaders. The ISOLINUX boot loader is used on systems with BIOS firmware, and the GRUB2 boot loader is used on systems with UEFI firmware. Both the boot loaders are present on all Red Hat images for AMD64 and Intel 64 systems.

Customizing the boot menu options can especially be useful with Kickstart. Kickstart files must be provided to the installer before the installation begins. Normally, this is done by manually editing one of the existing boot options to add the inst.ks= boot option. You can add this option to one of the pre-configured entries, if you edit boot loader configuration files on the media.

The ISOLINUX boot loader is used on systems with BIOS firmware.

Figure 2.1. ISOLINUX Boot Menu

The isolinux/isolinux.cfg configuration file on the boot media contains directives for setting the color scheme and the menu structure (entries and submenus).

In the configuration file, the default menu entry for Red Hat Enterprise Linux, Test this media & Install Red Hat Enterprise Linux 8, is defined in the following block:

label check
  menu label Test this ^media & install Red Hat Enterprise Linux 8.3.0.
  menu default
  kernel vmlinuz
  append initrd=initrd.img inst.stage2=hd:LABEL=RHEL-8-2-0-BaseOS-x86_64 rd.live.check
quiet

Where:

Other important options which are not included in the menu entry definition are:

The GRUB2 boot loader is used on systems with UEFI firmware.

The EFI/BOOT/grub.cfg configuration file on the boot media contains a list of preconfigured menu entries and other directives which controls the appearance and the Boot menu functionality.

In the configuration file, the default menu entry for Red Hat Enterprise Linux (Test this media & install Red Hat Enterprise Linux 8.3.0) is defined in the following block:

menuentry 'Test this media & install Red Hat Enterprise Linux 8.3' --class fedora --class gnu-linux --class gnu --class os {
    linuxefi /images/pxeboot/vmlinuz inst.stage2=hd:LABEL=RHEL-8-3-0-BaseOS-x86_64 rd.live.check quiet
    initrdefi /images/pxeboot/initrd.img
}

Where:

Other options used in the grub.cfg configuration file are:

To customize the graphical elements, you can modify or replace the customisable elements with the custom branded material, and update the container files.

The customisable graphical elements of the installer are stored in the /usr/share/anaconda/pixmaps/ directory in the installer runtime file system. This directory contains the following customisable files:

pixmaps
├─ anaconda-password-show-off.svg
├─ anaconda-password-show-on.svg
├─ right-arrow-icon.png
├─ sidebar-bg.png
├─ sidebar-logo.png
└─ topbar-bg.png

Additionally, the /usr/share/anaconda/ directory contains a CSS stylesheet named anaconda-gtk.css, which determines the file names and parameters of the main UI elements - the logo and the backgrounds for the sidebar and top bar. The file has the following contents that can be customized as per your requirement:

/* theme colors/images */

@define-color product_bg_color @redhat;

/* logo and sidebar classes */

.logo-sidebar {
   background-image: url('/usr/share/anaconda/pixmaps/sidebar-bg.png');
   background-color: @product_bg_color;
   background-repeat: no-repeat;
}

/* Add a logo to the sidebar */

.logo {
   background-image: url('/usr/share/anaconda/pixmaps/sidebar-logo.png');
   background-position: 50% 20px;
   background-repeat: no-repeat;
   background-color: transparent;
}

/* This is a placeholder to be filled by a product-specific logo. */

.product-logo {
   background-image: none;
   background-color: transparent;
}

AnacondaSpokeWindow #nav-box {
   background-color: @product_bg_color;
   background-image: url('/usr/share/anaconda/pixmaps/topbar-bg.png');
   background-repeat: no-repeat;
   color: white;
}

The most important part of the CSS file is the way in which it handles scaling based on resolution. The PNG image backgrounds do not scale, they are always displayed in their true dimensions. Instead, the backgrounds have a transparent background, and the stylesheet defines a matching background color on the @define-color line. Therefore, the background images "fade" into the background color, which means that the backgrounds work on all resolutions without a need for image scaling.

You could also change the background-repeat parameters to tile the background, or, if you are confident that every system you will be installing on will have the same display resolution, you can use background images which fill the entire bar.

Any of the files listed above can be customized. Once you do so, follow the instructions in Section 2.2, “Creating a product.img File” to create your own product.img with custom graphics, and then Section 2.3, “Creating Custom Boot Images” to create a new bootable ISO image with your changes included.

To customize the product name, you must create a custom .buildstamp file. To do so, create a new file .buildstamp.py with the following content:

[Main]
Product=My Distribution
Version=8.3
BugURL=https://bugzilla.redhat.com/
IsFinal=True
UUID=202007011344.x86_64
[Compose]
Lorax=28.14.49-1

Change My Distribution to the name which you want to display in the installer.

After you create the custom .buildstamp file, follow the steps in Section 5.1, “Creating a product img file” section to create a new product.img file containing your customizations, and the Section 5.2, “Creating custom boot images” section to create a new bootable ISO file with your changes included.

You can create your own configuration file and use it to customize the configuration of the installer.

[Anaconda]
# Run Anaconda in the debugging mode.
debug = False

# Enable Anaconda addons.
addons_enabled = True

# List of enabled Anaconda DBus modules.
kickstart_modules =
    org.fedoraproject.Anaconda.Modules.Timezone
    org.fedoraproject.Anaconda.Modules.Network
    org.fedoraproject.Anaconda.Modules.Localization
    org.fedoraproject.Anaconda.Modules.Security
    org.fedoraproject.Anaconda.Modules.Users
    org.fedoraproject.Anaconda.Modules.Payloads
    org.fedoraproject.Anaconda.Modules.Storage
    org.fedoraproject.Anaconda.Modules.Services
    org.fedoraproject.Anaconda.Modules.Subscription


[Installation System]
# Should the installer show a warning about enabled SMT?
can_detect_enabled_smt = True


[Installation Target]
# Type of the installation target.
type = HARDWARE

# A path to the physical root of the target.
physical_root = /mnt/sysimage

# A path to the system root of the target.
system_root = /mnt/sysroot

[Network]
# Network device to be activated on boot if none was configured so.
# Valid values:
#
#   NONE                   No device
#   DEFAULT_ROUTE_DEVICE   A default route device
#   FIRST_WIRED_WITH_LINK  The first wired device with link
#
default_on_boot = DEFAULT_ROUTE_DEVICE


[Payload]
# Default package environment.
default_environment =

# List of ignored packages.
ignored_packages =
    ntfsprogs
    btrfs-progs
    dmraid

# Enable installation of latest updates.
enable_updates = False

# List of .treeinfo variant types to enable.
# Valid items:
#
#   addon
#   optional
#   variant
#
enabled_repositories_from_treeinfo = addon optional variant

# Enable installation from the closest mirror.
enable_closest_mirror = False

# Default installation source.
# Valid values:
#
#   CLOSEST_MIRROR  Use closest public repository mirror.
#   CDN             Use Content Delivery Network (CDN).
#
default_source = CDN

# Enable ssl verification for all HTTP connection
verify_ssl = True


[Security]
# Enable SELinux usage in the installed system.
# Valid values:
#
#  -1  The value is not set.
#   0  SELinux is disabled.
#   1  SELinux is enabled.
#
selinux = -1


[Bootloader]
# Type of the bootloader.
# Supported values:
#
#   DEFAULT   Choose the type by platform.
#   EXTLINUX  Use extlinux as the bootloader.
#
type = DEFAULT

# Name of the EFI directory.
efi_dir = redhat

# Hide the GRUB menu.
menu_auto_hide = False

# Are non-iBFT iSCSI disks allowed?
nonibft_iscsi_boot = False

# Arguments preserved from the installation system.
preserved_arguments =
    cio_ignore rd.znet rd_ZNET zfcp.allow_lun_scan
    speakup_synth apic noapic apm ide noht acpi video
    pci nodmraid nompath nomodeset noiswmd fips selinux
    biosdevname ipv6.disable net.ifnames net.ifnames.prefix
    nosmt


[Storage]
# Enable dmraid usage during the installation.
dmraid = True

# Enable iBFT usage during the installation.
ibft = True

# Do you prefer creation of GPT disk labels?
gpt = False

# Tell multipathd to use user friendly names when naming devices during the installation.
multipath_friendly_names = True

# Do you want to allow imperfect devices (for example, degraded mdraid array devices)?
allow_imperfect_devices = False

# Default file system type. Use whatever Blivet uses by default.
file_system_type = xfs

# Default partitioning.
# Valid values:
#
#   SERVER          Choose partitioning for servers.
#   WORKSTATION     Choose partitioning for workstations.
#   VIRTUALIZATION  Choose partitioning for virtualizations.
#
default_partitioning = WORKSTATION

# Default partitioning scheme.
# Valid values:
#
#   PLAIN      Create standard partitions.
#   BTRFS      Use the Btrfs scheme.
#   LVM        Use the LVM scheme.
#   LVM_THINP  Use LVM Thin Provisioning.
#
default_scheme = LVM

# Default version of LUKS.
# Valid values:
#
#   luks1  Use version 1 by default.
#   luks2  Use version 2 by default.
#
luks_version = luks2


[Storage Constraints]

# Minimal size of the total memory.
min_ram = 320 MiB

# Minimal size of the available memory for LUKS2.
luks2_min_ram = 128 MiB

# Should we recommend specifying a swap partition?
swap_is_recommended = True

# Recommended minimal sizes of partitions.
# Specify a mount point and a size on each line.
min_partition_sizes =
    /      250 MiB
    /usr   250 MiB
    /tmp   50  MiB
    /var   384 MiB
    /home  100 MiB
    /boot  200 MiB

# Required minimum sizes of partitions.
# Specify a mount point and a size on each line.
req_partition_sizes =

# Allowed device types of the / partition if any.
# Valid values:
#
#   LVM        Allow LVM.
#   MD         Allow RAID.
#   PARTITION  Allow standard partitions.
#   BTRFS      Allow Btrfs.
#   DISK       Allow disks.
#   LVM_THINP  Allow LVM Thin Provisioning.
#
root_device_types =

# Mount points that must be on a linux file system.
# Specify a list of mount points.
must_be_on_linuxfs = / /var /tmp /usr /home /usr/share /usr/lib

# Paths that must be directories on the / file system.
# Specify a list of paths.
must_be_on_root = /bin /dev /sbin /etc /lib /root /mnt lost+found /proc

# Paths that must NOT be directories on the / file system.
# Specify a list of paths.
must_not_be_on_root =


[User Interface]
# The path to a custom stylesheet.
custom_stylesheet =

# The path to a directory with help files.
help_directory = /usr/share/anaconda/help/rhel

# Default help pages for TUI, GUI and Live OS.
default_help_pages =
    rhel_help_placeholder.txt
    rhel_help_placeholder.xml
    rhel_help_placeholder.xml

# A list of spokes to hide in UI.
# FIXME: Use other identification then names of the spokes.
hidden_spokes =


[License]
# A path to EULA (if any)
#
# If the given distribution has an EULA & feels the need to
# tell the user about it fill in this variable by a path
# pointing to a file with the EULA on the installed system.
#
# This is currently used just to show the path to the file to
# the user at the end of the installation.
eula = /usr/share/redhat-release/EULA

[Product]
product_name = Red Hat Virtualization

[Base Product]
product_name = Red Hat Enterprise Linux

[Storage]
default_scheme = LVM_THINP
default_partitioning = VIRTUALIZATION

[Storage Constraints]
root_device_types = LVM_THINP
must_not_be_on_root = /var
req_partition_sizes =
	/var   10 GiB
	/boot  1  GiB

[User Interface]
help_directory = /usr/share/anaconda/help/rhv

Anaconda is the operating system installer used in Fedora, Red Hat Enterprise Linux, and their derivatives. It is a set of Python modules and scripts together with some additional files like Gtk widgets (written in C), systemd units, and dracut libraries. Together, they form a tool that allows users to set parameters of the resulting (target) system and then set up this system on a machine. The installation process has four major steps:

Using Anaconda enables you to install Fedora, Red Hat Enterprise Linux, and their derivatives, in the following three ways:

Using graphical user interface (GUI):

This is the most common installation method. The interface allows users to install the system interactively with little or no configuration required before starting the installation. This method covers all common use cases, including setting up complicated partitioning layouts.

The graphical interface supports remote access over VNC, which allows you to use the GUI even on systems with no graphics cards or attached monitor.

Using text user interface (TUI):

The TUI works similar to a monochrome line printer, which allows it to work on serial consoles that do not support cursor movement, colors and other advanced features. The text mode is limited and allows you to customize only the most common options, such as network settings, language options or installation (package) source; advanced features such as manual partitioning are not available in this interface.

Using Kickstart file:

A Kickstart file is a plain text file with shell-like syntax that can contain data to drive the installation process. A Kickstart file allows you to partially or completely automate the installation. A set of commands which configures all required areas is necessary to completely automate the installation. If one or more commands are missed, the installation requires interaction.

Apart from automation of the installer itself, Kickstart files can contain custom scripts that are run at specific moments during the installation process.

Anaconda is a set of Python modules and scripts. It also uses several external packages and libraries. The major components of this toolset include the following packages:

Apart from the division into packages previously mentioned, Anaconda is internally divided into the user interface and a set of modules that run as separate processes and communicate using the D-Bus library. These modules are:

Each module declares which parts of Kickstart it handles, and has methods to apply the configuration from Kickstart to the installation environment and to the installed system.

The Python code portion of Anaconda (pyanaconda) starts as a “main” process that owns the user interface. Any Kickstart data you provide are parsed using the pykickstart module and the Boss module is started, it discovers all other modules, and starts them. Main process then sends Kickstart data to the modules according to their declared capabilities. Modules process the data, apply the configuration to the installation environment, and the UI validates if all required choices have been made. If not, you must supply the data in an interactive installation mode. Once all required choices have been made, the installation can start - the modules write data to the installed system.

The Anaconda user interface (UI) has a non-linear structure, also known as hub and spoke model.

The advantages of Anaconda hub and spoke model are:

The following diagram shows the installer layout and the possible interactions between hubs and spokes (screens):

Figure 4.1. Hub and spoke model

In the diagram, screens 2-13 are called normal spokes, and screens 1 and 14 are standalone spokes. Standalone spokes are the screens that can be used before or after the standalone spoke or hub. For example, the Welcome screen at the beginning of the installation which prompts you to choose your language for the rest of the installation.

Each spoke has the following predefined properties that reflect the hub.

To make the user interface clearer, spokes are grouped together into categories. For example, the Localization category groups together spokes for keyboard layout selection, language support and time zone settings.

Each spoke contains UI controls which display and allow you to modify values from one or more modules. The same applies to spokes that add-ons provide.

Some of the actions that you need to perform during the installation process may take a long time. For example, scanning disks for existing partitions or downloading package metadata. To prevent you from waiting and remaining responsive, Anaconda runs these actions in separate threads.

The Gtk toolkit does not support element changes from multiple threads. The main event loop of Gtk runs in the main thread of the Anaconda process. Therefore, all actions pertaining to the GUI must be performed in the main thread. To do so, use GLib.idle_add, which is not always easy or desired. Several helper functions and decorators that are defined in the pyanaconda.ui.gui.utils module may add to the difficulty.

The @gtk_action_wait and @gtk_action_nowait decorators change the decorated function or method in such a way that when this function or method is called, it is automatically queued into Gtk’s main loop that runs in the main thread. The return value is either returned to the caller or dropped, respectively.

In a spoke and hub communication, a spoke announces when it is ready and is not blocked. The hubQ message queue handles this function, and periodically checks the main event loop. When a spoke becomes accessible, it sends a message to the queue announcing the change and that it should no longer be blocked.

The same applies in a situation where a spoke needs to refresh its status or complete a flag. The Configuration and Progress hub has a different queue called progressQ which serves as a medium to transfer installation progress updates.

These mechanisms are also used for the text-based interface. In the text mode, there is no main loop, but the keyboard input takes most of the time.

Anaconda’s modules run as independent processes. To communicate with these processes via their D-Bus API, use the dasbus library.

Calls to methods via D-Bus`API are asynchronous, but with the `dasbus library you can convert them to synchronous method calls in Python. You can also write either of the following programs:

For more information about threads and communication, see Section 4.4, “Communication across Anaconda threads”.

Additionally, Anaconda uses Task objects running in modules. Tasks have a D-Bus API and methods that are automatically executed in additional threads. To successfully run the tasks, use the sync_run_task and async_run_task helper functions.

Anaconda developers publish an example addon called “Hello World”, available on GitHub: https://github.com/rhinstaller/hello-world-anaconda-addon/ The descriptions in further sections are reproduced in this.

An Anaconda add-on is a Python package that contains a directory with an __init__.py and other source directories (subpackages). Because Python allows you to import each package name only once, specify a unique name for the package top-level directory. You can use an arbitrary name, because add-ons are loaded regardless of their name - the only requirement is that they must be placed in a specific directory.

The suggested naming convention for add-ons is similar to Java packages or D-Bus service names.

To make the directory name a unique identifier for a Python package, prefix the add-on name with the reversed domain name of your organization, using underscores (_) instead of dots. For example, com_example_hello_world.

When writing an add-on, ensure the following:

Following is a sample directory structure for an add-on which supports every interface (Kickstart, GUI and TUI):

com_example_hello_world
├─ gui
│  ├─ init.py
│  └─ spokes
│     └─ init.py
└─ tui
   ├─ init.py
   └─ spokes
   └─ init.py

Each package must contain at least one module with an arbitrary name defining the classes that are inherited from one or more classes defined in the API.

You can include a category subpackage if an add-on needs to define a new category, but this is not recommended.

Anaconda services and configuration files are included in data/ directory. These files are required to start the add-ons service and to configure D-Bus.

Following are some examples of Anaconda Hello World add-on:

<!DOCTYPE busconfig PUBLIC
"-//freedesktop//DTD D-BUS Bus Configuration 1.0//EN"
"http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd">
<busconfig>
       <policy user="root">
               <allow own="org.fedoraproject.Anaconda.Addons.HelloWorld"/>
               <allow send_destination="org.fedoraproject.Anaconda.Addons.HelloWorld"/>
       </policy>
       <policy context="default">
               <deny own="org.fedoraproject.Anaconda.Addons.HelloWorld"/>
               <allow send_destination="org.fedoraproject.Anaconda.Addons.HelloWorld"/>
       </policy>
</busconfig>

This file must be placed in the /usr/share/anaconda/dbus/confs/ directory in the installation environment. The string org.fedoraproject.Anaconda.Addons.HelloWorld must correspond to the location of addon’s service on D-Bus.

[D-BUS Service]
# Start the org.fedoraproject.Anaconda.Addons.HelloWorld service.
# Runs org_fedora_hello_world/service/main.py
Name=org.fedoraproject.Anaconda.Addons.HelloWorld
Exec=/usr/libexec/anaconda/start-module org_fedora_hello_world.service
User=root

This file must be placed in the /usr/share/anaconda/dbus/services/ directory in the installation environment. The string org.fedoraproject.Anaconda.Addons.HelloWorld must correspond to the location of addon’s service on D-Bus. The value on the line starting with Exec= must be a valid command that starts the service in the installation environment.

You can deploy and test your own Anaconda add-on into the installation environment. To do so, follow the steps:

For specific instructions on unpacking an existing boot image, creating a product.img file and repackaging the image, see Section 1.2.3, “Extracting Red Hat Enterprise Linux boot images”.

A product.img image file is an archive containing new installer files that replace the existing ones at runtime.

During a system boot, Anaconda loads the product.img file from the images/ directory on the boot media. It then uses the files that are present in this directory to replace identically named files in the installer’s file system. The files when replaced customizes the installer (for example, for replacing default images with custom ones).

Note: The product.img image must contain a directory structure identical to the installer. For more information about the installer directory structure, see table, Table 5.1, “Installer directory structure and custom contents”

The procedure below explains how to create a product.img file.

The product.img file is now created and the customizations that you want to make are placed in the respective directories.

See the Anaconda Boot Options for more information about Anaconda boot options.

After you customize the boot images and the GUI layout, create a new image that includes the changes you made.

To create custom boot images, follow the procedure below.