Bug 200749 - Loop devices with 4k logical blocks do not autodetect GPT partitions
Summary: Loop devices with 4k logical blocks do not autodetect GPT partitions
Status: RESOLVED INVALID
Alias: None
Product: IO/Storage
Classification: Unclassified
Component: Block Layer (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: Jens Axboe
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-08-06 18:23 UTC by Andrew Jeddeloh
Modified: 2019-03-05 16:46 UTC (History)
3 users (show)

See Also:
Kernel Version: 4.17.12, 4.14.49
Subsystem:
Regression: No
Bisected commit-id:


Attachments

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.

Note You need to log in before you can comment on or make changes to this bug.