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.

Host cannot download files from VMware vSphere Update Manager patch store.  Check the network connectivity and firewall setup, and check esxupdate logs for details.
The host returns esxupdate error codes: 30. Check the Update Manager log files and esxupdate log files for more details.
Could not install image profile: ('', 'There was an error checking file system on altbootbank, please see log for detail.
The host returns esxupdate error code:15. The package manager transaction is not successful. Check the Update Manager log files and esxupdate log files for more details.

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:

[root@esx21:~] vmkfstools -P /altbootbank
vfat-0.04 (Raw Major Version: 0) file system spanning 1 partitions.
File system label (if any):
Mode: private
Capacity 261853184 (63929 file blocks * 4096), 102514688 (25028 blocks) avail, max supported file size 0
UUID: 86cddeee-3a88be39-39f6-60990aa2d308
Partitions spanned (on "disks"):
Is Native Snapshot Capable: NO

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):

[root@esx21:~] dosfsck -a -w /dev/disks/eui.00a0504658335330:5
dosfsck 2.11, 12 Mar 2005, FAT32, LFN
/dev/disks/eui.00a0504658335330:5: 148 files, 38901/63929 clusters

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.

Bryan van Eeden

Bryan is an ambitious and seasoned IT professional with almost a decade of experience in designing, building and operating complex (virtual) IT environments. In his current role he tackles customers, complex issues and design questions on a daily basis. Bryan holds several certifications such as VCIX-DCV, VCAP-DCA, VCAP-DCD, V(T)SP and vSAN and vCloud Specialist badges.


Emanuele Roserba · October 4, 2019 at 10:45 am

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.

    Bryan van Eeden · October 4, 2019 at 12:41 pm

    Hi Emanuele,

    Great that you got it fixed in the end! Rebuilding an ESXi host is the last resort for me usually, but ultimately it fixes most issues.

ashokan · August 19, 2020 at 7:20 pm

nice one really

Ramesh · February 25, 2022 at 12:08 am

This worked for me!

Leave a Reply

Avatar placeholder

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