The other day I was patching a couple of hosts on one of our environments. All worked out fine until I got one host that refused to update from vSphere ESXi 6.5 U1 to ESXi 6.5 U3. Throughout the day this host actually gave me loads of different errors. In this blogpost I will post them all in case you are able to reference this to your own issues. Below are the errors I witnessed during the day, not in any particular order.

The last two messages is when I started browsing the web to find a solution. Us silly tenacious engineers always try to find a solution ourselves. I checked the following settings/items during the troubleshooting session. These are my go to checks when there is something wrong with a host:

  1. vdf -h (check if ramdisk is full).
  2. df -h (check if there are full partitions).
  3. Check /var/log/esxupdate for any entries that make some sense.
  4. Check the /var/log/vmkernel.log and /var/log/hostd.log for entries that make some sense.
  5. Check the /locker partition. If that’s empty or full of logfiles that’s usually not good (see KB2030665 or KB60372)
    1. Use df /locker for example.
    2. Use du -sh /locker/* to check on file sizes.
  6. Check Update Manager settings and health (in the vCenter) to verifiy Update Manager isn’t broken.
  7. If all else fails, reboot the host just in case.

As you can probably guess, the above didn’t really help fix my issue. I did however find the error message about the ‘altbootbank’ interesting and decided to search the web for a solution. Turns out, VMware has a resolution for this mentioned in the following KB2033564.

They don’t say much in the KB as to why this is happening, but the resolution worked out fine for me. All you have to do is the following:

You have to run the above command to find the device for the /altbootbank. You can do this with vmkfstools -P (Query filesystem). Once you did that you can “repair” the filesystem with the following command (-a to automatically fix any found errors, and -w to write them to disk immediately):

Once I did the above I could immediately return to the remediation of my ESXi host. It worked flawlessly again. This is just one of many many KB’s I walked through that contain error messages in regards to the phrase : “The host returns esxupdate error code:15”. So this might not be the fix for your ESXi host, it was however the fix for mine!

There you have it! One of many quick fixes to get you back to patching your hosts.


  1. Similar problem here on some hosts that were upgraded 5.5–>6.5.
    I’ve tried both the dosfsck steps you described and rebuilding and repopulating the /store symlink (kb 60372) without any luck.
    I resolved to backup the configuration reinstall from scratch the host.

Leave a Reply

Your email address will not be published. Required fields are marked *