kpartx 0.5.0-7ubuntu11 fails to remove loop mapping on kpartx -d

Bug #1543430 reported by Steve Langasek on 2016-02-09
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
multipath-tools (Ubuntu)
Critical
Mathieu Trudel-Lapierre
Trusty
Critical
Unassigned

Bug Description

I've observed in livefs build logs that with kpartx 0.5.0-7ubuntu12, 'kpartx -d' is not removing the loop mapping (losetup -d). E.g., build log diff:

 + kpartx -v -d binary/boot/disk.ext4
 del devmap : loop0p1
-loop deleted : /dev/loop0

This doesn't seem to be causing any immediate practical problems because each livefs build gets a dedicated VM which is torn down afterwards, so the mappings do not persist. But it's definitely incorrect for these mappings to persist.

The good build log used kpartx 0.5.0-7ubuntu9. Testing the intermediate versions, 0.5.0-7ubuntu11 shows the same buggy behavior as 12. 10 clears the loop mapping, but also appears to fail to correctly set up partitions in my test case so I'm not sure if this bug is present or not in 0.5.0-7ubuntu10.

Steve Langasek (vorlon) on 2016-02-09
Changed in multipath-tools (Ubuntu):
assignee: nobody → Mathieu Trudel-Lapierre (mathieu-tl)
importance: Undecided → Critical
Dimitri John Ledkov (xnox) wrote :

Well, it's a problem on s390x, where they are not dedicated VMs.

wgrant has run a cleanup of loopsetup devices now, on those builders.

adding a check to test that losetup -f matches after a kpartx -a / -d round trip.

Ugh, yeah, I see now that the patch fixing dealing with loopbacks at all "regresses" in a way, but not dealing correctly with the loop entries even though it appears to deal with the devmapper table just fine.

I'm looking at it right now, it's not pretty. There are basically two ways I can think of to deal with this. Either relying more on loopdev/device than S_ISREG on the buf that describes the file opened (we needed to stat the loopback device after picking it, otherwise no major/minor numbers to do the partition mappings), or hacking buf.st_mode to convince kpartx we're still dealing with a regular file.

I'm trying to see what might break if we just use loopdev or device everywhere. I will upload as soon as I'm reasonably confident this does not further break things, and I'll adjust the autopkgtest accordingly.

Changed in multipath-tools (Ubuntu):
status: New → In Progress
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package multipath-tools - 0.5.0-7ubuntu14

---------------
multipath-tools (0.5.0-7ubuntu14) xenial; urgency=medium

  * debian/patches/kpartx_more_loopback_fixes.patch: fix loopback mounted
    files some more: since we stat() the loopback device node, we can't rely
    on S_ISREG() tests to handle this case, and should look at the device
    itself instead. (LP: #1543430)
  * debian/tests/kpartx-file-loopback: check for left-over loop devices after
    deleting a map.

 -- Mathieu Trudel-Lapierre <email address hidden> Tue, 09 Feb 2016 15:24:27 -0500

Changed in multipath-tools (Ubuntu):
status: In Progress → Fix Released

Hello Steve, or anyone else affected,

Accepted multipath-tools into trusty-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/multipath-tools/0.4.9-3ubuntu7.9 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

tags: added: verification-needed
Changed in multipath-tools (Ubuntu Trusty):
status: New → Fix Committed

Verified; this works as expected:

kpartx -av adds a loop device node and mounts the image, and sets up the partitions.
kpartx -dv deletes the partition maps and removed the loop device node.

tags: added: verification-done
removed: verification-needed
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package multipath-tools - 0.4.9-3ubuntu7.9

---------------
multipath-tools (0.4.9-3ubuntu7.9) trusty; urgency=medium

  * debian/patches/kpartx-support-device-names-with-spaces.patch: fix loopback
    files unmapping. (LP: #1543430)

multipath-tools (0.4.9-3ubuntu7.8) trusty; urgency=medium

  * debian/patches/kpartx-support-device-names-with-spaces.patch: deal with
    spaces in device names in kpartx too (LP: #1432062)
  * debian/initramfs/local-premount: wait for udev to settle before mounting
    so the by-uuid/ symlinks have a chance to be updated by udev rules.
    (LP: #1503286)
  * Allow device detection all through the initramfs: run multipathd instead
    of only scanning once for devices, so those that come up slower can still
    be used as a root device (LP: #1526984):
    - debian/patches/0050-readonly-bindings_prefix.patch,
      debian/patches/0051-readonly-bindings_multipath.patch,
      debian/patches/0052-readonly-bindings_multipathd.patch,
      debian/patches/0053-readonly-bindings_multipathd_prod.patch: support -B
      to allow multipathd to handle cases where the bindings file is read-only.
    - debian/initramfs/hooks: install multipathd and required directories.
    - debian/initramfs/local-premount: also reload all maps to make sure
      they're ready before we mount.
    - debian/initramfs/local-top: run multipathd rather than a one-off call to
      multipath so that new paths can be correctly added as detected while
      we're still in the initramfs.
    - debian/initramfs/local-bottom: remember to stop multipathd.
    - debian/initramfs/local-bottom, debian/rules: install local-bottom for
      initramfs.
  * debian/patches/lp1496210_add_IBM_XIV_defaults.patch: add support (default
    config values) for the IBM 2810XIV storage system. (LP: #1496210)
  * debian/patches/0054-kpartx-update-option.patch: run kpartx -u rather than
    kpartx -a, so as to remove old partition entries if the partition table
    has changed. (LP: #1473903)
  * debian/patches/multipath_enable_sync_support_1b8082c8.patch,
    debian/patches/kpartx_rely_on_udev_dev_creation_9a632fff.patch: synchronize
    udev, device-mapper and multipath, and let udev deal with creating device
    nodes and symlinks. (LP: #1486370)
  * debian/initramfs/local-top: drop scsi_wait_scan stanza, that module is no
    longer available. (LP: #1538775)

 -- Mathieu Trudel-Lapierre <email address hidden> Tue, 09 Feb 2016 16:03:10 -0500

Changed in multipath-tools (Ubuntu Trusty):
status: Fix Committed → Fix Released

The verification of the Stable Release Update for multipath-tools has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

Changed in multipath-tools (Ubuntu Trusty):
importance: Undecided → Critical
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers