3

I've got a standalone ESXi server and I'm having problems with it losing config on reboot. I restored the config from a previous install and it reverts to that every time it's restarted.

My current hypothesis is that although the state is correctly being backed up to /bootbank/local.tgz on the hour (it's a USB installation and if I understand autobackup.sh correctly, that's expected behaviour), the boot process is reading from /bootbank/state.tgz.

I think this because of the contents of /bootbank/boot.cfg (specifically the modules line) and because the restored config was from a disk installation, rather than USB:

~ # cat /bootbank/boot.cfg
kernel=b.z
kernelopt=
modules=k.z --- s.z --- c.z --- oem.tgz --- license.tgz --- m.z --- state.tgz
build=4.1.0-381591
updated=2
bootstate=0

Should I swap in local.tgz for state.tgz here (bearing in mind one is an archive and one is an archive of an archive and so need to be treated differently), or is this entry a result of a setting elsewhere I should be targeting instead?

Alternatively, should I just delete this entry from the modules line (to have it go to local.tgz by default because of the USB boot status)? Do I need to adjust /altbootbank/boot.cfg too? I ask these two questions because neither state file is included in the modules line in this file.

Normally, I'd just experiment, but I'm wary of tampering with the boot process in case it stops booting!

The system is a recently patched 4.1 (free version - it's not a production system) on more or less HCL hardware, using DAS for the datastore and a 2GB USB stick for the hypervisor install.

Edit

I've looked through /sbin/backup.sh (which is called from autobackup.sh) and this actually adds --- state.tgz to the modules line in boot.cfg if a) it's not a USB boot and b) it's not already there. This strongly suggests to me that (in my USB boot environment) it's there erroneously and I should just delete it... but I'd still love some confirmation of that from someone more knowledgeable.

Can anyone tell me (or even speculate on) why "embedded" / USB booting systems use local.tgz and "installed" systems use state.tgz (which, AIUI, just contains local.tgz)? Could it be something to do with multiple configs for clusters?

1 Answer 1

1

In the absence of suggestions either way, I bit the bullet and removed the --- state.tgz parameter from the modules line in /bootbank/boot.cfg and, judging by a couple of test restarts, config changes are persisting between boots now. I read post #44 in this thread, which suggested it was a valid thing to do. It seems local.tgz is read on boot now instead of the stale state.tgz, as I was hoping.

I still don't know what the reason for this entry appearing in the modules line was, so I'll be keeping an eye out for it returning. As an entirely new boot image is written to /altbootbank/ whenever updates are applied, I'll be checking the newly created boot.cfg to make sure it hasn't crept back in when I next patch the server.

2
  • My state.tgz file was corrupt and could not be untarred. Removing the ` --- state.tgz` parameter allowed my VMware ESXi 7 host to boot. I had to reconfigure the host's password and network settings, and re-register the VMs. Also had to delete one .lck file on a particular VM via Datastore Browser so that VM could power on. Ran /sbin/auto-backup.sh on the host command line, which added the state.tgz parameter back in to boot.cfg. I lost my VMware license activation (will reapply license key soon). Anyway, my host is back up-and-running and my VMs are there. Thanks for this answer.
    – MikeOnline
    Jan 25, 2021 at 21:11
  • Sorry to hear about your troubles, but I'm glad my experience was able to help get your system up and running again. Amazing it's still relevant 10 years on! Perhaps in another decade this class of problem will have been addressed..?! Feb 12, 2021 at 20:58

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .