| Published:
| Reading Time:
3 minutes
| Author:

| Simple Fixes For A Complex Problem

  1. Fixing Linux-Cloud-Tools-Common in Ubuntu on Azure
  2. The Long Term Fix: Cloud-Tools-Common On Ubuntu 14.04 LTS

In a previous post we detailed an issue we were facing with performing updates on Ubuntu 14.04 LTS on the Microsoft Azure Cloud Network.

Setting up linux-cloud-tools-common (3.13.0-36.63) ...
start: Job failed to start
invoke-rc.d: initscript HV-kvp daemon, action "start" failed.
dpkg: error processing linux package cloud-tools-common (--configure): subprocess installed post-installation script Returned error exit status 1
dpkg: dependency problems preventinfo configuration or linux-cloud-tools-3.13.0-34: linux-cloud-tools-3.13.0-34 depends on linux-cloud tools-common; HOWEVER: Package linux-cloud-tools-common is not configured yet.

Unable to fix this issue, we sought help from the Linux and Server communities, but received either no response or a lack of any suggestions that helped. Whilst there wasn’t and still isn’t many examples of others experiencing this problem, we did notice that in all cases this was a problem with Ubuntu on the Azure Network.

Within a short period of time we were experiencing further issues when trying to update or install other packages. This compounding of issues meant we were unable to restart Apache on the most seriously affected machine, and thus we had an emergency situation.

Ultimately we found some clues that led us to a workaround, which enabled us to keep the system up to date and fully operation. This however, meant manually editing a server config file, performing the update and then restoring the file. This was better than nothing, but ultimately labourious and repetitive. As time has past we’ve huge amounts of traffic to our blog post with the above solution, and evidently little hope for a long term solution.

Much time passed and then finally we received a comment suggesting a more long term fix. This solution suggested creating a sym link, which essentially create an alias for the missing file and points to an existing file. Again, this seemed like an encouraging development but failed to give any details on how to do it.  Further reading on the Ubuntu bugs site suggested that the missing file was simply named wrong or the infamous ‘exec /usr/sbin/hv_kvp_daemon’  command should actually read as ‘exec /usr/sbin/hv_kvp_daemon.hv-kvp-daemon-init’.

Eitherway, we now knew that the comment we received was pointing in the right direction towards a permanent fix. As such we’re now presented with two ways to implement a long term fix, as we detail below.


Fix 1: The File Rename

  1. Log-in to your terminal:
  2. run the following code:
mv /usr/sbin/hv_kvp_daemon /usr/sbin/hv_kvp_daemon.hv-kvp-daemon-init

This method renames the file ‘/usr/sbin/hv_kvp_daemon.hv-kvp-daemon-init’ to ‘/usr/sbin/hv_kvp_daemon.hv-kvp-daemon’ and allows ‘hv-kvp-daemon.conf’ to run as expected. However, it’s possible that some part of the server may need to run ‘/usr/sbin/hv_kvp_daemon.hv-kvp-daemon-init’ at some point. Since this file would no longer exist, you may have issues.


Fix 2: The Symbolic Link

  1. Log-in to your terminal:
  2. run the following code:
ln -s /usr/sbin/hv_kvp_daemon.hv-kvp-daemon-init /usr/sbin/hv_kvp_daemon


In all we now have 3 working solutions to the problem, however each has it’s issues. The original solution that we recommend has been tried and testing over the last year and we’ve had no reports of issues. Whilst this method does require you to manually edit the ‘hv-kvp-daemon.conf’, performing the update and then restoring ‘hv-kvp-daemon.conf’, it does at least return the system to it’s natively state. At worst, rebooting the system will ensure a normal startup.

However, the two options detailed above, give the ability to potentially set the fix and then leave the system alone. However, there may be issue down the road. In the case of Fix 1: The File Rename, you are physically renaming the file and thus any actions on the server requiring the old file name will kick up a fuss. Who knows if or when this might happen, and what the consequence might be?

Fix 2: The Symbolic Link offers all the benefits of file renaming but without actually having to rename the file. So both version of the file name will be available to the system whenever needed, and so there should be no issues here. However, I have some recollection of symbolic links potentially causing potential issues with dependencies and commands such as ‘autoremove’. I’m by no means a Ubuntu expert and I can’t remember the specifics of the above statement, but it’s something to bare in mind.

So, the cleanest fix is likely achieved from implementing the symbolic link. However, if you are less confident &/or are fairly new to Ubuntu we’d recommend the manual editing of ‘hv-kvp-daemon.conf’ as detailed in our previous post.

Let us know in the comments how you get on with the various solutions to the linux-cloud-tools-common issue. If you have any thoughts, questions or comments, let us know below.