Bugzilla – Bug 780668
RN: loop block devices: Only /dev/loop0 usable if max_part parameter is used
Last modified: 2012-10-29 12:09:09 UTC
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20100101 Firefox/15.0 If the loop kernel module gets loaded with a max_part parameter, only /dev/loop0 is usable, other loop devices cannot be attached to files. Reproducible: Always Steps to Reproduce: Make sure the loop module is not loaded already. Then: $ modprobe loop max_part=8 $ dd if=/dev/null of=/tmp/loopimg seek=1M $ losetup /dev/loop0 /tmp/loopimg # <-- OK $ losetup /dev/loop1 /tmp/loopimg # <-- Fails Actual Results: failed to setup loop device: No such device or address Expected Results: silent success I tested with a full openSUSE 12.2 installation from DVD (inside VirtualBox, hosted by 12.1, on x86_64). I don't know what the error message "No such device or address" refers to. The file and the (non-attached) loop device node both do exist. This is a regression, max_part didn't cause such trouble with openSUSE 12.1. I filed this under "kernel" since the max_part parameter seems to cause this bug, but it might be a bug in the loop userspace tool as well.
This isn't a bug but rather a change of how things work in the 3.4 kernel. There are two ways to have partitions for loopback devices. The first is with max_part and the second is with the -P parameter to losetup. They behave slightly differently since -P will dynamically allocate minor numbers for each device (including adding/removing them on the fly with blockdev --rereadpt). Using the max_part parameter causes each loop device to allocate that many minor numbers for each device. So when you use max_part = 8 and don't change max_loop, which defaults to 8, you're using all of the allocated minor numbers with the first device. The solution is either to use -P or to _also_ use max_loop. This should probably have a release note issued.
Aha, things are working as expected now. Thanks, Jeff, for your detailed explanation, and sorry for reporting a non-bug. -- Yarny
You reported a bug -- we didn't document the change. :)
Here is my proposal for the release notes (broadly based on your input; is there a readme in the Kernel source docs that I can reference?): Specifying Partitions for Loopback Devices With Kernel 3.4 there are two ways to have partitions for loopback devices. The first is with max_part and the second is with the -P parameter to <command>losetup</command>. They behave slightly differently since -P will dynamically allocate minor numbers for each device (including adding or removing them on the fly with <command>blockdev --rereadpt</command>). Using the max_part parameter causes each loop device to allocate that many minor numbers for each device. So when you use max_part=8 and do not change max_loop, which defaults to 8, you are using all of the allocated minor numbers with the first device. The solution is either to use -P or to <emphasis>also</emphasis> use max_loop.
Fixed in SVN.
openSUSE-RU-2012:1407-1: An update that has four recommended fixes can now be installed. Category: recommended (low) Bug References: 780668,784291,784364,784757 CVE References: Sources used: openSUSE 12.2 (src): release-notes-openSUSE-12.2.9-1.12.1