In which our hero makes the titular mistake.
I was in the process of creating a new DomU, a virtual machine guest under Xen, and had just completed a basic Arch install.
At this point I thought “Oh, it would be handy to have a bare-bones Arch image ready to go, I should make that happen”. So I took an LVM snapshot of the logical volume in one terminal window, and continued with post-install setup in another.
I went to copy the logical volume using dd and tab completed:
$ dd if=/dev/vg/newdomudisk of=/dev/vg/a<TAB>
$ dd if=/dev/vg/newdomudisk of=/dev/vg/archrootBecause it’s an Arch install, I had probably named it ‘archsomething’, right? Well, no.
I had named the intended LV ‘basearch’ because it’s a base Arch install. While I continued customising the guest, I had a nagging feeling that something wasn’t right.
$ ls /etc
Segmentation faultSide note: this is almost the same point as Mario Wolczko in the [in]famous recovery story as told to alt.forklore.computers, archived in a bunch of places (mirror here). Only his error was “ls: not found.” The story is well worth a read for the creativity shown in recovery.
My reaction was ‘Oh poop‘. I stopped the dd. Unfortunately it had written a good couple of gigabytes by that point. The ssh connection stayed up for a while, letting me see that most things had been nuked. Then the connection hung, and the guests stopped responding.
I was caught out in this situation by a couple of things. My other server running the Xen hypervisor uses Debian as a base, so it didn’t cross my mind that an Arch logical volume would be the one with the hypervisor. I was also multitasking, and didn’t double-check the target (LV) before dd-ing.
So: make names obvious. Make them blindingly obvious. I’ve named the new LV containing root for the Xen hypervisor xenroot. and you can bet I’ll be double and triple-checking dd for a good while, at least!