❌

Normale Ansicht

Ubuntu-Server-Update von 24.04 auf 26.04

30. Oktober 2026 um 10:59

Über Ubuntu 26.04 habe ich hier schon berichtet. Heute habe ich meinen ersten Ubuntu-Server von Version 24.04 auf 26.04 aktualisiert. Es ist eigentlich recht gut gegangen. Dieser Beitrag fasst die wichtigsten Erkenntnisse zusammen.

  • MySQL-Passwörter
  • Dovecot-Konfiguration (Update 2.3 -> 2.4)
  • SSH-Server-Konfiguration
  • Externe und obsolete Pakete aufräumen

Grundsätzliche Vorgehensweise

Logischerweise sollten Sie zuerst ein Backup machen. Mein System ist eine virtuelle Maschine (KVM), ich habe also ein Backup des Images gemacht (LVM-Snapshot im laufenden Betrieb). Wäre irgendetwas total schief gegangen, hätte ich den ganzen Server blitzschnell in den alten Zustand zurückversetzen können.

Wichtig: Falls Sie Nextcloud verwenden, aktualisieren Sie die Nextcloud-Version zuerst und führen Sie das Ubuntu-Update erst danach durch. Andernfalls kann es Ihnen passieren, dass Nextcloud danach nicht mehr startet (Fehlermeldung: This version of Nextcloud is not compatible with PHP>=8.5. You are currently running 8.5.4). Es ist ziemlich mühsam, aus dieser Falle wieder herauszukommen, weil die üblichen Update-Mechanismen PHP voraussetzen!

Am Zielsystem habe ich dann ein letztes Update durchgeführt und dann do-release-upgrade gestartet. Der erste Lauf scheiterte an alten MySQL-Passwörtern. Nachdem ich diese umgestellt hatte (Details folgen gleich), lief do-release-upgrade ziemlich problemlos durch.

Bei sämtlichen Rückfragen, ob ich meine geänderten Konfigurationsdateien behalten oder lieber die neuen Konfigurationsdateien verwenden möchte, habe ich mich für meine alten Konfigurationsdateien entschieden. (Die Entscheidung ist nicht ganz einfach: Die neuen Konfigurationsdateien enthalten in der Regel bessere/neuere Einstellungen, die vorzuziehen wären. Umgekehrt will ich aber auch nicht die in der Vergangenheit vorgenommenen Änderungen verlieren.)

Danach ein Reboot, nach 30 Sekunden war ein neuer SSH-Login möglich. Sehr gut!

Jetzt begannen die Aufräumarbeiten. Es gab zwei Hauptprobleme:

  • Dovecot funktionierte nicht mehr (das war zu erwarten).
  • PHP auch nicht (das kam überraschend).

Vor dem Ubuntu-Update: MySQL-Passwörter

Mit Ubuntu 26.04 kommt MySQL 8.4. Diese Version des Datenbank-Servers unterstützt standardmäßig keine mysql_native_password-Passwörter mehr. Das ist an sich vernünftig, die Passwörter werden nach einem unsicheren Verfahren verschlüsselt. Es gibt zwei Lösungen: Eine besteht darin, das nicht mehr empfohlene Plugin mysql_native_password doch wieder zu aktivieren. (In Version 9 wird das aber nicht mehr gehen.) Die andere besteht darin, für alle betroffenen Benutzer ein neues Passwort mit dem Verfahren caching_sha2_password einzurichten, im Wesentlichen so:

ALTER USER name@localhost IDENTIFIED WITH caching_sha2_password BY 'topsecret';

Ich habe mich für diese Variante entschieden, zumal es ohnedies nur wenige betroffene Accounts gab. Zwei bereiteten mir allerdings Kopfzerbrechen. Welche Passwörter sollte ich für die (in der Vergangenheit) automatisch eingerichteten Accounts 'debian-sys-maint'@localhost und mysql.session@localhost verwenden? Eine kurze Recherche ergab, dass sich das Passwort für ersteren Account (eine Debian/Ubuntu-Spezialität) in /etc/mysql/debian.cnf befindet. Der zweite Account ist MySQL-intern. Es muss existieren, ist aber nicht für einen Login gedacht. Jedes zufällige Passwort ist OK.

Das eigentliche Update habe ich NACH den MySQL-Änderungen gestartet.

Nach dem Ubuntu-Update: PHP

