When a udev "block" event is received, subiquity starts a probert run so it can show a more up-to-date list of block devices, filesystems, etc. This is an asynchronous operation that can take a few seconds to a couple minutes.
When the probert run finishes, the data is immediately loaded in subiquity and it effectively discards any partitioning change that the user may have done so far.
This is a problem during manual partitioning in the desktop installer. The user may be in the middle of creating, editing or deleting partitions when the probert run finishes. All of a sudden, all the changes are discarded without any visible indication on the UI. At that point, the UI becomes inconsistent with subiquity's internal partitioning information ; and trying to edit partitions further leads to all sorts of errors (that are not visible to the user).
Steps to reproduce:
1. Go into the manual partitioning menu
2. Do any of these:
* Plug/unplug a USB key
* Run sudo udevadm trigger
The udev events can also occur from other reasons.
xnox mentioned a script in ubiquity that is meant to reduce the number of udev events generated:
https:/