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