Red Hat Bugzilla – Bug 198981
rpm and yum hang during kernel installation
Last modified: 2007-11-30 17:11:37 EST
Description of problem: While running "yum update", the operation hangs while installing the latest kernel: <a few lines deleted after "yum update"> Running Transaction Updating : libselinux ####################### [ 1/33] Updating : gtk2 ####################### [ 2/33] <more lines removed> Updating : selinux-policy ####################### [10/33] Installing: kernel ####################### [11/33] <no progress from this point> If I scan through "ps -ef", I see the following chain: UID PID PPID C STIME TTY TIME CMD root 2940 2512 2 11:38 pts/0 00:01:09 /usr/bin/python /usr/bin/yum update root 3176 2940 0 11:46 pts/0 00:00:00 /bin/sh /var/tmp/rpm-tmp.90001 3 root 3179 3176 0 11:46 pts/0 00:00:00 /bin/bash /sbin/new-kernel-pkg --package kernel --mkinitrd --depmod --install 2.6.17-1.2157_FC5 root 3189 3179 0 11:46 pts/0 00:00:00 /bin/bash --norc /sbin/mkinitrd --allow-missing -f /boot/initrd-2.6.17-1.2157_FC5.img 2.6.17-1.2157_FC5 root 3388 3189 0 11:46 pts/0 00:00:00 /bin/bash --norc /sbin/mkinitrd --allow-missing -f /boot/initrd-2.6.17-1.2157_FC5.img 2.6.17-1.2157_FC5 root 3389 3388 0 11:46 pts/0 00:00:00 lvs --noheadings -o vg_name hda3 The only way I have found to kill this is with <Ctrl>C. There are no logical volumes on this system. I had a hang on another system (also no logical volumes) running FC6test1 last night but I didn't confirm that it was hung on lvs. Version-Release number of selected component (if applicable): Trying to install kernel-2.6.17-1.2157_FC5.i686 mkinitrd-5.0.32-1 lvm2-2.02.01-1.2.1 How reproducible: Well, I haven't tried it on my FC5 system, but it always happened on my FC6T1 system regardless of whether I was using yum or rpm to install the kernel. Steps to Reproduce: 1. yum update or rpm -ivh kernel-2.6.17-1.2157_FC5.i686.rpm 2. wait a lot Actual results: It never finishes. Expected results: Additional info: On my FC6T1 system, I was trying to install kernel-2.6.17-1.2396.fc6 The following are installed there: lvm2-2.02.06-1.2.1 mkinitrd-5.0.47-1
Oops. I guess I am comparing apples to oranges between my FC5 and FC6T1 systems. After cleaning up the partially installed rpms on my FC5 system, I was able to get the 2157 kernel to install using rpm -ivh --replacepkgs kernel-2.6.17-1.2157_FC5.i686.rpm There was something wrong when yum tried to install this kernel, but using rpm overcame the problem (or one of the other rpms like selinux-policy fixed something). In the meantime, my FC6T1 system still hangs with rpm -ivh --replacepkgs kernel-2.6.17-1.2396.fc6.i686.rpm The chain of processes ends with UID PID PPID C STIME TTY TIME CMD root 2723 2374 0 20:24 pts/0 00:00:00 /bin/bash /sbin/new-kernel-pkg --package kernel --mkinitrd --depmod --install 2.6.17-1.2396.fc6 root 2725 2723 95 20:24 pts/0 00:03:54 /sbin/nash --forcequiet I am changing this to an FC6T1 problem. In the meantime, I recommend that if anyone else is having this problem that they should exclude the kernel update during their yum update: yum --exclude=kernel update This will keep the other rpms from becoming half installed. That is, the %post scripts for the other rpms don't run, so the RPM database shows that there are a lot of duplicate rpms installed.
I am experiencing the same initial problem with nash consuming 90 plus cpu usage when attempting to install the kernel. I am able to get the kernels to install by using killall -9 nash during updates and the kernel seems to install fine. Noting the above last command which apparently is supposed to kill nash, it does not --forcequit as it is supposed to. Is nash supposed to force quit itself or --forcequit something else? Successful kernels installed are below: (using killall -9 nash) rpm -q kernel kernel-2.6.17-1.2396.fc6 kernel-2.6.17-1.2401.fc6 This is not a fix of course, you should not need to do a killall on nash manually.
Yep. That's what I am seeing, too. Today I had the opportunity to install the next kernel, 2405.fc6 in my case. I saw high CPU usage by nash; killing the nash process allowed yum to finish. The default SIGTERM signal was enough to kill nash.
This problem was solved with changes to mkinitrd. signing off of ticket.