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
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1834875
Title:
cloud-init growpart race with udev
To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1834875/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
