Copyright (c) 2007 Red Hat, Inc. and others ^[[1]1] --------------------------------------------------------------------------- Introduction The following topics are covered in this document: o Installation-Related Notes o Feature Updates o Driver Updates o Kernel-Related Updates o Other Updates o Technology Previews o Resolved Issues o Known Issues Some updates on Red Hat Enterprise Linux 5.1 may not appear in this version of the Release Notes. An updated version may also be available at the following URL: [2]http://www.redhat.com/docs/manuals/enterprise/RHEL-5-manual/index.html Installation-Related Notes This section includes information specific to Anaconda and the installation of Red Hat Enterprise Linux 5.1. In order to upgrade an already-installed Red Hat Enterprise Linux 5, you must use Red Hat Network to update those packages that have changed. You may use Anaconda to perform a fresh installation of Red Hat Enterprise Linux 5.1 or to perform an upgrade from the latest updated version of Red Hat Enterprise Linux 5 to Red Hat Enterprise Linux 5.1. o When installing Red Hat Enterprise Linux 5.1 on a fully virtualized guest, do not use the kernel-xen kernel. Using this kernel on fully virtualized guests can cause your system to hang. If you are using an Installation Number when installing Red Hat Enterprise Linux 5.1 on a fully virtualized guest, be sure to deselect the Virtualization package group during the installation. The Virtualization package group option installs the kernel-xen kernel. Note that paravirtualized guests are not affected by this issue. Paravirtualized guests always use the kernel-xen kernel. o If you are using the Virtualized kernel when upgrading from Red Hat Enterprise Linux 5 to 5.1, you must reboot after completing the upgrade. The hypervisors of Red Hat Enterprise Linux 5 and 5.1 are not ABI-compatible. If you do not reboot between upgrades, the upgraded Virtualization RPMs will not match the running kernel. Installation / Boot for iSCSI software initiator (open-iscsi) iSCSI installation and boot was originally introduced in Red Hat Enterprise Linux 5 as a Technology Preview. This feature is now fully supported, with the restrictions described below. This capability has three configurations depending on whether you are: o using a hardware iSCSI initiator (such as the QLogic qla4xxx) o using the open-iscsi initiator on a system with firmware boot support for iSCSI (such as iSCSI Boot Firmware, or a version of Open Firmware that features the iSCSI boot capability) o using the open-iscsi initiator on a system with no firmware boot support for iSCSI Using a Hardware iSCSI Initiator If you are using a hardware iSCSI initiator, you can use the card's BIOS set-up utility to enter the IP address and other parameters required to obtain access to the remote storage. The logical units of the remote storage will be available in Anaconda as standard sd devices, with no additional set-up required. If you need to determine the initiator's qualified name (IQN) in order to configure the remote storage server, follow these steps during installation: 1. Go to the installer page where you select which disk drives to use for the installation. 2. Click on Advanced storage configuration. 3. Click on Add iSCSI target. 4. The iSCSI IQN will be displayed on that screen. Using open-iscsi On A System With Firmware Boot Support for iSCSI If you are using the open-iscsi software initiator on a system with firmware boot support for iSCSI, use the firmware's setup utility to enter the IP address and other parameters needed to access the remote storage. Doing this configures the system to boot from the remote iSCSI storage. Currently, Anaconda does not access the iSCSI information held by the firmware. Instead, you must manually enter the target IP address during installation. To do so, determine the IQN of the initiator using the procedure described above. Afterwards, on the same installer page where the initiator IQN is displayed, specify the IP address of the iSCSI target you wish to install to. After manually specifying the IP address of the iSCSI target, the logical units on the iSCSI targets will be available for installation. The initrd created by Anaconda will now obtain the IQN and IP address of the iSCSI target. If the IQN or IP address of the iSCSI target are changed in the future, enter the iBFT or Open Firmware set-up utility on each initiator and change the corresponding parameters. Afterwards, modify the initrd (stored in the iSCSI storage) for each initiator as follows: 1. Expand the initrd using gunzip. 2. Unpack it using cpio -i. 3. In the init file, search for the line containing the string iscsistartup. This line also contains the IQN and IP address of the iSCSI target; update this line with the new IQN and IP address. 4. Re-pack the initrd using cpio -o. 5. Re-compress the initrd using gunzip. The ability of the operating system to obtain iSCSI information held by the Open Firmware / iBFT firmware is planned for a future release. Such an enhancement will remove the need to modify the initrd (stored in the iSCSI storage) for each initiator whenever the IP address or IQN of the iSCSI target is changed. Using open-iscsi On A System With No Firmware Boot Support for iSCSI If you are using the open-iscsi software initiator on a system with no firmware boot support for iSCSI, use a network boot capability (such as PXE/tftp). In this case, follow the same procedure described earlier to determine the initiator IQN and specify the IP address of the iSCSI target. Once completed, copy the initrd to the network boot server and set up the system for network boot. Similarly, if the IP address or IQN of the iSCSI target is changed, the initrd should be modified accordingly as well. To do so, use the same procedure described earlier to modify the initrd for each initiator. Feature Updates EXT3 Enhancement The maximum capacity of the EXT3 is now 16TB (increased from 8TB). This enhancement was originally included in Red Hat Enterprise Linux 5 as a Technology Preview, and is now fully supported in this update. Anaconda layer 2 Mode Enhancement Restarting a Resource Independently It is now possible to restart a resource in a cluster without interrupting its parent service. This can be configured in /etc/cluster/cluster.conf on a running node using the __independent_subtree="1" attribute to tag a resource as independent. For example: