From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.5) Gecko/20011011 Description of problem: mkinitrd umount the loop-back file system carrying drivers without flushing it to the file. this results in a non-usable initrd image at boot time, so sometimes a boot failure, when the needed scsi driver is part of the modules. added a "sync" line just before the "umount $MNTPOINT" fixes the problem. the root cause is maybe located in the loop.c lopp-back driver itself. the bug-fix above is just a work-around. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. compile a new kernel (>=2.4.14) 2. install it (make install && make install_modules) 3. attempt to build a new initrd image with mkinitrd 4. reboot. Actual Results: in case the root fs is located on a scsi device, whose driver is not built-into the kernel, the boot sequence fails. Expected Results: scsi module found in the loopback image & boot successful Additional info: I know that RedHat 7.2 usually only carries kernel 2.4.7 by default. However, this fix is a matter of improving the robustness of the mkinitrd script.
Created attachment 38824 [details] An initrd file made by mkinitrd 3.2.6
An adjunct to the original report. mkinitrd had no problem building 2.4.15's initrd file. But it failed with 2.4.15-pre1 and beyond. Attached is what it builds for 2.4.16. I'm going to try Francois-Xavier's suggested patch...
Kernel bug; fixed in 2.4.16; never occured in any real Red Hat release.