Skip to content

snapshot operation failed / VERR_FILE_NOT_FOUND

Today a virtual machine would not start, something about a missing disk. Oh, right...I had a raw disk assigned to the VM which is now gone. So, I just get rid of the disk and start the VM anyway, right?
$ VBoxManage list hdds 
[...]
UUID:        fa9fb372-3ea5-4849-8fe6-b60989b6948e
Parent UUID: base
Format:      VMDK
Location:   ../disk3.vmdk
State:       inaccessible
Type:        immutable

$ VBoxManage closemedium disk fa9fb372-3ea5-4849-8fe6-b60989b6948e
ERROR: Cannot close medium '../disk3.vmdk' because it has 1 child media
Details: code NS_ERROR_FAILURE (0x80004005), component Medium, interface
         IMedium, callee nsISupports
Context: "Close()" at line 1617 of file VBoxManageDisk.cpp
Ah, indeed. I had taken a snapshot of the VM as well when the raw disk was still attached. So let's delete the snapshot and/or the parent disk, OK?
$ VBoxManage snapshot foo delete 505f9e2d-3d63-468e-8a86-b883ab9a10be
0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...
Progress state: NS_ERROR_FAILURE
Error: snapshot operation failed. Error message: Could not open the 
         medium '../disk3.vmdk'.
VD: error VERR_FILE_NOT_FOUND opening image file '../disk3.vmdk' (VERR_FILE_NOT_FOUND)

$ VBoxManage closemedium disk 701e85eb-548a-4b1f-b515-cc8dae424234
ERROR: Medium '../Snapshots/{701e85eb-548a-4b1f-b515-cc8dae424234}.vmdk' is attached 
            to 1 virtual machines
Details: code VBOX_E_OBJECT_IN_USE (0x80bb000c), component Medium, interface
          IMedium, callee nsISupports
Context: "Close()" at line 1617 of file VBoxManageDisk.cpp
Well, that's not working then. However, we can change the backing store of disk3.vmdk to something that does exist:
$ grep RW ../disk3.vmdk 
RW 63 FLAT "disk3-pt.vmdk" 0
RW 8129 ZERO 
RW 7736320 FLAT "/dev/disk3s1" 0

$ touch /tmp/foo

$ grep RW ../disk3.vmdk 
RW 63 FLAT "disk3-pt.vmdk" 0
RW 8129 ZERO 
RW 7736320 FLAT "/tmp/foo" 0
And now we can delete the snapshot and the disk; the VM should start afterwards:
$ VBoxManage snapshot foo delete 505f9e2d-3d63-468e-8a86-b883ab9a10be

0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100%

$ VBoxManage closemedium disk fa9fb372-3ea5-4849-8fe6-b60989b6948e

Popcorn!

A bit late in the game, but here's a linkdump covering the recent Wikileaks Cablegate events - don't forget your popcorn!

Update:
Say No to Online Censorship!

bash completion leaves tty echo off after tail -f

Ah, this one bothered me for a while now, finally found it: Apparently when using bash-completion, Apple's /bin/bash gets confused after using e.g. "tail". From #25968:
$ . /opt/local/etc/bash_completion
$ tail -f .prof<TAB>ile
^C
After this (you have to use tab-completion to reach .profile), echo seems to be off. To fix this, simply type
  stty echo
or
  reset
and echo should be on again.

s9y backu^Wrestore

Of course I do regular backups of my Serendipity installation. As all articles are stored in a MySQL database, I only have to backup that plus serendipity_config_local.inc.php and the uploads directory. But I always wanted to know if a restore would work. And it does, with a few alterations, as the system I'm restoring to is slightly different from the original:

