Red Hat Bugzilla – Bug 144441
mkinitrd randomly fails to make initrd properly -- missing sync?
Last modified: 2007-04-18 13:17:56 EDT
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.)
Steps to Reproduce:
1. run mkinitrd a bunch of times
sometimes, you won't get a full initrd
always a correct initrd
this also can affect the initrd generated as part of the anaconda
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."
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.
Adding Jeremy Katz to the CC list because this also affects anaconda
building (although in its own build scripts, not through mkinitrd).
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.
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. :)
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)
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.)
Created attachment 109455 [details]
here's the right patch for FC2
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.)
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.)
I think Fedora Legacy should consider this, since it *can* seriously screw up
kernel updates on FC2.
This doesn't seem to be important enough to fix just on its own, so mark it DEFER.