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. 1 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. 1 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. 1 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. 1 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:

vdf -h (check if ramdisk is full). df -h (check if there are full partitions). Check /var/log/esxupdate for any entries that make some sense. Check the /var/log/vmkernel.log and /var/log/hostd.log for entries that make some sense. Check the /locker partition. If that’s empty or full of logfiles that’s usually not good (see KB2030665 or KB60372) Use df /locker for example. Use du -sh /locker/* to check on file sizes. Check Update Manager settings and health (in the vCenter) to verifiy Update Manager isn’t broken. 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"): eui.00a0504658335330:5 Is Native Snapshot Capable: NO 1 2 3 4 5 6 7 8 9 [ 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" ) : eui . 00a0504658335330 : 5 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 1 2 3 [ 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.