First we restore the files and directories:
$ tar -xjf serendipity-1.5.4.tar.bz2
$ mv serendipity s9y && cd s9y
$ chmod 0775 templates_c uploads
$ sudo chown root:www-data templates_c uploads
Or, if you're using an SVN checkout:
$ svn co svn://svn.berlios.de/serendipity/trunk serendipity-svn
$ mkdir /var/www/html/s9y && cd /var/www/html/s9y
$ for i in ../serendipity-svn/* | egrep -v 'templates_c|uploads'; do ln -s "$i"; done
$ mkdir -m0775 templates_c uploads
$ sudo chown root:www-data templates_c uploads
Import our configuration and the database backup:
$ cp ~/backup/serendipity_config_local.inc.php .
$ mysql -e 'create database s9y;'
$ bzip2 -dc ~/backups/s9y.sql.bz2" | mysql -D s9y
Because my DocumentRoot on the new machine is different and is not stored in serendipity_config_local.inc.php (why?) but in the database, we have to make a small modification here:
$ cd /var/www/html/s9y/
$ ln -s serendipity.css.php serendipity.css

$ mysql -D s9y
mysql> update serendipity_config set value = '/var/www/html/s9y/' \
            where name = 'serendipityPath';
mysql> update serendipity_config set value = 'http://10.10.0.3/s9y/' \
            where name = 'baseURL';
Note that the trailing slash is important! With all that, our s9y installation is working just fine.

DNSSEC woes

Somehow I could not resolve bugs.debian.org or security.debian.org any more. And it took quite a while to return NXDOMAIN. Was my OS to blame? My router even? Other hostnames were resolving just fine. Was it Debian's fault?

After some fiddling to rule out PEBKAC I noticed that my router has been equipped with new DNS servers: 75.75.75.75 and 75.75.76.76.

And indeed, both servers just wont resolve these hostnames anymore:
$ nslookup bugs.debian.org 75.75.75.75
Server:         75.75.75.75
Address:        75.75.75.75#53

** server can't find bugs.debian.org: NXDOMAIN

$ nslookup bugs.debian.org 75.75.75.76
;; connection timed out; no servers could be reached
This does not seem to be a new problem though; Comcast's DNSSEC tests were running all year long. But now they seem to roll out their new DNS servers to the endusers. And all would be cool, except:
Q: What happens if I try to access a website that fails DNSSEC validation?
A: The DNS will will send a "SERVFAIL" response to your computer.
Whooha. I'd rate this as a serious change - without any announcement to their customers? So now I'm off to their legacy DNS servers. The good news is, they will phase out their brain-damaged Comcast Domain Helper feature for now.

Btw, don't bother with OpenDNS, it's even more insane than "Domain Helper":
$ nslookup 1.1.1.341 208.67.222.222
Server:         208.67.222.222
Address:        208.67.222.222#53

Non-authoritative answer:
Name:   1.1.1.341
Address: 67.215.65.132


Update: Apparently someone filed a bug for this one - but it was closed and forwarded to debian-admin. So now it really seems that debian.org is missing the DS records. Deploying DNSSEC to the debian.org has been announced earlier this year, but it does not seem to be finished yet.

This still does not explain why fcc.gov cannot be resolved:
$ dig @75.75.75.75 fcc.gov
; <<>> DiG 9.6-ESV-R1 <<>> @75.75.75.75 fcc.gov
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached

$ dig @75.75.76.76 fcc.gov
; <<>> DiG 9.6-ESV-R1 <<>> @75.75.76.76 fcc.gov
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached
Update: Comcast got back to me with non-DNSSEC opt-out servers (that is, with "Domain Helper" disabled):
  Standard (Opt-Out) DNS Servers:
  Primary:   68.87.69.146
  Secondary: 68.87.85.98
However, the issue persists: the new DNSSEC servers cannot resolve certain hostnames :-\

Assigning different VRDP ports to all my VMs

Hint of the day: how to enable VRDP on all the VirtualBox VMs and assign a different VRDP port to each of them, so they don't collide:
j=0
for vm in `VBoxManage list vms | awk '/^\"/ {print $1}' | sed 's/\"//g'`; do
     k=`printf %02d $j`
     VBoxManage modifyvm "$vm" --vrdp on --vrdpport 389"$k"
     j=$((j+1))
done
Of course, if you have more than 99 VMs, the printf would look slightly different :-)