Loop devices with the logical sector size set to 4096 do not autodetect partitions when attached. It may be the case for devices with 4k logical sectors in general, but I do not have hardware to test that. I have not tested with non-GPT disks. I expect to see /dev/loopNpX devices appear when attaching a loopback device with partitions, regardless of logical block size. With 4096 byte logical block size I only see /dev/loopN devices and no /dev/loopNpX devices. Steps to reproduce: 1) truncate -s 1G diskimg 2) losetup -fP --show -b 4096 diskimg 3) sgdisk -n 0:0:0 /dev/loopN # Other partitioning tools will probably also work. 4) losetup -d /dev/loopN 5) losetup -fP --show -b 4096 diskimg This happens reliably. I can reproduce it 100% of the time. Running `sgdisk -p /dev/loopN` with trigger a partition scan and it find the partitions correctly then, but they do not appear when initially attached with `losetup -P`. Disk images with logical block size 512 do appear correctly. I've tested this with a Fedora 4.17.x kernel, my gentoo 4.17.x kernel and a Container linux 4.14.x kernel; they all exhibit the same behavior. I don't see anything interesting in dmesg and udevadm monitor shows there are no ADD uevents for the partition block devices until `sgdisk -p /dev/loopN` is run.
(In reply to Andrew Jeddeloh from comment #0) > Loop devices with the logical sector size set to 4096 do not autodetect > partitions when attached. It may be the case for devices with 4k logical > sectors in general, but I do not have hardware to test that. I have not > tested with non-GPT disks. > > I expect to see /dev/loopNpX devices appear when attaching a loopback device > with partitions, regardless of logical block size. With 4096 byte logical > block size I only see /dev/loopN devices and no /dev/loopNpX devices. > > Steps to reproduce: > 1) truncate -s 1G diskimg > 2) losetup -fP --show -b 4096 diskimg > 3) sgdisk -n 0:0:0 /dev/loopN # Other partitioning tools will probably also > work. > 4) losetup -d /dev/loopN > 5) losetup -fP --show -b 4096 diskimg > > This happens reliably. I can reproduce it 100% of the time. > > Running `sgdisk -p /dev/loopN` with trigger a partition scan and it find the > partitions correctly then, but they do not appear when initially attached > with `losetup -P`. Disk images with logical block size 512 do appear > correctly. > > I've tested this with a Fedora 4.17.x kernel, my gentoo 4.17.x kernel and a > Container linux 4.14.x kernel; they all exhibit the same behavior. > > I don't see anything interesting in dmesg and udevadm monitor shows there > are no ADD uevents for the partition block devices until `sgdisk -p > /dev/loopN` is run. I can reproduce the issue using the current master (from today), but so far I can't reproduce using current util-linux master. A fix landed in Jan 22 2019 regarding this issue: commit 422f0e9f206a145c59a71333dad20d38cbbfc0c4 Author: Karel Zak <kzak@redhat.com> Date: Tue Jan 22 11:50:20 2019 +0100 losetup: properly use --sector-size when create a new device The --partscan functionality depends on sector size. Make sure sector size is set before we force kernel to scan the device for partitions. For example: losetup -f loopfile --sector-size 4KiB --partscan --show where 'loopfile' contains GPT with 4096 sectors. Reported-by: Jeffrey Ferreira <jeffpferreira@gmail.com> Signed-off-by: Karel Zak <kzak@redhat.com> So far I can't reproduce the issue using current util-linux master. Since the newest version of uitl-linux was release in Jan 9 (before this fix landed), you'll need to grab the source code of losetup from util-linux git and compile it. Closing as INVALID as the issue was fixed in util-linux.