Chapter 4. Known Issues
4.1. anaconda
The anaconda package contains the program which was used to install your system.
The following are the Known Issues that apply to the anaconda package in Red Hat Enterprise Linux 5.7.
- Anaconda does not support XTS encryption for storage volumes. If you have existing XTS encrypted volumes, Anaconda will detect them as unpartitioned storage space and ask whether they should be initialized. Make sure to have Anaconda ignore any volumes with XTS encryption and configure them for use after installation.If you wish to set up new XTS volumes, you will need to do so after installation. Make sure to leave available storage space that you can allocate for the XTS encrypted volumes after installation. (BZ#718123)
- anaconda 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]
(BZ#530465) - Performing a System z installation, when the
install.imgis 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 forinstall.img. BZ#455929 - When installing to an
ext3orext4file system, anaconda disables periodic file system checking. Unlikeext2, 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
/varon a network file system (nfs,iSCSIdisk,nbd, etc.) This is because/varcontains the utilities required to bring up the network, for example/var/lib/dhcp. However, you may have/var/spool,/var/wwwor 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 InitiatorName=iqn.1994-05.com.fedora:d62f2d7c09f EOF
- Start iscsid:
$ iscsid
- 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 your
/partition:$ 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
chrootto 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.
*or@everythingis listed in the%packagessection of thekickstartfile) 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=1024x768orresolution=1280x1024" to the installer using the boot command line. - The NFS default for RHEL5 is "locking". Therefore, to mount
nfsshares from the%postsection of anaconda, use themount -o nolock,udpcommand to start the locking daemon before usingnfsto 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
dom0.To prevent the consumption of additional entitlements for guests, install therhn-virtualization-commonpackage 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. - Using the
swap --growparameter in akickstartfile without setting the--maxsizeparameter 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
vfatfile systems will appear as typeforeignin 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/etc/fstab. For details on how to do so, refer toman fstab. (BZ#467202) - 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.
The following note applies to PowerPC Architectures:
- The minimum RAM required to install Red Hat Enterprise Linux 5.7 is 1GB; the recommended RAM is 2GB. If a machine has less than 1GB RAM, the installation process may hang.Further, PowerPC-based machines that have only 1GB of RAM experience significant performance issues under certain RAM-intensive workloads. For a Red Hat Enterprise Linux 5.7 system to perform RAM-intensive processes optimally, 4GB of RAM is recommended. This ensures the system has the same number of physical pages as was available on PowerPC machines with 512MB of RAM running Red Hat Enterprise Linux 4.5 or earlier.
The following note applies to s390x Architectures:
- Installation on a machine with existing Linux or non-Linux file systems on DASD block devices may cause the installer to halt. If this happens, it is necessary to clear out all existing partitions on the DASD devices you want to use and restart the installer.
The following note applies to the ia64 Architecture:
- If your system only has 512MB of RAM, attempting to install Red Hat Enterprise Linux 5.4 may fail. To prevent this, perform a base installation first and install all other packages after the installation finishes. (BZ#435271)
