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 ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs