Some observations:
* growpart uses sfdisk without --no-tell-kernel option, meaning that it does notify kernel about partition changes
* growpart later calls partx, which may be redundant / cause no changes or events
* as a side note, partprobe, blockdev --rereadpt can also be used to reread partition tables, I'm not sure the difference between them
* growpart does not take exclusive lock of the device, meaning sgdisk is known to be racy with udev events
Imho the sequency of commands should be:
* take flock on the device, to neutralise udev
* modify device with sfdisk
* reread partitions tables (i would say with blockdev --rereadpt, rather than partx/partprobe)
* release the flock
* udevadm trigger --action=add --wait device (or trigger && settle)
This way it ensures that no udev events are processed for the device whilst we are operating and rereading the device partitions, and then we release the lock, at which point everything has to be quiet and steady, trigger, settle, done.
See:
sfdisk uses BLKRRPART (reread partition table) ioctl to make sure that the device is not used
by system or another tools (see also --no-reread). It's possible that this feature or another
sfdisk activity races with udevd. The recommended way how to avoid possible collisions is to
use exclusive flock for the whole-disk device to serialize device access. The exclusive lock
will cause udevd to skip the event handling on the device. For example:
flock /dev/sdc sfdisk /dev/sdc
Note, this semantic is not currently supported by udevd for MD and DM devices.
Some observations:
* growpart uses sfdisk without --no-tell-kernel option, meaning that it does notify kernel about partition changes
* growpart later calls partx, which may be redundant / cause no changes or events
* as a side note, partprobe, blockdev --rereadpt can also be used to reread partition tables, I'm not sure the difference between them
* growpart does not take exclusive lock of the device, meaning sgdisk is known to be racy with udev events
Imho the sequency of commands should be:
* take flock on the device, to neutralise udev
* modify device with sfdisk
* reread partitions tables (i would say with blockdev --rereadpt, rather than partx/partprobe)
* release the flock
* udevadm trigger --action=add --wait device (or trigger && settle)
This way it ensures that no udev events are processed for the device whilst we are operating and rereading the device partitions, and then we release the lock, at which point everything has to be quiet and steady, trigger, settle, done.
See:
sfdisk uses BLKRRPART (reread partition table) ioctl to make sure that the device is not used
by system or another tools (see also --no-reread). It's possible that this feature or another
sfdisk activity races with udevd. The recommended way how to avoid possible collisions is to
use exclusive flock for the whole-disk device to serialize device access. The exclusive lock
will cause udevd to skip the event handling on the device. For example:
flock /dev/sdc sfdisk /dev/sdc
Note, this semantic is not currently supported by udevd for MD and DM devices.
at http:// manpages. ubuntu. com/manpages/ eoan/en/ man8/sfdisk. 8.html