After a reboot of a freshly-installed system, the IP over Infiniband (IPoIB) interface fails to come up automatically as Anaconda fails to manually enable the openibd init script. To work around this issue, enable the openibd init script in the post section of the Kickstart file prior to the installation of the system:
chkconfig --level 12345 openibd on
When installing Red Hat Enterprise Linux 5.8 on a machine that had previously used a GPT partitioning table, Anaconda does not provide the option to remove the previous disk layout and is unable to remove the previously used GPT partitioning table. To work around this issue, switch to the tty2 terminal (using CTRL+ALT+F2), execute the following command, and restart the installation process:
dd if=/dev/zero of=/dev/USED_DISK count=512
Starting with Red Hat Enterprise Linux 5.2, to boot with
ibft, the iSCSI boot firmware table support, use the
ip=ibft option as the network install option:
IP to use for a network installation, use 'dhcp' for DHCP.
By default, the installer waits 5 seconds for a network device with a link. If an iBFT network device is not detected in this time, you may need to specify the
linksleep=SECONDS parameter in addition to the
ip=ibft parameter by replacing
SECONDS with an integer specifying the number of seconds the installer should wait, for example:
dhcptimeout=0 parameter does not mean that DHCP will disable timeouts. If the user requires the clients to wait indefinitely, the
dhcptimeout parameter needs to be set to a large number.
When starting an installation on IBM S/390 systems using SSH, re-sizing the terminal window running the SSH client may cause the installer to unexpectedly exit. Once the installer has started in the SSH session, do not resize the terminal window. If you want to use a different size terminal window during installation, re-size the window before connecting to the target system via SSH to begin installation.
Installing on June with a RAID backplane on Red Hat Enterprise Linux 5.7 and later does not work properly. Consider the following example: a test system which had two disks with two redundant paths to each disk was set up:
mpath0: sdb, sdd
mpath1: sda, sdc
In the above setup, Anaconda created the PReP partition on mpath0 (sdb/sdd), but set the bootlist to boot from sda. To work around this issue, follow these steps:
mpath to the append line in the
--ondisk=mapper/mpath0 in all
part directives of the kickstart file.
Add the following script to the
%post section of the kickstart file.
# Determine the boot device
# Set the bootlist in NVRAM
if [ "z$device" != "z" ]; then
bootlist -m normal $device;
# Print the resulting boot list in the log
bootlist -m normal -o;
bootlist -m normal -r;
echo "Could not determine boot device!";
The above script simply ensures that the bootlist is set to boot from the disk with the PReP partition.
Mounting an NFS volume in the rescue environment requires portmap to be running. To start portmap, run:
Failure to start portmap will return the following NFS mount errors:
sh-3.2# mount 192.168.11.5:/share /mnt/nfs
mount: Mounting 192.168.11.5:/share on /mnt/nfs failed: Input/output error
The order of device names assigned to USB attached storage devices is not guaranteed. Certain USB attached storage devices may take longer to initialize than others, which can result in the device receiving a different name than you expect (for example,
sdc instead of
During installation, be sure to verify the storage device size, name, and type when configuring partitions and file systems.
occasionally crashes while attempting to install on a disk containing partitions or file systems used by other operating systems. To workaround this issue, clear the existing partition table using the command:
clearpart --initlabel [disks]
Performing a System z installation, when the
is located on direct access storage device (DASD) disk, causes the installer to crash, returning a backtrace. anaconda
is attempting to re-write (commit) all disk labels when partitioning is complete, but is failing because the partition is busy. To work around this issue, a non-DASD source should be used for
When installing to an
file system, anaconda
disables periodic file system checking. Unlike
, these file systems are journaled, removing the need for a periodic file system check. In the rare cases where there is an error detected at runtime or an error while recovering the file system journal, the file system check will be run at boot time. (BZ#513480
Red Hat Enterprise Linux 5 does not support having a separate
on a network file system (
, etc.) This is because
contains the utilities required to bring up the network, for example
. However, you may have
or the like on a separate network disk, just not the complete /var file system. (BZ#485478
When using rescue mode on an installation which uses iSCSI drives which were manually configured during installation, the automatic mounting of the root file system does not work. You must configure iSCSI and mount the file systems manually. This only applies to manually configured iSCSI drives; iSCSI drives which are automatically detected through iBFT are fully supported in rescue mode.
To rescue a system which has
/ on a non-iBFT configured iSCSI drive, choose to skip the mounting of the root file system when asked, and then follow the steps below:
$TARGET_IP: IP address of the iSCSI target (drive)
$TARGET_IQN: name of the iSCSI target as printed by the discovery command
$ROOT_DEV: devicenode (/dev/.....) where your root fs lives
Define an initiator name:
$ mkdir /etc/iscsi
$ cat << EOF>> /etc/iscsi/initiatorname.iscsi
Discover and login to target:
$ iscsiadm -m discovery -t st -p $TARGET_IP
$ iscsiadm -m node -T $TARGET_IQN -p $TARGET_IP --login
If the iSCSI LUN is part of a LVM Logical volume group:
$ lvm vgscan
$ lvm vgchange -ay
$ mount /dev/path/to/root /mnt/sysimage
$ mount -t bind /dev /mnt/sysimage/dev
$ mount -t proc proc /mnt/sysimage/proc
$ mount -t sysfs sysfs /mnt/sysimage/sys
Now you can
chroot to the root file system of your installation if wanted
$ chroot /mnt/sysimage /bin/su -
When installing KVM or Xen guests, always create a partition for the guest disk, or create an LVM volume. Guests should not be installed to block devices or raw disk devices. Anaconda includes disk label duplication avoidance code, but when installing within a VM, it has no visibility to the disk labels elsewhere on the host and cannot detect duplicates.
If guest file systems, especially the root file system, are directly visible to the host, a host OS reboot may inadvertently parse the partition table and mount the guest file systems. This can lead to highly undesirable outcomes.
The minimum memory requirement when installing all Red Hat Enterprise Linux packages (i.e.
@everything is listed in the
%packages section of the
kickstart file) on a fully virtualized Itanium guest is 768MB. After installation, the memory allocated to the guest can be lowered to the desired amount.
Upgrading a system using Anaconda is not possible if the system is installed on disks attached using zFCP or iSCSI (unless booted from the disk using a network adapter with iBFT). Such disks are activated after Anaconda scans for upgradable installations and are not found. To update please use the Red Hat Network with the hosted Web user interface, a Red Hat Network Satellite, the local graphical Updater, or the yum command line.
Anaconda's graphical installer fails to start at the default 800x600 resolution on systems utilizing Intel Graphics Device Next Generation (IGDNG) devices. To work around this issue, ensure anaconda uses a higher resolution by passing the parameters
resolution=1280x1024 to the installer using the boot command line.
The NFS default for RHEL5 is
. Therefore, to mount
shares from the
section of anaconda, use the
mount -o nolock,udp
command to start the locking daemon before using
to mount shares. (BZ#426053
If you are using the Virtualized kernel when upgrading from Red Hat Enterprise Linux 5.0 to a later 5.x release, you must reboot after completing the upgrade. You should then boot the system using the updated Virtualized kernel.
The hypervisor ABI changes in an incompatible way between Red Hat Enterprise Linux 5 and 5.1. If you do not boot the system after upgrading from Red Hat Enterprise Linux 5.0 using the updated Virtualized kernel, the upgraded Virtualization RPMs will not match the running kernel. (BZ#251669
When upgrading from Red Hat Enterprise Linux 4.6 to Red Hat Enterprise Linux 5.1 or later, gcc4
may cause the upgrade to fail. As such, you should manually remove the gcc4
package before upgrading. (BZ#432773
When provisioning guests during installation, the option will not be available. When this occurs, the system will require an additional entitlement, separate from the entitlement used by
To prevent the consumption of additional entitlements for guests, install the
package manually before attempting to register the system to Red Hat Network. (BZ#431648
When installing Red Hat Enterprise Linux 5 on a guest, the guest is configured to explicitly use a temporary installation kernel provided by
dom0. Once installation finishes, it can then use its own bootloader. However, this can only be achieved by forcing the guest's first reboot to be a shutdown.
As such, when the button appears at the end of the guest installation, clicking it shuts down the guest, but does not reboot it. This is an expected behavior.
Note that when you boot the guest after this it will then use its own bootloader.
swap --grow parameter in a
kickstart file without setting the
--maxsize parameter at the same time makes anaconda impose a restriction on the maximum size of the swap partition. It does not allow it to grow to fill the device.
For systems with less than 2GB of physical memory, the imposed limit is twice the amount of physical memory. For systems with more than 2GB, the imposed limit is the size of physical memory plus 2GB. (BZ#462734
Existing encrypted block devices that contain
file systems will appear as type
in the partitioning interface; as such, these devices will not be mounted automatically during system boot. To ensure that such devices are mounted automatically, add an appropriate entry for them to
. For details on how to do so, refer to
When using anaconda's automatic partitioning on an IBM System p partition with multiple hard disks containing different Linux distributions, the anaconda installer may overwrite the bootloaders of the other Linux installations although their hard disks have been unchecked. To work around this, choose manual partitioning during the installation process.