previously, when anaconda could not read the extended display identification data (EDID) of a monitor, it reverted to text mode. However, EDID information is frequently not available on systems connected to Keyboard–Video–Mouse (KVM) switches. Therefore, when installing Red Hat Enterprise Linux 5 on a system with a KVM switch, installation would be constrained to text mode. Anaconda no longer checks for bad or missing EDID, and allows graphical installation to proceed even when this information is unavailable. Graphical installation on machines attached to KVM switches therefore continues as if them monitor were connected directly to the graphics adapter. (BZ#445486)

previously, anaconda expected storage devices to be available immediately when it probed for the location of a kickstart file. On systems where USB storage might not be available immedately (for example, IBM BladeCenter systems), anaconda would not find the kickstart file and would prompt the user for its location. This interaction negated the usefulness of kickstart, since the installation could not then complete unattended. Anaconda now waits until it has probed five times or for more than 31 seconds before prompting the user for the location of a kickstart file. This allows USB storage enough time to respond and for kickstart to proceed unattended. (BZ#460566)

previously, some user interface elements in the the Malayalam translation of anaconda overlapped. The overlapping elements disabled some buttons in the screen where anaconda lets users to choose a partitioning scheme for the system, and prevented installation from continuing. The text of the Malayalam translation has been shortened so that the interface elements no longer overlap. The buttons on the partitioning scheme screen now work correctly and allow installation to continue. (BZ#479353)

during installation, anaconda automatically examines any storage device that has the label OEMDRV for driver updates and applies any updates that it finds there. Previously, anaconda searched for this label on the devices listed in /proc/partitions. However, /proc/partitions does not identify CD or DVD media, so anaconda overlooked optical disks that had the correct label. Anaconda now examines the devices listed in /sys/block. Therefore, anaconda correctly identifies CDs and DVDs labelled OEMDRV as driver discs and automatically applies any driver updates contained on them. (BZ#485060)

previously, if anaconda required network access early in an installation (for example, to retrieve a kickstart file or driver disk image), it temporarily saved information about the network configuration while it enabled access to the network. However, if anaconda required network access again for a separate reason, it would not attempt to configure network access again, but would not be able to connect to the network either, because it no longer retained the configuration information that it had already used. Therefore, anaconda could not download both a kickstart file and a driver disk image over a network. Anaconda now retains the network configuration that it obtains early in the installation process, and can reuse this information multiple times. Therefore, anaconda can use more than one resource obtained over a network during installation. (BZ#495042)

previously, while upgrading a system, anaconda did not check whether packages marked for installation as dependencies were already installed on the system. Consequently, many packages would be reinstalled during an upgrade, wasting time and, in the case of network installations, bandwidth. Now, when performing an upgrade, anaconda matches the packages to be installed against the packages that are already installed. Any packages with the same Name, Arch, Epoch, Version, Release (NAEVR) as a package already on the system are skipped and not reinstalled. (BZ#495796)

previously, anaconda did not specify a value for HOTPLUG when writing the system's networking configuration files, although it did write a value for ONBOOT. Because HOTPLUG is enabled by default, the effect of disabling ONBOOT was limited because any interface not activated at boot time would be enabled anyway whenever probed by the system. Anaconda now writes a value for HOTPLUG, setting it to the same value as ONBOOT. Therefore, any network interface not meant to be enabled at boot time will not be automatically enabled by probing either. (BZ#498086)

the part kickstart command accepts an option called --label that allows a label to be applied to a disk partition during a kickstart installation. However, the code that implemented this option was previously missing from anaconda. Any label specified in a kickstart file was therefore ignored. Anaconda now includes code to transfer the specified label from the kickstart file to the disk partition. Users can now label disk partitions during kickstart installations. (BZ#498856)

when running in rescue mode, anaconda previously lacked the ability to identify partitions on logical volumes if the partitions were identified in fstab by label rather than by device name. Therefore, if the root (/) partition were identified in this way, the usefulness of rescue mode would be limited. Anaconda in rescue mode now uses the getLabels() method to find partitions and therefore properly detects root partition even if it resides on a logical volume and is identified by label in fstab. (BZ#502178)

previously, the help text available while configuring NETTYPE for IBM System z systems did not mention HiperSockets. Users new to System z might therefore not have known to choose qeth to configure HiperSocket interfaces on their hardware. The help text has now been updated to indicate the correct choice and users can select the appropriate option. (BZ#511962)

when the RUNKS was set to 0 in the CMSCONFFILE file on IBM System z systems, anaconda should have performed an installation in interactive mode. However, a rewrite of linuxrc.s390 changed the behavior of RUNKS and led to anaconda ignoring this variable. Installation would therefore proceed in non-interactive mode regardless of what value was set in CMSCONFFILE. A new test is now included in the version of linuxrc.s390 in Red Hat Enterprise Linux 5.5 so that anaconda honors RUNKS=0 and performs an interactive install if this value is set. (BZ#513951)

by design, anaconda recognizes any block device with the label OEMDRV as a driver disc and searches it for a driver update. However, anaconda previously failed to examine dev nodes and therefore, it would not recognize this label on USB storage devices mounted as a partitionless block devices. Anaconda now examines dev nodes for the label OEMDRV and treats them the same as partitions with this label. It is therefore possible to use a partitionless device as a driver disc. (BZ#515437)

previously, anaconda did not reinitialize its record of the partition layout on a system when users clicked the back button from the partitioning screen. Therefore, when a user selected a partition layout, went back to an earlier screen, and then went forward again to choose a different partition layout, anaconda would attempt to implement the new partition layout over the previously-selected partition layout instead of the partition layout actually present on the system. This would sometimes result in a crash. Now, when users step backwards from the partitioning screen. anaconda reinitializes its record of the partitions present on the system. Users can therefore change their minds about partitioning options without crashing anaconda. (BZ#516715)

systems store information about iSCSI targets to which they are connected in the iSCSI Boot Firmware Table (iBFT) in BIOS. Previously, however, when anaconda installed Red Hat Enterprise Linux 5 from a local installation source such as a CD, DVD, or hard disk, it would not initialize network connections before asking users to configure storage on the system. Therefore, on systems with iSCSI storage, users would have to configure a network connection manually before proceding with installation, even when this information was already available to anaconda in the system BIOS. Now, when anaconda detects a valid iBFT present on a system, it automatically loads the network configuration specified there and does not requre users to enter this information. Installation from local media on systems with iSCSI storage is therefore simpler and more reliable. (BZ#517768)

due to faulty logic, anaconda previously did not parse IPv6 addresses correctly and attempted to read the final byte of the address as a port number. It was therefore not possible, for example, to install on an iSCSI target specified by in IPv6 address. The logic by which anaconda parses IP addresses has now been corrected, but now requires IPv6 addresses to be specified in the [address]:port form to comply with the relevant RFCs. This form removes ambiguity, since IPv6 addresses are still valid if they omit a sequence of bytes with zero values. When IPv6 addresses are specified in this format, anaconda parses them correctly and installation continues as normal. (BZ#525054)

comments in kickstart files are marked with a pound symbol (#) at the start of the line. However, anaconda did not previously account for the possibility that users might mark a comment with multiple pound symbols (for example, #####). Anaconda would therefore attempt to parse lines that started with multiple pound symbols and installation would fail. Anaconda now recognizes lines that start with multiple pound symbols as comments and does not attempt to parse them. Users can now safely mark comments in kickstart files in this way. (BZ#525676)

to avoid a circular dependency that exists between the ghostscript and ghostscript-fonts packages, anaconda ignored ghostscript's dependency on ghostscript-fonts. However, ghostscript-fonts was not explicitly installed as part of the Printing package group. The usefulness of Ghostscript as installed by anaconda was therefore limited. Anaconda still avoids the circular dependency, but now specifically installs ghostscript-fonts when users select the Printing package group. (BZ#530548)

previously, anaconda did not automatically instruct the kernel to check for multipath devices when installing on IBM System z systems. Therefore, unless users booted with the mpath boot option, iSCSI devices detected on more than one path would be represented in the installer multiple times, one for each path. Anaconda now automatically loads the mpath boot option and therefore represents multipath devices correctly. (BZ#538129)

Dell PowerEdge servers equipped with the SAS6i/R integrated RAID controller use BIOS Enhanced Disk Drive Services (EDD) to identify the storage device from which to boot the operating system. Previously, anaconda did not parse EDD to identify the correct boot device. Consequently, with a RAID 0 and RAID 1 configured on the system, anaconda would choose the wrong device and the system would not be bootable. Anaconda now parses EDD to support the SAS6i/R integrated RAID controller, so that it selects the correct boot device for systems that use this device. (BZ#540637)

previously, anaconda would always attempt to reconstruct pre-existing Logical Volume Management (LVM) devices during installation. Anaconda would attempt to recreate the LVM device even when a user cleared the LVM partitions from one or more of the disks that held partitions that formed part of a volume group. In this case, installation would fail. Now, anaconda no longer attempts to reconstruct incomplete LVM devices. Users can therefore safely re-allocate storage that was once part of a volume group and installation will proceed as expected. (BZ#545869)

when ksdevice=link is set in a kickstart file, anaconda should automatically select the first available network interface and use it during installation. This avoids the need for user input and allows installation to proceed unattended. However, if interfaces were in a state where anaconda could not determine their status, anaconda would revert to interactive more and prompt the user to select a network interface, thus making unattended installation impossible on systems where network interfaces could be in such a state. Anaconda now forces the network interfaces on the system into IFF_UP and IFF_RUNNING states before it attempts to obtain link status. Because the interfaces are now in a state where they can report their link status to anaconda, Anaconda can automatically choose one to use during installation and kickstart installations can proceed unattended. (BZ#549751)

previously, when installing on IBM System z systems, anaconda assumed that the network gateway was unreachable if its attempt to ping the gateway timed out after 10 seconds. Anaconda would then prompt the user to select a gateway. However, if IPADDR in the conf file has changed recently, network interfaces take longer to respond. Anaconda now prompts the user only when three pings have failed and therefore avoids prompting the user for gateway information that is already correctly specified in the conf file. (BZ#506742)

after transferring installation files to a z/VM guest, a user must execute a series of Conversational Monitor System (CMS) commands to IPL the zLinux installation. These commands can be scripted, but no such script was previously included with Red Hat Enterprise Linux 5. The lack of a readymade script made installation more difficult for users unfamiliar with CMS commands. The CMS script for starting the install process on z/VM is now included in the Red Hat Enterprise Linux 5 images, simplifying installation. (BZ#475343)

anaconda now loads the Brocade BNA Ethernet Controller driver, and supports Brocade Fibre Channel to PCIe Host Bus Adapters. (BZ#475707)

previously, anaconda did not offer users the opportunity to configure NFS options during interactive installation (although these could be configured in kickstart files). Users who needed to fine-tune NFS parameters for installation were therefore forced to run an unattended installation. Now, anaconda presents users who select NFS installation with a dialog in which they can configure NFS options to suit their needs. (BZ#493052)

previously, it was not possible to configure hypervisor parameters during a kickstart installation. As a result, users needed to specify hypervisor parameters manually after installation, negating the usefulness of kickstart as as a mechanism for unattended installations. Now, anaconda recognizes a new kickstart option, --hvargs and sets Hypervisor parameters accordingly. (BZ#501438)

previouisly, during a kickstart installation when multiple multipath LUNs were available, anaconda would automatically choose the LUN with the lowest ID number for the root device. Users had no ready way to customize this behavior. Now, anaconda supports a multipath kickstart command with --name and --device options that allow users to specify a LUN for root. (BZ#502768)

anaconda can retrieve kickstart files from FTP servers. Previously, however, anaconda did not support users specifying authentication credentials to access an FTP server. Therefore, if access to the server were protected by a passphrase, anaconda could not retrieve the kickstart file. Now, when specifying the location of a kickstart file with the ks= boot option, users can provide a passphrase to allow anaconda to retrieve the kickstart files fom a protected server. (BZ#505424)

previously, troubleshooting errors that occurred while running %pre and %post kickstart scriptlets was very difficult because anaconda did not log the behavior of these scriptlets. Anaconda now copies %pre and %post kickstart scriptlets to /tmp together with a log. These records make troubleshooting kickstart installations easier. (BZ#510636)

Reipl is a kernel feature that instructs IBM System z systems where to boot next, as these systems do not have a default boot location. Anaconda did not previously support Reipl, which meant that during installation, users had to specify a boot location manually between different phases of the installation. Anaconda now supports Reipl, so these reboots can happen automatically. (BZ#512195)

NPort ID Virtualization (NPIV) presents one physical Fibre Channel adapter port to the SAN as multiple WWNN/WWPN pairs. Anaconda now supports NPIV, which allows users on PowerPC systems to install to a NPIV LUN. (BZ#512237)

the Python executables that make up anaconda now all explicitly use the system Python (#! /usr/bin/python instead of #! /usr/bin/env python). This ensures that anaconda functions correctly when more than one Python stack is present on a system. (BZ#521337)

anaconda now supports the Emulex OneConnect iSCSI network interface card. (BZ#529442)

anaconda now supports PMC Sierra MaxRAID controller adapters. (BZ#532777)

although users have been able to specify package groups for installation in kickstart files, using the @ prefix, it was not possible to exclude package groups from installation, only individual packages. Anaconda now supports excluding package groups with the -@ prefix (BZ#558516)

anaconda now loads the xorg-x11-qxl-drv and xorg-x11-ast-drv X11 video drivers as required. xorg-x11-qxl-drv supports the qemu QXL video accelerator when installing Red Hat Enterprise Linux 5 as a guest operating system. xorg-x11-ast-drv supports ASPEED Technologies video hardware. (BZ#567666)