# Bootstrap.conf for beginners?

**URL:** <https://discuss.kubernetes.io/t/bootstrap-conf-for-beginners/32577>\
**Category:** General Discussions\
**Created:** [June 17, 2025, 9:58pm UTC](https://discuss.kubernetes.io/t/bootstrap-conf-for-beginners/32577 "2025-06-17T21:58:48Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![3rdapocalypse](https://sea2.discourse-cdn.com/flex016/user_avatar/discuss.kubernetes.io/3rdapocalypse/32/16842_2.png) [@3rdapocalypse](https://discuss.kubernetes.io/u/3rdapocalypse)\
**Post date:** [June 17, 2025, 9:58pm UTC](https://discuss.kubernetes.io/t/bootstrap-conf-for-beginners/32577/1 "2025-06-17T21:58:49Z")

</div>

when i try to start kubelet, it isn’t able to find a bootstrap.conf file. from my understanding it seems that the bootstrap file is created when you run kubeadm init or join, but then the kubeadm process stops because it can’t _find_ a health kubelet. i’ve seen a few different answers-- do i just have to run kubeadm init, stop it when it tries to start the kubelet, and run it again? that doesn’t seem correct. another theory is that in the process of troubleshooting i fix a _different_ problem (probably failswap) that isn’t as obvious, but that seems unlikely since bootstrap is what shows up in the fail logs. any sort of pointers help; even just suggestions on where to look or basic explanations of bootstrap/kubelet/kubeadm in this context. thanks.

### Cluster information:

kubernetes version (1.33) on ubuntu 24.04. installed via command line (apt), using containerd as a runtime.

---

<div class="post-metadata">

**Author:** ![brandon](https://sea2.discourse-cdn.com/flex016/user_avatar/discuss.kubernetes.io/brandon/32/17364_2.png) [@brandon](https://discuss.kubernetes.io/u/brandon)\
**Post date:** [June 19, 2025, 5:59pm UTC](https://discuss.kubernetes.io/t/bootstrap-conf-for-beginners/32577/2 "2025-06-19T17:59:38Z")

</div>

> [@3rdapocalypse](#):
>
> other theory is that in the proc

Hi @3rdapocalypse

I think the process didn’t stop because of a missing “healthy kubelet,” but rather because the kubelet couldn’t start (for reasons such as swap settings, cgroup configuration, permissions, CRI, etc.).

Here are some commands that can help you:

1. View the kubelet logs  
`journalctl -u kubelet -f`

2. Run kubeadm’s preflight checks  
`kubeadm init --dry-run`

3. Temporarily disable kubelet before running kubeadm init

```auto
systemctl stop kubelet
systemctl disable kubelet
kubeadm init …
systemctl enable kubelet
systemctl start kubelet

```

Hope you fix this soon.

---

<div class="post-metadata">

**Author:** ![3rdapocalypse](https://sea2.discourse-cdn.com/flex016/user_avatar/discuss.kubernetes.io/3rdapocalypse/32/16842_2.png) [@3rdapocalypse](https://discuss.kubernetes.io/u/3rdapocalypse)\
**Post date:** [June 19, 2025, 6:14pm UTC](https://discuss.kubernetes.io/t/bootstrap-conf-for-beginners/32577/3 "2025-06-19T18:14:29Z")

</div>

yes, the kubelet can’t start because of the missing bootstrap.conf file, which is where my issue is. systemctl status kubelet and journalctl -xeu kubelet both show an issue with the bootstrap file. i do not know where in the process that file should be generated.