screen + minicom (how to get out of)

So, I did it again. You see, I like to use minicom as a terminal program since it plays nice with my usb-to-serial cables and my serial devices (Sun and AIX workstations, Seagate Dockstar, Pogoplug, routers, switches). And I have used it long enough to remember some of the commands. I also like screen, which allows me to run multiple sessions on different machines and stop and resume them as needed; kinda like running vnc/rdp but in command-line.

The problem begins when I try to use them together. I really should not do that because you can connect to a serial port from screen by doing something like

:screen /dev/ttyUSB0 115200

(some devices I use have their default port speed set to 9600, others like the one in this example to 115200)

But, force of habit (read: lazyness) or distraction (did you see that ant crawling up the wall?) caused me to start minicom right in screen. At first that does not seem to be a bad idea; after all, it would be nice to connect to the console of, say, a Brocade fabric switch, start something there, log out, and then come back to it later. But, problem is that screen and minicom by default use the same CTRL-A sequence to enter commands. So, if I want to send a CTRL-A X (exit) to minicom, screen will think I am talking to it and then lock the screen. Not fun.

Some of you will argue that I could remap the escape sequences for each program so they will not match, but hindsight is 20/20: it does not do me any good once they are already running inside each other. Another option would be to close that screen session, which would quit minicom... but not gracefully. As a result, that serial port (/dev/ttyUSB0 in my case. Yes, it is USB but you know exactly what I am talking about) would not be freed even if I remove the serial-to-USB cable. We need something better.

If we look at the screen man page, we will find the escape sequence CTRL-a a. What it does is send a CTRL-a escape to the screen session, so whatever program running in that session can grab and run away with it. So, what we want to do is probably CTRL-a a x, which should quit minicom. Now, the trick here is speed: you have to press CTRL-a together, then immediately a and then x. It took a while for me because I was either not typing fast enough or just mashing keys together. But, once I got it just right, I was rewarded with the minicom quit dialog box:

+----------------------+
|    Leave Minicom?    |
|     Yes       No     |
+----------------------+

And now I was able to properly quit minicom. Life was good once again.

Do I plan on running minicom inside screen again? Not if I can avoid it. But, if I can't, now I have a way out.

Deleting VirtualBox drives that do not want to be deleted

Today's episode began with me wanting to delete a VirtualBox virtual machine (vm for short) that was acting up in a rather bad way. I was at the point that all I wanted to do was wipe it and restart from scratch. Problem is I screwed up, out of frustration, in the deleting the old vm. I thought I had done it right and then wiped the old directory and proceded to recreate the vm... just to find out that virtualbox thought the new disk image was associated with some snapshots that were in fact associated with the old image. So, I decided to tell virtualbox to just delete the image:

root@fileserver:~# VBoxManage closemedium disk /export/hosts/sambabox/sambabox.vdi --delete
VBoxManage: error: Storage for the medium '/export/hosts/sambabox/sambabox.vdi' is already created
VBoxManage: error: Details: code VBOX_E_INVALID_OBJECT_STATE (0x80bb0007), component Medium, interface IMedium, callee nsISupports
Context: "DeleteStorage(progress.asOutParam())" at line 1166 of file VBoxManageDisk.cpp
VBoxManage: error: Failed to delete medium. Error code Unknown Status 0x80BB000C
VBoxManage: error: Cannot close medium '/export/hosts/sambabox/sambabox.vdi' because it has 2 child media
VBoxManage: error: Details: code VBOX_E_OBJECT_IN_USE (0x80bb000c), component Medium, interface IMedium, callee nsISupports
Context: "Close()" at line 1182 of file VBoxManageDisk.cpp
root@fileserver:~#

As you can see, it did not work quite as I expected. What to do now since all the old files, snapshots included, are gone? Well, it seems that virtualbox still somehow knows about all the drives even though they are not mentioned in VirtualBox.xml:

root@fileserver:~# VBoxManage list hdds
UUID:        1c2b04ba-7090-4ad9-8db0-9884f254ca23
Parent UUID: base
Format:      VMDK
Location:    /export/hosts/windowsXP32/windowsXP32-disk1.vmdk
State:       locked write
Type:        normal
Usage:       windowsXP32 (UUID: d5c4efde-5587-43b6-bf81-8f606a746c58)

UUID:        a9275089-0812-43d3-b3b8-da7dea5c0dc7
Parent UUID: base
Format:      VDI
Location:    /export/hosts/sambabox/sambabox.vdi
State:       inaccessible
Type:        normal

UUID:        98a1f274-93af-4747-988d-b8e91cac00b8
Parent UUID: a9275089-0812-43d3-b3b8-da7dea5c0dc7
Format:      VDI
Location:    /export/hosts/sambabox/Snapshots/{98a1f274-93af-4747-988d-b8e91cac00b8}.vdi
State:       inaccessible
Type:        normal

UUID:        d33e0420-4f1f-461c-abc8-bb38c55697b8
Parent UUID: a9275089-0812-43d3-b3b8-da7dea5c0dc7
Format:      VDI
Location:    /export/hosts/sambabox/Snapshots/{d33e0420-4f1f-461c-abc8-bb38c55697b8}.vdi
State:       inaccessible
Type:        normal

root@fileserver:~# 

Look at the inaccessible ones. Note their path: as far as virtualbox is concerned, they are in the sambabox snapshot directory. I would bet a cookie that is my problem. Now, how to delete it? I tried providing the path (/export/hosts/sambabox/Snapshots/{98a1f274-93af-4747-988d-b8e91cac00b8}.vdi) and that did not work.

Well, it did not work because the file itself is no longer with us. But, what if we enter the UUID instead?

root@fileserver:~# VBoxManage closemedium disk 98a1f274-93af-4747-988d-b8e91cac00b8
root@fileserver:~# VBoxManage list hdds
UUID:        1c2b04ba-7090-4ad9-8db0-9884f254ca23
Parent UUID: base
Format:      VMDK
Location:    /export/hosts/windowsXP32/windowsXP32-disk1.vmdk
State:       locked write
Type:        normal
Usage:       windowsXP32 (UUID: d5c4efde-5587-43b6-bf81-8f606a746c58)

UUID:        a9275089-0812-43d3-b3b8-da7dea5c0dc7
Parent UUID: base
Format:      VDI
Location:    /export/hosts/sambabox/sambabox.vdi
State:       inaccessible
Type:        normal

root@fileserver:~# VBoxManage closemedium disk a9275089-0812-43d3-b3b8-da7dea5c0dc7
root@fileserver:~# VBoxManage list hdds
UUID:        1c2b04ba-7090-4ad9-8db0-9884f254ca23
Parent UUID: base
Format:      VMDK
Location:    /export/hosts/windowsXP32/windowsXP32-disk1.vmdk
State:       locked write
Type:        normal
Usage:       windowsXP32 (UUID: d5c4efde-5587-43b6-bf81-8f606a746c58)

root@fileserver:~# 

As you can see from above, using the UUID did work out rather nicely. You have to delete the inaccessible files in the reverse order they were created but after a few steps all the offending images were gone. And now we can install a new version of this vm without fear that unloved images will come back to haunt us.