Comment 23 for bug 1292234

On my main server (3.13.0-32-generic with precise userspace) I installed a trusty container with ext3 (LVM) backing store. There I installed uvt and created 4 VMs, 2 precise amd64 and 2 precise i386. I several times did:

ubuntu@uvttest:~$ cat list
p-precise-server-amd64
p-precise-server-i386
q-precise-server-i386
q-precise-server-amd64
ubuntu@uvttest:~$ for n in `cat list`; do uvt start -fr $n; done
ubuntu@uvttest:~$ for n in `cat list`; do tmux splitw -p 25 -t $TMUX_PANE "expect vmupgrade.expect $n"; done

where vmupgrade.expect is:
=================================================================
#!/usr/bin/expect

set container [lrange $argv 0 0]
spawn ssh $container
#expect "assword:"
#send -- "ubuntu\r"

expect "$container:~$"
send -- "export DEBIAN_FRONTEND=noninteractive\r"
send -- "sudo sed -i 's/never/lts/' /etc/update-manager/release-upgrades\r"
expect "assword for ubuntu:"
send -- "ubuntu\r"

expect "$container:~$"
send -- "sudo apt-get update\r"
expect "$container:~$"
send -- "sudo do-release-upgrade -f DistUpgradeViewNonInteractive\r"
set timeout 11000
expect "$container:~$"
send -- "sudo reboot\r"
=================================================================

Then I find /lib -name xxx; sudo reboot; find /lib -name xxx; and look
through dmesg for errors, then do

ubuntu@uvttest:~$ for n in `cat list`; do uvt stop -fr $n; done

Alas I've seen no corruption yet. The goal here isn't just to reproduce
it, but to do so reliably enough to be able to bisect - this isn't it :(