Fünf Jahre kein Update: So habe ich Kali auf dem Raspberry Pi wiederbelebt, ohne neu zu installieren

Du kennst das: Irgendwo liegt ein Raspberry Pi, liebevoll eingerichtet, mit Touchdisplay, Gehäuse und allem Drum und Dran – und seit Jahren hat niemand mehr apt update getippt. Bei mir war es ein Pi 4 mit Kali Linux 2021.2, Kernel 5.4 aus der Re4son-Ecke und Xfce 4.16. Fünf Jahre Rolling Release im Rückstand. Ein Kali Raspberry Pi Upgrade in dieser Größenordnung ist kein „mal eben“.

Die vernünftige Antwort wäre: neues Image drauf, fertig. Ich wollte aber die Einrichtung behalten – Display-Drehung, Touch, Bildschirmtastatur, Werkzeuge. Also Upgrade. Nicht in einem Rutsch, sondern in Phasen, jede einzeln geprüft, mit einem verifizierten SD-Karten-Image als Rückweg. Damit du (oder dein zukünftiges Ich) nicht dieselben Umwege läufst, hier der komplette Ablauf mit allen Stolperstellen.

Ziel

• Kali auf aktuellen Stand bringen (bei mir Metapakete 2026.4), ohne Neuinstallation.
• Zuerst den Kernel tauschen, dann den Rest – in dieser Reihenfolge.
• Jederzeit einen Weg zurück haben.
• Am Ende: keine fehlgeschlagenen Dienste, Display, Touch und WLAN funktionieren.

Voraussetzungen

• Ein geprüftes Image der SD-Karte (Größe und SHA-256 von Karte und Image verglichen). Ohne das würde ich gar nicht anfangen.
• SSH-Zugang zum Pi und tmux darauf. Das Upgrade dauert Stunden, eine abgerissene SSH-Verbindung darf es nicht abbrechen.
• Ein Notzugang, falls das WLAN nach einem Neustart fehlt: Netzwerkkabel zum Laptop mit Internetfreigabe.
• Zeit. Bei mir lag zwischen erstem apt update und letztem Neustart knapp ein Tag, mit Pausen.

Warum apt full-upgrade allein hier scheitert

Drei Dinge machen einen so großen Sprung heikel:

1. Neuer Archivschlüssel: Kali hat 2025 den Signaturschlüssel des Paketarchivs gewechselt. Mit dem alten Schlüsselring scheitert schon apt update.
2. Kernel zu alt für das neue systemd: systemd 262 unterstützt Kernel unter 5.10 laut eigener README überhaupt nicht. Mein Kernel war 5.4. Erst den Userspace zu aktualisieren und dann den Kernel, hätte sehr wahrscheinlich ein System ergeben, das nicht mehr startet.
3. Kleine Boot-Partition: /boot hatte 126 MB, davon 51 MB frei. Ein neuer Kernel samt initramfs passt da nur nach dem Aufräumen hinein.

Daraus ergibt sich die Reihenfolge: Quellen und Schlüssel → Kernel → Userspace → Aufräumen.

Vorbereitung: tmux, Log und Sicherungen

Alles läuft in einer tmux-Sitzung, alle Ausgaben zusätzlich in ein Log:

tmux new -s upgrade
sudo mkdir -p /root/upgrade-2026

Vor jeder Phase sichere ich die betroffenen Dateien mit Zeitstempel und Grund im Namen, z. B. config.txt.bak-20261024-2220-kernel. Und vor jedem echten Schritt kommt die Simulation mit apt-get -s – die ändert nichts, zeigt aber, was passieren würde.

Phase 1: Paketquellen und neuer Archivschlüssel

sudo cp -a /etc/apt /root/upgrade-2026/apt-vorher

In /etc/apt/sources.list bleibt genau eine aktive Zeile:

deb http://http.kali.org/kali kali-rolling main contrib non-free non-free-firmware

kali-experimental und alte Fremdquellen (bei mir die nicht mehr existierende Re4son-Quelle) habe ich auskommentiert. non-free-firmware ist neu und für die Raspberry-Pi-Firmware nötig.

Dann den neuen Schlüsselring holen und vor dem Einsetzen prüfen – Prüfsumme und Fingerabdrücke stehen im Kali-Blogbeitrag „New Kali archive signing key“:

wget https://archive.kali.org/archive-keyring.gpg -O /tmp/kali-archive-keyring.gpg
sha1sum /tmp/kali-archive-keyring.gpg
gpg --show-keys /tmp/kali-archive-keyring.gpg

Stimmen die Werte, ersetzt die Datei den alten Schlüsselring unter /usr/share/keyrings/kali-archive-keyring.gpg (und eine eventuelle Kopie unter /etc/apt/trusted.gpg.d/). Danach muss sudo apt update ohne Signaturfehler durchlaufen.

Hinweis: Bei mir endete apt-get update trotzdem mit Exit-Code 100. Schuld war das uralte command-not-found, dessen Hook die Komponente non-free-firmware nicht kennt. Die Paketlisten waren in Ordnung – das erledigt sich mit dem Upgrade von selbst.

