The first time the Release Notes button is clicked in Anaconda, a delay occurs while the window renders the Release Notes. During this delay, a seemingly empty list appears in the window. The rendering normally completes quickly, so most users may not notice this.
This delay is mostly due to the fact that the package installation phase is the most CPU-intensive phase of installation.
Host bus adapters that use the MegaRAID driver must be set to operate in "Mass Storage" emulation mode, not in "I2O" emulation mode. To do this, perform the following steps:
Enter the MegaRAID BIOS Set Up Utility.
Enter the Adapter settings menu.
Under Other Adapter Options, select Emulation and set it to Mass Storage.
If the adapter is incorrectly set to "I2O" emulation, the system will attempt to load the i2o driver. This will fail, and prevent the proper driver from being loaded.
Previous Red Hat Enterprise Linux releases generally do not attempt to load the I2O driver before the MegaRAID driver. Regardless of this, the hardware should always be set to "Mass Storage" emulation mode when used with Linux.
Laptops equipped with the Cisco Aironet MPI-350 wireless may hang trying to get a DHCP address during any network-based installation using the wired ethernet port.
To work around this, use local media for your installation. Alternatively, you can disable the wireless card in the laptop BIOS prior to installation (you can re-enable the wireless card after completing the installation).
Currently, system-config-kickstart does not support package selection and deselection. When using system-config-kickstart, the Package Selection option indicates that it is disabled. This is because system-config-kickstart uses yum to gather group information, but is unable to configure yum to connect to Red Hat Network.
At present, you need to update package sections in your kickstart files manually. When using system-config-kickstart to open a kickstart file, it will preserve all package information in it and write it back out when you save.
Boot-time logging to /var/log/boot.log is not available in this update of Red Hat Enterprise Linux 5. An equivalent functionality will be added in a future update.
When upgrading from Red Hat Enterprise Linux 4 to Red Hat Enterprise Linux 5, the Deployment Guide is not automatically installed. You need to use pirut to manually install it after completing the upgrade.
The system may not successfully reboot into a kexec/kdump kernel if X is running and using a driver other than vesa. This problem only exists with ATI Rage XL graphics chipsets.
If X is running on a system equipped with ATI Rage XL, ensure that it is using the vesa driver in order to successfully reboot into a kexec/kdump kernel.
When using Red Hat Enterprise Linux 5 on a machine with an nVidia CK804 chipset installed, the following kernel messages may appear:
kernel: assign_interrupt_mode Found MSI capability
kernel: pcie_portdrv_probe->Dev[005d:10de] has invalid IRQ. Check vendor BIOS
These messages indicate that certain PCI-E ports are not requesting IRQs. Further, these messages do not, in any way, affect the operation of the machine.
Using yum to install packages from the 32-bit Compatibility Layer disc may fail. If it does, it is because the Red Hat package signing key was not imported into the RPM database. This happens if you have not yet connected to Red Hat Network and obtained updates. To import the key manually, run the following command as root:
rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release
Once the Red Hat GPG key is imported, you may now use yum to install packages from the 32-bit Compatibility Layer disc.
Note that when installing from this disc, it is advisable to use yum instead of rpm to ensure that base OS dependencies are addressed during installation.
Removable storage devices (such as CDs and DVDs) do not automatically mount when you are logged in as root. As such, you will need to manually mount the device through the graphical file manager.
Alternatively, you can run the following command to mount a device to /media:
mount /dev/<device name> /media
The IBM System z does not provide a traditional Unix-style physical console. As such, Red Hat Enterprise Linux 5 for the IBM System z does not support the firstboot functionality during initial program load.
To properly initialize setup for Red Hat Enterprise Linux 5 on the IBM System z, run the following commands after installation:
When upgrading from Red Hat Enterprise Linux 5 to Red Hat Enterprise Linux 5.1 via Red Hat Network, yum may not prompt you to import the redhat-beta key. As such, it is advised that you import the redhat-beta key manually prior to upgrading. To do this, run the following command:
rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-beta
When a LUN is deleted on a configured filer, the change is not reflected on the host. In such cases, lvm commands will hang indefinitely when dm-multipath is used, as the LUN has now become stale.
To work around this, delete all device and mpath link entries in /etc/lvm/.cache specific to the stale LUN.
To find out what these entries are, run the following command:
ls -l /dev/mpath | grep <stale LUN>
For example, if <stale LUN> is 3600d0230003414f30000203a7bc41a00, the following results may appear:
lrwxrwxrwx 1 root root 7 Aug 2 10:33 /3600d0230003414f30000203a7bc41a00 -> ../dm-4
lrwxrwxrwx 1 root root 7 Aug 2 10:33 /3600d0230003414f30000203a7bc41a00p1 -> ../dm-5
This means that 3600d0230003414f30000203a7bc41a00 is mapped to two mpath links: dm-4 and dm-5.
As such, the following lines should be deleted from /etc/lvm/.cache:
/dev/dm-4
/dev/dm-5
/dev/mapper/3600d0230003414f30000203a7bc41a00
/dev/mapper/3600d0230003414f30000203a7bc41a00p1
/dev/mpath/3600d0230003414f30000203a7bc41a00
/dev/mpath/3600d0230003414f30000203a7bc41a00p1
When attempting to create a fully virtualized Windows™ guest from a CD or DVD, the second stage of the guest install might not continue upon reboot.
To work around this, edit /etc/xen/<name of guest machine> by properly appending an entry for the CD / DVD device.
If an installation to a simple file is used as a virtual device, the disk line of /etc/xen/<name of guest machine> will read like the following:
disk = [ 'file:/PATH-OF-SIMPLE-FILE,hda,w']
A DVD-ROM device located on the host as /dev/dvd can be made available to stage 2 of the installation as hdc by appending an entry like 'phy:/dev/dvd,hdc:cdrom,r'. As such, the disk line should now read as follows:
disk = [ 'file:/opt/win2003-sp1-20061107,hda,w', 'phy:/dev/dvd,hdc:cdrom,r']
The precise device path to use may vary depending on your hardware.
If the sctp module is not added to the kernel, running netstat with the -A inet or -A inet6 option abnormally terminates with the following message:
netstat: no support for `AF INET (sctp)' on this system.
To avoid this, install the sctp kernel module.
Current kernels do not assert Data Terminal Ready (DTR) signals before printing to serial ports during boot time. DTR assertion is required by some devices; as a result, kernel boot messages are not printed to serial consoles on such devices.
The AMD 8132 and HP BroadCom HT100 used on some platforms (such as the HP dc7700) do not support MMCONFIG cycles. If your system uses either chipset, your PCI configuration should use the legacy PortIO CF8/CFC mechanism. To configure this, boot the system with the kernel parameter -pci nommconfig during installation and add pci=nommconf to GRUB after rebooting.
Further, the AMD 8132 chipset does not support Message Signaled Interrupts (MSI). If your system uses this chipset, you should also disable MSI. To do this, use the kernel parameter -pci nomsi during installation and add pci=nomsi to GRUB after rebooting.
However, if your specific platform is already blacklisted by the kernel, your system does not require the aforementioned pci kernel parameters. The following HP platforms are already blacklisted by the kernel:
DL585g2
dc7500
xw9300
xw9400
The Virtual Machine Manager (virt-manager) included in this release does not allow users to specify additional boot arguments to the paravirtualized guest installer. This is true even when such arguments are required to install certain types of paravirtualized guests on specific types of hardware.
This issue will be addressed in a future release of virt-manager. To specify arbitrary kernel arguments in installing paravirtualized guests from the command line, use virt-install.
By default, the Itanium dom0 virtualized kernel boots up with 512MB RAM and one CPU. You can override this on the hypervisor command line using the dom0_mem and dom0_max_vcpus parameters. For example, you can set dom0 to boot with 4GB of RAM and 8 CPUs using the parameters dom0_mem=4G dom0_max_vcpus=8.
For Red Hat Enterprise Linux 5, the maximum supported value for dom0_mem is 256G. The maximum supported value for dom0_max_vcpus is 32.
However, setting dom0 to boot with the actual amount of RAM the system has may result in a kernel panic. This is because there is likely to be slightly less than the full RAM actually available for dom0 to use. At present, the hypervisor is unable to handle this situation gracefully.
As such, if the system has x amount of RAM, it is not advisable to use dom0_mem=x.
On some Itanium systems configured for console output to VGA, the dom0 virtualized kernel may fail to boot. This is because the virtualized kernel failed to properly detect the default console device from the Extensible Firmware Interface (EFI) settings.
When this occurs, you can work around this by adding the boot parameter console=tty to the kernel boot options in /boot/efi/elilo.conf.
On some Itanium systems, X may fail to start on the VGA console. This is because the system memory layout does not prevent X from attempting to utilize memory regions incompatible to its needs. This can cause a Machine Check Abort (MCA), while in some cases X will simply fail with an X log entry of xf86MapDomainMem(): mmap() failure.
It is recommended that you boot affected systems in runlevel 3, and any necessary X applications should be run within a VNC X server or over X11-forwarding on a remote host. Both bare-metal and virtualized kernels are affected by this issue.
This issue will be resolved in an upcoming minor update of Red Hat Enterprise Linux 5. Testing results confirm that the issue should only manifest on Itanium systems with more than 128 PCI devices. This behavior is consistent with X on Red Hat Enterprise Linux 5.
With the default dm-multipath configuration, Netapp devices may take several minutes to complete failback after a previously failed path is restored. To resolve this problem, add the following Netapp device configuration to the devices section of the multipath.conf file:
devices {
device {
vendor "NETAPP"
product "LUN"
getuid_callout "/sbin/scsi_id -g -u -s /block/%n"
prio_callout "/sbin/mpath_prio_netapp /dev/%n"
features "1 queue_if_no_path"
hardware_handler "0"
path_grouping_policy group_by_prio
failback immediate
rr_weight uniform
rr_min_io 128
path_checker directio
}
Red Hat Summit