Fedora 18 features an installer that is rewritten and redesigned from the ground up. This summary is meant to help you understand why the installer has been rewritten, what improvements the new installer will bring, what to expect when you work with the new installer, and some known issues with the installer that will be resolved in later releases of Fedora.

Why rewrite the installer?

After many years of maintaining and developing the pre-Fedora 18 installer, the installer development team determined that a rewrite of the installer was necessary for a myriad of reasons, including the following:

The previous installer had an aging (around 13 years old) infrastructure that was difficult and time-consuming to maintain and improve, constraining new feature development. One current install team developer refers to the old infrastructure as "an incredible mess."
The performance of the old installer left a lot to be desired. Long-term tasks could not be performed in the background. This required long wait times and pauses throughout the installation experience. For example, as CPU and time-intensive tasks were processed, the UI would freeze for several moments until a given processing task completed.
The previous UI was not very responsive. This manifested in various ways, including a failure of the UI screens to redraw when the display was changed between a TTY and back to the UI.
The text-only version of the installer interface was a completely separate codebase, which increased the maintenance burden of the installer. This also increased the amount of work needed to implement new features as they would need to be written twice, once for each codebase.
The previous codebase was not written in a modular fashion. This caused issues where similar functionality in different modes (for example, GUI vs kickstart) used different logic and resulted in inconsistencies for users.
The automated kickstart mode of the installer was separate and incompatible with the UI modes of the installer. A separate utility, system-config-kickstart, was created solely to provide a UI for creating kickstarts since the existing UI could not be used for this purpose without a completed install.
The live media method of installation used a different codepath than the installer than the DVD method, causing maintenance and development difficulties and resulting in an inconsistent and at times buggy user experience.
The old installer's interface had a 'point of no return' past which any changes you'd made to your storage configuration could destroy data on your disk(s) and you couldn't go back to change it. Since the UI followed a linear path, this exact inflection point occurred close to the middle of the screen flow and required a rather discouraging pop-up dialog to explain the impact.
In previous versions of Fedora, the installer's interface followed a wizard design pattern , consisting of multiple linear screens with occasional nested modal pop-up dialogs. (See diagram below) While nothing is inherently problematic with wizards as a design pattern, the sheer number of screens required by the installer made it unwieldy. You could end up several screens into the process and need to go back and change something on an earlier screen, requiring a lot of clicking and screen flipping to go back and return to where you left off. Multiple modal nested dialog windows also made it confusing at times to interact with certain screens, in particular the partitioning-related screens.

In Even More Detail...

Will Woods has put together a great set of write ups going over, in more technical detail, the issues with the old installer codebase and why it needed to be rewritten. Please check it out here:

New installer improvements in Fedora 18

In order to address these and other issues, the installer development team changed the UI model from a linear wizard-based model to a hub and spoke model. Essentially, the installer UI has been distilled into two main menus, from which you can optionally visit various option screens. Each menu list out each sub-screen and summarizes the choices selected for each sub-screen so you can skip screens that you don't need to configure if you'd like. See the diagram below for a visual illustration of how the hub and spoke model works.

The new installer available in Fedora 18 addresses a number of issues that were difficult to solve in the old codebase:

The new installer is written in a modular fashion, so there aren't multiple copies of code that does the same thing scattered around the codebase.
Long-running tasks can be performed in the background as you use the installer. For example, when you first start the installer and land on the first screen for language selection, the installer is - in the background - attempting to auto-detect your network settings and set up a network connection for you.
The UI of the new installer has been written in such a way that it does not block and freeze up while waiting for CPU and time-intensive tasks to process.
The new installer is primarily based on kickstart, whether or not you are using the automated & unattended kickstart option to install, the text user interface, or the graphic user interface. All three, in addition to the live media installation method, share a common codebase, providing a more consistent experience across installation methods as well as a more easily-maintained codebase. Eventually, the plan is to auto-detect any kickstart files available to a system during install and offer to pre-fill the fields in the UI with the values in the kickstart to help save users time.
With the change to a hub-and-spoke model rather than a linear wizard model, the new UI allows users to entirely skip screens that they aren't interested in interacting with, streamlining the install process to only those screens that are most essential for installation to proceed.
When the feature is completed for Fedora 19, the new installer will allow you to complete firstboot while the installer downloads and installs Fedora to your computer, helping to further streamline the install process. If you opt to not complete firstboot during installation, it will appear after you reboot the system.

What to expect when using the new installer

Do you like to watch videos? Of course you do! You can watch Adam Williamson give a walkthrough presentation of the new Anaconda UI from FUDcon Lawrence in this video starting at around 2:13:00.

Storage workflow

