When a node will not boot, you cannot reach it with `kubectl` or SSH. The serial console shows the node's boot output, including the kernel messages that never reach a log file. The Hetzner rescue system gives you a shell on the server to collect logs and, if needed, reprovision it. ## Read the boot on the serial console The serial console shows what happens before systemd (the Linux init system) starts: kernel panics and [dm-verity](/docs/hetzner/apalla/concepts/internals/syself-linux) errors that never reach a log file. A failing sealed boot looks like a verity error followed by an unreadable root: ```text device-mapper: verity: 8:2: data block 0 is corrupted EXT4-fs (dm-0): unable to read superblock ``` That is an integrity failure of the OS image. The node cannot repair it, so it must be reprovisioned. For other symptoms and their exact fix, see [Debug a node](/docs/hetzner/apalla/servers-and-nodes/access/debug-a-node). ## Activate the rescue system and collect logs The Hetzner rescue system is a small Debian environment that boots entirely in RAM. It is the same environment Syself uses to install a node the first time. To get a shell on a bare-metal server that will not boot normally: Enable rescue In the [Hetzner Robot console](https://robot.hetzner.com/), select the server, open the **Rescue** tab, choose your SSH key and keyboard layout, and activate the rescue system. Reset into rescue On the **Reset** tab, send a **CTRL+ALT+DEL** reset. The server reboots into the rescue system after a few minutes. Mount the disk and collect logs SSH into the rescue system with the key you selected, then mount the node's disk. Read `/var/log/syself-activate.log` with `cat` directly: it holds the full node activation output. `journalctl -u syself-activate` shows only the systemd lifecycle lines, not the actual output, so it is not enough on its own. > [!CAUTION] > Collect what you need for the ticket before you reprovision. Reprovisioning overwrites the root disk. ## Fixing the OS means reprovisioning The fix for a broken sealed OS is to **reprovision** the node, which reinstalls a fresh, verified image. Data on the extra disks survives; the root disk is rewritten. ## IPMI and KVM caveats Out-of-band management is not universal on Hetzner dedicated servers. Since 2019, most models no longer ship IPMI/KVM modules (IPMI: a standard for remote server management). Only Dell models and Server Auction servers have out-of-band management. Where it is not available, the serial console plus the rescue system are your tools. Even on a server without a built-in module, you can order a **KVM console** from Hetzner. They attach a remote console on request, free for up to three hours, which is enough to watch a boot or change a BIOS setting. Request it from Robot; see [Hetzner's KVM console docs](https://docs.hetzner.com/robot/dedicated-server/maintenance/kvm-console/). Where a server does have a BMC (Baseboard Management Controller, the chip behind IPMI/KVM), reach it through the IPMI web interface, or with the vendor tool that Hetzner documents. See [Hetzner's IPMI docs](https://docs.hetzner.com/robot/dedicated-server/maintenance/ipmi/) for the steps. A server that will not even reach rescue is a case to [get provisioning unstuck](/docs/hetzner/apalla/servers-and-nodes/access/server-not-provisioning) or [grant Syself bare-metal access](/docs/hetzner/apalla/support/grant-syself-baremetal-access). If the disk still fails the install check after reprovisioning, wipe it by hand from the rescue system: see [Wipe a disk before provisioning](/docs/hetzner/apalla/servers-and-nodes/maintenance/wipe-a-disk). ## Related - [Debug a node](/docs/hetzner/apalla/servers-and-nodes/access/debug-a-node) - [A server that will not provision](/docs/hetzner/apalla/servers-and-nodes/access/server-not-provisioning) - [Wipe a disk before provisioning](/docs/hetzner/apalla/servers-and-nodes/maintenance/wipe-a-disk)