So after a recent update of VirtualBox from 5.0.20 to 5.0.22 I found that a Windows 7 image I have suddenly didn't work anymore. Worse yet, everything was empty or reset to default values.

You can most likely recover from this by following these steps:

• Close VirtualBox (although you might not want to until you safeguarded vbox-prev if you find out you don't have a versioned backup file)
• Go to the directory you have your VM files
• In here look for your faulty image's directory and cd in
• Look for a vbox file with the same name as your image, but most likely containing a version number as the settings/metadata file got upgraded. DO NOT lose this file.
• Run a vboxmanage list vms
• Copy the UUID listed as inaccessible
• Run vboxmanage unregistervm <UUID>
• Copy the backup vbox file over the existing, wrong one
• Run vboxmanage registervm /path/to/file.vbox
• Most likely VBoxManage will error out with an error about a conflict with DVD images with different UUIDs (in my case)
• Edit the vbox file, remove offending line (in the case of the DVD image, might be more difficult with other error cases)
• Run vboxmanage registervm /path/to/file.vbox again
• VBoxManage should now not error out
• Start VirtualBox and your VM should be ok again

Of course the behaviour from VirtualBox is downright dangerous here. If there is such a conflict or error it should NEVER mess around with your metadata file and thus corrupt it. This is one of the biggest sins in software programming. Only after you successfully start an application are you allowed to write out any updates of settings files and whatnot.

If PyCharm complains that it Can't start Mercurial: /usr/bin/hg Probably the path to hg executable is not valid, then check if running hg from the command line triggers a problem running a certain extension. In my case I had a version of keyring and mercurial_keyring that did not play nice with each other. After upgrading these to 3.0.5 and 0.6.0 respectively, the problem went away. I guess PyCharm tests the run of the hg binary and if the shell return code (echo $?) is something other than 0 will show this warning.

After upgrading various ports on my FreeBSD system and days later a full world and kernel, a reboot showed me that unbound didn't start. The system reported that:

error: reading root hints
/usr/local/etc/unbound/named.cache 88: Empty line was returned

It turns out that from ldns 1.6.13 to 1.6.14 there is an API change that caused problems for unbound. After upgrading ldns you also need to recompile unbound to pick up on these changes. If you do not, you will run into the problem above.

So recently I had an issue with Steam where the Witcher 2 update got stuck at 99% and the status "Update Paused". No matter what I tried with the pause/resume button, I couldn't get it to budge from this status and actually update.

After a while I grabbed Process Explorer from the Microsoft website and checked the files that were being opened when I toggled this state. I noticed a reference to Steamsteamappsdownloading20920CookedPCpack0.dzip. Then I also noticed a file reference to Steamsteamapplogscontent.log. Upon checking that file I found a notice that it was trying to preallocate about 11 GB for this pack0.dzip. Checking my drive status, I saw that this particular drive letter only had about 9 GB left. Freeing up some space allowed the update process to actually start and finish, after which I got even more space back, since it seems Steam downloads these files and then replaces them, deleting the temporary one. So I guess the lesson learnt is that you should always have enough disk space free as the single largest file in any of your games.

I recently switched to using xfce on my FreeBSD desktop. Window Maker is nice but it was starting to feel a bit dated. Thus far I like xfce, but I had one problem with Terminal. Whenever I tried to resize it or switch desktops to one with Terminal open in it I could see it painstakingly render the window. Xterm and aterm didn't exhibit this behaviour, my 3d was accelerated, and other screen drawing didn't show problems either (do note I am using NVIDIA's binary driver for my GeForce 8800, the nv driver from X.org is unusable at this point).

Someone pointed me at the environment variable XLIB_SKIP_ARGB_VISUALS=1. Once added to .zshenv, properly exported on my shell and an X restart later I find Terminal to zoom along as expected. It turns out that the NVIDIA driver doesn't properly accelerate alpha channels.

I have a 256 colour xterm set up on my DragonFly box.

Works perfectly. Especially for vim.

Now, I use FreeBSD 5.x as a gateway box to ssh into and have irssi and likewise programs screened.

Now, I was surprised to learn that I had only 16 colours. Outside of screen I had a full 256 colour palette (make sure to fix your PuTTY configuration by the way), but inside I was stripped of my colour scheme.

So I set off to find what was causing this. Interestingly enough one of the first emails encountered was from Jeremy Chadwick who had the exact same problem.

Turns out that screen needs to be compiled with 256 colour support (a knob should be in your ports Makefile now).

Since FreeBSD's and DragonFly's termcap is bereft of any 256 colour definitions for xterm apparently, you need to add the following to $HOME/.screenrc:

termcap xterm* 'Co#256:AB=E[48;5;%dm:AF=E[38;5;%dm'
terminfo xterm* 'Co#256:AB=E[48;5;%p1%dm:AF=E[38;5;%p1%dm'

This overrides your termcap settings with the appropriate definitions.

If you now start screen from a shell that has TERM exported as xterm or xterm-color (xterm* wildcard actually) it will fork off to a screen with 256 colour support.

You might need this in $HOME/.vimrc:

if &term =~ "xterm" || &term =~ "screen"
  set t_Co=256
  if has("terminfo")
    let &t_Sf=nr2char(27).'[3%p1%dm'
    let &t_Sb=nr2char(27).'[4%p1%dm'
  else
    let &t_Sf=nr2char(27).'[3%dm'
    let &t_Sb=nr2char(27).'[4%dm'
  endif
endif