From Bugzilla Helper: User-Agent: Mozilla/4.76 [en] (X11; U; Linux 2.4.1-ac18 i686) mkinitrd hangs while running mke2fs on loop device. Running mke2fs in debugger, it's failing in zapbootblock(), in the write(). Running losetup (with no params) reports the loop device -> relationship, then IT hangs, most likely in the close() (lomount.c:95) Am using: losetup-2.10r-2 mount-2.10r-2 mkinitrd-3.0.5-2 kernel 2.4.2-pre{3,4} 2.4.1-ac13 and above. Have not built util-linux-2.10r that has new mount and new losetup yet. Reproducible: Always Steps to Reproduce: 1. Build a kernel. Run mkinitrd to make the image file. 2. Need to be running kernel 2.4.2-pre3 or later 3. Actual Results: Hangs that processes. Worst: can't do a shutdown afterwards, unless you're smart enough to unmount all fs's to read-only. Then, shutdown will hang, but it won't need a fsck... Expected Results: Works [root@cactus /proc]# losetup /dev/loop0 /dev/loop0: [0801]:99103 (/tmp/initrd.img.yR1IS0) offset 0, no encryption ^^losetup loosing it's lunch^^
Only the *stock* kernels have all the necessary loopback patches. When you build your own you're on your own (until these get fixed upstream). If the stock kernel in fisher doesn't work, please reopen.
Interestingly enough, applying Jakub's patch to 2.4.2-pre4 doesn't help it. I'm not sure why it would anyway, as it deals with changing the FD on the losetup'd file. How does an lseek to offset 0 followed by a write (to zap the boot sector) in mke2fs be affected by a patch that adds a 'change-fd ioctl' call? Anyway, 1) 2.4.0-0.99.11enterprise seems to work with the patch 2) 2.4.2-pre4 does not. And I'm not sure (see above) that the patch was trying to do anything specifically related to this issue. Which means if I'm right you might have problems with 2.4.2
we won't have a problem with 2.4.2 because we'll test it and fix it if it is broken. The only thing that we can support is the kernel as shipped with the release you're using.