[Bug 1640823] Re: [trusty] mount -o loop is limited to 8 loop devices

[Martin Pitt]

** Description changed:

  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 in
- http://git.kernel.org/cgit/utils/util-linux/util-
- linux.git/commit/?id=0b14bf7a
+ 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: (FIXME: this does not actually get fixed with the above commit)
+ 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:
- $ sudo mount -o loop /etc/issue /mnt
+ $ 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 util-linux this will fail with "could not find any
- free loop device". With the proposed version, this should "only" fail
- with "you must specify the filesystem type" (or try it on an actual file
- system image).
+ free loop device". With the proposed version, this should succeed, and
+ "sudo losetup -a" should show "/dev/loop8: ... (/tmp/img)".
  
- 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.
+ 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.
+ 
+ 
+ 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.

** Description changed:

  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 util-linux 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)".
+ 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}
+   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.
  
- 
- 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.
+ 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.

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, 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.

  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