> ## Content Index > Fetch the complete content index at: https://prod-0-dol-blog-zrh1.dol.ch/llms.txt > Use this file to discover other available public pages before exploring further. # Ein Hetzner-Snapshot startet nicht auf neuer UEFI-only-Hardware: die Lösung - URL: https://prod-0-dol-blog-zrh1.dol.ch/blog/hetzner-snapshot-startet-nicht-uefi-fix/ - Published: 2026-09-12T13:36:50.000Z - Updated: 2026-09-12T13:56:28.000Z - Description: Eine Website, die mein Vater und ich zusammen gebaut haben, fast zwanzig Jahre alt, lag in einem Snapshot, der plötzlich nicht mehr starten wollte, und sie zurückzuholen kostete einen Abend in einer Partitionstabelle, den ich nicht eingeplant hatte. - Author: dima - Tags: de, Hetzner, UEFI, CentOS, Linux, Sysadmin Bevor es ein Hosting-Geschäft gab, gab es einen Counter-Strike: Source-Server, den mein Vater und ich zusammen betrieben haben, aus einer Zeit, in der das in der Ukraine noch etwas bedeutet hat. Wir hatten eine Zeit lang einen der bekanntesten im Land, und ich habe als Teenager meine Abende damit verbracht, eigene Mods dafür zu coden, statt Hausaufgaben zu machen. Die Domain aus diesem Projekt, uasource.com, lebt immer noch. Sie ist inzwischen fast zwanzig Jahre alt. Das Hosting-Geschäft kam später und unabhängig davon dazu, die Erfahrung mit Hardware und Netzwerk aus dem Betrieb dieser Gameserver hat es mir nur leichter gemacht, dafür meinen ersten eigenen dedizierten Server zu mieten. Ich habe dieses Geschäft jahrelang neben der Festanstellung weitergeführt, 2026 geschlossen und die letzte Handvoll zahlender Kunden zu Infomaniak migriert. uasource.com ist im Geiste mitgekommen, auch wenn es dabei fast schiefgegangen wäre. Ich habe einen Snapshot des alten Hetzner-Servers gezogen, den Server selbst gelöscht, und irgendwann später aus genau diesem Snapshot eine neue Instanz gestartet, um die Seite runterzuholen. Sie kam nicht hoch. ![](https://dol-blog-prod.s3.eu-west-lz-zrh-a.cloud.ovh.net/content/images/2026/09/uefi-shell-stuck-boot.png) Was mich über VNC tatsächlich erwartet hat: eine UEFI-Shell statt eines Logins. **Wenn dein Server gerade nicht startet und du über die Fehlermeldung hier gelandet bist:** spring direkt zu [dem Fix](#schritt-fuer-schritt). Neuere Hetzner-Server-Generationen booten nur noch über UEFI, ohne Legacy-BIOS-Fallback, und ein Snapshot von älterer Hardware bringt keine EFI-Partition mit, das ist die Kurzfassung von alledem. Der Support kann eine bestehende Instanz manchmal auf Anfrage zurück auf Legacy-Boot stellen, es lohnt sich also, [erst ein Ticket zu schreiben und nachzufragen](#warum-er-nicht-startete), bevor du an der Partitionstabelle rumschneidest. Wenn das nicht klappt, funktioniert der Weg unten, bei mir dauerte er etwa eine Stunde, sobald ich aufgehört hatte, gegen tote Paketquellen anzukämpfen. ## Womit ich es zu tun hatte Das Setup, für alle, die ihre eigene Situation damit abgleichen wollen: | Komponente | Version / Detail | Anmerkung | | ----------------------------- | ------------------------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------- | | Ursprünglicher Server | Hetzner Cloud, Cost-Optimized-Stufe (CX-Linie) | In der Konsole mit "Limited availability" markiert, ältere Hardware, MBR-Platte, BIOS/CSM-Boot | | Ersatzserver | CPX32, Regular-Performance-Stufe | 4 vCPUs, 8 GB RAM, 160 GB SSD, neuere Hardware-Generation, nur UEFI, kein CSM | | Betriebssystem auf der Platte | CentOS 7.9 ("Boris Yegorov") mit CloudLinux 7.9 | CentOS 7 hat am 30\. Juni 2024 sein End of Life erreicht, Mirrors sind weg | | Rescue-Umgebung | Hetzner Rescue System, basiert auf Debian 12 (bookworm), eigener Kernel | Auf der neuen Instanz über EFI gebootet | | Partitionierung vorher | 152.59 GiB, dos-Disklabel, eine Partition (sda1, ext4) | Nirgendwo eine EFI System Partition | | Partitionierung nachher | sda1 verkleinert auf 151.4 GiB (ext4), sda2 neu angelegt mit 1.1 GiB (Typ ef, FAT32) | Bleibt eine MBR-Platte, nur mit zusätzlicher ESP, keine GPT-Konvertierung nötig | | Verwendete Tools | e2fsck/resize2fs 1.47.0, fdisk (util-linux 2.38.1), grub2-efi-x64 1:2.02-0.87.0.2.el7.centos.14, shim-x64 15-8.el7 | GRUB und shim aus CentOS' archivierten Vault-Mirrors, nicht aus den toten Live-Mirrors | ## Warum er nicht startete Neue Server-Modelle von Hetzner werden standardmässig mit UEFI ausgeliefert und haben laut Hetzners eigener Dokumentation "no longer Legacy/BIOS support (CSM)". Mein Snapshot stammte von einer älteren Generation, MBR-Partitionstabelle, keine EFI System Partition. Das funktioniert, bis sich die Hardware darunter ändert, und genau das war bei mir passiert. Andere sind auf den neueren CX-, CPX- und CCX-Linien von Hetzner Cloud auf exakt dieselbe Wand gelaufen, das ist also keine reine Dokumentations-Fussnote. Einer beschreibt eine VM, die sich zwar installieren liess, aber schlicht nicht hochkam, bis der Support sie von Hand auf Legacy-Boot zurückgestellt hat. Mein Snapshot passte auf einen Servertyp, der mir gerade unter den Händen ausging, und genau das hat mich eigentlich geärgert. Hetzners eigene Konsole markiert die ältere, günstigere Stufe mit "Limited availability" und beschreibt sie als "cost-efficient on older hardware generations, with limited availability". Genau die Grösse, die ich brauchte, zeigte einen Tooltip mit dem Text "Not available. Please choose another location or type". ![](https://dol-blog-prod.s3.eu-west-lz-zrh-a.cloud.ovh.net/content/images/2026/09/hetzner-old-cx-line-unavailable.png) Genau die Grösse, auf der mein alter Server lief, an diesem Standort weg. "Einfach denselben Typ nochmal deployen" gab es also nicht, obwohl ich das ohne Zögern genommen hätte. Was ich stattdessen bestellen musste, war ein CPX32 in der neueren, nicht wählbaren Stufe, vier vCPUs und 8 GB RAM auf "higher CPU performance based on newer hardware generations", Hetzners eigene Beschreibung genau der Hardware, die mit meinem Snapshot nichts anfangen kann. ![](https://dol-blog-prod.s3.eu-west-lz-zrh-a.cloud.ovh.net/content/images/2026/09/hetzner-cpx32-selected.png) Was ich stattdessen bestellen musste, neue Hardware inklusive. Bevor du einen Abend in den Fix unten steckst, lohnt es sich, den Hetzner-Support zu fragen, ob genau diese Instanz auf Legacy-Boot umgestellt werden kann. Andere auf den neueren Cloud-Linien haben genau das per Ticket erreicht. Das kostet ein Ticket, keinen Nachmittag mit `fdisk`, und reicht vielleicht schon. Bei mir war das zu dem Zeitpunkt, als ich das begriffen hatte, keine Option mehr, also bin ich den Weg über die Neupartitionierung gegangen. ## Schritt für Schritt: einen BIOS-only-Snapshot als UEFI zum Laufen bringen ### 1\. Ins Rescue-System booten und erst mal nur schauen ![](https://dol-blog-prod.s3.eu-west-lz-zrh-a.cloud.ovh.net/content/images/2026/09/hetzner-rescue-system-banner.png) Zurück im Rescue-System, diesmal auf der neueren Hardware. `lsblk -f` und `fdisk -l /dev/sda` sind das Erste, was laufen sollte, bevor irgendwas angefasst wird. Ein dos-Disklabel (MBR) mit einer einzigen Linux-Partition und nirgendwo einer Partition vom Typ `ef` ist die Bestätigung, die Platte hatte nie eine EFI System Partition, und kein noch so oftes Neustarten ändert das auf Hardware, die nur UEFI spricht. ### 2\. Das Dateisystem prüfen, bevor irgendwas verkleinert wird Dieser Teil lief für einmal wirklich glatt. ``` e2fsck -f /dev/sda1 ``` ![](https://dol-blog-prod.s3.eu-west-lz-zrh-a.cloud.ovh.net/content/images/2026/09/e2fsck-repair-output.png) Der einzige Teil davon, der wirklich glatt lief. Ein Dutzend verwaister Inodes von einem nicht sauberen Unmount, repariert in wenigen Sekunden. Aus Gewohnheit noch einmal laufen lassen, danach. Sauber, keine Änderungen mehr, also war das Dateisystem selbst nicht das, womit ich es hier zu tun hatte. ### 3\. Das Dateisystem verkleinern, um Platz für die EFI-Partition zu schaffen Eine EFI System Partition muss irgendwo herkommen, und auf einer Platte mit einer einzigen Partition, die sie schon komplett ausfüllt, heisst das, zuerst das Dateisystem zu verkleinern und danach die Partition, in dieser Reihenfolge. Erst prüfen, wie weit es sicher geht, bevor eine Zahl feststeht: ``` resize2fs -P /dev/sda1 # meldet die minimale Grösse, auf die das Dateisystem schrumpfen kann resize2fs /dev/sda1 39700000 # verkleinern, mit Puffer über dem gemeldeten Minimum ``` Echten Puffer über dem Minimum lassen, das `resize2fs -P` meldet. Ich habe auf eine Partition gezielt, die noch komfortabel über 150 GB von den ursprünglichen 152.6 lag, eine EFI System Partition braucht nur ein paar hundert Megabyte bis knapp über ein Gigabyte. ### 4\. Neu partitionieren, vorsichtig, auf der lebenden Platte Das war der Teil, auf den ich mental nicht vorbereitet war, es auf der echten Platte in einer Rescue-Shell zu tun statt irgendwo auf einem Image, in sicherer Distanz. `fdisk /dev/sda`, die bestehende Partition löschen, dann am selben Startsektor mit dem neuen, kleineren Endsektor neu anlegen, und den frei gewordenen Platz am Ende der Platte für eine zweite Partition vom Typ `ef` (EFI System) lassen. **Den Startsektor der bestehenden Partition unbedingt identisch lassen**, und Nein sagen, wenn `fdisk` fragt, ob die erkannte ext4-Signatur gelöscht werden soll, die Daten liegen im Dateisystem, nicht in diesem Eintrag der Partitionstabelle, aber nur, wenn Signatur und Startsektor unangetastet bleiben. Ich habe das beim ersten Versuch nicht richtig hinbekommen. Mein erster Durchgang durch `fdisk` hat die Partition gelöscht, sie mit den Standardwerten wieder in voller Grösse angelegt, und als ich dann vor einer zweiten Partition mit genau einem Sektor stand, habe ich Ja gesagt zum Löschen der ext4-Signatur, bevor ich mich gefangen habe und ohne Speichern rausgegangen bin. Verloren war nichts, weil noch nichts geschrieben worden war, aber es ist genau die Art Fehler, die man lieber bei einem Übungsdurchgang macht als im Ernstfall. Der zweite Versuch, diesmal bewusst, sah so aus: ``` fdisk /dev/sda # d bestehende Partition löschen # n, p, 1, 2048, 317602047 neu anlegen, gleicher Start, kleineres Ende # (bei der Nachfrage zur ext4-Signatur mit N antworten) # n, p, 2, 317602048, 320004062 neue Partition im frei gewordenen Platz # t, 2, ef Typ auf EFI System setzen # w Tabelle schreiben ``` Die neue Partition formatieren und die Tabelle nochmal prüfen, bevor es weitergeht: ``` mkfs.fat -F32 /dev/sda2 ``` ### 5\. Alles mounten und in den chroot ``` mount /dev/sda1 /mnt mkdir -p /mnt/boot/efi mount /dev/sda2 /mnt/boot/efi for d in dev proc sys run; do mount --bind /$d /mnt/$d; done chroot /mnt /bin/bash ``` ### 6\. Die toten CentOS- und CloudLinux-Repositories reparieren Hier ist die eigentliche Zeit draufgegangen. CentOS 7 hat am 30\. Juni 2024 sein End of Life erreicht, und auch CloudLinux' eigene Lizenzserver kennen eine alte Installation nicht mehr. Jedes `yum install` kam mit demselben Rauschen zurück, ein `rhn_check`\-Login-Fehler, ein 404 von `mirror.centos.org`, ein gescheiterter CloudLinux-Registrierungsversuch. Nichts davon liess sich durch Wiederholen beheben, nur dadurch, `yum` auf eine Quelle zu zeigen, die die Pakete noch hat: ``` # der aktive extras-Mirror ist weg, stattdessen auf den CentOS-Vault zeigen sed -i 's|mirror.centos.org|vault.centos.org|' /etc/yum.repos.d/centos-extras.repo # base und updates fehlen komplett auf den aktiven Mirrors, von Hand ergänzen cat > /etc/yum.repos.d/vault-os.repo <<'EOF' [vault-os] name=CentOS-7 - Base (vault) baseurl=http://vault.centos.org/7.9.2009/os/x86_64/ enabled=1 gpgcheck=0 [vault-updates] name=CentOS-7 - Updates (vault) baseurl=http://vault.centos.org/7.9.2009/updates/x86_64/ enabled=1 gpgcheck=0 EOF yum clean all ``` ### 7\. Den UEFI-Boot-Stack installieren und eine Konfiguration erzeugen `grub2-efi-x64` und `shim-x64` liessen sich diesmal auflösen. ``` yum install -y grub2-efi-x64 shim-x64 grub2-mkconfig -o /boot/efi/EFI/centos/grub.cfg ``` Auf CentOS 7 zieht das `shim-x64`, `mokutil`, `efivar-libs` und aktualisierte `grub2`\-Pakete als Abhängigkeiten nach, und legt die eigentlichen Boot-Dateien unter `/boot/efi/EFI/BOOT/` und `/boot/efi/EFI/centos/` ab, genau das, wonach die Firmware der neuen Hardware beim Start sucht. Zu prüfen, dass diese Verzeichnisse existieren und gefüllt sind, bevor neu gestartet wird, hat mir erspart, es erst beim Booten auf die harte Tour herauszufinden. ### 8\. Aufräumen und neu starten ``` exit umount /mnt/dev /mnt/proc /mnt/sys /mnt/run umount /mnt/boot/efi umount /mnt ``` In dieser Reihenfolge unmounten, die Bind-Mounts und die ESP vor dem Root-Dateisystem, danach aus dem Rescue-Modus neu starten. Ob es wirklich bootet, zeigt erst der nächste Neustart. ## Was fast schiefgegangen wäre Zwei Dinge hatten mit den technischen Schritten oben nichts zu tun und hätten das Ganze je für sich anders enden lassen können. Bevor das alles passiert ist, hatte ich ernsthaft überlegt, den Snapshot einfach zu löschen, er sah wie totes Gewicht aus, das im Storage Geld kostet für einen Server, den ich nicht mehr zu brauchen glaubte. Und mittendrin, beim ersten, missglückten Versuch mit der EFI-Partition, habe ich Ja gesagt zum Löschen der ext4-Signatur, bevor ich mich gefangen und von vorn angefangen habe. Eines von beiden falsch, und das war es. Keine Seite mehr, nichts zum Draufschreiben, nur ein Server, auf dem mein Vater und ich etwas aufgebaut hatten, weg. > Ein Snapshot ist kein Backup der Maschine. Es ist ein Backup der Platte, unter der Annahme, dass die Maschine darunter noch existiert. Was sich davon klar trennen lässt: Ich hatte auch ein echtes Daten-Backup der Seite von 2018, extra für genau so einen Notfall aufgehoben. Es stellte sich als zu alt heraus, um sich überhaupt auf Infomaniak installieren zu lassen, Jahre an Updates und Inhalten lagen in der Zwischenzeit nur noch auf dem Server selbst. Dieses Scheitern lag unabhängig vom Hetzner-Vorfall, schon bevor ich überhaupt wusste, dass am Ende der Snapshot der entscheidende sein würde. Dieses Backup von 2018 sollte meine zweite Kopie sein. Als es sich als unbrauchbar herausstellte, war der Snapshot alles, was noch da war, und deshalb war es mir so wichtig, ihn zum Laufen zu bringen. ## Wenn dir das gerade passiert Prüf zuerst den Boot-Modus, bevor du sonst irgendwas anfasst. `lsblk` und `fdisk -l` im Rescue-System zeigen den Typ der Partitionstabelle, und eine reine MBR-Platte ohne EFI System Partition auf Hardware, die nur UEFI spricht, ist deine Antwort. Frag zuerst beim Hetzner-Support nach, ob genau diese Instanz auf Legacy-Boot zurückgestellt werden kann, bevor du einen ganzen Abend in den Rest davon steckst. Verkleinere das Dateisystem, bevor du die Partitionstabelle anfasst. Prüf vorher mit `resize2fs -P`, wie viel freien Platz es meldet, bevor du entscheidest, wie stark du verkleinerst. Arbeite an einer gestoppten, ungemounteten Platte, und lass den Snapshot selbst währenddessen unangetastet irgendwo liegen. Ich habe mich auf einer echten Partitionstabelle nur deshalb wohl genug gefühlt zu improvisieren, weil ich diese Rückfalloption hatte. Ohne sie hätte ich das jemand anderen machen lassen, oder den Hetzner-Support dafür bezahlt. uasource.com läuft wieder, aktualisiert, auf Infomaniak statt auf dem Server, auf den mein Vater und ich sie zuerst gestellt haben. So vorsichtig wie an diesem Abend bin ich damit nicht mehr, inzwischen warte ich sie einfach wie alles andere, was bei mir läuft. Wenn du auf dieselbe UEFI-Wand läufst, schreib mir, mich würde interessieren, ob Hetzner dafür irgendwann eine Warnung ergänzt.