I recently started receiving the following error from SkyDrive Pro (not to be confused with the Free ‘SkyDrive’) after changing some hardware in my computer. I have Windows 8 Professional 64bit with Office 2013 Professional Plus. This solution will also work for users of Office365

[SkyDrive Pro Critical Error]

SkyDrive Pro needs to close becuase of a hardware or configuration problem.

Error Description: Unspecified error

HRESULT: 0x8004005

AssertTag: 0x00c6d180

SkyDriveProCriticalError

After much searching, I found the following to be the solution to the problem.

  1. Close any SkyDrive related processes. Look for SkyDrive and Groove in your process list. Stop them all!
  2. Open a command prompt (Not PowerShell!) and change to the directory where Microsoft Office 2013 is installed.

(type) cd “C:Program FilesMicrosoft OfficeOffice15” (press enter)

(type) groove.exe /clean /all (press enter)

The above command clears all SkyDrive Pro cache and settings, setting it back to default again.  You can now restart SkyDrive services and sync from SharePoint / Office365 again.

References:

  • http://support.microsoft.com/kb/982279

Having recently set up OpenVZ on Xen, I wanted to create a Debian 7 VPS for a friend. Unfortunately, after creation, the VPS would not start. I kept receiving the following error message:

FATAL: kernel too old

This is actually an error message from the VPS, not the OpenVZ node level. In short, the new Debian 7 VPS was expecting a kernel newer than 2.6.18 (the OpenVZ node level version). Remember: OpenVZ VPS’s don’t have their own kernel, they run on the OpenVZ node level kernel, but you can replace the version that is available 😉

Thanks to Nallappan TK at Linux by TK Nalla for the original post.

We need to replace the kernel version in ‘/proc/sys/kernel/virt_osrelease’ on the OpenVZ node level.

# cd /proc/sys/kernel/

# cat virt_osrelease
2.6.18-348.4.1.el5.028stab107.2xen

# echo 2.6.32 > virt_osrelease

Thats it! You should now be able to start the VPS. Generally speaking, you should be able to increase the kernel version to whatever version a VPS is expecting, whenever you get that error message. Now, how to find out what kernel version a VPS OS is expecting…

Update 14-09-2013: I received a tweet from _openvz_ earlier this week indicating you can set the expected kernel version for each OS template in the /etc/vz/osrelease.conf file. As per the above, I was trying to start a Debian 7 based VPS. My /etc/vz/osrelease.conf file did not contain an entry for Debian 7. I proceeded to revert the above change to the /proc/sys/kernel/virt_osrelease file and added an entry to the /etc/vz/osrelease.conf file instead:

# cd /proc/sys/kernel/

# cat virt_osrelease
2.6.32

echo 2.6.18-348.4.1.el5.028stab107.2xen > virt_osrelease

# cat virt_osrelease
2.6.18-348.4.1.el5.028stab107.2xen

# cd /etc/vz

# vi osrelease.conf

[press the insert button]

(I added the following line to the end)

debian-7.0      2.6.32

[press the escape button]

(type a colon)

(type: wq)

:wq

[Press the enter button]

