// Module included in the following assemblies:
//
// * support/troubleshooting/troubleshooting-installations.adoc

:_mod-docs-content-type: PROCEDURE
[id="gathering-bootstrap-diagnostic-data_{context}"]
= Gathering bootstrap node diagnostic data

When experiencing bootstrap-related issues, you can gather `bootkube.service` `journald` unit logs and container logs from the bootstrap node.

.Prerequisites

* You have SSH access to your bootstrap node.
* You have the fully qualified domain name of the bootstrap node.
* If you are hosting Ignition configuration files by using an HTTP server, you must have the HTTP server's fully qualified domain name and the port number. You must also have SSH access to the HTTP host.

.Procedure

. If you have access to the bootstrap node's console, monitor the console until the node reaches the login prompt.

. Verify the Ignition file configuration.
+
* If you are hosting Ignition configuration files by using an HTTP server.
+
.. Verify the bootstrap node Ignition file URL. Replace `<http_server_fqdn>` with HTTP server's fully qualified domain name:
+
[source,terminal]
----
$ curl -I http://<http_server_fqdn>:<port>/bootstrap.ign  <1>
----
<1> The `-I` option returns the header only. If the Ignition file is available on the specified URL, the command returns `200 OK` status. If it is not available, the command returns `404 file not found`.
+
.. To verify that the Ignition file was received by the bootstrap node, query the HTTP server logs on the serving host. For example, if you are using an Apache web server to serve Ignition files, enter the following command:
+
[source,terminal]
----
$ grep -is 'bootstrap.ign' /var/log/httpd/access_log
----
+
If the bootstrap Ignition file is received, the associated `HTTP GET` log message will include a `200 OK` success status, indicating that the request succeeded.
+
.. If the Ignition file was not received, check that the Ignition files exist and that they have the appropriate file and web server permissions on the serving host directly.
+
* If you are using a cloud provider mechanism to inject Ignition configuration files into hosts as part of their initial deployment.
+
.. Review the bootstrap node's console to determine if the mechanism is injecting the bootstrap node Ignition file correctly.

. Verify the availability of the bootstrap node's assigned storage device.

. Verify that the bootstrap node has been assigned an IP address from the DHCP server.

. Collect `bootkube.service` journald unit logs from the bootstrap node. Replace `<bootstrap_fqdn>` with the bootstrap node's fully qualified domain name:
+
[source,terminal]
----
$ ssh core@<bootstrap_fqdn> journalctl -b -f -u bootkube.service
----
+
[NOTE]
====
The `bootkube.service` log on the bootstrap node outputs etcd `connection refused` errors, indicating that the bootstrap server is unable to connect to etcd on control plane nodes. After etcd has started on each control plane node and the nodes have joined the cluster, the errors should stop.
====
+
. Collect logs from the bootstrap node containers.
.. Collect the logs using `podman` on the bootstrap node. Replace `<bootstrap_fqdn>` with the bootstrap node's fully qualified domain name:
+
[source,terminal]
----
$ ssh core@<bootstrap_fqdn> 'for pod in $(sudo podman ps -a -q); do sudo podman logs $pod; done'
----

. If the bootstrap process fails, verify the following.
+
* You can resolve `api.<cluster_name>.<base_domain>` from the installation host.
* The load balancer proxies port 6443 connections to bootstrap and control plane nodes. Ensure that the proxy configuration meets {product-title} installation requirements.
