Hi Troy,
Thank you.
>
> Which version of nash do you have installed? It seems to be a factor.
>
>From my workstation/desktop:
$ rpm -qa | grep nash
nash-5.1.19.6-28.x86_64
The nash base version is consistent between the systems (ignoring
architecture) for my workstation and sacrificial test boxes as well
as our platform validation boxes.
>
> Also, what happens if you run the affected command by hand.
>
Well, precisely the same thing as the package install/update did:
$ rpm -q --scripts kernel | grep mkinit
/sbin/new-kernel-pkg --package kernel --mkinitrd --depmod --install 2.6.18-92.1.10.el5 || exit $?
/sbin/new-kernel-pkg --package kernel --mkinitrd --depmod --install 2.6.18-92.1.13.el5 || exit $?
$
$ sudo /sbin/new-kernel-pkg --package kernel --mkinitrd --depmod --install 2.6.18-92.1.13.el5
/sbin/mkinitrd: line 368: cd: slaves: No such file or directory
The mkinitrd process then consumes one complete cpu and makes no
apparent progress; eventually you need (really want) to kill the
mkinitrd process to free the cpu.
Thoughts and/or suggestions... ?
Thank you again, and my best regards,
==> dave
On Wed, 2008-10-01 at 10:11 -0500, Troy Dawson wrote:
> 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
>
>
|
