$ 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.
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'. cloud-images. ubuntu. com/daily/ server/ trusty/ current/ trusty- server- cloudimg- amd64-root. tar.gz server- cloudimg- amd64-root. tar.gz
Heres what I did:
wget http://
mkdir x
tar -C x -Sxpzf trusty-
$ cat go.py
#!/usr/bin/python
from curtin import util
import sys, os
runs = int(os. environ. get("RUNS" , "10")) Target( target= target, allow_daemons= False):
util.subp( ['chroot' , target] + cmd)
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.Chrootable
# 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.