Bug 1225905 - writing to a block device no longer triggers udev events
Summary: writing to a block device no longer triggers udev events
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: systemd
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: systemd-maint
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-05-28 12:21 UTC by Marius Vollmer
Modified: 2015-06-15 07:56 UTC (History)
18 users (show)

(edit)
Clone Of:
(edit)
Last Closed: 2015-06-11 14:00:15 UTC


Attachments (Terms of Use)

Description Marius Vollmer 2015-05-28 12:21:20 UTC
Description of problem:

Commands like "parted /dev/XXX mklabel gpt" now need an explicit "udevadm trigger" to cause udev to pick up the changes.

Version-Release number of selected component (if applicable):

parted-3.2-7.fc23.x86_64

How reproducible:

Always

Steps to Reproduce:

1. parted -s /dev/vdb mklabel gpt

2. udevadm info /dev/vdb | grep ID_PART
   <empty>

3. udevadm trigger

4. udevadm info /dev/vdb | grep ID_PART
   E: ID_PART_TABLE_TYPE=gpt
   E: ID_PART_TABLE_UUID=df196dda-aad8-4341-a1d4-fefc4b12d999


Actual results:

Step 2 shows nothing, step 4 shows the expected properties.

Expected results:

Step 2 also shows the expected properties.

Additional info:

The works as expected on Fedora 22 with parted-3.2-5.fc22.x86_64.

Comment 1 Brian Lane 2015-05-28 15:55:34 UTC
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?

Comment 2 David Lehman 2015-05-28 16:04:57 UTC
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.

Comment 3 Marius Vollmer 2015-05-28 19:01:44 UTC
(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?

Comment 4 Marius Vollmer 2015-05-28 19:02:31 UTC
> On F22, I guess numerous "change" events for vdb:

"I get", sorry.

Comment 5 Brian Lane 2015-05-28 21:34:44 UTC
Could you install this systemd update and see if that fixes the issue?

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

Comment 6 Marius Vollmer 2015-05-28 22:21:45 UTC
(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.

Comment 7 Marius Vollmer 2015-05-29 10:37:23 UTC
(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.

Comment 8 Marius Vollmer 2015-05-29 10:38:18 UTC
This is with kernel-4.1.0-0.rc5.git0.1.fc23.x86_64.

Comment 9 Josh Boyer 2015-05-29 11:48:33 UTC
Jeff, have you seen any changes in 4.1 that would cause this behavior?

Comment 10 Josh Boyer 2015-05-29 13:09:51 UTC
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.

Comment 11 Josh Boyer 2015-05-29 13:41:44 UTC
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.

Comment 12 Zbigniew Jędrzejewski-Szmek 2015-06-10 17:23:55 UTC
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.

Comment 13 Zbigniew Jędrzejewski-Szmek 2015-06-11 14:00:15 UTC
OK, works for me with systemd-220-9.fc23.x86_64.

Comment 14 Marius Vollmer 2015-06-15 07:56:14 UTC
(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?


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