Hi Dave,
I haven't seen this but I also haven't been looking to closely for it, but I
will now.
Which version of nash do you have installed? It seems to be a factor.
Also, what happens if you run the affected command by hand.
You can find this by doing
rpm -q --scripts kernel
or more precisely
rpm -q --scripts kernel | grep mkinit
Troy
dave peck wrote:
Hello All,
I seem to have run into a somewhat known "mkinitrd" problem when
attempting the latest SL5.x i386/x86_64 Kernel update from:
2.6.18-92.1.10.el5 to 2.6.18-92.1.13.el5. (see attached errata from
Troy).
I'm getting an 'yum update' log showing:
...
Trying other mirror.
(1/4): kernel-devel-2.6.1 100% |=========================| 5.0
MB 00:04
(2/4): kernel-doc-2.6.18- 100% |=========================| 2.9
MB 00:02
(3/4): kernel-2.6.18-92.1 100% |=========================| 16
MB 00:15
(4/4): kernel-headers-2.6 100% |=========================| 883
kB 00:01
Running rpm_check_debug
Running Transaction Test
Finished Transaction Test
Transaction Test Succeeded
Running Transaction
Installing: kernel-devel
######################### [1/6]
Updating : kernel-headers
######################### [2/6]
Installing: kernel
######################### [3/6]
/sbin/mkinitrd: line 368: cd: slaves: No such file or directory
At this point in the update process, mkinitrd then consumes all of its
available CPU until it is manually terminated as well as it's attendant
processes (uni-processors beware) .
This problem appears quite similar to the issue being reported as:
<https://bugzilla.redhat.com/show_bug.cgi?id=447841#c6>
In any event, my test systems are (my) workstation and our platform
validation machines running the 2.6.18-92.1.10 PAE kernel to match our
lab systems.
Running Config : SL 5.2.x
mkinitrd-5.1.19.6-28.i386 / mkinitrd-5.1.19.6-28.x86_64
kernel-2.6.18-92.1.10.el5 / kernel-2.6.18-92.1.10.el5.x86_64
These systems do _not_ run any 'mounted' encrypted file-systems, but key
file-systems: '/boot' (ext2) and '/' (ext3) do run on dm mirrors and are
then under LVM management.
I'm wondering if others are seeing this same regressive 'kernel update'
behaviour, or if it is limited to my systems.
Thank you, and my very best regards,
==> dave
------------------------------------------------------------------------
Subject:
Security ERRATA for kernel on SL5.x i386/x86_64
From:
Troy J Dawson <[EMAIL PROTECTED]>
Date:
Thu, 25 Sep 2008 15:11:59 -0500
To:
"[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
To:
"[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
Synopsis: Important: kernel security and bug fix update
Issue date: 2008-09-24
CVE Names: CVE-2008-2931 CVE-2008-3275 CVE-2007-6417
CVE-2007-6716 CVE-2008-3272
Security fixes:
* a missing capability check was found in the Linux kernel do_change_type
routine. This could allow a local unprivileged user to gain privileged
access or cause a denial of service. (CVE-2008-2931, Important)
* a flaw was found in the Linux kernel Direct-IO implementation. This could
allow a local unprivileged user to cause a denial of service.
(CVE-2007-6716, Important)
* Tobias Klein reported a missing check in the Linux kernel Open Sound
System (OSS) implementation. This deficiency could lead to a possible
information leak. (CVE-2008-3272, Moderate)
* a deficiency was found in the Linux kernel virtual filesystem (VFS)
implementation. This could allow a local unprivileged user to attempt file
creation within deleted directories, possibly causing a denial of service.
(CVE-2008-3275, Moderate)
* a flaw was found in the Linux kernel tmpfs implementation. This could
allow a local unprivileged user to read sensitive information from the
kernel. (CVE-2007-6417, Moderate)
Bug fixes:
* when copying a small IPoIB packet from the original skb it was received
in to a new, smaller skb, all fields in the new skb were not initialized.
This may have caused a kernel oops.
* previously, data may have been written beyond the end of an array,
causing memory corruption on certain systems, resulting in hypervisor
crashes during context switching.
* a kernel crash may have occurred on heavily-used Samba servers after 24
to 48 hours of use.
* under heavy memory pressure, pages may have been swapped out from under
the SGI Altix XPMEM driver, causing silent data corruption in the kernel.
* the ixgbe driver is untested, but support was advertised for the Intel
82598 network card. If this card was present when the ixgbe driver was
loaded, a NULL pointer dereference and a panic occurred.
* on certain systems, if multiple InfiniBand queue pairs simultaneously
fell into an error state, an overrun may have occurred, stopping traffic.
* with bridging, when forward delay was set to zero, setting an interface
to the forwarding state was delayed by one or possibly two timers,
depending on whether STP was enabled. This may have caused long delays in
moving an interface to the forwarding state. This issue caused packet loss
when migrating virtual machines, preventing them from being migrated
without interrupting applications.
* on certain multinode systems, IPMI device nodes were created in reverse
order of where they physically resided.
* process hangs may have occurred while accessing application data files
via asynchronous direct I/O system calls.
* on systems with heavy lock traffic, a possible deadlock may have caused
anything requiring locks over NFS to stop, or be very slow. Errors such as
"lockd: server [IP] not responding, timed out" were logged on client
systems.
* unexpected removals of USB devices may have caused a NULL pointer
dereference in kobject_get_path.
* on Itanium-based systems, repeatedly creating and destroying Windows
guests may have caused Dom0 to crash, due to the "XENMEM_add_to_physmap"
hypercall, used by para-virtualized drivers on HVM, being SMP-unsafe.
* when using an MD software RAID, crashes may have occurred when devices
were removed or changed while being iterated through. Correct locking is
now used.
* break requests had no effect when using "Serial Over Lan" with the Intel
82571 network card. This issue may have caused log in problems.
* on Itanium-based systems, module_free() referred the first parameter
before checking it was valid. This may have caused a kernel panic when
exiting SystemTap.
SL 5.x
SRPMS:
kernel-2.6.18-92.1.13.el5.src.rpm
i386:
kernel-2.6.18-92.1.13.el5.i686.rpm
kernel-debug-2.6.18-92.1.13.el5.i686.rpm
kernel-debug-devel-2.6.18-92.1.13.el5.i686.rpm
kernel-devel-2.6.18-92.1.13.el5.i686.rpm
kernel-doc-2.6.18-92.1.13.el5.noarch.rpm
kernel-PAE-2.6.18-92.1.13.el5.i686.rpm
kernel-PAE-devel-2.6.18-92.1.13.el5.i686.rpm
kernel-xen-2.6.18-92.1.13.el5.i686.rpm
kernel-xen-devel-2.6.18-92.1.13.el5.i686.rpm
Dependancies:
kernel-module-fuse-2.6.18-92.1.13.el5-2.6.3-1.sl5.i686.rpm
kernel-module-fuse-2.6.18-92.1.13.el5PAE-2.6.3-1.sl5.i686.rpm
kernel-module-fuse-2.6.18-92.1.13.el5xen-2.6.3-1.sl5.i686.rpm
kernel-module-ipw3945-2.6.18-92.1.13.el5-1.2.0-2.sl5.i686.rpm
kernel-module-ipw3945-2.6.18-92.1.13.el5PAE-1.2.0-2.sl5.i686.rpm
kernel-module-ipw3945-2.6.18-92.1.13.el5xen-1.2.0-2.sl5.i686.rpm
kernel-module-madwifi-2.6.18-92.1.13.el5-0.9.4-15.sl5.i686.rpm
kernel-module-madwifi-2.6.18-92.1.13.el5PAE-0.9.4-15.sl5.i686.rpm
kernel-module-madwifi-2.6.18-92.1.13.el5xen-0.9.4-15.sl5.i686.rpm
kernel-module-madwifi-hal-2.6.18-92.1.13.el5-0.9.4-15.sl5.i686.rpm
kernel-module-madwifi-hal-2.6.18-92.1.13.el5PAE-0.9.4-15.sl5.i686.rpm
kernel-module-madwifi-hal-2.6.18-92.1.13.el5xen-0.9.4-15.sl5.i686.rpm
kernel-module-ndiswrapper-2.6.18-92.1.13.el5-1.53-1.SL.i686.rpm
kernel-module-ndiswrapper-2.6.18-92.1.13.el5PAE-1.53-1.SL.i686.rpm
kernel-module-ndiswrapper-2.6.18-92.1.13.el5xen-1.53-1.SL.i686.rpm
kernel-module-openafs-2.6.18-92.1.13.el5-1.4.7-68.SL5.i686.rpm
kernel-module-openafs-2.6.18-92.1.13.el5PAE-1.4.7-68.SL5.i686.rpm
kernel-module-openafs-2.6.18-92.1.13.el5xen-1.4.7-68.SL5.i686.rpm
kernel-module-xfs-2.6.18-92.1.13.el5-0.4-1.sl5.i686.rpm
kernel-module-xfs-2.6.18-92.1.13.el5PAE-0.4-1.sl5.i686.rpm
kernel-module-xfs-2.6.18-92.1.13.el5xen-0.4-1.sl5.i686.rpm
x86_64:
kernel-2.6.18-92.1.13.el5.x86_64.rpm
kernel-debug-2.6.18-92.1.13.el5.x86_64.rpm
kernel-debug-devel-2.6.18-92.1.13.el5.x86_64.rpm
kernel-devel-2.6.18-92.1.13.el5.x86_64.rpm
kernel-doc-2.6.18-92.1.13.el5.noarch.rpm
kernel-headers-2.6.18-92.1.13.el5.x86_64.rpm
kernel-xen-2.6.18-92.1.13.el5.x86_64.rpm
kernel-xen-devel-2.6.18-92.1.13.el5.x86_64.rpm
Dependancies:
kernel-module-fuse-2.6.18-92.1.13.el5-2.6.3-1.sl5.x86_64.rpm
kernel-module-fuse-2.6.18-92.1.13.el5xen-2.6.3-1.sl5.x86_64.rpm
kernel-module-ipw3945-2.6.18-92.1.13.el5-1.2.0-2.sl5.x86_64.rpm
kernel-module-ipw3945-2.6.18-92.1.13.el5xen-1.2.0-2.sl5.x86_64.rpm
kernel-module-madwifi-2.6.18-92.1.13.el5-0.9.4-15.sl5.x86_64.rpm
kernel-module-madwifi-2.6.18-92.1.13.el5xen-0.9.4-15.sl5.x86_64.rpm
kernel-module-madwifi-hal-2.6.18-92.1.13.el5-0.9.4-15.sl5.x86_64.rpm
kernel-module-madwifi-hal-2.6.18-92.1.13.el5xen-0.9.4-15.sl5.x86_64.rpm
kernel-module-ndiswrapper-2.6.18-92.1.13.el5-1.53-1.SL.x86_64.rpm
kernel-module-ndiswrapper-2.6.18-92.1.13.el5xen-1.53-1.SL.x86_64.rpm
kernel-module-openafs-2.6.18-92.1.13.el5-1.4.7-68.SL5.x86_64.rpm
kernel-module-openafs-2.6.18-92.1.13.el5xen-1.4.7-68.SL5.x86_64.rpm
kernel-module-xfs-2.6.18-92.1.13.el5-0.4-1.sl5.x86_64.rpm
kernel-module-xfs-2.6.18-92.1.13.el5xen-0.4-1.sl5.x86_64.rpm
-Connie Sieh
-Troy Dawson
--
__________________________________________________
Troy Dawson [EMAIL PROTECTED] (630)840-6468
Fermilab ComputingDivision/LCSI/CSI DSS Group
__________________________________________________
