This service will be undergoing maintenance at 00:00 UTC, 2016-09-28. It is expected to last about 1 hours
Bug 439591 - kernel update fails (hangs forever) while executing mkinitrd
kernel update fails (hangs forever) while executing mkinitrd
Product: Fedora
Classification: Fedora
Component: mkinitrd (Show other bugs)
x86_64 Linux
low Severity medium
: ---
: ---
Assigned To: Peter Jones
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2008-03-29 09:08 EDT by Dieter Bürßner
Modified: 2009-01-09 01:16 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-01-09 01:16:57 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:

Attachments (Terms of Use)
output of mkinitrd (8.45 KB, text/plain)
2008-07-03 08:20 EDT, Ricardo Veguilla
no flags Details

  None (edit)
Description Dieter Bürßner 2008-03-29 09:08:02 EDT
Description of problem:
kernel update always fails (hangs forever) on my system while executing mkinitrd

Version-Release number of selected component (if applicable):
update from kernel #1 SMP Tue Oct 30 13:18:33 EDT 2007 x86_64
x86_64 x86_64 
mkinitrd: version 6.0.19
How reproducible:
Since a while any (atuomatically triggered) kernel update failed. Maybe any
kernel update at all, since I installed Fedora 8

Steps to Reproduce:
1. When a kernel update is available, it fails (using pup, I believe)
Actual results:
processes are hanging

Expected results:
updated installed kernel

Additional info:
Here the process list of relevant processes, when the update process hangs, late
on the shell script, that was executed from /var/tmp:

0 S buers     8600  3312  0  80   0 - 31803 wait   13:16 ?        00:00:00
/usr/bin/python /usr/bin/getproxy /usr/bin/pup
0 S buers     8601  8600  0  80   0 - 47855 -      13:16 ?        00:00:00
4 S root      8608  8601  0  80   0 - 31256 wait   13:16 ?        00:00:00
/usr/sbin/userhelper -w pup
4 S root      8683  8608  4  80   0 - 171803 futex_ 13:16 ?       00:01:29
/usr/bin/python -tt /usr/sbin/pup
0 S root     24377  8683  0  80   0 - 21246 wait   13:36 ?        00:00:00
/bin/sh /var/tmp/rpm-tmp.36415 3
0 S root     24381 24377  0  80   0 - 21246 wait   13:36 ?        00:00:00
/bin/bash /sbin/new-kernel-pkg --package kernel --mkinitrd --depmod --install
0 S root     24390 24381  0  80   0 - 21408 pipe_w 13:36 ?        00:00:00
/bin/bash --norc /sbin/mkinitrd --allow-missing -f
1 S root     24464 24390  0  80   0 - 21408 pipe_w 13:36 ?        00:00:00
/bin/bash --norc /sbin/mkinitrd --allow-missing -f
1 S root     24465 24464  0  80   0 - 21408 wait   13:36 ?        00:00:00
/bin/bash --norc /sbin/mkinitrd --allow-missing -f
4 D root     24467 24465  0  80   0 - 14059 blk_ex 13:36 ?        00:00:00
/sbin/nash --forcequiet

File /var/tmp/rpm-tmp.36415:
if [ `uname -i` == "x86_64" -o `uname -i` == "i386" ] &&
   [ -f /etc/sysconfig/kernel ]; then
  /bin/sed -i -e 's/^DEFAULTKERNEL=kernel-smp$/DEFAULTKERNEL=kernel/'
/etc/sysconfig/kernel || exit $?
/sbin/new-kernel-pkg --package kernel --mkinitrd --depmod --install || exit $?
#if [ -x /sbin/weak-modules ]
#    /sbin/weak-modules --add-kernel || exit $?
Comment 1 Warren Togami 2008-03-29 19:34:37 EDT
This is not enough information to possibly diagnose the problem.  Could you
please run mkinitrd manually with the -v parameter and paste the entire output
into an attachment here?
Comment 2 Dieter Bürßner 2008-03-30 02:05:42 EDT
I am sorry, I said it hang several times forever, but actually I had not enough 
patience. After about 2 hours, the kernel update succeeded. So this seems only 
a performance issue (and a minor user interface isssue, because the updater GUI 
did not redraw for over an hour, so one has to think, that it hangs).

You asked me, to call mkinitrd manually, but with which arguments besides -v? 
Can it be run in any directory? Any provision to not destroy my installation or 
to have a fallback? As you can see from ps output, 3 instances of mkinitrd are 
running in parallel, and possibly are piped together with some other processes.
Comment 3 Haakon Riiser 2008-07-02 08:12:44 EDT
This problem also affects me on every Fedora system I have, regardless of Fedora
version (I believe Fedora 6 - 9 have all had this problem), and it happens both
on 32-bit and 64-bit.  Kernel upgrades take forever for no apparent reason.  The
CPU load is almost at zero and strace shows no activity in nash.  What is
mkinitrd doing that takes so long time?  It doesn't take hours for me, probably
less than a minute, but that is still _way_ longer than any other package on the
Comment 4 Ricardo Veguilla 2008-07-03 08:20:17 EDT
Created attachment 310916 [details]
output of mkinitrd

I'm having the same problem on Fedora 9 x86_64. Here is the output of timed
output of "mkinitrd -v ...".
Comment 5 Andreas Weggel 2008-11-10 12:13:15 EST
I have the same problem on Fedora 10 x86_64.

mkinitrd -v /boot/initrd-
Creating initramfs

That's everything it outputs
Comment 6 Bug Zapper 2008-11-26 05:18:22 EST
This message is a reminder that Fedora 8 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 8.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '8'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 8's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 8 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here:
Comment 7 Bug Zapper 2009-01-09 01:16:57 EST
Fedora 8 changed to end-of-life (EOL) status on 2009-01-07. Fedora 8 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

Note You need to log in before you can comment on or make changes to this bug.