I successfully ran the test case against ubuntu20.9 in -proposed. I also verified that using losetup and mount on loop devices still works:
$ sudo losetup -f --show debian-stretch-DI-alpha7-amd64-netinst.iso /dev/loop0 $ sudo mount /dev/loop0 /mnt mount: block device /dev/loop0 is write-protected, mounting read-only $ ls /mnt autorun.inf debian [...] With the -proposed version, losetup -f also succeeds to use /dev/loop- control, so you can do the above a few times and it works with /dev/loop12 too. When moving /dev/loop-control out of the way, the above also works up to loop7, and then errors out with "losetup: could not find any free loop device" as expected. "losetup -a" correctly shows the bound devices/files. ** Tags removed: verification-failed ** Tags added: verification-needed ** Tags removed: verification-needed ** Tags added: verification-done -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to util-linux in Ubuntu. https://bugs.launchpad.net/bugs/1640823 Title: [trusty] mount -o loop is limited to 8 loop devices Status in util-linux package in Ubuntu: Fix Released Status in util-linux source package in Trusty: Fix Committed Bug description: trusty has a very old util-linux which does not yet know about /dev /loop-control to create arbitrarily many loop devices. This feature was introduced in Linux 3.1 already (i. e. before precise even). This is a showstopper for backporting snappy as that needs a lot of loop mounts. Support for loop-control got introduced later util-linux versions, but backporting full support for it (for losetup) is too intrusive. We only need a partial backport for "mount -o loop". SRU TEST CASE: First, use up all default 8 loop devices: $ for i in `seq 8`; do echo $i; sudo losetup --find /etc/issue; done Now try to use a 9th: $ dd if=/dev/zero of=/tmp/img bs=1M count=50 $ mkfs.ext2 -F /tmp/img $ sudo mount -o loop /tmp/img /mnt With current trusty's "mount" package this will fail with "could not find any free loop device". With the proposed version, this should succeed, and "sudo losetup -a" should show "/dev/loop8: ... (/tmp/img)". Now, reboot, disable loop-control with sudo mv /dev/loop-control{,.disabled} and run the test case again. Now "mount -o loop" should fail with "could not find any free loop device" (as before). Ensure that there are no hangs, infinite loops, etc. ADDITIONAL REGRESSION CHECKING TEST CASES 1. Check that every type of losetup call documented in the losetup manpage still works correctly. 2. Check that mount and umount commands that use loop devices still work correctly. REGRESSION POTENTIAL: /dev/loop-control and the corresponding util- linux support has exited for a long time without known/major issues, so this should be fairly safe. Also, the patch falls back to the previous "iterate over loop0 to loop7" behaviour if loop-control is not available. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/1640823/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
