# Elasticsearch on Kubernetes - cluster red, one node cannot start

**URL:** https://discuss.elastic.co/t/elasticsearch-on-kubernetes-cluster-red-one-node-cannot-start/212738
**Category:** Elasticsearch
**Created:** [December 21, 2019, 2:03pm UTC](https://discuss.elastic.co/t/elasticsearch-on-kubernetes-cluster-red-one-node-cannot-start/212738 "2019-12-21T14:03:05Z")
**Posts on this page:** 1
**Showing post:** 2

<div class="post-metadata">

### Author: ![DavidTurner](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/davidturner/32/22453_2.png) [@DavidTurner](https://discuss.elastic.co/u/DavidTurner)
#### Post date: [December 22, 2019, 9:55am UTC](https://discuss.elastic.co/t/elasticsearch-on-kubernetes-cluster-red-one-node-cannot-start/212738/2 "2019-12-22T09:55:18Z")

</div>

The lack of line breaks make this pretty hard to read, but this is the fundamental problem:

`org.apache.lucene.index.CorruptIndexException: codec footer mismatch (file truncated?): actual footer=-470888448 vs expected footer=-1071082520 (resource=BufferedChecksumIndexInput(SimpleFSIndexInput(path="/usr/share/elasticsearch/data/nodes/0/_state/global-80.st")))`

The metadata on disk is corrupt, or at least it is different from the metadata that Elasticsearch wrote. This indicates something wrong with your storage or filesystem. Elasticsearch presents a workload to the underlying disks that's quite good at exposing bugs (e.g. [in the kernel](https://bugs.launchpad.net/ubuntu/+source/linux-azure/+bug/1848739/comments/9) or [in the filesystem](https://discuss.elastic.co/t/underlying-file-changed-by-an-external-force/137555/4)) as well as faulty hardware.

After addressing that, I think it's best to start this node afresh by wiping the data directory and restore any red indices from a recent snapshot.

---

_[View the full topic](https://discuss.elastic.co/t/elasticsearch-on-kubernetes-cluster-red-one-node-cannot-start/212738)._