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 <[log in to unmask]>
> Date:
> Thu, 25 Sep 2008 15:11:59 -0500
> To:
> "[log in to unmask]" <[log in to unmask]>
>
> To:
> "[log in to unmask]" <[log in to unmask]>
>
>
> 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 [log in to unmask] (630)840-6468
Fermilab ComputingDivision/LCSI/CSI DSS Group
__________________________________________________
|
