Release Notes
40
Stopping disk encryption [FAILED]
This message can safely be ignored, the shutdown process will complete successfully.
• When using an encrypted device, the following error message may be reported during bootup:
insmod: error inserting '/lib/aes_generic.ko': -1 File exists
This message can safely be ignored.
• Installation using a Multiple Device (MD) RAID on top of multipath will result in a machine that
cannot boot. Multipath to Storage Area Network (SAN) devices which provide RAID internally are
not affected.
• When a large number of LUNs are added to a node, multipath can significantly increase the time it
takes for udev to create device nodes for them. If you experience this problem, you can correct it by
deleting the following line in
/etc/udev/rules.d/40-multipath.rules
:
KERNEL!="dm-[0-9]*", ACTION=="add", PROGRAM=="/bin/bash -c '/sbin/lsmod
| /bin/grep ^dm_multipath'", RUN+="/sbin/multipath -v0 %M:%m"
This line causes udev to run multipath every time a block device is added to the node. Even with this
line removed, multipathd will still automatically create multipath devices, and multipath will still be
called during the boot process, for nodes with multipathed root filesystems. The only change is that
multipath devices will not be automatically created when multipathd is not running, which should not
be a problem for the vast majority of multipath users.
• When upgrading from an earlier version of Red Hat Enterprise Linux to 5.3, you may encounter the
following error:
Updating : mypackage ################### [ 472/1655]
rpmdb: unable to lock mutex: Invalid argument
The cause of the locking issue is that the shared futex locking in glibc was enhanced with per-
process futexes between 5.2 and 5.3. As a result, programs running against the 5.2 glibc can not
properly perform shared futex locking against programs running with the 5.3 glibc.
This particular error message is a side effect of a package calling rpm as part of its install scripts.
The rpm instance performing the upgrade is using the prior glibc throughout the upgrade, but the
rpm instance launched from within the script is using the new glibc.
To avoid this error, upgrade glibc first in a separate run:
# yum update glibc
Summary of Contents for ENTERPRISE LINUX 5.3 - RELEASE MANIFEST
Page 240: ...240 ...
