ESXi 6.0 reports “error code: 15” during Remediate update in VUM operation

//ESXi 6.0 reports “error code: 15” during Remediate update in VUM operation

ESXi 6.0 reports “error code: 15” during Remediate update in VUM operation

Another vCenter another ESXi with problems applying last updates.

In this case is a HP DL360 G9 with ESXi 6.0 build 3568940.

Using VMware Update Manager to scan it shows 17 updates to install, stage is 7(the rest are older versions), when remediate the host we get this:

Remediate entity esxi721.localdomain. 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.

Again in issue lot of troubleshooting to check were was the problem here.

Looking at the esxupdate.log there is some information about the locker folder:

2016-04-24T15:11:44Z esxupdate: downloader: DEBUG: Downloading from http://esxi721.localdomain:9084/vum/repository/hostupdate/vmw/vib20/tools-light/VMware_locker_tools-light_6.0.0-2.34.3620759.vib…
2016-04-24T15:12:48Z esxupdate: LockerInstaller: WARNING: There was an error in cleaning up product locker:

[Errno 2] No such file or directory: ‘/locker/packages/var/db/locker’
2016-04-24T15:12:48Z esxupdate: esxupdate: ERROR: An esxupdate error exception was caught:

So need to investigate in the ESXi host. In VMware KB about this ‘error 15’ it says to double check the folder/link Locker > Store

I double check the link to see if the link exists and also the folder, and all is ok. Next check locker folder/link and if locker link is valid

Check if store location is correct

All is ok, so need to check locker/packages folder to see if Version(in this case folder 6.0.0) exists.

The folder doesn’t exist, and there is no floppies, vmtools folders that have all the files that ESXi and VUM needs for the updates. In the VMware KB recommends to delete old folder and links and recreate, in this case we don’t need to delete nothing, but to recreate and copy the necessary files(we will use another ESXi host with the same build).

Connecting to another host we will use SCP to copy all files to this ESXi host.

First if  you don’t have your SSH Client enable in the host firewall, you need to enabled to do the next task using SCP command.

To enable SSH Client in the source ESXi host:

Note: Don’t forget to disable SSH Client after do this tasks.

After you run SCP command you will be prompted for the root password of the remote host and once you have successfully authenticated the files will copy.

Only when trying to copy the files we find the real issue. Did not find anything in the logs related to this. Space issue to apply the updates.

So need to double check the root space.

Here I don’t see any issues with the space, but see big files from the Tardisk

Checking filesystems I see that the one is use for Locker is 100% full.

So next step is to find big files logs, and also inside /tmp if there is any dump files, or other big files that are contributing to this issue.

As we can see there is some big temp files in the list, so the next step is to delete some.

Note: Double check which files do you want to delete. Don’t delete any log files that you could need for any troubleshooting or audit.

After deleting the files that we will not need(and also deleted the files that we copy from the previous ESXi host), and also all folders inside Locker/Store folder, we can check the space.

We now have space around 0% and lot of free space.

Well copy the files again from the other ESXi host and finish 100%.

Now using VUM we will scan, stage and remediate the ESXi host and the problem is fix. After a final reboot(from remediate) the ESXi is fully updated.

Hope this can help.

Note: Share this article, if you think is worth sharing.

Share this:

Like this:

Like Loading...
By | 2017-12-30T02:50:08+02:00 April 25th, 2016|Virtualization|13 Comments

About the Author:

I am over 20 years’ experience in the IT industry. Working with Virtualization for more than 10 years (mainly VMware). I am an MCP, VCP6.5-DCV, VMware vSAN Specialist, Veeam Vanguard 2018/2019, vExpert vSAN 2018/2019 and vExpert for the last 4 years. Specialties are Virtualization, Storage, and Virtual Backups. I am working for Elits a Swedish consulting company and allocated to a Swedish multinational networking and telecommunications company as a Teach Lead and acting as a Senior ICT Infrastructure Engineer. I am a blogger and owner of the blog ProVirtualzone.com

13 Comments

  1. Wilbert November 7, 2016 at 9:40 pm - Reply

    Same issue here, HP Blade g9 environment with HP custom VMware image, version ESXi 6.0 build 3568940. Only 1 host had the issue. After recreating the symbolic link, copying the /locker/packages/ folder from a healthy host did the trick.
    Thanks for writing this up mate!

    • Luciano Patrao November 9, 2016 at 9:09 am - Reply

      Hi Wilbert,

      Thanks. Glade that I could help.

      PS: Share if you think can help others.

      Thank You

      Luciano Patrao

    • Luciano Patrao June 11, 2017 at 6:46 pm - Reply

      Hi Wilbert,

      Only today I notice that my reply is not sending emails to users that comment on my blog. So now I am just FYI to you regarding my comment.

      Thank You

      Luciano Patrao

  2. Bob January 6, 2017 at 2:25 pm - Reply

    I have the same exact problem on a Dell Server … BUT in my case the /locker/packages is only 29% used when running the df -h command.

    When I run find / -path “/vmfs” -prune -o -type f -size +50000k -exec ls -l ‘{}’ \; I don’t see anything that makes sense to delete. I do see /tardisks/sb.v00 AND /tardisks/s.v00 BUT I get busy message when attempt to delete. Any ideas? Thank you in advace.

    • Luciano Patrao January 13, 2017 at 12:59 am - Reply

      Hi bob,

      What information you get in your esxupdate.log?

      That is important.

      But you can delete all information that you have in the /locker/packages and then copy from a working ESXi host. Don’t forget that needs to be same ESXi version.

    • Joe Schmo January 24, 2017 at 9:50 pm - Reply

      I had this problem too (about 30% used), there was a dump file sitting in /var/core that needed to be deleted.

    • Luciano Patrao June 11, 2017 at 6:44 pm - Reply

      Hi Bob,

      Only today I notice that my reply is not sending emails to users that comment on my blog. So now I am just FYI to you regarding my comment.

      Thank You

      Luciano Patrao

  3. Cristiano March 15, 2017 at 10:35 pm - Reply

    Hi, tank you for the help!

    • Luciano Patrao March 16, 2017 at 2:27 pm - Reply

      Hi Cristiano,

      No problem, glad to help.

    • Luciano Patrao June 11, 2017 at 6:43 pm - Reply

      Hi Cristiano,

      Only today I notice that my reply is not sending emails to users that comment on my blog. So now I am just FYI to you regarding my comment.

      Thank You

      Luciano Patrao

  4. Ben March 21, 2017 at 4:43 pm - Reply

    Hello, thank you for the help, the VMWare KB isn’t revelant about space issue. Same as Joe, I had do delete a dump file in /var/core to do the trick.

    • Luciano Patrao March 22, 2017 at 12:31 am - Reply

      Hi Ben,

      Glad to help.

    • Luciano Patrao June 11, 2017 at 6:42 pm - Reply

      Hi Ben,

      Only today I notice that my reply is not sending emails to users that comment on my blog. So now I am just FYI to you regarding my comment.

      Thank You

      Luciano Patrao

Leave a Reply

%d bloggers like this: