Yet another mystery - cloop bug ?

[mack]

While remastering with a new kernel (2.4.22-pre7) I've hit a strange situation. Initrd's linuxrc starts running and gets stuck. I added -x to linuxrc, to see what its doing when it gets stuck, and it turned out to be always in the same place, during some cp command. Note that its not the first cp command. Files have already been read from the mounted cloop before it got stuck.

I tried replacing the cloop'ed image with an uncompressed iso image and have linuxrc attach it to /dev/loop2 and mount it instead of using cloop, and everything works, so the problem is with cloop. It was the only thing different between the two boots.

I tested the cloop'ed image with the same cloop.o module under the same kernel but not from initrd, and the same cp command works fine. I even tar'ed the whole filesystem from it just to make sure there are no errors. Everything seems fine.

Its a strange bug that only happens when cloop is used for the actual /KNOPPIX during boot. When /KNOPPIX is the same image, uncompressed, and cloop is later attached and mounted as /mnt/test, cloop image is identical to the mounted /KNOPPIX.

By the way, if I'm trying to execute something from /KNOPPIX at some point before this cp, it gets stuck on exec. (I tried to exec strace from the mounted cloop device to trace whats going on).

I'm using the latest cloop version, 0.68, compiled under kernel 2.4.22-pre7.

Any suggestions on how to debug it ?

[garyng]

not an easy task. This sounds similar with what I have encountered with the 1.X NTFS driver. Only when putting together, it doesn't work but tracking down where it went wrong is tough. I believe only the guys on the kernel list can help.