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 > >