Fedora 26 is available now, providing a wide range of improvements across the entire operating system. Anaconda — the Fedora installer — has many new features and improvements implemented for Fedora 26. The most visible addition is the introduction of Blivet GUI, providing power users an alternate way to configure partitioning. Additionally, there are improvements to automated installation with kickstart, a range of networking improvements, better status reporting when your install is under way, and much more.
Enhanced storage configuration with Blivet GUI
The main highlight of Anaconda in Fedora 26 is the integration of Blivet GUI storage configuration tool into the installation environment. Previously, there were two options for storage configuration — automatic partitioning and manual partitioning. Automatic partitioning is mostly useful for really simple configurations, like installing Fedora on an empty hard drive or alongside of another existing operating system. The existing manual partitioning tool provides more control over partition layouts and size, enabling more complicated setups.
The previously-available manual partitioning tool is quite unique. Instead of creating all the storage components manually, the user just specifies future mountpoints and their properties. For example, you simply create two “mountpoints” for
/ (root), specify properties like encryption or RAID and Anaconda properly configures all the necessary components below. This top-down model is really powerful and easy to use but might be too simple for some complicated storage setups.
This is where Blivet GUI can help — it is a storage configuration tool that works in the standard way. If you want an LVM storage on top of RAID, you need to create it manually from the building blocks — from bottom up. With a good knowledge of custom partitioning layouts, complicated custom storage setups are easily created with BlivetGUI.
Using Blivet GUI in Anaconda
Blivet GUI has been available from Fedora repositories as a standalone desktop application since Fedora 21 and now comes also to Anaconda as a third option for storage configuration. Simply choose Advanced Custom (Blivet-GUI) from the Installation Destination window in Anaconda.
Blivet GUI has full integration into the Anaconda installation workflow. Only the selected disks in the Installation Destination window show in BlivetGUI. Changes remain unwritten to the disks until you leave the window and choose Begin Installation. Additionally, you can always go back and use one of the other partitioning methods. However, Blivet GUI discards changes if you switch to a different partitioning method.
Automated install (kickstart) improvements
Kickstart is the configuration file format for automation of the installation process. A Kickstart file can configure all options available in the graphical and text interfaces and much more. View the Kickstart documentation for more information about Kickstart and how to use it.
Support for –nohome, –noswap and –noboot options in auto partitioning
When you don’t want to specify your partitions, you can let anaconda do that for you with the autopart command. It will automatically create a root partition, a swap partition and a boot partition. With Fedora Workstation, the installed creates a /home partition on large enough drives. To make the auto partitioning more flexible, anaconda now supports the –nohome, –noswap and –noboot options that disable the creation of the given partition.
Strict validation of the kickstart file with inst.ksstrict
It is not uncommon for sysadmins to have complicated kickstart files, and sometimes kickstart files have errors. At the beginning of the installation, anaconda checks the kickstart file and produces errors and warnings. Errors result in the termination of the installation.The log records warnings and the installation continues.
To ensure a kickstart file doesn’t produce any warnings, enable the new strict validation with the boot option
inst.ksstrict. This treats warnings in kickstart in the same way as errors.
Sometimes it is helpful to save an old installation or have a backup of freshly installed system for recovery. For these situations the snaphost kickstart command is now available. View the pykickstart documentation for full usage instructions of this new command. This feature is currently supported on LVM thin pools only. To request support for other partition types please file an RFE bug on bugzilla.
Networking is a critical part of Anaconda as many installations are partially or fully network based. Anaconda also supports installation to network attached storage devices such as iSCSI, FCoE and Multipass. For this reason Anaconda needs to be able to support complex networking setups not only to even just start the installation but also to correctly setup networking for the installed system.
For this Fedora cycle we have mostly bug fixes, adaptation to NetworkManager rebase, enhancements to the network kickstart tests suite to discover issues caused by NM changes and some changes in components we are using in general. Also adding support for various – mostly enterprise driven – features:
- Support for IPoIB (IP over infiniband) devices in TUI.
- Support for setting up bridge device at early stage of installation (eg to fetch kickstart).
- New inst.waitfornet boot option for waiting for connectivity at later stage of installation in cases where default waiting for DHCP configuration is not sufficient due to special network environment (DHCP servers) setup.
Anaconda and Pykickstart documentation on Read the Docs
The Anaconda and Pykickstart documentation have a new home on ReadTheDocs:
Progress reporting for all installation phases
Do you also hate it when Anaconda says “processing post installation setup tasks” for many minutes (or even tens of minutes!) without any indication what’s actually going on and how much longer it might take?
The cause of the previous lack of status reporting was simple – during the final parts of the RPM installation transaction RPM post & posttrans scriptlets are running and that can take a significant amount of time. And until recently there was no support from RPM and DNF for progress reporting from this installation phase.
But this has been rectified, RPM & DNF now provide the necessary progress reporting, so Anaconda can finally report what’s actually happening during the full installation run. 🙂
Run Initial Setup TUI on all usable consoles
Initial Setup is a utility to configure a freshly installed system on the first start. Initial Setup provides both graphical and text-mode interfaces and is basically just a launcher for the configuration screens normally provided by Anaconda.
During a “normal” installation everything is configured in Anaconda and Initial Setup does not run. However, the situation is different for the various ARM boards supported by Fedora. Here the installation step is generally skipped and users boot from a Fedora image on an SD card. In this scenario Initial Setup is a critical component, enabling users to customize the pre-made system image as needed.
The Initial Setup text interface (TUI) is generally used on ARM systems. During the Fedora 25 time frame two nasty issues showed up:
- some ARM board have both serial and graphical consoles with no easy way detect which the user is using
- some ARM board consoles appear functional, but throw errors when Initial Setup tries to run the TUI on them
To solve these issues, the Initial Setup TUI is run on all consoles that appear to be usable. This solves the first issue – the TUI will run on both the serial and graphical consoles. It also solves the second issue, as consoles that fail to work as expected are simply skipped.
Built in help is now also available for the TUI
Previously, only the graphical installation mode featured help. However, help is accessible in the TUI from every screen that offers the ‘h to help’ option.
New log-capture script
The new log-capture script is an addition from community contributor Pat Riehecky. This new script makes it easy to gather many installation relevant log files into a tarball, which is easily transferred outside of the installation environment for detailed analysis.
The envisioned use case is running the log-capture script in kickstart %onerror scriptlets.
Structured installation tasks
Anaconda does a lot of things during the installation phase (configures storage, installs packages, creates users & groups, etc.). To make the installation phase easier to monitor and to debug any issues the individual installation tasks are now distinct units (eq. user creation, user group creation, root user configuration.) that can be part of task groups (eq. user & group configuration).
End result – it is now easy to see in the logs how long each task took to execute, which task is currently running & how many tasks still need to be executed until the installation is done.
User interaction config file
Anaconda supports the new user interaction config file. A special configuration file to record the screens and (optionally) the settings manipulated by the user.
The main idea behind the user interaction config file is that a user generally comes into contact with multiple separate applications (Anaconda, Gnome Initial Setup, Initial Setup, a hypothetical language selector on a live CD, etc.) during an installation run and it would make sense to only present each configuration option (say language or timezone selection) only once and not multiple times. This should help to reduce the amount of screens a user needs to click through, making the installation faster.
Anaconda will record visited screens and will hide screens marked as visited in an existing user interaction config file. But once other pre & post installations tools (such as for example Gnome Initial Setup) start picking up support it should be easy to spot as users should no longer be asked to configure the same setting twice. But we might not have to wait for long as a Fedora 27 change proposal for adding Gnome Initial Setup support already exists.