Product SiteDocumentation Site

3. Changes in Fedora for System Administrators

3.1. Kernel

Fedora 22 features the 4.0.0 kernel.

3.1.1. Modular Kernel Packaging

The kernel package is now a meta package that pulls in kernel-core and kernel-modules. The kernel-core package is smaller than a full package and is well-suited for virtualized environments. By optionally uninstalling kernel-modules, cloud image size can be reduced.
The kernel-modules package should be included when Fedora is installed on real hardware.
Fedora's initramfs is configured to include only drivers required for your system, allowing you to boot Fedora faster. A single, fully featured initramfs is provided under a Rescue boot entry in the GRUB menu to allow use after hardware changes. To recreate initramfs after hardware or driver changes, use the rescue boot option and run the command dracut --regenerate-all.

Initramfs Changes

Please note, that a new initramfs is only automatically generated by the kernel-core package but not the kernel-modules package. If you only installed kernel-core at first and install kernel-modules at a later point in time, you need to create a new initramfs manually using dracut, if any of the newly installed modules has become critical for your system's boot up.
The dracut utility is used to create the initramfs on Fedora. To regenerate an initramfs for all installed kernels, use the following command:
        # dracut --regenerate-all

3.2. Installation

3.2.1. General Anaconda Changes

  • Development of the Anaconda installer and related components such as pykickstart, pyparted and initial-setup has been moved from Fedorahostedg to Github (
  • Full documentation of Kickstart commands and options is now in the rhinstaller/pykickstart Github repository as well: The version on the Fedora Wiki has been removed. Keeping the documentation in the Git repository will allow the development team to maintain multiple, more accurate versions of documentation matching with various releases of pykickstart.
  • The localization effort for Anaconda has migrated from Transifex to Zanata.
  • The new DNF package manager is now used to install packages. You can use the inst.nodnf option to revert back to Yum if needed. See Section 3.6.1, “Yum replaced by DNF” for more information about DNF.

3.2.2. Changes in Anaconda's Graphical Interface

  • The advanced storage section of the Manual Partitioning screen now allows adding zFCP storage devices. The screen also now has a Refresh button, allowing you to refresh the list of network (iSCSI, FCoE, etc.) storage devices without having to leave the screen.
  • The graphical interface now has animated transitions when moving back and forth between screens. This improvement aims to improve user experience by emphasizing the relationship between the main menu (Installation Summary) and other screens.
  • Anaconda is now maximized, instead of full-screen, when running on top of a desktop (e.g. when installing from a Live DVD).
  • When changing the settings on an existing connection in the Network & Hostname screen, you no longer have to turn the connection on and off for the changes to take effect.

3.2.3. Changes in Anaconda Boot Options

  • The inst.dnf boot option, which was added in Fedora 21, has been replaced by the inst.nodnf option, which behaves in an opposite way. Use inst.nodnf to force the installer to use the older Yum package manager to install packages instead of DNF, which is now default.
  • A new option, inst.kdump_addon=, has been added. Use inst.kdump_addon=on to enable the Kdump configuration add-on in the graphical and text user interface as well as in Kickstart. The Kdump configuration screen is disabled by default.

3.2.4. Changes in Kickstart Syntax

  • The --nobase option for the %packages section has been removed.
  • New command: sshkey. Use this command to install a SSH key to the authorized_keys file for a specified user using the following syntax:
    sshkey --username=user "ssh_key"
    Replace user with the user name, and ssh_key with the SSH key. The key must be enclosed in quotes because it may contain spaces. Also note that the user must either be root, or it must exist (must be created by the user command in the Kickstart file, or by a package specified in the %packages section).
  • New section: %anaconda. This section can now be used in a Kickstart file to control the behavior of the installer, but not the installed system. Currently, the only command supported in this section is pwpolicy, described below. This section must end with an %end statement.
  • New command: pwpolicy. This command sets password requirements such as minimum length for a named password entry.
    pwpolicy name [--minlen=LENGTH] [--minquality=QUALITY] [--strict|notstrict] [--emptyok|notempty] [--changesok|nochanges]
    Replace name with one of the following: root, user, or luks, to set a policy for the root password, user passwords, or LUKS (disk encryption) password.
    Available options are:
    • --minlen= - The minimum allowed password length. This parameter will be passed to the libpwquality library. The default minimum length is 8.
    • --minquality= - Minimum allowed quality of the password, as calculated by libpwquality. If the --strict option is used, passwords with lower quality will not be allowed. If --notstrict is used, using a password of lower than specified quality will display a warning require the user to click Done twice in the graphical user interface to confirm. The default quality value is 50.
    • --strict - Passwords with lower quality than specified in --minquality will be rejected completely. This is the default.
    • --notstrict - Passwords with lower quality than specified in --minquality will be accepted, but Anaconda will display a warning and require the user to click Done twice before accepting the password.
    • --emptyok - Allow empty passwords. This is the default.
    • --notempty - Do not allow empty passwords.
    • --changesok - Allow changing a password pre-configured in the Kickstart file to be changed interactively in the graphical user interface.
    • --nochanges - Passwords set in the Kickstart file can not be changed in the GUI. This is the default.
    The defaults are set in the /usr/share/anaconda/interactive-defaults.ks file provided by Anaconda on installation media. To override the default Kickstart file (and therefore change the installer's password policy), a product.img file with a separate %anaconda section must be created and passed to Anaconda.

3.3. File Systems

3.3.1. XFS as a Default File System for Fedora Server

The Fedora Server variant of Fedora 22 now uses the XFS file system by default. Other variants (Workstation, Cloud) continue to use ext4 as a default; this can be changed during the installation.
XFS is a highly scalable, high-performance file system that supports file systems up to 16 exabytes (approximately 16 million terabytes), files up to 8 exabytes (approximately 8 million terabytes), and directory structures containing tens of millions of entries. XFS also supports metadata journaling, which facilitates quicker crash recovery. The maximum supported size of a single XFS file system is 500 TB (the limit for ext4 is 50 TB).


The size of an XFS file system can not be reduced after it is created - it can only be made bigger, not smaller. Use ext4 if you require the ability to shrink the file system at any point after the installation.

3.4. Virtualization

3.4.1. AArch64 QEMU/KVM VM Installation with libvirt and virt-manager Support

You may now use libvirt and virt-manager to install a virtual machine on the AArch64 (64-bit ARM) architecture with the KVM hypervisor. For specific instructions, see:

3.4.2. UEFI VMs Installation with libvirt and virt-manager Support

UEFI installation options are now automatically available if UEFI/OVMF binaries are installed.
Instructions for installing virtual machines with UEFI are available at:

3.5. Web Servers

3.5.1. Ipsilon

The Ipsilon identity provider is now included in the Fedora 22 updates repository, allowing this application to be installed using the DNF package manager.
Ipsilon is a server and a toolkit to configure Apache-based Service Providers. The server is a pluggable mod_wsgi application which provides federated single sign-on to web application. User authentication is always performed against a separate Identity Management system, such as an IPA server, and communication with applications is performed using a federation protocol such as SAML or OpenID.
See the project page on Fedorahosted for more information.

3.6. Server Configuration Tools

3.6.1. Yum replaced by DNF

The yum package manager has been replaced in Fedora 22 by its successor, dnf. The yum fork has been available in Fedora for testing since Fedora 18, and is now the default command line package manager.
Most dnf commands use directives that are familiar to yum users, and it uses the same RPM package repositories. Behind the scenes, dnf uses an improved dependency solver, hawkey, along with librepo for repository operations and libcomps for package groups.
The /usr/bin/yum command will redirect to /usr/bin/dnf and print a warning about the redirection. The legacy yum package manager can be manually installed; the legacy command line utility has been renamed to yum-deprecated.
Read more about using dnf! Consult the upstream documentation at Extra plugins are documented at
The behavior of dnf differs from yum in some areas: Updates that don't work are skipped
If a portion of a transaction is not viable, dnf will automatically exclude it and transparently continue with the portions that will work. For example, if a package has unmet dependencies during a dnf update action, that package will not be updated, but others will. This is similar to yum's --skip-broken directive, but evaluates the impact of the problem against the entire transaction. Because this is the default behavior, there is no --skip-broken switch for dnf.
To reveal details about a problematic package direction, you can use the --best option. dnf update --best will force dnf to resolve the transaction using the latest versions of involved packages, and report any problems instead of skipping them. This is equivalent to yum's behavior without --skip-broken. Repos that don't work are skipped
If a configured and enabled repository does not respond, dnf will skip it and continue the transaction with the available repos. This differs from yum, which would immediately stop if a repository was not available. Update and Upgrade are the same
The commands dnf update and dnf upgrade are equivalent. This differs from yum, where yum upgrade would have the same effect as yum update --obsoletes, and take obsolete packages into account. Dependencies are not upgraded on package installation
When installing a new package, previously installed dependencies will not be upgraded. Yum offered an option for this behavior, upgrade_requirements_on_install. To upgrade with dnf, use dnf update.
If dnf reports that dependencies on installed packages are unmet while installing a new package, update the dependent packages before trying again. Clean on remove
When removing a package, dnf will automatically remove any dependent packages that were not explicitly installed by the user. If a package was independently installed, it won't be uninstalled this way. Only packages installed as dependencies are removed.
This behavior is configured by the clean_requirements_on_remove option in /etc/dnf/dnf.conf Repo cache refresh schedule
By default, dnf will check for updates in configured repositories hourly, starting ten minutes after the system boots. The action is controlled by a systemd timer unit, /usr/lib/systemd/system/dnf-makecache.timer.
To adjust this, copy the timer file to /etc/systemd/system/dnf-makecache.timer and edit it.
Alternatively, setting the metadata_timer_sync in /etc/dnf/dnf.conf to a number of seconds configures the minimum number of seconds between makecache operations. If the timer has not expired, dnf makecache will exit immediately.
dnf will also honor the metadata_expire option set in individual repo configs, and refresh repo metadata at runtime if it is too old. This option is described in man yum.conf. Repository Actions
The repository-packages directive can be used to search for or get info about packages in a specific repository, list installed packages from that repository, and more. This simplifies operations that would have required use of --excluderepo and --includerepo options with yum, and is especially useful for managing similar packages from different repositories. Listing dependencies
To find out what package supplies a particular provide, use the dnf provides foo command. This replaces yum resolvedep foo.
To list the dependencies of a package, use dnf repoquery --requires foo. This replaces yum deplist foo. dnf will remove kernels
kernel packages are not protected by dnf. Unlike with yum, you can remove all kernel packages, including the running package, if you direct it to. Be cautious with removing kernels, and specify the full version and release when removing them for best results. Replacing packages
When a system requires the capabilities of a package you want to replace, use the --allowerasing option. For example, dnf --allowerasing mariadb will allow you to replace mysql with mariadb, without disrupting packages that require capabilities provided by both packages. This replaces yum shell and yum swap functionality. DNF Langpacks Plug-in
DNF supports installing language packs using the dnf-langpacks plug-in, which is expected to work identically to the older yum-langpacks plug-in. See Section 4.3.3, “DNF Langpacks Plug-in” for details. Support for disabled repositories
The Software tool and PackageKit now support searching for packages in disabled repositories.
If a user searches for a package using one of these applications and the package is found in a repository which includes the line enabled_metadata=1 in its definition, a dialog window will be displayed informing the user that the package has been found, but an additional repository must be enabled before it can be installed.
The same message can also inform the user about the reason why the repository is disabled by default.
This change allows Fedora remixes to ship pre-configured but disabled repositories for any reason - for example, if said repositories contain non-free software. Fedora itself does not have any such repositories pre-configured; therefore this feature will not be visible on a Fedora 22 installation unless you specifically configure one or more repositories with the enabled_metadata=1 statement.

3.6.2. Preupgrade Assistant

Fedora 22 introduces the Preupgrade Assistant, a diagnostics utility which assesses the system for possible in-place upgrade limitations and provides a report with the analysis results. It is based on a module system, with each module performing a separate test, checking for package removals, incompatible obsoletes, changes in libraries, names changes, or deficiencies in the compatibilities of some configuration files. The Preupgrade Assistant does not modify your system except for storing log files.
Data gathered by the Preupgrade Assistant can be used for migrating the system using a Kickstart file. It also provides post-upgrade scripts to finish more complex problems after an in-place upgrade. The preupgrade-assistant-contents package is part of the preupgrade-assistant package and it delivers the set of scripts and plug-ins that are used to assess the system. Every module runs its own test and display an exit code that represents the result of that text (for example PASS, FAIL, NEEDS_ACTION, etc.). Contents can be done by users on the base of the Packaging Guidelines here: Package owners are responsible for adding a module if it is suitable, for example changes in the MariaDB database between system versions.
To install the Preugrade Assistant with all available contents, use the dnf install preupgrade-assistant-* command. You can find information on how to run the Preupgrade Assistant here:

3.7. Big Data

3.7.1. Elasticsearch

The Elasticsearch indexing server has been integrated into the updates repository in Fedora 22. You can now install this application using DNF instead of relying on the stand-alone upstream installer.
Elasticsearch is a distributed, scalable, highly available search and analysis tool built on top of Apache Lucene, available under the Apache 2 license.
For information about Elasticsearch, see the official project website.