Bug 200749

Summary:	Loop devices with 4k logical blocks do not autodetect GPT partitions
Product:	IO/Storage	Reporter:	Andrew Jeddeloh (andrew.jeddeloh)
Component:	Block Layer	Assignee:	Jens Axboe (axboe)
Status:	RESOLVED INVALID
Severity:	normal	CC:	andrew.jeddeloh, axboe, marcos.souza.org
Priority:	P1
Hardware:	All
OS:	Linux
Kernel Version:	4.17.12, 4.14.49	Subsystem:
Regression:	No	Bisected commit-id:

Description Andrew Jeddeloh 2018-08-06 18:23:18 UTC

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.

Comment 1 Marcos Souza 2019-03-05 16:46:56 UTC

(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.