Bug 144441 - mkinitrd randomly fails to make initrd properly -- missing sync?
mkinitrd randomly fails to make initrd properly -- missing sync?
Product: Fedora Legacy
Classification: Retired
Component: mkinitrd (Show other bugs)
All Linux
medium Severity high
: ---
: ---
Assigned To: Peter Jones
: Patch
Depends On:
  Show dependency treegraph
Reported: 2005-01-06 21:11 EST by Matthew Miller
Modified: 2007-04-18 13:17 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-03-29 18:38:37 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
adds "sync; sleep 3" before umount (318 bytes, patch)
2005-01-06 21:15 EST, Matthew Miller
no flags Details | Diff
here's the right patch for FC2 (278 bytes, patch)
2005-01-06 21:59 EST, Matthew Miller
no flags Details | Diff

  None (edit)
Description Matthew Miller 2005-01-06 21:11:59 EST
Description of problem:

Often, when installing a new kernel, mkinitrd generates an empty (12k)
initrd, or one that is otherwise missing some parts. Behavior is
sporadic and can't be always reproduced.

Version-Release number of selected component (if applicable):

Definitely 3.5.22 on FC2 and 4.1.18 on FC3, and I assume 4.1.20 in
devel, since there's no particular patches to fix this.

I'm using the latest errata kernels in every case (but it's been this
way for the last few.)

How reproducible:

Sporadically, unfortunately

Steps to Reproduce:
1. run mkinitrd a bunch of times

Actual results:

sometimes, you won't get a full initrd

Expected results:

always a correct initrd

Additional info:

this also can affect the initrd generated as part of the anaconda
install process!

I believe that running sync before unmounting the temporary loopback
mount where the initrd is constructed solves the problem -- it has in
all my tries. It's hard to prove a negative, though, unless someone
can come along and defininitively say "The 2.6 kernel doesn't sync
loopback mounts when you umount them."
Comment 1 Matthew Miller 2005-01-06 21:15:29 EST
Created attachment 109452 [details]
adds "sync; sleep 3" before umount

The "sleep 3" may not be necessary, and is almost certainly overkill, but this
is a case where I'll wait three seconds just to be sure.
Comment 2 Matthew Miller 2005-01-06 21:20:49 EST
Adding Jeremy Katz to the CC list because this also affects anaconda
building (although in its own build scripts, not through mkinitrd).
Comment 3 Jeremy Katz 2005-01-06 21:31:13 EST
You realize that the code path you patched isn't used in any way
whatsoever with a default FC3 setup?  It'll only get used if you're
using a 2.4 kernel as otherwise, we do an initramfs and then there's
no use of loopback devices and mount/unmounting at all.

Comment 4 Matthew Miller 2005-01-06 21:48:16 EST
Doh! No, I didn't realize that. :) Trying too fast to solve the
problem, sorry. I noticed the code path change but clearly didn't
think as much of it as I should have. 

It's likely, then, that the problem doesn't exist on FC3. I admit most
of my testing was on FC2, and, um, now that I think about it, pretty
much every complaint I got was too. 

I'm pretty sure this is still necessary on FC2, though. Or else switch
to the newer mkinitrd and initramfs for FC2 (although, I guess the
sync should still be there for the old path). And also for the
anaconda build scripts, where initrd is still used.

Sorry about that. Everyone else in the world must have moved really
quickly to FC3, or else isn't updating their FC2 kernels. :)
Comment 5 Jeremy Katz 2005-01-06 21:53:23 EST
I haven't seen/heard any other reports of it or seen it at _all_ in
any of our test trees except when the loop module hasn't been loaded
for some reason.

(and new anaconda doesn't use an initrd anymore... I just didn't get
there in time for FC3)
Comment 6 Matthew Miller 2005-01-06 21:58:33 EST
Yeah, I saw that the devel tree anaconda doesn't; I'm currently
working from the nahant beta one, which does.

My problem was definitely not a lack of the loop module.

It's possible that this is something that's developed with newer
kernels -- I am running under the newest errata ones. Maybe when you
were working with FC3, it wasn't a problem.

The FC2 mkinitrd thing, though, you should be able to reproduce pretty
easily -- it happens to me an appreciable fraction of the time. (Not a
majority, but enough that you should be able to notice it. On several
very different machines.)
Comment 7 Matthew Miller 2005-01-06 21:59:56 EST
Created attachment 109455 [details]
here's the right patch for FC2
Comment 8 Barry K. Nathan 2005-01-07 11:05:11 EST
Like Jeremy, I've never seen this one, and if it was anything
widespread I probably would have by now. (Just speaking up so you know
you're not being ignored.)
Comment 9 Matthew Miller 2005-01-07 11:32:04 EST
I got several e-mails from people who have seen it occassionally.

Try doing `mkinitrd /tmp/tmpinitrd` over and over -- I can almost
guarantee you'll see it. (Again, FC2.)
Comment 10 Matthew Miller 2005-04-12 11:02:31 EDT
I think Fedora Legacy should consider this, since it *can* seriously screw up
kernel updates on FC2.
Comment 11 Pekka Savola 2005-11-16 08:22:37 EST
This doesn't seem to be important enough to fix just on its own, so mark it DEFER.

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