I then created a new Debian 7.0 VPS that deployed and started successfully!

  1. Prepare a Xen VM with a minimal install of CentOS/RHEL 5 (64bit or 32bit).
    1. Make sure you have set your host name and IP Addressing etc. The VM should have internet access (obviously).
  2. Install HyperVM following these instructions.
    1. Be sure to append [–virtualization-type=openvz] (omit the square brackets) to the install command.
  3. At the end of the installer, don’t reboot!
    1. The default OpenVZ kernel installed by the HyperVM installer won’t work inside of a Xen VM (it will work on a normal bare metal server). Download the proper kernel for your architecture: 32bit (i686) or 64bit (x86_64). At the time of writing, the current OpenVZ kernel was 2.6.18-384.4.1.
    2. You are specifically looking to download and install the kernel that starts with: ‘ovzkernel-xen’ anything else will likely install, but will not boot!
    3. Install using this command [# rpm -ivh ovzkernel-xen-*.rpm] – Don’t use [# rpm -Uvh] you will upgrade the installed kernel instead and you will lose the ability to roll back to a known working kernel should things go wrong.
    4. Open your /boot/grub/grub.conf file (in vi or nano) and make sure you are able to differentiate between the existing kernel and the ovzkernel-xen kernel. Perhaps append something to the title line, like ‘OpenVZ-Xen’. I saw three kernels in mine, the original CentoS 5 kernel, the OpenVZ kernel (installed by the HyperVM installer) and the OpenVZ-Xen kernel.
  4. Now it’s time to reboot. How you perform this step will be dependant on a couple of things.
    1. If you have console access to your VM (it may be via an alternate SSH connection or applet if your hosting provider has one), I suggest not editing your grub.conf file just yet. Connect to the console and reboot the VM. You can then catch the grub boot loader and choose the OpenVZ-Xen kernel (not to be confused with the similar named OpenVZ kernel). If all goes well, you can edit the grub.conf file later and set grub to boot from the OpenVZ-Xen kernel by default. If things break, you’ll either be able to reboot and choose a different ‘known working’ kernel, or your VM won’t boot at all. In this case you’ll have to ask your hosting provider to switch your default kernel back to the original kernel. If you have Dom0 access (you’ll know what this if you do) you can edit grub.conf via pyGrub and try again.
    2. If you don’t have console access, you’ll need to edit the grub.conf file first and set the OpenVZ-Xen kernel as the default kernel and reboot, hoping all goes well. As above, if all does go well, you’ll be able to login via SSH and also to the HypeVM control panel. If things break and you lose access to your VM, you’ll have to contact your hosting provider and have them investigate for you. You can assist them be asking them to configure grub to boot from the standard normal CentOS kernel again. Afterwards, when you have access, you can try again 😉
  5. By default, HyperVM wants to use the ‘Xen driver’ as the virtualisation method. This won’t work, you can’t run xen VMs inside of a Xen VM. Why Xen is the default ‘driver’ when you chose OpenVZ at the very beginning? I have no idea.
    1. Use the following commands to switch the system from Xen to OpenVZ [#. /scripts/directory] [# lphp.exe ../bin/common/setdriver.php –server=localhost –class=vps –driver=openvz] (omit the square brackets of course). There are two commands, the first changes the current working directory, the second changes the virtualisation driver.
    2. After a few moments, you’ll see a confirmation message.
  6. You’re done! You can now login to the HyperVM control panel, add IP Addresses and create VMs!

Comments, Suggestions, Requests, all welcome 😉

A little while ago (and again more recently) I updated my kernel to 3.7.3-101 and was stumped as to why VMware Workstation was unable to find the matching kernel headers, despite confirming they were indeed correct and installed. After lots of searching and some reading, I found the following command:

ln -s /usr/src/kernels/3.7.3-101.fc17.x86_64/include/generated/uapi/linux/version.h /usr/src/kernels/3.7.3-101.fc17.x86_64/include/linux/version.h

This basically creates a symbolic link in the /usr/src/kernels/<version>/include/linux/ directory for the version.h file that the VMware Workstation compiler is looking for. After running this command, I started VMware Workstation again and was greeted by the GUI compiling the necessary modules to run VMware Workstation.

I suspect the requirement for this command has something to do with re-arrangement of kernel source files in recent releases. It seems likely that VMware will update the compiler in new releases of their Workstation product.

Here’s a more recent upgrade, using the same step:

ln -s /usr/src/kernels/3.7.9-101.fc17.x86_64/include/generated/uapi/linux/version.h /usr/src/kernels/3.7.9-101.fc17.x86_64/include/linux/version.h

So long as you have the matching kernel headers installed, the above command should work for you just fine.

Note: On the second time around, I had troubles when running VMware Workstation as a normal user (just the compiling step, afterwards it was fine). For some reason there was an issue elevating the user to root (this happened to me on Fedora 17 x86_64) to complete the compiler process. To work around this, I simply opened a console/terminal, became root (sudo, or su – , whatever suits you) and then typed just: vmware – The compiler GUI appeared and completed, followed by VMware Workstation starting. I then closed ‘that’ VMware Workstation and started it my usual way (KDE menu for me) and it worked just fine.

Update (2013-03-25): VMware has recently released VMware Workstation 9.0.2 (2013-03-07) which has the above issue resolved. I am currently running VMware Workstation 9.0.2 build-1031769 on Fedora 17 (Kernel 3.8.3-103) and I did not have to carry out any additional steps to compile the kernel modules.

Update 2 (2013-07-10): I updated my kernel today, all the way up to 3.9.6-200-fc18 – Afterwards I was unable to compile the module again. After much searching, trouble-shooting and attempts to roll back to previous kernels, I checked something a little more fundamental; was gcc installed? Nope! It wasn’t! A quick browse through my yum logs showed it removed as a dependency when I removed something else earlier in the year. After installing gcc again, the kernel module compiled normally again 😉

Update 3 (2013-08-30): I updated my kernel again today, just a standard yum update with all the usual packages. My kernel ended up on 3.10.9-200.fc18.x86_64 (I haven’t upgraded to Fedora 19 yet). This time, the vmware kernel modules kept failing to compile (different to the previous issues). I did a quick google search for “vmware kernel 3.10.9-100” and found this article. If you follow the instructions, verbatim, the issue is solved straight away. For reference, I’ve copied the main content of the article below. Kudos to the author at http://guide.ecsmy.com/ for getting this one out there!

# tar xf /usr/lib/vmware/modules/source/vmnet.tar
# cd vmnet-only
# wget  http://communities.vmware.com/servlet/JiveServlet/download/2239207-108590/procfs.patch
# patch -p1 < procfs.patch
# cd ..
# tar -cvf vmnet.tar vmnet-only/
# cp vmnet.tar /usr/lib/vmware/modules/source/

This will patch the procfs interface.

Secondly download the vmnet patch from http://mysticalzero.blogspot.com/2013/07/vmblock-patch-for-linux-310-vmware.html. The link of the patch is here.

Or you can use the following command:

# tar xf /usr/lib/vmware/modules/source/vmblock.tar
# cd vmblock-only
# wget  https://sites.google.com/site/mysticalzerotmp/vmblock.3.10.patch
# patch -p1 < vmblock.3.10.patch
# cd ..
# tar -cvf vmblock.tar vmblock-only/
# cp vmblock.tar /usr/lib/vmware/modules/source/

Then, issue this command to compile and install the vmware player module

# sudo vmware-modconfig –console –install-all

I know it says ‘vmware player’ but trust me, it works for VMware Workstation just the same.

Update 4 (2013-10-20): I updated my kernel again today, just a standard yum update with all the usual packages. My kernel ended up on 3.11.4-101.fc18.x86_64 (I haven’t upgraded to Fedora 19 yet). This time, the vmware kernel vmblock module kept failing to compile (similar but different to the previous issue). I did a quick google search for “vmware kernel 3.11” and found this article. If you follow the instructions, verbatim, the issue is solved straight away. For reference, I’ve copied the main content of the article below. Kudos to the author (dibl) at siduction.org for getting this one out there!

The VMware module source needs to be patched to build on kernel 3.11. If you have already patched for 3.10, then only a single patch is needed. Here is the procedure:

Download the “vmblock.3.11.patch” from here.

In a root terminal, give these commands:

# cd /usr/lib/vmware/modules/source
# tar xvf vmblock.tar
# cd vmblock-only
# patch -p1 < /path/to/vmblock-3.11.patch
# cd ..
# tar cvf vmblock.tar vmblock-only/
# vmware-modconfig –console –install-all

You should see an error-free completion of the build.

Update 5 (2013-12-14): While still on Fedora 18 (I know, Fedora 19 is well and truly out, and Fedora 20 (celebrating 10 years of Fedora Linux!) is less than three weeks away from release!), I just upgraded to Kernel 3.11.10-100. I also upgrade from VMware Workstation 9.0.2 to VMware Workstation 10.0.1 – After a reboot, no additional work required. VMware Workstation 10.0.1 simply worked ‘straight out of the box’ so to speak 😉