One of the more comprehensively reworked parts of the new installer is the storage workflow. This is a very complex element from a design perspective and pre-release testing has indicated that it is not immediately obvious to many users exactly how it works in Fedora 18. Future releases will aim to make the design more discoverable. For a comprehensive guide to both this and all other elements of the new installer we strongly recommend reading the Installation Guide, but if you are in a tearing hurry, the following shortish notes on the design may be of use.

When you click the Installation Destination spoke, you are entering a short 'wizard' for storage configuration. The storage section of the installer constitutes one of the 'spokes' of the 'hub-and-spoke' design, but within itself is effectively a mini 'wizard': it is not possible to fit all the complexities of storage configuration into a single screen.

On the first screen, you are presented with an overview of all the permanent storage devices (disks, RAID arrays, USB sticks...) present on the system. You can select those you wish to form part of the Fedora installation. Any disks not selected on this screen will not be touched as part of the installation. There is also a link at bottom-left labelled Full disk summary and options...: clicking on this provides you with more information on each device, but - importantly for some users - allows you to explicitly select which disk should have the Fedora bootloader installed on it, or choose not to install a bootloader at all. It is no longer possible to install a bootloader to the / or /boot partition of the installed system. See Bugzilla: #872826 for more details on this.

If you hit the 'Done' button at top left of the screen after disk selection, the installer will attempt to complete storage configuration with all defaults for all other choices. This will only succeed if there is sufficient free (unpartitioned) space available within the target disks, and will result in a default (LVM-based) partition layout which takes up all available free space on the disks, with the bootloader location being chosen by the installer. Existing partitions will not be touched in any way. If sufficient free space is not available, the installer will refuse to proceed and force you to return to the Installation Destination spoke.

To continue with the 'wizard', click the 'Continue' button at bottom right of the disk selection screen. This will pop up a dialog. There are two versions of this dialog, one shown if the target disks have sufficient free (unpartitioned space), another shown if they do not. In both cases, there will be an 'expander' (+ button) labelled Partition scheme configuration, a checkbox whose label mentions something about 'customizing disk partitioning', and a button labelled Reclaim space (if sufficient space is not available) or Continue (if it is). In both cases, this screen is a point where you choose between two possible workflows that are sometimes referred to as 'guided partitioning' and 'custom partitioning'. If you check the 'customize partitioning' box and click either Continue or Reclaim space, you will be in the 'custom partitioning' workflow. At this point, it doesn't matter whether you had sufficient space available or not: custom partitioning works the same way in either case, and allows you full control over what will be done to the selected disks. Full instructions on using the 'custom partitioning' page are beyond the scope of this document: please refer to the Installation Guide.

If you do not check the customize partitioning box, then when you click Continue or Reclaim space, you are in the 'guided partitioning' workflow. If sufficient space was available (and so the button is labelled Continue), partitioning is now complete: the installer will be configured to automatically create a partition layout in the available space, and you will be returned to the hub. If sufficient space is not available (and so the button is labelled Reclaim space), you will be taken to a screen where you can configure the installer to delete some existing storage volumes to free up space for the installation. Once you have scheduled enough volumes for deletion that there would be sufficient space for installation, you can complete this screen and again you will be returned to the hub: the installer will automatically configure a partition layout within the freed-up space.

The Partition scheme configuration drop-down has an effect whether you choose the 'custom' or 'guided' workflow. You can choose between LVM, raw ext4, and btrfs. If you use the 'guided' workflow, the chosen technology will be used by the installer when it automatically handles partitioning. If you use the 'custom' workflow, the chosen option will be the default type for volumes you create on the custom partitioning screen, but you can of course change this after creating the volumes.

You cannot combine the 'guided' and 'custom' workflows: they are alternatives. Changes made on the 'disk selection' screen apply to either workflow, but you cannot, for instance, run through the 'guided' workflow to schedule some partitions for deletion, then go back into the spoke and enter the 'custom' workflow to create the partition layout in the freed-up space. Entering the 'custom' workflow will ditch the configuration you chose in the 'guided' workflow.

As noted elsewhere on this page, none of the changes scheduled within the entire storage configuration section actually go into effect immediately. No changes are actually written to disk until you return to the hub and click the Begin Installation button. You can re-run the Installation Destination spoke as many times as you like and modify or completely change your configuration, and if you are worried that something is wrong about the settings and do not wish to apply any of them, you can simply reboot at any point before clicking Begin Installation and your system will remain entirely untouched.

Known installer issues

Please refer to the Common_F18_bugs page for information on single specific bugs (there is useful information on several particular installer bugs here, and we recommend that you read it before installing Fedora 18). This section will concentrate on more generic issues, mainly features that are missing or incomplete in Fedora 18 due to lack of development time but will be improved or restored in Fedora 19.

