parted will generate two devices when adding one partition on mpath device

Default Comment by Bridge

Thank you for taking the time to report this bug and helping to make Ubuntu better. It seems that your bug report is not filed about a specific source package though, rather it is just filed against Ubuntu in general. It is important that bug reports be filed about source packages so that people interested in the package can find the bugs about it. You can find some hints about determining what package your bug might be about at https://wiki.ubuntu.com/Bugs/FindRightPackage. You might also ask for help in the #ubuntu-bugs irc channel on Freenode.

To change the source package that this bug is filed about visit https://bugs.launchpad.net/ubuntu/+bug/1473903/+editstatus and add the package name in the text box next to the word Package.

[This is an automated message. I apologize if it reached you inappropriately; please just reply to this message indicating so.]

I'm not sure why the error from parted's mkpart command, but the fact that there are two different devices is due to the multipath-tools guys deciding to break traddition and configure their udev script to run kpartx and ask it to create the partition with the form base-partX rather than the baseX or basepX ( if base already ends in a digit ), like the rest of linux has done since the dawn of time. They need to come in line with the rest of the world and use the correct naming convention.

As for the parted error itself, can you try killing udev while issuing that command and see if it still happens?

------- Comment From <email address hidden> 2015-07-15 01:28 EDT-------
(In reply to comment #12)
> I'm not sure why the error from parted's mkpart command, but the fact that
> there are two different devices is due to the multipath-tools guys deciding
> to break traddition and configure their udev script to run kpartx and ask it
> to create the partition with the form base-partX rather than the baseX or
> basepX ( if base already ends in a digit ), like the rest of linux has done
> since the dawn of time. They need to come in line with the rest of the
> world and use the correct naming convention.
>
> As for the parted error itself, can you try killing udev while issuing that
> command and see if it still happens?

How could we kill udev while issuing the command, please. And please note that this problem cannot be reproduced with latest 3.2 parted.

sudo /etc/init.d/udev stop

------- Comment From <email address hidden> 2015-07-20 02:15 EDT-------
(In reply to comment #14)
> sudo /etc/init.d/udev stop

dilllp1 has some problem and we are trying to recover it now. On another system pinelp2, looks like the udevd *cannot* be killed and this problem can be reproduced:

% ls /dev/mapper
control mpath1-part1 mpath1-part3 mpath3 mpath3-part2 mpath3-part4 mpath4-part1 mpath4-part3
mpath1 mpath1-part2 mpath2 mpath3-part1 mpath3-part3 mpath4 mpath4-part2 mpath4-part4
% sudo /etc/init.d/udev stop
* Stopping the hotplug events dispatcher udevd
...done.
% sudo /etc/init.d/udev status
* udevd is running
% pgrep udevd
2534
% sudo pkill udevd
% pgrep udevd
6197
% sudo /etc/init.d/udev status
* udevd is running
% sudo parted /dev/mapper/mpath2
GNU Parted 2.3
Using /dev/mapper/mpath2
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) p
Model: Linux device-mapper (multipath) (dm)
Disk /dev/mapper/mpath2: 34.4GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Number Start End Size Type File system Flags

(parted) mkpart
Partition type? primary/extended?
Partition type? primary/extended? primary
File system type? [ext2]?
Start? 0%
End? 25%
Device /dev/mapper/mpath2p1 not found
device-mapper: table ioctl on failed: No such device or address
Device /dev/mapper/mpath2p1 not found
device-mapper: table ioctl on failed: No such device or address
(parted) p
Model: Linux device-mapper (multipath) (dm)
Disk /dev/mapper/mpath2: 34.4GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Number Start End Size Type File system Flags
1 1049kB 8590MB 8589MB primary ext4

(parted) q
Information: You may need to update /etc/fstab.

% ls /dev/mapper
control mpath1-part1 mpath1-part3 mpath2p1 mpath3 mpath3-part2 mpath3-part4 mpath4-part1 mpath4-part3
mpath1 mpath1-part2 mpath2 mpath2-part1 mpath3-part1 mpath3-part3 mpath4 mpath4-part2 mpath4-part4
%

No clear solution (per Steve Langasek) and late for 14.04.3.
Thierry Fauck to check parted 3.2 package.
Need to understand what we think the fix is, but expect it can go in service stream.

------- Comment From <email address hidden> 2015-07-20 02:20 EDT-------
A more clear process shows udevd cannot be killed and problem reproduced on pinelp2:

% ls /dev/mapper
control mpath1-part1 mpath1-part3 mpath3 mpath3-part2 mpath3-part4 mpath4-part1 mpath4-part3
mpath1 mpath1-part2 mpath2 mpath3-part1 mpath3-part3 mpath4 mpath4-part2 mpath4-part4
% sudo /etc/init.d/udev stop
* Stopping the hotplug events dispatcher udevd
...done.
% sudo /etc/init.d/udev status
* udevd is running
% pgrep udevd
2534
% sudo pkill udevd
% pgrep udevd
6197
% sudo /etc/init.d/udev status
* udevd is running
% sudo parted /dev/mapper/mpath2
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) p
Model: Linux device-mapper (multipath) (dm)
Disk /dev/mapper/mpath2: 34.4GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Number Start End Size Type File system Flags