Nach dem Update liefen Apache und der MySQL-Server auf Anhieb, nur PHP wollte nicht. Die Fehlermeldung im Apache-Log lautete:

(2)No such file or directory: AH02454: FCGI: attempt to connect to Unix domain socket /run/php/php8.3-fpm.sock (localhost:8000) failed

Der Fehler war leicht zu finden: Ich verwende PHP mit dem FastCGI Process Manager (FPM). Die PHP-Version wurde auf 8.5 aktualisiert, aber die Konfiguration verwies weiter auf die FPM-8.3-Version. Abhilfe:

apt install php-fpm
systemctl enable --now php8.5-fpm
a2disconf php8.3-fpm
a2enconf php8.5-fpm
systemctl restart apache2

Warum der Upgrade-Prozess sich um diese Details nicht gekümmert hat, kann ich nicht sagen. Möglicherweise hatte ich unter Ubuntu 24.04 irgendeine Abweichung von der Default-Konfiguration durchgeführt und die Konfigurationsdateien wurden deswegen nicht aktualisiert.

Ein letzter Hinweis zu PHP: Mit PHP 8.5 werden neue Konfigurationsdateien nach /etc/php/8.5 installiert. In meinem Fall (FPM) ist die Datei /etc/php/8.5/fpm/php.ini relevant. Änderungen, die in der Vergangenheit in der 8.3er-Version von php.ini vorgenommen wurden, müssen jetzt in der 8.5er-Version wiederholt werden. (In meinem Fall war vor allem memory_limit = 512M wichtig, damit Nextcloud ordentlich läuft. Der Defaultwert 128M ist zu klein.)

Dovecot

Dovecot (ein IMAP-Server) macht mit Ubuntu 26.04 einen Versionssprung von 2.3 auf 2.4. Das klingt unspektakulär, aber tatsächlich hat Dovecot mit der neuen Version die Syntax der Konfigurationsdateien grundlegend geändert. Solange die Dateien nicht angepasst werden und insbesondere die Anweisungen dovecot_config_version = 2.4.0 sowie dovecot_storage_version = 2.4.0 an den Beginn von /etc/dovecot.conf eingebaut werden, startet der Dienst nicht.

Upgrading Dovecot CE from 2.3 to 2.4 enthält eine umfassende Migrationsanleitung. Die simple Übernahme der neuen Konfigurationsdateien ist (in meinem Fall) unmöglich, weil ich diverse eigene Anpassungen vorgenommen habe. Schon vor dem Ubuntu-Update habe ich deswegen sicherheitshalber ein Backup des alten Konfigurationsverzeichnisses /etc/dovecot durchgeführt.

Die manuelle Migration erschien mir recht mühsam. Also habe ich Claude Code SSH-Zugriff auf meinen Server gegeben (für einen normalen Account, nicht für root) und habe den folgenden Prompt formuliert:

