このコンテンツは選択した言語では利用できません。
Chapter 5. Known Issues
5.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
- anaconda sometimes crashes while attempting to install on a disk containing partitions or filesystems 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.img is located on direct access storage device (DASD) disk, will cause 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 install.img. BZ#455929
- When installing to an ext3 or ext4 file system, anaconda disables periodic filesystem checking. Unlike ext2, these filesystems are journaled, removing the need for a periodic filesystem check. In the rare cases where there is an error detected at runtime or an error while recovering the filesystem journal, the file system check will be run at boot time. (BZ#513480)
- Red Hat Enterprise Linux 5 does not support having a separate /var on a network filesystem (nfs, iscsi disk, nbd, etc.) This is because /var contains the utilities required to bring up the network, for example /var/lib/dhcp. However, you may have /var/spool, /var/www or the like on a separate network disk, just not the complete /var filesystem. 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 filesystem will not work and you need to configure iscsi and mount the filesystems manually. This only applies to manual 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 fs 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
- Now 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 chroot to the root fs 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 filesystems, especially the root filesystem, are directly visible to the host, a host OS reboot may inadvertantly parse the partition table and mount the guest filesystems. This can lead to highly undesirable outcomes. (BZ#518461)
- The minimum memory requirement when installing all Red Hat Enterprise Linux packages (i.e. '*' or '@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. (BZ#507891)
- 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 adaptor 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. (BZ#494033)
- 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 nfs shares from the %post section of anaconda, use the
mount -o nolock,udpcommand to start the locking daemon before using nfs 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 RHEL 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. (BZ#328471) - Using the
swap --growparameter in a kickstart file 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 harddisks containing different Linux distributions, the anaconda installer may overwrite the bootloaders of the other Linux installations although their harddisks have been unchecked. To work around this, choose manual partitioning during the installation process.(BZ#519795)
The following note applies to PowerPC Architectures:
- The minimum RAM required to install Red Hat Enterprise Linux 5.2 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.2 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. (BZ#209165)
The following note applies to s390x Architectures:
- Installation on a machine with existing Linux or non-Linux filesystems 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. (BZ#289631)
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)