(parted) mkpart
Partition type? primary/extended?
Partition type? primary/extended? primary
File system type? [ext2]?
Start? 0%
End? 25%
Device /dev/mapper/mpath2p1 not found
device-mapper: table ioctl on failed: No such device or address
Device /dev/mapper/mpath2p1 not found
device-mapper: table ioctl on failed: No such device or address
(parted) p
Model: Linux device-mapper (multipath) (dm)
Disk /dev/mapper/mpath2: 34.4GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Number Start End Size Type File system Flags
1 1049kB 8590MB 8589MB primary ext4

(parted) q
Information: You may need to update /etc/fstab.

% ls /dev/mapper
control mpath1-part1 mpath1-part3 mpath2p1 mpath3 mpath3-part2 mpath3-part4 mpath4-part1 mpath4-part3
mpath1 mpath1-part2 mpath2 mpath2-part1 mpath3-part1 mpath3-part3 mpath4 mpath4-part2 mpath4-part4
%

ok, so at least part of the problem here is a mismatch with different parts of the system referencing the two different ways of naming partitions on mpath devices.

------- Comment From <email address hidden> 2015-07-22 22:09 EDT-------
Just to sum up with what has already been said.

parted creates the 'p1' block device, via libparted (see dm_add_partition() in arch/linux.c, IIRC)
kpartx creates the '-part1' block device (see /lib/udev/rules.d/*-kpartx.rules).

In order to test that the '-part1' block device won't show up, you can disable the kpartx.rules file temporarily.
Something like this:
$ sudo mv /lib/udev/rules.d/*-kpartx.rules /lib/udev/rules.d/*-kpartx.rules.disabled
$ sudo udevadm control --reload

Another thought.
Not sure why latest parted doesn't show this problem (2 block devices for partition #1)
If only 'p1' is created, it seems the kpartx udev rules either fail or are not run.
If only '-part1' is created, it seems parted didn't create the partition in the devmap.

------- Comment From <email address hidden> 2015-07-28 09:53 EDT-------
The parted-3.2 NEWS file provides the info:
libparted: On multipath systems new partitions would sometimes not appear, reporting 'device-mapper: create ioctl failed: Device or resource busy' until the system was rebooted. Added dm_udev_wait calls to synchronize parted with udev.
This refer to thread https://lists.gnu.org/archive/html/bug-parted/2010-09/msg00007.html
pointing to a patch in libparted/arch/linux.c.
Apparently that patch could be added to current patches adding the dm-* functionailities already available in current 2.3 version.

Could it be possible to validate the idea of just applying that udev_sync patch makes the difference ?

------- Comment From <email address hidden> 2015-07-30 02:13 EDT-------
(In reply to comment #19)
> Just to sum up with what has already been said.
>
> parted creates the 'p1' block device, via libparted (see dm_add_partition()
> in arch/linux.c, IIRC)
> kpartx creates the '-part1' block device (see
> /lib/udev/rules.d/*-kpartx.rules).
>
> In order to test that the '-part1' block device won't show up, you can
> disable the kpartx.rules file temporarily.
> Something like this:
> $ sudo mv /lib/udev/rules.d/*-kpartx.rules
> /lib/udev/rules.d/*-kpartx.rules.disabled
> $ sudo udevadm control --reload
>
I can confirm that after disabling kpartx by thoes commands, '-part1' block device won't show up.

------- Comment From <email address hidden> 2015-08-06 09:50 EDT-------
(In reply to comment #24)
> Hello Vaishnavi,
>
> Can you, Sandhya or Mamatha help build this for Ping today please? Thanks.

Hi Luciano / Ping,
Apologies for the delayed reply as I was away on vacation last few days.

I tried to apply the patch from the link in comment #20.
Few things I noticed was,
- In parted (GNU parted) 2.3 which is on Ubuntu14.04.3:
There is no _dm_remove_map_name() in libparted/arch/linux.c, hence the patch failes to apply at this part.
Ignoring the above function and making the changes for _dm_add_partition() according to the patch and building the package, fails with

../configure: line 32229: syntax error near unexpected token `CHECK,'
../configure: line 32229: `PKG_CHECK_MODULES(CHECK, check >= 0.9.3, have_check=yes, have_check=no)'
make: *** [build-deb/config.status] Error 2
dpkg-buildpackage: error: debian/rules build gave error exit status 2

Can anyone help me to fix this error and help me to proceed in the package building ?

All the fixes for this should have landed already, in parted, partman, and multipath-tools. Could you please re-test this on 14.04 with all updates applied?

------- Comment From <email address hidden> 2015-08-14 01:45 EDT-------
(In reply to comment #29)
> All the fixes for this should have landed already, in parted, partman, and
> multipath-tools. Could you please re-test this on 14.04 with all updates
> applied?

Looks like there is no updated packages for 14.04.3 yet:

% sudo apt-get upgrade 8:41 hpt@pinelp2 ~ %
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
The following packages will be upgraded:
apparmor bsdutils libapparmor-perl libapparmor1 libblkid1 libmount1
libservicelog-1.1-1 libuuid1 libvpd-2.2-2 linux-firmware lsvpd mount
powerpc-ibm-utils ppc64-diag servicelog tzdata uuid-runtime
17 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 25.8 MB of archives.
After this operation, 7,977 kB of additional disk space will be used.
Do you want to continue? [Y/n]

multipath-tools 0.4.9-3ubuntu7.4 was published to trusty-updates on July 28. Do you already have this package installed? Does it not address this issue?

Actually, this would be more of a partman-multipath issue, but it seems to me like it would anyway be fixed by partman-multipath 4ubuntu0.1; but you'll only find this version number from within the installer; looking at /var/lib/dpkg/status.

Seeing as we didn't make any additional changes which would solve this similar problem from the *installed system*; I think we probably in fact still have some work to do here in parted to stop making 'p' partitions at all.

------- Comment From <email address hidden> 2015-08-18 02:40 EDT-------
(In reply to comment #31)
> multipath-tools 0.4.9-3ubuntu7.4 was published to trusty-updates on July 28.
> Do you already have this package installed? Does it not address this issue?

Yes, multipath-tools 0.4.9-3ubuntu7.4 had been installed on our systems, but this problem still can be reproduced on them.

------- Comment (attachment only) From <email address hidden> 2015-08-31 17:41 EDT-------

------- Comment (attachment only) From <email address hidden> 2015-08-31 17:42 EDT-------

------- Comment (attachment only) From <email address hidden> 2015-08-31 17:43 EDT-------

------- Comment (attachment only) From <email address hidden> 2015-08-31 17:43 EDT-------

------- Comment (attachment only) From <email address hidden> 2015-08-31 17:43 EDT-------

------- Comment (attachment only) From <email address hidden> 2015-08-31 17:44 EDT-------

Thierry, could you please simply attach the patch you used instead?

I've been looking into this today, I can't reproduce the issue with the default settings (without user_friendly_names), as expected. I can see how this would happen with friendly-names though, because then the parts of dm_p_separator.patch that apply this separator only if the device name ends in a number would get run.

Now, my only issue is that I'm not sure what else this might break if we were to change parted to use '-part' instead of 'p' as a separator. It would at least need to be checked against the installer to make sure it doesn't break install (though I don't expect it to).

------- Comment From <email address hidden> 2015-09-01 07:02 EDT-------
the purpose of adding packages was for user to have a test since applying previously mentioned patch was not as is.

------- Comment on attachment From <email address hidden> 2015-09-01 07:01 EDT-------

Created the patch adapted to current source

I'm having a bit of trouble seeing why dm_udev_wait() would make this work properly ... Seems like the device creation should happen regardless of whether kpartx has done its job beforehand, at least from my quick look at the code in parted.

Also, this patch seems to be for parted 3.2; but in 14.04, we're using an earlier version than that.

------- Comment From <email address hidden> 2015-09-02 08:06 EDT-------
Looking at parted-2.3 on trusty the code for dm_udev_wait(cookie) is already part of the installed patches, so you are right this is not related to our issue.

Don't both device names actually work fine though? I couldn't find any blocking issue to leaving both in place, since they don't seem to interfere with any operation of the system. This would certainly constitute the least-intrusive change, on account that there would be no change required.

Otherwise, there doesn't seem to be a straightforward way to fix this. We basically have two not great options to contend with (unless someone else can think of another):

1) Patch parted to write -part partitions instead of -p.
This is fine for the installed system, but means we'd need to revert SRUs already done for multipath-tools in the installer -- where we expect to see -p partitions always, and rewrite them to -part at the end (since there will be just kpartx on the installed system), modify partman-multipath to pick up all partitions and make them -part. There remains the issue of rewriting fstab later on, when comes the time to migrate to multipath 0.5.0 (which changes the partition names in other ways too, so unavoidable).

2) Fix kpartx rules either by disabling them or making them use -p only.
This would fix the installed system (since parted creates p partitions itself) and detected partitions on drives at boot would show up correctly, but we'd need to do other SRU changes to installer bits to not rewrite /etc/fstab to use -part as a partition separator. This is apparently a simpler change, but means we also need to deal with changing fstab on upgrade for those who use -part, which makes it dangerous and very intrusive.

I'd love to get some guidance on this, but I'm thinking not changing anything for now is the best option; although if there is any effect in having both devices show up and we need to stop it, then 1) would be best.

We have already spent a lot of effort over the years going with #2, so turning around at this point isn't the right thing to do. The one place I still see multipath-tools doing the wrong thing is in its kpartx.rules file, which still contains this stanza:

ENV{DM_STATE}=="ACTIVE", ENV{DM_UUID}=="mpath-*", \
        RUN+="/sbin/kpartx -a -p -part /dev/$name"

That '-p part' simply needs deleted.

I managed to find a patch I'm testing now, which adds udev sync support to parted 2.3 (in 14.04) which is already in parted 3.2.

Testing is in progress, this should help remove the "device is busy" warnings.

As for the two devices, other patches to multipath-tools and parted's partitioning policy should fix this.

multipath-tools already carries the patches to synchronize with udev; so does parted. This should fix the issues with "device is busy" messages when doing the partitioning (but it looks as though there can still be some), and on xenial I can verify that there is just one device being created.

I've tested the patches for parted / multipath-tools on trusty and things look like they work correctly (again, aside from the "device is busy" errors, but the correct device node is created anyway).

Hello bugproxy, or anyone else affected,

Accepted parted into trusty-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/parted/2.3-19ubuntu1.14.04.2 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!

------- Comment From <email address hidden> 2016-02-02 20:35 EDT-------
In which release this bug will be fixed? 14.04.4? Thanks.

------- Comment (attachment only) From <email address hidden> 2015-08-31 17:43 EDT-------

Hello bugproxy, 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.8 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!

This is working correctly.
Marking as verification-done.

After partitioning with parted, there's only one device node for the partition (with the -part disk-partition separator).

There's /still/ some messages in parted mentioning it could not find the device, but the partitions are created correctly -- note those messages were already present in the original bug report, so this is not a regression.

# multipath -l mpath1
mpath1 (0QEMU QEMU HARDDISK trustytest) dm-0 QEMU ,QEMU HARDDISK
size=8.0G features='0' hwhandler='0' wp=rw
|-+- policy='round-robin 0' prio=-1 status=active
| `- 0:0:3:0 sdf 8:80 active undef running
`-+- policy='round-robin 0' prio=-1 status=enabled
  `- 0:0:2:0 sde 8:64 active undef running

# ls -l /dev/mapper/mpath1*
brw-rw---- 1 root disk 252, 0 Feb 9 10:55 /dev/mapper/mpath1

# parted /dev/mapper/mpath1
GNU Parted 2.3
Using /dev/mapper/mpath1
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) p
Error: /dev/mapper/mpath1: unrecognised disk label
(parted) mklabel msdos
(parted) p
Model: Linux device-mapper (multipath) (dm)
Disk /dev/mapper/mpath1: 8590MB
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Number Start End Size Type File system Flags

(parted) mkpart
Partition type? primary/extended? primary
File system type? [ext2]?
Start? 0%
End? 10%
Device /dev/mapper/mpath1-part1 not found
device-mapper: table ioctl on failed: No such device or address
Device /dev/mapper/mpath1-part1 not found
device-mapper: table ioctl on failed: No such device or address
(parted) p
Model: Linux device-mapper (multipath) (dm)
Disk /dev/mapper/mpath1: 8590MB
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Number Start End Size Type File system Flags
 1 1049kB 859MB 858MB primary

(parted) q
Information: You may need to update /etc/fstab.

# ls -l /dev/mapper/mpath1*
brw-rw---- 1 root disk 252, 0 Feb 9 11:00 /dev/mapper/mpath1
lrwxrwxrwx 1 root root 7 Feb 9 11:00 /dev/mapper/mpath1-part1 -> ../dm-5

After some more play, all correct: only 1 node per partition (-part).

# ls -l /dev/mapper/mpath1*
brw-rw---- 1 root disk 252, 0 Feb 9 11:05 /dev/mapper/mpath1
lrwxrwxrwx 1 root root 7 Feb 9 11:00 /dev/mapper/mpath1-part1 -> ../dm-5
lrwxrwxrwx 1 root root 7 Feb 9 11:04 /dev/mapper/mpath1-part2 -> ../dm-6
lrwxrwxrwx 1 root root 7 Feb 9 11:05 /dev/mapper/mpath1-part3 -> ../dm-7
lrwxrwxrwx 1 root root 7 Feb 9 11:05 /dev/mapper/mpath1-part5 -> ../dm-8

Your output there clearly shows that the verification *failed*. This change needs to be reverted as it does completely the wrong thing. The correct name is p1, not -part1. It is multipath-tools that needs changed, not parted. Please revert the parted change immediately.

Hello bugproxy, 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!

This was already verified successfully before; the additional update does not need reverification, only checking the regression in bug 1543430.

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

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.

I'm not sure we are understanding each other correctly. I am not sure what the change you made to multipath-tools has to do with this bug, but the change you made to parted which is still sitting in the -proposed pocket is incorrect and needs to be rejected. Instead of changing parted, it is multipath-tools that needs changed to not use the -part naming scheme. Changing parted to use -part will also break dmraid.

Please leave this bug as it was.

Any sort of response on your part other than that one would be appreciated. You have not made any attempt at all to explain yourself. This bug has two parts:

1) Parted seems to be failing to sync with udev and wait for it to create the device, despite carrying a patch to make it do just that

2) multipath-tools still has a udev rule that creates a duplicate partition device using the '-part' suffix.

Your proposed change to parted actually makes #2 even worse, and your change to multipath-tools was to have it run an update rather than an add, which helps remove deleted partitions, but does nothing to address either of the two issues this bug is about.

Please explain why you think this bug has been solved in multipath-tools and still needs work in parted.

This SRU got removed due to the failed verification of bug 1536008, and is generally stalled. At this point 14.04 is old enough that actual users who encounter this will either have learned how to live with this or moved to 16.04 LTS. Thus "wontfix".