VMware Cloud Community
ryusoma
Contributor
Contributor

ESXi 5.1U1 upgrade failure - OSError: [Errno 39] Directory not empty

Hello all-

just attempted to update my ESXi server from 5.1 799733 to 5.1U1 1065491.  During the upgrade the process hangs at 24% completion with the error message as above:

OSError: [Errno 39] Directory not empty: '/vmfs/volumes/3934f7e6-f070467f-afd0-f0ef312248d9/state.7173326'


I have retried a second time with the same result.  Is there any workaround?  Or can I perform a clean install and just import the VMs from the datastores without any problems?

26 Replies
Smurfic
Contributor
Contributor

MrTScottMrTScotts workaround fixed the problem for me I had exactly the same issue

many thanks /Tom

0 Kudos
aquarios
Contributor
Contributor

Copying the contents of bootbank to altbootbank via WinSCP totally helped and I managed to get passed 24% barrier when the upgrade from ESXi 5.5 to ESXi 6.0 failed. Thanks a lot!

0 Kudos
PaulWestNet
Enthusiast
Enthusiast

I just had this same issue while upgrading from ESXi 6.0 to ESXi 6.5, except it complained about files in /vmfs/volumes/<volumeid>/state.<stateid> instead of /bootbank/state.<stateid> (your volumeid and stateid will be different on every host), but /altbootbank ends up in the same place anyway when you cd into it.

Cleaning up the directory was as easy as typing "cd /vmfs/volumes/<volumeid>/state.<stateid>" followed by "mv * ../".

I then ran into the no upgrade option, like others, and the copying of /bootbank to /altbootbank solved the problem. The command to do so is "cp /bootbank/* /altbootbank", in case anyone has trouble getting that step done.

So, just to confirm, this is all still relevant with the most current release.

Thanks for everyone's posts. If not for this, I'd be re-configuring all my vSwitches and stuff again from scratch - and that would have been rather unpleasant *grin*.

affinityidnz
Contributor
Contributor

Thanks to all that posted in here.

I was booting directly from an HP Custom Image for esx 6.5 for a HP Proliant DL360 Gen 9

I was upgrading from 5.5

Originally I had the error "Errno39 directory not empty" pointing to a VMFS Directory which ended up being /altbootbank

After this came up I tried the upgrade again but the upgrade option was no longer there.

I booted back into 5.5, removed the file and tried the upgrade using Update Manager this time.

On that attempt I got "UnicoDecodeError: ‘utf-8’ codec can’t decode byte 0x8b in position 513: invalid start byte"

So I booted back into 5.5, cleared the /altbootbank directory and then copied all files from /bootbank to /altbootbank

Booted from CD, upgrade option was available and upgrade sucdeeded.

THANKS TO EVERYONE FOR TAKING THE TIME TO  POST IN HERE!

Solved my problem.

0 Kudos
LKaderavek
Contributor
Contributor

Thanks a lot for your posts!

I've managed to upgrade from 6.0.0 U3 to 6.5.0 U2 with hp custom image - wyping and copying altbootbank / bootbank directories was necessary!

Saved my day!

>>> We had one issue left - after upgrade the VMs won't start - if you had unlocker (for MacOS VMs) installed you need to uninstall the old version, before installing the new version.

> Best would be to uninstall the old version before upgrading...because maybe you won't have access to the old installed version anymore...

0 Kudos
jekyll530
Contributor
Contributor

This very issue still exist on ESXi 6.5u2, and the work-around above is not applicable to ESXi 6.5 since there is no /altbootbank directory in 6.5. Anybody has a solution?

0 Kudos
Koby3663
Contributor
Contributor

Thanks MrTScott!  I tried several times and it kept failing on a different state.XXXXX folders AND Volumes.

 

I ended up using WinSCP to just copy ALL the state.XXXXX files to my local drive, and just deleted the local.tgz files from them manually.

Upgrade worked!

Although because i tried so many times and copied the /bootbank to /altbootbank repeatedly, it lost my recently upgraded vCenter Server 6.7.  Also it took the Host out of maintenance mode...  Although luckily when i logged into my VM's none of them were complaining about a non-graceful shutdown.

I did have to re-register my Vcenter 6.7 VM from the datastore, and had to re-connect it to my vCenter 6.7.  Little sketchy but everything APPEARS to be running well!

0 Kudos