regression: max number of loop devices

[Jasper Spaans]

Since the patch in https://lkml.org/lkml/2022/12/8/904 got backported to linux-hwe-5.15 (apparently in 5.15.0-68) the kernel effectively boots with max_loop=CONFIG_BLK_DEV_LOOP_MIN_COUNT as a parameter.

In /boot/config-... we find CONFIG_BLK_DEV_LOOP_MIN_COUNT=8, which means no more than 8 loop devices are supported. This is a regression.

At least one other distro solves this by compiling with CONFIG_BLK_DEV_LOOP_MIN_COUNT=0 [1]; maybe Ubuntu could start doing that as well.

We currently workaround this by setting max_loop=0 on the kernel cmdline but would rather not have to.

[1] https://github.com/archlinux/svntogit-packages/blob/62b8243b1d485493d3e8b10b05281efa20fe7918/trunk/config#L2517

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[David Trudgian (dtrudg-sylabs)]

Users of our software (singularity) were affected by this issue.

https://github.com/sylabs/singularity/issues/1499

For historic reasons (old kernels without /dev/loop-control), we have been creating /dev/loopXX devices directly via mknod, if needed, before using them.

After the backport of https://lkml.org/lkml/2022/12/8/904 it was possible to mknod additional loop devices, in addition to those present on boot, but they could not then be used successfully.

We found that switching to creating devices via LOOP_CTL_ADD ioctl against /dev/loop-control avoids the issue. >8 devices are created and are usable.

While there will be a workaround for people who can upgrade to a new version of our software, the change in the Ubuntu kernel causes a regression for users of existing versions of singularity, who must set max_loop in the kernel cmdline to work around the problem.