Phase 2: Erst der Kernel – und zwar parallel zum alten

Der Trick in dieser Phase: Der neue Raspberry-Pi-Kernel kommt in einen eigenen Unterordner von /boot, der alte bleibt als Rückfall liegen. Umschalten ist dann eine Zeile in config.txt.

1. /boot komplett sichern und Platz schaffen. Auf einem Pi 4 mit 64 Bit liegen dort Kernel für Pi 1 bis 3 und 32 Bit, die niemand braucht:

bash
sudo tar -cf /root/upgrade-2026/boot-vorher.tar -C / boot

2. Kleineres initramfs: in /etc/initramfs-tools/initramfs.conf MODULES=dep statt most.
3. Die alten Kernelpakete festhalten, damit apt sie nicht anfasst, dann den neuen Kernel installieren:

bash
sudo apt-mark hold kalipi-kernel kalipi-bootloader kalipi-re4son-firmware
sudo apt-get install linux-image-rpi-v8

4. Kernel, Device Tree (bcm2711-rpi-4-b.dtb), Overlays und cmdline.txt nach /boot/rpt/ kopieren. Weil unklar war, ob die Bootfirmware von 2021 den komprimierten Kernel lädt, habe ich ihn vorsorglich entpackt als kernel8.img abgelegt.
5. In config.txt im Abschnitt [pi4]:

text
os_prefix=rpt/
kernel=kernel8.img
#kernel=kernel8l-alt.img <- alter Kernel, als Rückfall

Neustart, dann prüfen: uname -r, SSH, systemctl --failed, Display, Drehung, Touch an allen vier Ecken.

Rückfall in Minuten statt Stunden: Startet der neue Kernel nicht, Karte in den Laptop – die Boot-Partition ist FAT und wird direkt angezeigt –, die beiden Zeilen auskommentieren, die alte wieder aktivieren, fertig.

Bei mir startete der Pi sauber mit 6.12 – nur das WLAN kam beim ersten Mal nicht hoch: Treiber und Firmware luden, aber dhclient bekam kein Angebot, bevor networking.service aufgab. Über das Kabel zum Mac (mit Internetfreigabe) kam ich trotzdem drauf, ein sudo ifup wlan0 brachte das WLAN zurück, und beim nächsten Neustart lief es ohne Eingriff. Genau für solche Momente ist der Notzugang da.

Phase 3: Der große Sprung im Userspace

Jetzt erst die Simulation des eigentlichen Upgrades:

sudo apt-get -s full-upgrade | tail -1

Bei mir: 1917 Aktualisierungen, 1175 neue Pakete, 164 Entfernungen, rund 3,4 GB Download. Die Entfernungen genau ansehen: Bei mir waren es fast nur alte Bibliotheksversionen mit Nachfolger und ein paar eingestellte Tools.

Die Reihenfolge, die sich bewährt hat:

sudo apt-get install apt dpkg kali-archive-keyring command-not-found
sudo apt-get upgrade --without-new-pkgs
sudo apt-get -o Dpkg::Options::=--force-confdef -o Dpkg::Options::=--force-confold full-upgrade

--force-confold behält deine geänderten Konfigurationsdateien, die neuen Vorlagen landen als *.dpkg-dist daneben. So fragt dich apt nicht 50-mal mitten in der Nacht.

Und dann kam, was bei fünf Jahren Rückstand kommen musste. Das Upgrade lief nicht in einem Durchgang, sondern in mehreren Fortsetzungsläufen. Die Hindernisse, in der Reihenfolge ihres Auftretens:

1. Verwaiste Umleitung: Ein Paket scheiterte an einer dpkg-divert-Umleitung ohne zugehörige Datei. Lösung: sudo dpkg-divert --no-rename --remove <pfad>.
2. Dateikonflikte durch aufgeteilte Pakete: dbus wurde in mehrere Pakete zerlegt, freeglut3, python3-spnego und libgtk-3 heißen heute anders. dpkg meldet dann „Versuch, … zu überschreiben“. Lösung: genau diese Archive einmal mit sudo dpkg -i --force-overwrite entpacken – nur bei dieser Meldung, nicht pauschal.
3. perl hinkte hinterher: Paketskripte verlangten perl ≥ 5.36, installiert war 5.32. sudo apt-get install perl vorziehen.
4. /boot voll beim initramfs: Das alte initrd des neuen Kernels wurde gar nicht benutzt (die Firmware startet ohne), also weg damit.
5. Der Resolver hielt 629 Pakete zurück. Erst als ich die aktuellen Metapakete direkt angefordert habe, ging es weiter:

bash
sudo apt-get install kali-linux-default kali-desktop-xfce kali-linux-headless

6. systemd 262 kann keine SysV-Skripte mehr: Alte Init-Skripte ließen sich nicht stoppen, dpkg brach ab. Für die Dauer des Upgrades habe ich Dienstaktionen gesperrt und danach wieder freigegeben:

