Comment 7 for bug 1741096

I considered the fact that maybe the partitioned image that test-mic was
creating was somehow invalid. To test that, I modifed mount-image-callback
to set the mount device in MOUNT_DEV, and then did:

cp "$pt1" /tmp/part1.img
cp "$pt2" /tmp/part2.img
mount-image-callback --read-only --part=1 "$img_mbr" -- sh -c 'dd if=$MOUNT_DEV of=/tmp/part1.mbr.img'
mount-image-callback --read-only --part=2 "$img_mbr" -- sh -c 'dd if=$MOUNT_DEV of=/tmp/part2.mbr.img'
mount-image-callback --read-only --part=1 "$img_gpt" -- sh -c 'dd if=$MOUNT_DEV of=/tmp/part1.gpt.img'
mount-image-callback --read-only --part=2 "$img_gpt" -- sh -c 'dd if=$MOUNT_DEV of=/tmp/part2.gpt.img'

then an 'md5sum' shows that the 'dd'd image is identical to the partition image.

It seems to me that that validates the partition table and the data. I was
somewhat concerned that maybe my partition/sector math in test-mic was
truncating the partition or filesystem. that does not seem to be the case.

So, it seems that this is either an issue in
 a.) qemu-nbd
 b.) kernel
 c.) mount-image-callback assumptions on qemu-nbd usage.

for 'c', the assumption is that this is valid:
DEV=/dev/nbd0 # unused nbd device
BNAME=$(basename $DEV)
PARTNUM=2
PART_PATH=${DEV}p${PARTNUM}
FILE=/tmp/my-2partition-mbr.img
 1.) qemu-nbd --format=raw --connect $DEV $FILE
 2.) wait until a 'pid' file appears in /sys/block/$BNAME/pid)
 3.) wait until $PART_PATH exists
 4.) mount $PART_PATH to MOUNTPOINT
 5.) execute user code that operates on on MOUNTPOINT
 6.) umount MOUNTPOINT (and anything under it)
 7.) qemu-disconnect --disconnect $DEV

I have assumed that 'umount' would block until all file descriptors
are flushed to the backing /dev/nbd device, and that 'qemu-disconnect'
would block until any writes already sent were written through to the
backing file.