Note, assuming our theory on the circumstances of the race is correct above (that it is 'read' or mount of that device), I was unable to reproduce with a loop device, which I thought would have caused a similar issue:
1. truncate --size 100m /tmp/my.img 2. mkfs -F -t ext3 /tmp/my.img 3. LODEV=$(sudo losetup --show --find /tmp/my.img) 4. sudo python -c 'import time, sys; print sys.argv[1]; fp=open(sys.argv[1]); time.sleep(30); fp.close();' /dev/loop1 & # inside the 30 seconds that that will have an open RO file handle, do step 5 5. sudo fsck.ext3 -f /dev/loop1 # '-f' forces fsck even if not marked dirty or sudo fsck.ext3 /dev/loop1 Other things I've found: * using 'open(sys.argv[1],"rw")' does not change anything, fsck will still continue. * changing step 4 to 'mount -o ro /dev/loop1 /mnt' *will* cause fsck.ext3 to complain that the filesystem is mounted and print a similar error message. So, I'm suspecting that it is indeed the OVF code's mount -o,ro that is causing this problem. I'm not sure how to resolve it, other than limiting the mounts checked to FS of iso9660 only. -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to cloud-init in Ubuntu. https://bugs.launchpad.net/bugs/898373 Title: fsck.ext3: Device or resource busy while trying to open /dev/xvda2 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/898373/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs