[Bug 1469143] Re: kpartx -d fails with image paths longer than 63 characters

[Risto Kankkunen]

In addition to not handling long paths, kpartx also fails to handle
relative paths correctly. Here's an example:

for d in 1 2
do
  mkdir $d && (
    cd $d &&
    dd if=/dev/zero of=disk.img seek=8k count=1 2> /dev/null &&
    (echo n;echo;echo;echo;echo;echo w) | fdisk disk.img >/dev/null &&
    kpartx -av disk.img
  )
done

Expected result:
add map loop1p1 (254:0): 0 6145 linear /dev/loop0 2048
add map loop2p1 (254:1): 0 6145 linear /dev/loop1 2048

Actual result:
add map loop1p1 (254:0): 0 6145 linear /dev/loop0 2048
add map loop1p1 (254:0): 0 6145 linear /dev/loop0 2048

Currently kpartx end up modifying the existing binding instead of
creating a new one.

Both the long path problem and the relative path problem are caused by
kpartx trying to use the binding name to store the image file path and
assuming that the name would uniquely identify a binding.

The correct way is to use the device and inode numbers of the image
files to identify which loop mount is attached to which image file. I
have attached a patch which does exactly this.


** Patch added: "Use inode to match loopback mount to backing file"
   https://bugs.launchpad.net/ubuntu/+source/multipath-tools/+bug/1469143/+attachment/4422343/+files/0014-kpartx-long-path.patch

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to multipath-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1469143

Title:
  kpartx -d fails with image paths longer than 63 characters

Status in multipath-tools package in Ubuntu:
  In Progress
Status in multipath-tools source package in Precise:
  New
Status in multipath-tools source package in Trusty:
  New
Status in multipath-tools source package in Utopic:
  New
Status in multipath-tools source package in Vivid:
  New

Bug description:
  $ apt-show-versions multipath-tools
  multipath-tools:amd64/vivid 0.4.9-3ubuntu12 uptodate

  Reproduce:
  Mount an image from a path longer than 63 chars succeeds:
  $ sudo kpartx -av asfd1asdf2asdf3asdf4asdf5asdf6asfd7asdf8asdf9asf10asdf11asdf12asdf13/disk.img
  add map loop0p1 (252:0): 0 409600 linear /dev/loop0 2048
  add map loop0p2 (252:1): 0 2 linear /dev/loop0 411648
  add map loop0p5 : 0 819200 linear /dev/loop0 413696
  add map loop0p6 : 0 819200 linear /dev/loop0 1234944
  add map loop0p7 : 0 819200 linear /dev/loop0 2056192
  add map loop0p8 : 0 1316864 linear /dev/loop0 2877440

  but dismounting fails:
  $ sudo kpartx -dv asfd1asdf2asdf3asdf4asdf5asdf6asfd7asdf8asdf9asf10asdf11asdf12asdf13/disk.img

  strace shows that the parameter on the dismount appears to get cut at 63 chars:
  ioctl(3, DM_LIST_VERSIONS, 0x15b89b0)   = 0
  stat("asfd1asdf2asdf3asdf4asdf5asdf6asfd7asdf8asdf9asf10asdf11asdf12asdf13/disk.img", {st_mode=S_IFREG|0644, st_size=2147483648, ...}) = 0
  stat("/dev/loop0", {st_mode=S_IFBLK|0660, st_rdev=makedev(7, 0), ...}) = 0
  open("/dev/loop0", O_RDONLY)            = 4
  ioctl(4, LOOP_GET_STATUS, {number=0, offset=0, flags=0, name="asfd1asdf2asdf3asdf4asdf5asdf6asfd7asdf8asdf9asf10asdf11asdf12a", ...}) = 0
  close(4)                                = 0
  stat("/dev/loop1", {st_mode=S_IFBLK|0660, st_rdev=makedev(7, 1), ...}) = 0
  open("/dev/loop1", O_RDONLY)            = 4
  ioctl(4, LOOP_GET_STATUS, {number=0, offset=0, flags=0, name="asfd1asdf2asdf3asdf4asdf5asdf6asfd7asdf8asdf9asf10asdf11asdf12a", ...}) = -1 ENXIO (No such device or address)

  if the path is 63 chars or less, the dismount also succeeds.

  This is quickly becomes an issue if you want to use full disk paths in
  your shell scripts.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/multipath-tools/+bug/1469143/+subscriptions