https://bugzilla.redhat.com/show_bug.cgi?id=1400475 In order to avoid a possible error as a result of kernel interactions with the partition helper, let's use virWaitForDevices to force things to settle down before attempting to open and read the partition. This is related to https://bugzilla.redhat.com/show_bug.cgi?id=1264719. Signed-off-by: John Ferlan <jferlan(a)redhat.com&gt; --- NB: This also resolves issues seen while testing the patch with using pool-refresh "frequently" on the disk pool. Perhaps the timing of things has changed enough that it'd be see more often now. At least with the f26 test system I used. BTW: The other option proposed long ago, but rejected was adding a timeout loop. I've also run the python script from the other bz with 100% success. src/storage/storage_backend_disk.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/src/storage/storage_backend_disk.c b/src/storage/storage_backend_disk.c index 7b4549c34d..2e3d1e04a4 100644 --- a/src/storage/storage_backend_disk.c +++ b/src/storage/storage_backend_disk.c @@ -183,7 +183,16 @@ virStorageBackendDiskMakeDataVol(virStoragePoolObjPtr pool, * after an extended partition is created an open on the extended * partition will fail, so pass the NOERROR flag and only error if a * -1 was returned indicating some other error than an open error. + * + * NB: A small window exists in some cases where the just created + * partition disappears, but then reappears. Since we were given + * vol->target.path from parthelper, let's just be sure that any + * kernel magic that occurs as a result of parthelper doesn't cause + * us to fail with some sort of ENOENT failure since that would be + * quite "unexpected". So rather than just fail, let's use the + * virWaitForDevices to ensure everything has settled properly. */ + virWaitForDevices(); if (vol->source.partType == VIR_STORAGE_VOL_DISK_TYPE_EXTENDED) { if (virStorageBackendUpdateVolInfo(vol, false, VIR_STORAGE_VOL_OPEN_DEFAULT | -- 2.14.3