you can ssh to example.com (no root); go to /etc/dovecot and look at the config files; these are partially from 2.3 and must be updated to 2.4 (see also https://doc.dovecot.org/main/installation/upgrade/2.3-to-2.4.html); explain me what to change, don’t try to do it yourself; summarize your findings locally (not on example.com) into dovecot-migration-plan.md

Diesen Plan habe ich anschließend manuell umgesetzt. Anbei eine Kurzfassung:

Dovecot 2.3 -> 2.4: config changes

dovecot.conf

  Add these as the very first settings:

    dovecot_config_version = 2.4.0
    dovecot_storage_version = 2.4.0

  Remove the empty "dict { }" block.

conf.d/10-auth.conf

  Old: auth_username_format = %Ln
  New: auth_username_format = %{user | username | lower}

conf.d/auth-system.conf.ext

  passdb and userdb blocks need a name:

    passdb pam {
    }
    userdb passwd {
    }

conf.d/10-mail.conf

  mail_location is gone:

    mail_driver = maildir
    mail_path = ~/Maildir

conf.d/10-master.conf

  Old: user = $default_internal_user
  New: user = $SET:default_internal_user

conf.d/10-ssl.conf

  New setting names, no more "<" before file names:

    ssl = yes
    ssl_server_cert_file = /etc/letsencrypt/live/
                           example.com/fullchain.pem
    ssl_server_key_file  = /etc/letsencrypt/live/
                           example.com/privkey.pem
    ssl_server_dh_file   = /etc/dovecot/dh.pem
    ssl_server_prefer_ciphers = server

  (Each path belongs on one line; it is split here only
  for readability.)

  ssl_server_prefer_ciphers accepts "client" or "server";
  "yes" is a fatal error. The DH file is only needed for
  non-ECC key exchange and can be omitted.

conf.d/20-lmtp.conf

  "mail_plugins = $mail_plugins sieve" no longer works:

    protocol lmtp {
      postmaster_address = postmaster@example.com
      mail_plugins {
        sieve = yes
      }
    }

conf.d/90-sieve.conf

  The plugin { } block is gone. Use named script blocks:

    sieve_script personal {
      driver = file
      path = ~/sieve
      active_path = ~/.dovecot.sieve
    }
    sieve_script after {
      type = after
      driver = file
      path = /etc/dovecot/sieve-after
    }

  Recompile global sieve scripts (as root):

    sievec /etc/dovecot/sieve-after/spam-to-folder.sieve

  Users' own scripts are recompiled automatically.

Protocols

  2.4 enables no protocols by default. On Debian they come
  from /usr/share/dovecot/protocols.d, i.e. one file per
  installed package (imapd, lmtpd, managesieved, ...).

Testing

  doveconf -n          # must run without errors
  systemctl restart dovecot
  journalctl -u dovecot -n 50

  Then check IMAP login, LMTP delivery from Postfix, SMTP
  auth via the Postfix SASL socket and sieve filtering.

Eine halbe Stunde später konnte ich in Thunderbird meine Mails wieder abrufen.

Update Configuration File (UCF)

Eine Debian/Ubuntu-Pakete verwenden das Verfahren Update Configuration File (UCF). Bei diesen Paketen wird parallel zur unverändert belassenen Konfigurationsdateien die neue Version der Konfigurationsdatei mit der Kennung *.ucf-dist angelegt. Das ist praktisch, weil Sie unkompliziert danach suchen können:

find /etc -name '*.ucf-dist'

Leider wird UCF nur von ausgewählten Paketen verwendet (auf jeden Fall: apt, dovecot und ssh).

SSH-Server

Der SSH-Server (openssh-server 10.2) läuft zwar auf Anhieb (alles andere wäre ja eine Katastrophe), aber journalctl -u ssh liefert diverse Warnungen:

sshd: rexec line 16: Deprecated option UsePrivilegeSeparation
sshd: rexec line 19: Deprecated option KeyRegenerationInterval
sshd: rexec line 20: Deprecated option ServerKeyBits
sshd: rexec line 31: Deprecated option RSAAuthentication
sshd: rexec line 38: Deprecated option RhostsRSAAuthentication

Also habe ich auch diese Datei etwas aufgeräumt, wobei Claude Code einige weitere Verbesserungsvorschläge gemacht hat (ChallengeResponseAuthentication -> KbdInteractiveAuthentication, PermitRootLogin without-password -> PermitRootLogin prohibit-password, HostKey /etc/ssh/ssh_host_dsa_key entfernen).

Docker

In Ubuntu 24.04 hatte ich Docker-Pakete direkt aus dem Docker-Repo installiert. Die alten Pakete wurden unverändert belassen, Docker funktionierte weiter. Allerdings wurde im Rahmen des Updates die Docker-Paketquelle deaktiviert (siehe /etc/apt/sources.list.d/*.disabled), d.h. ich würde keine Updates mehr erhalten. Ich habe daher die folgende Datei docker.sources neu eingerichtet:

Types: deb
URIs: https://download.docker.com/linux/ubuntu
Suites: resolute
Components: stable
Architectures: amd64
Signed-By: /etc/apt/keyrings/docker.asc

apt update und apt list --upgradable zeigt jetzt zu Ubuntu 26.04 passende Docker-Pakete an, die ich mit apt dist-upgrade installierte. Ein kurzer Test mit docker ps zeigt, dass alle Docker-Container wie geplant laufen.

Obsolete Pakete entfernen

Das Kommando

apt list '?obsolete'

liefert eine Liste von Paketen, die aus früheren Ubuntu-Versionen stammen (zu meiner Schande bis zurück nach 14.04) und zu denen es keine aktive Paketquellen mehr gibt (z.T. uralte Kernel-Versionen). Höchste Zeit, auch hier aufzuräumen. Ich habe Claude Code um eine Analyse gebeten.

find obsolete packages and access which can be safely removed

In der Folge habe ich die meisten betreffenden Pakete mit apt purge entfernt.

Quellen/Links

Frame: Ein kompletter X11 Server passt in eine Assemblerdatei

Von: MK
17. Juli 2026 um 05:30

Ein außergewöhnliches Open Source Projekt sorgt derzeit für Aufmerksamkeit. Frame implementiert einen vollständigen X11 Server in Assembler. Künstliche Intelligenz spielte dabei eine zentrale Rolle. Der gesamte Quellcode steckt in einer einzigen Datei. Sie umfasst inzwischen fast 25000 Programmzeilen. Externe Bibliotheken kommen dabei nicht zum Einsatz. Frame kommuniziert direkt mit Linux Systemaufrufen und der Grafikhardware. Entwickelt […]

Der Beitrag Frame: Ein kompletter X11 Server passt in eine Assemblerdatei erschien zuerst auf fosstopia.

Ubuntu Livepatch erhält offizielle ARM64 Unterstützung

Von: MK
23. Juni 2026 um 10:54

Canonical erweitert seinen Livepatch Dienst nun auch auf ARM64 Systeme und ermöglicht damit sicherheitsrelevante Kernel Updates ohne Neustart auf performanter ARM-Hardware. Die neue Unterstützung richtet sich vor allem an Betreiber großer Serverlandschaften. Livepatch hält kritische Kernel Lücken geschlossen, während Dienste weiterlaufen. Das senkt Ausfallzeiten und schützt sensible Systeme an entfernten Standorten. Besonders ARM-Server und Edge-Geräte […]

Der Beitrag Ubuntu Livepatch erhält offizielle ARM64 Unterstützung erschien zuerst auf fosstopia.

AlmaLinux 10.2 bringt Btrfs Boot Support

Von: MK
27. Mai 2026 um 06:00

AlmaLinux 10.2 erscheint als stabile Ausgabe und setzt auf Linux Kernel 6.12. Die neue Version basiert auf RHEL 10.2 erweitert den Funktionsumfang deutlich und stärkt die Unterstützung älterer Hardware. Besonders spannend ist die Rückkehr klassischer Treiber und die Einführung von i686 Paketen für 32 Bit Software. Die Distribution bietet nun Btrfs Boot Support. Damit lassen […]

Der Beitrag AlmaLinux 10.2 bringt Btrfs Boot Support erschien zuerst auf fosstopia.

Red Hat veröffentlicht RHEL 10.2 mit besserer KI Unterstützung

Von: MK
20. Mai 2026 um 15:22

Red Hat stellt zwei neue Versionen seiner Unternehmensdistribution vor. RHEL 10.2 und RHEL 9.8 setzen stark auf moderne KI Werkzeuge. Im Mittelpunkt steht der neue Goose Assistent, der direkt im Terminal hilft. Goose nutzt MCP Integration und liefert farblich verbesserte Ausgaben. Red Hat verspricht schnellere Problemlösungen und einen leichteren Einstieg für neue Administratoren. Beide Versionen […]

Der Beitrag Red Hat veröffentlicht RHEL 10.2 mit besserer KI Unterstützung erschien zuerst auf fosstopia.

Rocky Linux führt spezielles Sicherheitsrepo für dringende Patches ein

Von: MK
19. Mai 2026 um 06:00

Rocky Linux bietet nun ein optionales Sicherheitsrepo für besonders kritische Fälle. Es greift ein, wenn eine Schwachstelle öffentlich ist und bereits Exploits existieren. Administratoren erhalten so schneller wichtige Korrekturen ohne auf Upstream Pakete zu warten. Das Repo bleibt standardmäßig deaktiviert und verändert das normale Updateverhalten nicht. Es dient nicht als schneller Updatekanal und ersetzt auch […]

Der Beitrag Rocky Linux führt spezielles Sicherheitsrepo für dringende Patches ein erschien zuerst auf fosstopia.

Ubuntu 16.04 erreicht Supportende

Von: MK
05. Mai 2026 um 05:30

Ubuntu 16.04 LTS Xenial Xerus erhält keine Sicherheitsupdates mehr, da der bisher noch laufenden “Expanded security maintenance” Supportplan auslief. Die Version erschien 2016 und bekam fünf Jahre Standardsupport sowie fünf weitere Jahre über ESM. Diese verlängerte Phase endete nun im April 2026 und macht gemäß Ubuntu Release-Cycle ein Handeln notwendig. Ein direktes Upgrade auf eine […]

Der Beitrag Ubuntu 16.04 erreicht Supportende erschien zuerst auf fosstopia.

PHP 8.4 FPM für Nextcloud 33

02. April 2026 um 04:00

Wer meinem Blog folgt und, wie im Artikel „PHP 7.4 FPM auf PHP 8.1 FPM für Nextcloud“, die externe PHP-Quelle von https://deb.sury.org/ eingebaut hat und später der Anleitung „PHP 8.2 FPM für Nextcloud 28“ gefolgt ist, könnte noch auf PHP 8.2 FPM hängen geblieben sein. Da sich diese Version im Status Security fixes only befindet, ist ein Wechsel auf eine höhere Version absolut empfehlenswert. Diese PHP-Version lässt sich recht einfach auf PHP 8.4 FPM umstellen. Unter dem Raspberry Pi OS ist das mit wenigen Befehlen erledigt. In diesem Beitrag zeige ich kurz, wie man PHP 8.2 deaktiviert, PHP 8.4 installiert und Nextcloud anschließend mit der neuen Version betreibt.

Vor der Umstellung empfiehlt es sich, ein Backup der Installation und der Datenbank anzulegen. Außerdem sollte geprüft werden, ob die eingesetzten Apps bereits mit Nextcloud 33 und PHP 8.4 kompatibel sind.

Diagramm der momentan unterstützten PHP-Versionen
Quelle: https://www.php.net/supported-versions.php

Installierte PHP-Version prüfen

Das System sollte zunächst auf den aktuellen Stand gebracht werden:

sudo apt update && sudo apt upgrade

Jetzt prüfen, welche PHP-Version aktuell aktiv ist:

php -v

Falls Apache mit PHP-FPM genutzt wird, lohnt sich auch ein Blick auf die aktiven Module und Konfigurationen.

PHP 8.4 und benötigte Module installieren

Wer von PHP 8.2 auf PHP 8.4 wechselt, installiert zunächst die neue Version samt der für Nextcloud üblichen Erweiterungen:

sudo apt update
sudo apt install php8.4 php8.4-mbstring php8.4-gd php8.4-curl php8.4-imagick php8.4-intl php8.4-bcmath php8.4-gmp php8.4-mysql php8.4-zip php8.4-xml php8.4-apcu libapache2-mod-php8.4 php8.4-bz2 php8.4-redis

PHP 8.2 deaktivieren und PHP 8.4 aktivieren

Nun wird PHP 8.2 deaktiviert und PHP 8.4 aktiviert:

sudo update-alternatives --config php
sudo update-alternatives --config php
Es gibt 7 Auswahlmöglichkeiten für die Alternative php (welche /usr/bin/php bereitstellen).

  Auswahl      Pfad                  Priorität Status
------------------------------------------------------------
  0            /usr/bin/php.default   100       automatischer Modus
  1            /usr/bin/php.default   100       manueller Modus
  2            /usr/bin/php7.4        74        manueller Modus
  3            /usr/bin/php8.1        81        manueller Modus
* 4            /usr/bin/php8.2        82        manueller Modus
  5            /usr/bin/php8.3        83        manueller Modus
  6            /usr/bin/php8.4        84        manueller Modus
  7            /usr/bin/php8.5        85        manueller Modus

Hier die entsprechende Nummer eingeben – in diesem Fall die 6 für PHP 8.4:

sudo update-alternatives --config php
Es gibt 7 Auswahlmöglichkeiten für die Alternative php (welche /usr/bin/php bereitstellen).

  Auswahl      Pfad                  Priorität Status
------------------------------------------------------------
  0            /usr/bin/php.default   100       automatischer Modus
  1            /usr/bin/php.default   100       manueller Modus
  2            /usr/bin/php7.4        74        manueller Modus
  3            /usr/bin/php8.1        81        manueller Modus
  4            /usr/bin/php8.2        82        manueller Modus
  5            /usr/bin/php8.3        83        manueller Modus
* 6            /usr/bin/php8.4        84        manueller Modus
  7            /usr/bin/php8.5        85        manueller Modus

Die Abfrage der Version zeigt, ob die Umstellung auf PHP 8.4 angenommen wurde.

php -v

PHP 8.4 FPM starten und Apache neu laden

Anschließend wird der neue FPM-Dienst aktiviert und gestartet:

sudo a2disconf php8.2-fpm
sudo apt install php8.4-fpm
sudo a2enconf php8.4-fpm

Der Neustart des Webservers aktiviert nun die aktuelle PHP-Version:

sudo service apache2 restart

Nextcloud-Konfiguration

Sollten in Nextcloud anschließend wieder die bekannten Fehlermeldungen erscheinen, sind diese am besten Schritt für Schritt abzuarbeiten. Dazu werden zunächst die neue php.ini geöffnet:

sudo nano /etc/php/8.4/fpm/php.ini

und anschließend die Werte für memory_limit sowie session.gc_maxlifetime gemäß den Empfehlungen angepasst:

memory_limit = 512M
session.gc_maxlifetime = 3600

Am Ende der php.ini werden außerdem noch die Einstellungen für den Zwischenspeicher OPcache ergänzt:

opcache.enable=1
opcache.interned_strings_buffer=64
opcache.max_accelerated_files=10000
opcache.memory_consumption=256
opcache.save_comments=1
opcache.revalidate_freq=1

Zur Optimierung von PHP 8.4 FPM können speziell auf einem Raspberry Pi 5 mit 8 GB RAM in der Datei www.conf

sudo nano /etc/php/8.4/fpm/pool.d/www.conf

die folgenden Werte angepasst werden. Standardmäßig stehen dort in der Regel:

pm = dynamic
pm.max_children = 5
pm.start_servers = 2
pm.min_spare_servers = 1
pm.max_spare_servers = 3

Diese werden dann auf folgende Werte geändert:

pm = dynamic
pm.max_children = 200
pm.start_servers = 20
pm.min_spare_servers = 10
pm.max_spare_servers = 30

Anschließend wird der Dienst neu gestartet:

sudo service php8.4-fpm restart

Danach muss in der apcu.ini noch das Command Line Interface (CLI) des PHP-Caches aktiviert werden. Dazu die Datei öffnen:

sudo nano /etc/php/8.4/mods-available/apcu.ini

und am Ende folgende Zeile ergänzen:

apc.enable_cli=1

Ist dies geschehen, wird der Webserver ein letztes Mal neu gestartet:

sudo service apache2 restart

Nextcloud prüfen

Danach sollte die Nextcloud-Instanz im Browser aufgerufen werden. Unter Administrationseinstellungen / System lässt sich kontrollieren, ob die neue PHP-Version erkannt wurde.

Zur Sicherheit zusätzlich die Logdateien von Apache, PHP-FPM und Nextcloud prüfen.

Fazit

Die Umstellung von PHP 8.2 auf PHP 8.4-fpm für Nextcloud 32 ist unter Raspberry Pi OS schnell erledigt. Wichtig ist vor allem, die benötigten PHP-Module zu installieren und anschließend die alte FPM-Konfiguration sauber durch die neue zu ersetzen.

Der Beitrag PHP 8.4 FPM für Nextcloud 33 erschien zuerst auf intux.de.

Raspberry Pi OS Bookworm -> Trixie

28. März 2026 um 05:23

Anfang Oktober 2025 hat das Raspberry Pi OS ein Upgrade auf Version 13 mit dem Codenamen Trixie erhalten. Dies setzt die Serverbetreiber wieder einmal mächtig unter Druck, obwohl Bookworm noch weitere Jahre unterstützt wird. Die Entwickler empfehlen eine Neuinstallation. Es ist immer von Vorteil, ein Betriebssystem wie im Falle von Trixie neu und somit sauber aufzusetzen. Da ich aber seit Jahren eine gut funktionierende Nextcloud-Instanz auf meinem Raspberry Pi pflege, die ich in meinem Alltag produktiv einsetze, wäre es zu schade, noch einmal ganz von vorn anfangen zu müssen. Aus diesem Grund war ich auf der Suche nach einem funktionierenden Tutorial für das anstehende OS-Upgrade. Schon beim Umstieg auf Bookworm war der Blog von Sascha Syring sehr hilfreich. Also hoffte ich auch dieses Mal, wieder hier fündig zu werden. Der Artikel „Raspberry Pi OS – Update von Bookworm (12) auf Trixie (13)“ von Sascha beschreibt einmal mehr die genaue Vorgehensweise.

Ich konnte somit alles 1:1 mit meinem System umsetzen. Hier nun alle Schritte mit den entsprechenden Erläuterungen.

Bevor es jedoch losgeht, noch ein wichtiger Hinweis:

Denkt bitte daran, vorher ein Backup zu erstellen! Das Upgrade birgt nicht zu unterschätzende Gefahren.

Upgrade auf Trixie

Zuerst sollte man dafür sorgen, das System inklusive Kernel und aller Abhängigkeiten auf den neuesten Stand zu bringen. Hierzu führt man folgenden Befehl aus:

sudo apt update && sudo apt full-upgrade

Vorbereitend wurde in meinem Fall die alte PHP-Fremd-Quelle deaktiviert.

Hierzu setzt man eine Raute (#) vor den Eintrag, öffnet dazu die php.list mit einem Editor

sudo nano /etc/apt/sources.list.d/php.list

und kommentiert die Zeile entsprechend aus:

#deb https://packages.sury.org/php/ bullseye main

Danach werden die hauseigenen Quellen des Raspberry Pi OS auf Trixie umgestellt:

sudo nano /etc/apt/sources.list

Hierzu wird in allen Quellen wie folgt bookworm durch trixie ersetzt:

deb http://deb.debian.org/debian trixie main contrib non-free non-free-firmware
deb http://security.debian.org/debian-security trixie-security main contrib non-free non-free-firmware
deb http://deb.debian.org/debian trixie-updates main contrib non-free non-free-firmware

Das Gleiche führt man analog hier durch:

sudo nano /etc/apt/sources.list.d/raspi.list
deb http://archive.raspberrypi.org/debian/ trixie main

Da beim ersten Versuch des Upgrades noch einiges schieflief, möchte ich an dieser Stelle darauf hinweisen, dass das Entfernen folgender Pakete für das Gelingen extrem wichtig ist!

sudo apt purge -y raspberrypi-ui-mods
sudo apt purge -y lxplug-batt
sudo apt purge -y lxplug-cpu

Ist dies erledigt, startet man via

sudo apt update && sudo apt full-upgrade

das eigentliche Upgrade. Hierzu ist noch zu erwähnen, dass bei den Abfragen zu alten Konfigurationen diese erhalten bleiben sollen. An diesen Stellen also bitte immer die Vorgabe (N) während der Installation wählen.

Die Pakete rpd-wayland-all und rpd-x-all werden noch nachinstalliert:

sudo apt install rpd-wayland-all rpd-x-all

Aufgeräumt wird mit:

sudo apt autoremove
sudo apt clean

und das System wird neu gestartet:

sudo reboot now

Überprüfung

Nach dem Neustart sollte der Befehl

sudo cat /etc/os-release

nun Folgendes ausgeben:

PRETTY_NAME="Debian GNU/Linux 13 (trixie)"
NAME="Debian GNU/Linux"
VERSION_ID="13"
VERSION="13 (trixie)"
VERSION_CODENAME=trixie
DEBIAN_VERSION_FULL=13.4
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"

Feintuning

Da der NetworkManager nach dem Neustart noch nicht arbeitet, sollte er mit

sudo systemctl enable NetworkManager && sudo systemctl start NetworkManager

aktiviert und gestartet werden.

PHP-Quelle wieder einbinden

Am Anfang der Anleitung hatte ich die PHP-Quelle auskommentiert. Das machen wir nun wieder rückgängig. Erscheint nun nach einem Update der Hinweis, dass der zugehörige Schlüssel abgelaufen ist, löscht man diesen, lädt den aktuellen herunter und liest ihn neu ein.

sudo rm -f /usr/share/keyrings/deb.sury.org-php.gpg
sudo curl -sSLo /etc/apt/trusted.gpg.d/sury-php.gpg https://packages.sury.org/php/apt.gpg

Die Paketquellen werden nun abermals eingelesen und das System aktualisiert:

sudo apt update && sudo apt upgrade

Da die PHP-Quelle allerdings noch nicht für Trixie optimiert ist, ersetzt man auch hier bookworm bzw. bullseye durch trixie:

sudo nano /etc/apt/sources.list.d/php.list
#deb https://packages.sury.org/php/ bullseye main

Ein weiteres Mal werden die Paketquellen eingelesen und das System aktualisiert:

sudo apt update && sudo apt upgrade

Ist dies geschehen, ist das Upgrade von Raspberry Pi OS Version 12 auf 13 abgeschlossen.

Viel Erfolg bei der Umsetzung!

Der Beitrag Raspberry Pi OS Bookworm -> Trixie erschien zuerst auf intux.de.

❌