Enterprise storage technologies missing from interactive installation

Support for some enterprise storage features is missing from the interactive installer interface in Fedora 18. This includes technologies like multipath and FCoE: generally speaking, if you had to use the 'Specialized Storage Devices' screen in Fedora 17 and earlier, your setup may not be supported in the Fedora 18 interactive installer. Kickstart-based installs can use these features as always. The missing support will be added back for Fedora 19.

Guided partitioning cannot shrink storage volumes

The screen in the 'guided partitioning' workflow (see above) where you free up space for the Fedora install, if this is needed, was designed to offer the ability to shrink existing storage volumes, not only to delete them. However, this option had to be removed late in the Fedora 18 development process due to implementation problems. The option should return in Fedora 19. If you would like to shrink an existing storage volume to free up space for a Fedora 18 installation, you can do so through the 'custom partitioning' workflow, or do it prior to Fedora installation using a tool such as parted.

Custom partitioning does not handle some complex configurations

The custom partitioning tool in Fedora 18 is able to handle a wide range of storage cases, including various raw partition formats, LVM, LUKS encryption, software RAID, btrfs, and various combinations. However, it was not possible in the time available to ensure that every possible advanced configuration combining these supported technologies was handled. If you have a complex storage configuration which does not appear to be handled correctly by the new installer, possible workarounds including using a kickstart, or in some cases preparing the drive with a partition tool like parted before installing Fedora. Please be aware that it is safe to experiment as much as you like with the partitioning screens in the new installer: no actual changes will be written to disk until you return to the hub screen and click the Begin Installation button. If you are not confident that you were able to achieve your desired configuration, you can simply reboot the system at any time before clicking that button and no changes will have been made.

Repository configuration limitations

The options for repository configuration during interactive Fedora 18 installation are significantly more limited than in previous releases. This is again a temporary result of time pressure and will be rectified for future releases.

It is not possible to specify additional supplementary repositories. You can of course choose the main repository location for any installation, and this can be a private mirror with modifications from the official Fedora mirrors, but you cannot specify an incomplete supplementary repository containing a few additional or updated packages.

It is not possible to configure which set of repositories any given installation will use. A DVD installation will always install only packages from the DVD itself; it cannot be supplemented with remote repositories. A network installation will always install packages from the fedora and updates repositories, and never from the updates-testing repository.

As in other cases, these restrictions do not apply to Kickstart-based installations: as in the past, you can specify any combination of repositories using a kickstart file.

Internationalization issues

As part of the changes for the new installer, some hard-coded information about various internationalization (i18n hereafter) scenarios was removed. The long-term plan is that such information should be provided in some more appropriate forum - ideally some kind of distribution-neutral, upstream project where any application (an OS installer or otherwise) which might be able to benefit from it could use it. However, in the short term, it means that the i18n experience in Fedora 18 may not be quite as polished as that in earlier releases. Specifically:

The names of languages and locations on the Welcome screen are taken from the CLDR database. In some cases these may not reflect real-world use as well as the tweaked list of names used previously. For instance, those who read and write Simplified Chinese typically use the zh_CN locale wherever they live, and those who read and write Traditional Chinese typically use the zh_TW locale: in previous Fedora releases, these locales were labelled Chinese (Simplified) and Chinese (Traditional) to reflect this. Based on the CLDR database, they are now labelled geographically as Chinese (China) and Chinese (Taiwan).

Previous Fedora releases offered only a subset of possible keyboard layouts to the user at installation time, but each of these options was tweaked to produce an optimal configuration. When you selected one of the keyboard types the installer knew about, it configured an appropriate console layout and X keyboard layout. In cases where users typically configure both a 'native' and a U.S. layout and switch between them in order to enter both 'native' and Roman characters, the installer would configure both X layouts and a keyboard combination to switch between them. The new installer does not have this special knowledge any more: the Keyboard spoke simply allows you to configure any combination of all the X layouts available in Fedora, and any layout switch combination you like if you configure more than one. This is more flexible, but requires a little more work and knowledge on the user's part.

Incomplete translations

The amount of change in the new installer caused two problems for translators: a lot of their existing work became obsolete, as far more text in the installer changed than usually does between two Fedora releases, and inevitably changes to text in the installer had to be made far later than is usually the case. So there are fewer complete translations of the installer for Fedora 18 than for many previous releases, and many of the incomplete translations are quite a long way from complete. Now the new UI is in place the amount of 'churn' in installer text should go back to lower levels, so the translation teams will be able to improve translation coverage for Fedora 19 and later.

Search

Anaconda/NewInstaller

Contents