A server that will not provision
A machine that never becomes a node is stuck for one of these reasons: the server will not boot Hetzner's rescue system, a disk fails the install check, or there is no cloud capacity in your region.
Work through them in that order. Start by reading the machine object.
Read the machine object first#
The provider machine object holds the real step and the real error. You do not need to hunt through logs. Describe the object for your machine:
$ kubectl describe hetznerbaremetalmachine <name> # bare metal
$ kubectl describe hcloudmachine <name> # cloud
The Status and the events show which phase stalled and why.
Note
If the machine already reached Running and the node itself will not go Ready, that is a different problem. See Debug a node .
Bare metal boots from disk instead of rescue#
Syself Autopilot installs the OS by booting the server into Hetzner's rescue system over the network, a small Linux that Hetzner serves for maintenance. The server reboots into rescue, gets inventoried, and reinstalls.
If a HetznerBareMetalHost stays in preparing or registering for more than 30 minutes, the server never entered the rescue system, and without rescue there is no install. The usual cause is the BIOS boot order. It puts the local disk first, so the server boots its old install instead of rescue, and provisioning never starts.
The reliable fix is to make network boot permanent. Ask Hetzner support to set it, with this text:
Please enable the network boot option for this machine permanently, because this
machine will be provisioned automatically. Please ensure that the boot order does
not get lost. The machine needs to boot from the network constantly.
Order a Remote Console from Hetzner and set the network card above the disks in the BIOS.
Tip
Common keys to enter the BIOS: ASUS DEL/F2, MSI/Gigabyte DEL, Dell/Acer F2, HP F10/ESC. Press the key repeatedly while the machine reboots. Trigger the reboot from the Robot web UI.
A foreign OS or RAID blocks the install#
If the server boots rescue but the install fails, the target disk probably still holds data the installer will not write over: RAID, an LVM volume, or another Linux install on any disk in the server. The machine object's status names the disk it stopped on.
The provisioner does not wipe the disk for you. Clear the RAID or foreign OS yourself in the Hetzner rescue system, then let the server reprovision: see Wipe a disk .
Warning
Wiping a disk destroys all data on it, permanently. Make sure it is the right server before you continue.
After a wipe, the failed attempt does not always retry on its own. Delete the machine object, and Syself recreates it with a fresh attempt:
$ kubectl delete hetznerbaremetalmachine <name> -n <namespace>
If the same error comes back, a disk was missed. Wipe every disk in the server, not only the one you are installing onto.
Before it writes anything, the installer also checks that the target disk exists, is large enough, and is fast enough to run a node. A failure here shows a different message in the machine object's events than the foreign-OS check above.
No cloud capacity available#
On Hetzner Cloud, a server type can sell out in a location, or a location can be closed to new servers. The HCloudMachine status shows:
server location disabled (resource_unavailable, *)
This blocks new provisioning, so upgrades and self-healing can stall too: no replacement server can come up for an old or failed node. You have three options:
- Wait for capacity to return.
- Choose a different server type or region.
- Move the workload to bare metal . Bare-metal servers are pre-registered by you and always available, so cloud capacity limits do not affect them.
See Bare metal and cloud for the trade-offs, or bare-metal Kubernetes for the cost and ownership case.
When to grant Syself access#
Sometimes the machine object shows the provision reached the hardware but stalled there: a disk that will not wipe, a server that will not POST (the power-on hardware check), firmware trouble. The next step is on the physical machine itself. The server sits in your own Hetzner account, so you can work it, order a KVM console, or open a hardware ticket with Hetzner. When you would rather Syself handle it, grant Syself bare-metal access so support can work it directly.
Important
Before you open the ticket, read what to collect first , then Grant Syself bare-metal access .
If none of the causes above match what you see, start from Where to start troubleshooting .