Comment 2 for bug 1462139

I was unable to reproduce this bug in testing, so I'm unfortunately not 100% certain the fix is doing more than effectively a 'sleep'.
Heres what I did:
  wget http://cloud-images.ubuntu.com/daily/server/trusty/current/trusty-server-cloudimg-amd64-root.tar.gz
  mkdir x
  tar -C x -Sxpzf trusty-server-cloudimg-amd64-root.tar.gz

  $ cat go.py
#!/usr/bin/python
from curtin import util
import sys, os

runs = int(os.environ.get("RUNS", "10"))
target = sys.argv[1]
cmd = sys.argv[2:]
print("target: %s" % target)
print("cmd: %s" % ' '.join(cmd))
for run in range(0, runs):
    print("run: %s" % run)
    with util.ChrootableTarget(target=target, allow_daemons=False):
        util.subp(['chroot', target] + cmd)

# install grub-pc in the target
$ sudo RUNS=1 PYTHONPATH=$PWD ./go.py x apt-get install grub-pc
# set up /dev/vdb (kvm / openstack guest) with partition
$ sudo wipefs --all /dev/vdb; echo "2048," | sudo sfdisk --force --unit=S /dev/vdb
$ sudo RUNS=100 PYTHONPATH=$PWD ./go.py x grub-install /dev/vdb

I was unable to see that fail, which is essentially what i believe was happening in Mike's failure case.
I also tried with trusty OS + trusty root.tar.gz and vivid OS + vivid root.tar.gz.

That said, udevadm monitor *does* show udev events, and so its quite possible that there was something responding to that event.

Worst case, this is a 'sleep'. Best case its a fix.