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
vboxmanage unregistervm <UUID>
- Copy the backup vbox file over the existing, wrong one
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)
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.
I like Meld as a visual diff/merge tool. You can also use it as the default in TortoiseHg. Open TortoiseHg’s Workbench. Go to
Settings, make sure the
global settings tab is active. Click
Edit File, if it doesn’t yet exist create a section called
[extdiff], and under
cmd.meld = /path/to/meld. For Windows it would be something like
cmd.meld = C:\Program Files (x86)\Meld\meld.exe. From the command line you should be able to use hg meld to get your diff shown in Meld.
Up until recently I often found myself switching back and forth between using
tail to monitor a file and
vimto page through it. I cannot understand how I missed the option, but when viewing a file with
less, simply press
F and it will go into monitoring mode. And by interrupting you go back to paging mode. So very convenient and it involves less context switching.
I have previously written on this subject, but now I am using IntelliJ IDEA 13 with the latest Android SDK of this writing (September 2014) and when you create a project you might be greeted by an error message like the following:
Error:Gradle: A problem occurred configuring project ':projectname'.
> Could not resolve all dependencies for configuration ':projectname:_debugCompile'.
> Could not find any version that matches com.android.support:support-v4:0.0.+.
> Could not find any version that matches com.android.support:appcompat-v7:19.+.
The Android SDK has switched over to Gradle since I last wrote about it. In this case the default setup already searches the local
libs directory under
Projectname/projectname for any jars to compile with the build of the application. But if you would follow the instructions from my previous post the chance is high that you keep running into this problem. Aside from the installation of the
Android Support Library, you will also need to install the
Android Support Repository in order to make dependency resolution work. Do verify that your
Projectname/local.properties contains a set property for
sdk.dir that points to the root of your locally installed Android SDK.
Now, you might still run into problems. The thing is that in your
Projectname/projectname/build.gradle you generally want to have the compile lines for
appcompat-v7 match the version of your
targetSdkVersion. So this might become:
compile fileTree(dir: 'libs', include: ['*.jar'])
These numbers can be found in the SDK under
extras/android/m2repository/com/android/support under the respective entries for
support-v4. If you would use
+ for the version identifier, you run the chance of picking up the latest version, including release candidates and this might break your build. So in this case being explicit is better than depending on it implictly.
Edit: On second thought, it might be better to use 20.+ or 20.0.+ for the version identifier in order to automatically pick up bugfix releases down the line. Looking at the release notes of the support library it seems that Google is quite strict in sticking to semantic versioning.
Having resolved recent SSL certificate issues with Mercurial/TortoiseHG, I now encountered a similar issue with the wildcard certificate for
*.google.com where getting a clone would result in a
"SSL: Server certificate verify failed" error.
One way around this issue is to add the fingerprint for this certificate to your configuration. Currently for
*.google.com this is
00:d5:88:35:29:b9:7f:03:92:60:c2:04:e4:b7:01:f0:07:53:15:a8 and one way to get this from a Unix command line is with
openssl s_client -connect code.google.com:443 < /dev/null 2> /dev/null | openssl x509 -in cert-code -fingerprint -noout -in /dev/stdin | tr "[:upper:]" "[:lower:]". This corresponds with Chrome’s certificate view’s thumbprint field, you just need to add colons.
Right click in Explorer, select
TortoiseHG » Global Settings and then click
Edit File and add the following:
code.google.com = 00:d5:88:35:29:b9:7f:03:92:60:c2:04:e4:b7:01:f0:07:53:15:a8
This should make Mercurial/TortoiseHG work, at least until the certificate expires and you need to update it with the latest fingerprint.
For my own development I use Mercurial and TortoiseHG for my version control system. I also use, at the moment, a CAcert certificate to use HTTPS with my repositories. I am not sure what changed when, but apparently the certificates now get verified. So this causes obvious problems trying to push or pull due to
"SSL: Server certificate verify failed" errors.
To make this work on a Windows 7 machine with TortoiseHG in stalled, first download the CAcert root PEM certificate and place it some permanent directory. Next open the TortoiseHG global settings (right click somewhere in Explorer and select
TortoiseHG » Global Settings). In the window that opens click the Edit File button. If it does not exist yet create a section similar to this:
cacerts = C:\path\to\cacert-root.pem
OK and any push and pull action with HTTPS URLs should work as they ought to.
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.
I am really impressed with pkgng. On the mebsd website there’s a handy explanation and tutorial that’s really worth reading to get up to speed.
If, like me, you had a working FreeBSD system with amavisd-new and p0f set up, you might find that p0f suddenly stopped working at some point. The cause for this is that it tries to use pcap on the USB bus, which it cannot do. The solution is to put
hw.usb.no_pf=1 in your
I pin programs that I use frequently to the taskbar of Windows. So I was a bit surprised to see that the newer version of Eclipse, Juno, doesn’t seem to support this by default. After some searching I find out that you can force this by adjusting the
eclipse.ini by starting the file with something akin to:
Then after starting Eclipse with this in place, you can, once fully loaded and past the splash screen, pin Eclipse to the taskbar.