Phillip Susi wrote: > On 12/21/2011 1:53 PM, Jim Meyering wrote: >> FAIL: t8000-loop.sh (exit: 1) >> ============================= >> ... >> + d1=/h/j/w/co/parted/6/tests/gt-t8000-loop.sh.NpVB/root/dev/loop1 >> + parted -s >> /h/j/w/co/parted/6/tests/gt-t8000-loop.sh.NpVB/root/dev/loop1 >> mklabel msdos >> + fail=1 > > I guess you snipped the part with losetup? It sounds like your kernel > has the loop driver built as a module, but on Ubuntu it is built in.
It did when I wrote that code, but for the kernel I'm using now, it is built in. > I thought that running losetup automatically made the module load, but > maybe it doesn't? Back when I added those lines, they really were required. > Can you make sure that the loop module is loaded > when you run the test, and that losetup succeeded? > > Also, I don't understand the goofy paths there instead of > /dev/loop1. This must have something to do with that artificial root > setup in the lvm.sh I didn't quite grok. It probably shouldn't be > used in t8000. I think I'll try to write a proper common loop setup > function that handles the automatic cleanup the way scsi_debug does. > Then the other tests can start to migrate from scsi_debug to loop > instead which will allow them to run in parallel. I'd really like to have a way to run two or more scsi_debug-using tests in parallel but that is not possible: the kernel allows only one. Note that for many of our scsi-debug-using tests, you cannot duplicate the functionality using a loop device. Besides, even where you can, because we don't use e.g., special alignment or block size, you risk being unable to create a loop device due to inherent limitations, or, if you create a few because their tests are running in parallel, you risk perturbing regular processes that (albeit rarely) need to create a loop device. That is part of the reason for my using a private-homed device tree: there I know I'm starting from a clean slate: i.e., far less risk of interfering with some other loop-creating process.