bash
printf '#!/bin/sh\nexit 101\n' | sudo tee /usr/sbin/policy-rc.d && sudo chmod +x /usr/sbin/policy-rc.d
# … Upgrade-Läufe …
sudo rm /usr/sbin/policy-rc.d

7. /tmp wird plötzlich tmpfs: Das neue systemd hängt /tmp in den Arbeitsspeicher. Dabei verschwanden meine Hilfsskripte – und der tmux-Socket. Die Sitzung lief weiter, ein kill -USR1 an den tmux-Server erzeugt den Socket neu. Skripte gehören seitdem ins Home-Verzeichnis.

Am Ende: 0 offene Aktualisierungen, dpkg --audit leer, sshd -t ohne Fehler. Dann der spannendste Moment: Neustart.

Nach dem Neustart: zwei Überraschungen

Kein D-Bus, kein Netz, kein Desktop. Der Pi landete auf einer Textanmeldung, systemctl fand keinen Bus. Ursache: /usr/lib/systemd/system/dbus.socket fehlte, obwohl das Paket ihn mitbringt. Das ist ein bekannter Effekt des zusammengelegten /usr: dpkg löscht beim Upgrade die „alte“ Datei unter /lib – die aber dank Symlink dieselbe ist wie die neue unter /usr/lib. Lösung: das Paket neu installieren – bei mir per dpkg -i mit der Datei aus dem apt-Cache, mit Netz geht es auch so:

sudo apt-get install --reinstall dbus-system-bus-common

Danach startete der Pi in 18 Sekunden bis zum grafischen Ziel.

LightDM läuft, zeigt aber nichts. Mein Display läuft noch im Firmware-Modus ohne KMS. Dann gibt es kein /dev/dri/card0, logind hält den Sitz für nicht grafisch, und LightDM wartet höflich auf ewig. Lösung in /etc/lightdm/lightdm.conf.d/50-fbdev-ohne-kms.conf:

[LightDM]
logind-check-graphical=false

Phase 4: Aufräumen und neues Image

• apt autoremove – bei mir 330 Pakete. Die Liste vorher gegen die Pakete prüfen, die du wirklich brauchst.
• Konfigurationsreste entfernen: sudo apt-get purge $(dpkg -l | awk '/^rc/{print $2}').
• Dienste prüfen, die mit dem neuen Stand nicht mehr passen (bei mir smartmontools – eine SD-Karte kann kein SMART).
• Neues geprüftes Image des Endstands ziehen. Erst danach habe ich den alten Kernel aus /boot entfernt.

So prüfst du es

uname -r
grep VERSION= /etc/os-release
systemctl is-system-running
systemd-analyze
apt-mark showhold
sudo apt-get -s full-upgrade | tail -1

running heißt: kein einziger Dienst fehlgeschlagen. Dazu Display, Drehung und Touch von Hand prüfen.

Rückweg

• Phase 1: /etc/apt aus der Kopie zurückholen.
• Phase 2: in config.txt auf den alten Kernel umschalten (siehe oben).
• Ab Phase 3: Das Image vom Anfang auf die Karte schreiben. Bei 64 GB inklusive Zurücklesen und Prüfsummenvergleich ein bis zwei Stunden.

Stolperstellen aus der Praxis

• Reihenfolge Kernel → systemd ist das Wichtigste an diesem Beitrag. Andersherum riskierst du ein System, das nicht mehr startet.
• Ohne Notzugang kein Kernelwechsel. Netzwerkpakete und WLAN-Firmware ändern sich mit – plane ein Kabel ein.
• --force-overwrite nur gezielt. Pauschal gesetzt, überdeckt es echte Konflikte.
• Gehaltene Pakete prüfen: Die alten kalipi-*-Pakete liefern bei mir die Bootfirmware und die Nexmon-WLAN-Firmware. Die habe ich behalten und nur den alten Kernel entfernt.
• tmux-Socket weg ≠ Sitzung weg. Erst nachsehen, ob der tmux-Prozess noch läuft, bevor du in Panik ein zweites Upgrade startest.
• Bildschirmtastatur im Anmeldebildschirm (bei Touchdisplays): Die eingebettete onboard-Tastatur blieb bei mir schwarz. Als eigenes Fenster über ein kleines Wrapper-Skript gestartet, lief sie.

Fazit

Fünf Jahre Rolling Release aufholen ist machbar – aber nicht mit einem einzigen full-upgrade und einer Tasse Kaffee. Mit einem geprüften Image im Rücken, dem Kernel zuerst und einer Simulation vor jedem Schritt wird aus dem Glücksspiel ein Projekt mit Plan. Ehrlicherweise: Für einen Pi ohne Sondereinrichtung ist ein frisches Image schneller. Wenn aber Display, Touch und ein paar Jahre Feinschliff dranhängen, lohnt sich das Kali Raspberry Pi Upgrade – und man lernt nebenbei mehr über dpkg, als man je wissen wollte.