This is not likely to be a parted bug. udev maybe, or the kernel which generates udev messages when partitions change.

What does the output of udevadm monitor look on rawhide vs. F22?

Writing the new disklabel should generate a "change" uevent, which should be what udev looks for in order to discover new/changed disklabels. I don't see how this could be a parted bug.

(In reply to Brian Lane from comment #1)
> This is not likely to be a parted bug. udev maybe, or the kernel which
> generates udev messages when partitions change.

I agree, but I think parted is a good place to start since it is very much affected.

Changes from wipefs are not reflected in udev either without an explicit udevadm trigger.

> What does the output of udevadm monitor look on rawhide vs. F22?

"udevadm monitor" on rawhide is completely silent during this sequence:

 # wipefs -a /dev/vdb
 # parted -s /dev/vdb mklabel gpt
 # partprobe

On F22, I guess numerous "change" events for vdb:

KERNEL[410.947124] change   /devices/pci0000:00/0000:00:0a.0/virtio3/block/vdb (block)
UDEV  [410.953470] change   /devices/pci0000:00/0000:00:0a.0/virtio3/block/vdb (block)
KERNEL[427.479645] change   /devices/pci0000:00/0000:00:0a.0/virtio3/block/vdb (block)
UDEV  [427.548489] change   /devices/pci0000:00/0000:00:0a.0/virtio3/block/vdb (block)
KERNEL[427.553211] change   /devices/pci0000:00/0000:00:0a.0/virtio3/block/vdb (block)
KERNEL[427.553397] change   /devices/pci0000:00/0000:00:0a.0/virtio3/block/vdb (block)
UDEV  [427.558455] change   /devices/pci0000:00/0000:00:0a.0/virtio3/block/vdb (block)
UDEV  [427.564993] change   /devices/pci0000:00/0000:00:0a.0/virtio3/block/vdb (block)
...

and tons more for other devices from partprobe.


On F22, a simple

  # echo >/dev/vdb

produces "change" events, but not on Rawhide.  I think I remember that someone said that people are unhappy that the kernel generates "change" events every time anyone opens a block device for writing.  Maybe the kernel simply doesn't do this anymore and now every program needs to generate the right events explicitly.  But since you guys don't know about this fundamental change, that can't be true, right?

> On F22, I guess numerous "change" events for vdb:

"I get", sorry.

Could you install this systemd update and see if that fixes the issue?

http://koji.fedoraproject.org/koji/buildinfo?buildID=639479

(In reply to Brian Lane from comment #5)
> Could you install this systemd update and see if that fixes the issue?
> 
> http://koji.fedoraproject.org/koji/buildinfo?buildID=639479

This makes no difference.

I don't want to play ping pong debugging here, to be honest.

(In reply to Marius Vollmer from comment #3)

> "udevadm monitor" on rawhide is completely silent during this sequence:
> 
>  # wipefs -a /dev/vdb
>  # parted -s /dev/vdb mklabel gpt
>  # partprobe

Also for "cryptsetup", as one could expect by now.

Let's assign this to the kernel.

This is with kernel-4.1.0-0.rc5.git0.1.fc23.x86_64.

Jeff, have you seen any changes in 4.1 that would cause this behavior?

I tested this with the rawhide kernel on F22 userspace and the uevent is still generated from the kernel:

[root@localhost ~]# rpm -q systemd
systemd-219-13.fc22.x86_64
[root@localhost ~]# cat /etc/os-release 
NAME=Fedora
VERSION="22 (Twenty Two)"
ID=fedora
VERSION_ID=22
PRETTY_NAME="Fedora 22 (Twenty Two)"
ANSI_COLOR="0;34"
CPE_NAME="cpe:/o:fedoraproject:fedora:22"
HOME_URL="https://fedoraproject.org/"
BUG_REPORT_URL="https://bugzilla.redhat.com/"
REDHAT_BUGZILLA_PRODUCT="Fedora"
REDHAT_BUGZILLA_PRODUCT_VERSION=22
REDHAT_SUPPORT_PRODUCT="Fedora"
REDHAT_SUPPORT_PRODUCT_VERSION=22
PRIVACY_POLICY_URL=https://fedoraproject.org/wiki/Legal:PrivacyPolicy
VARIANT="Server Edition"
VARIANT_ID=server
[root@localhost ~]# uname -a
Linux localhost.localdomain 4.1.0-0.rc5.git0.1.fc23.x86_64 #1 SMP Mon May 25 14:53:02 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
[root@localhost ~]# udevadm monitor --kernel
monitor will print the received events for:
KERNEL - the kernel uevent

^Z
[1]+  Stopped                 udevadm monitor --kernel
[root@localhost ~]# bg
[1]+ udevadm monitor --kernel &
[root@localhost ~]# echo > /dev/vdb
[root@localhost ~]# KERNEL[157.780209] change   /devices/pci0000:00/0000:00:09.0/virtio4/block/vdb (block)

[root@localhost ~]# 

So I'm not sure this is actually a kernel problem.

OK, I tried the same experiment on a rawhide userspace with both 4.1.0-0.rc5.git0.1 and 4.0.4-301 and neither shows events from udevadm monitor.

[root@localhost ~]# udevadm monitor
monitor will print the received events for:
UDEV - the event which udev sends out after rule processing
KERNEL - the kernel uevent

^Z
[1]+  Stopped                 udevadm monitor
[root@localhost ~]# bg
[1]+ udevadm monitor &
[root@localhost ~]# echo > /dev/vda
[root@localhost ~]# fg
udevadm monitor
^C[root@localhost ~]# uname -a
Linux localhost.localdomain 4.0.4-301.fc22.x86_64 #1 SMP Wed May 27 08:56:30 EDT 2015 x86_64 x86_64 x86_64 GNU/Linux
[root@localhost ~]# rpm -q systemd
systemd-220-2.fc23.x86_64
[root@localhost ~]# 


So this looks like something amiss in userspace land.  I'm reassigning to systemd.

http://cgit.freedesktop.org/systemd/systemd/commit/?id=b50063512d should fix this, although I didn't test this. I'm putting this patch in systemd-220-8 as a provisional fix.

OK, works for me with systemd-220-9.fc23.x86_64.

(In reply to Zbigniew Jędrzejewski-Szmek from comment #12)
> http://cgit.freedesktop.org/systemd/systemd/commit/?id=b50063512d should fix
> this, although I didn't test this. I'm putting this patch in systemd-220-8
> as a provisional fix.

Great, thanks!

Out of interest, how did this break in the first place?  Could we add a test somewhere to catch regressions like this?