Error loading python dll when launching Anki after wine upgrade

ImageThis is at least the 2nd time it hit and took me some time to figure it out, so I might as well write it down here for future reference.

I was updating (read: breaking and re-compiling) a couple of packages on my good ‘ol Gentoo GNU/Linux Laptop, one of them being wine.
Yes, the platform of choice for running the most non-free software possible. Mr. Stallman does not approve.

I’m actually running the awesome flashcard program Anki in wine as opposed to it’s native GNU/Linux implementation. Why you may ask? Because it relies on many other bloaty-ish packages like QT which I want this system to be clean of. Instead of compiling another 350 MB of sources, running Anki in wine works quite well. I also use the unknown ion3 tiling window manager (RIP) on this system and am quite happy with it.

So anyways, after updating wine to 1.4, starting Anki in wine resulted in an ugly “Error loading python dll” error. I knew I’ve seen and fixed this before and the solution is actually quite simple:
All I needed to do was reinstalling Microsoft Visual C++ 2008 SP1 Redistributable in wine.
I have not the slightest idea how the upgrade manages to break this every time.

ESXi host VMware Tools package update error – Broken pipe

Today when I went to install the recent VMware Tools updates on some hosts via Update Manager while they were running without maintenance mode (Tools Updates are no problem and don’t need maintenance mode/reboots), I ran into the following error:
Could not stage image profile ‘(Updated) ESXi-5.0.0-20120302001-standard’: (‘VMware_locker_tools-light_5.0.0-1.18.768111’, ‘[Errno 32] Broken pipe’)

Not really helpful this generic error, huh?
I suspected this already, and looking at the esxupdate.log of the host via SSH made pretty clear what was the causing the error:

2012-07-18T08:11:26Z esxupdate: HostImage: DEBUG:  — Stage: LockerInstaller adding [VMware_locker_tools-light_5.0.0-1.18.768111], removing []
2012-07-18T08:11:26Z esxupdate: HostImage: INFO: Attempting to download VIB tools-light
2012-07-18T08:11:26Z esxupdate: downloader: DEBUG: Downloading from http://vcenter.alpacafarm.local:9084/vum/repository/hostupdate/vmw/vib20/tools-light/VMware_locker_tools-light_5.0.0-1.18.768111.vib…
2012-07-18T08:11:30Z esxupdate: LockerInstaller: WARNING: There was an error in cleaning up product locker: [Errno 16] Device or resource busy: ‘/locker/packages/5.0.0/vmtools/windows.iso’
2012-07-18T08:11:30Z esxupdate: esxupdate: ERROR: An esxupdate error exception was caught:

Some VM obviously still has one of the tools images mounted! Just which of the ~30 running on that host is the culprit? While I was already connected to the host via SSH to check out the esxupdate.log file, I thought I might as well figure out the VM from here. So I ran the following command from the shell to dig through the VM config files:
find /vmfs/volumes/ -iname *.vmx | while read vmx; do grep -isH “/usr/lib/vmware/isoimages” $vmx ; done

Well, this filtered the list down quite a bit, but it listed a lot of innocent VMs too. That is because apparantly some tools update/installation procedures or CD (de)mounting in general doesn’t cleanup the “ide1:0.fileName = “/path/to/image/goes/here.iso” VMX directive properly. You will not see this image path in the GUI Client or elsewhere.

So let’s move on to our good ‘ol friend powercli in order to see who is to blame. The following one-liner shows us which VMs are actually actively bound to a VMware Tools image:
Get-VM | where { $_ | Get-CDDrive | where { $_.IsoPath -like “*/usr/lib/vmware*” } } | Select Name

As you can see it is actually not connected or anything, but still holding up a lock on the image. We can just set it to Client Device in the GUI to get rid of it, or if you want to do it in an automated fashion based on the previous powercli line, you may as well just execute this:
Get-VM | where { $_ | Get-CDDrive | where { $_.IsoPath -like “*/usr/lib/vmware*” } } | foreach { Get-CDDrive $_ | Set-CDDrive -NoMedia -Confirm:$false }

Et vóila, the device is now disconnected properly and I can update my tools-light packages on the host.


After figuring that out I went back to my SSH shell to see what I could have used to track the issue down from there. It would have had to look like this in my case:
find /vmfs/volumes/ -iname *.vmx | while read vmx; do grep -isH “clientDevice = \’false\'” $vmx ; done

Note that this kind of iterating through VMX files only works with VMX files of VMs the host you’re on is actually running. VMX files on shared storage which other hosts are accessing will generate a “Device or resource busy” warning (suppressed by via grep -s).
And of course one could have used powercli to check the raw VMX parameters too!