Documentation for a newer release is available. View Latest

Installation

Anaconda changes

This section covers changes in the Anaconda installer, including changes in the graphical and text mode interactive installers, Kickstart, and installer boot options.

General changes

  • In the Installer screen for setting up user, the "Make this user administrator" checkbox is now checked by default. This improves installation experience for users who do not know and need to rely on the default values to guide them.

  • Keyboard configuration is now disabled on live media with Wayland, due to ongoing issues with switching keyboard layouts in Wayland. Make sure to note what layout you are using during the installation if using live media, as any passwords will be set using that layout.

  • Support for built-in help has been revamped and now uses mapping files with a unified format. These mappings are located in the root of the help/ directory, typically in /usr/share/anaconda/help. These files contain data about available help content. See the pull request for details.

Kickstart changes

  • The previously deprecated %anaconda section has been removed. Use Anaconda configuration files to change the behavior of the installer instead.

  • Support for the ANA_INSTALL_PATH environment variable is now deprecated and will be removed in a future release. Use the /mnt/sysroot path instead. See the upstream documentation for details.

Anaconda boot options changes

  • The inst.nompath boot option is now deprecated.

Anaconda configuration file changes

  • You can now use the btrfs attribute in the default_partitioning configuration option to specify mount points that will be created only for the Btrfs scheme.

Other changes related to installation

Fedora Silverblue and Kinoite now create separate subvolumes for /var

When performing a fresh installation of Fedora Silverblue or Kinoite, the guided installation will automatically create a separate var Btrfs subvolume to be mounted at /var. This will allow it to be snapshot and rolled back independently from the root subvolume, which allows for an efficient way of backing variable system data.

Upgrading an existing system will not create the new subvolume, only new installations will.

Want to help? Learn how to contribute to Fedora Docs ›