Normale Ansicht

Vorgestern empfangen

Tipp: Probleme mit Raspberry-Pi-Boot-Reihenfolge beheben

08. Oktober 2025 um 15:00

Mein Raspberry Pi 5 ist mit einem SSD-Hat ausgestattet (Pimoroni, siehe Blog). Auf der SSD ist Raspberry Pi OS Bookworm installiert. Jetzt möchte ich aber Raspberry Pi OS Trixie ausprobieren. Das System habe ich mit dem Raspberry Pi Imager auf eine SD-Card geschrieben. Sowohl SSD als auch SD-Karte sind angeschlossen, die Boot-Reihenfolge ist auf SD-Card first eingestellt.

Boot-Reihenfolge einstellen

raspi-config verändert die Variable BOOT_ORDER, die im EEPROM gespeichert wird. Die Variable kann mit `rpi-eeprom-config´ gelesen werden:

rpi-eeprom-config

  [all]
  BOOT_UART=0
  WAKE_ON_GPIO=0
  POWER_OFF_ON_HALT=1
  BOOT_ORDER=0xf461

0xf461 bedeutet (die Auswertung erfolgt mit den niedrigsten Bits zuerst, also von rechts nach links):

1 - Try SD card
6 - Try NVMe
4 - Try USB mass storage
f - RESTART (loop back to the beginning)

Die Einstellung ist also korrekt, trotzdem bootet der Pi hartnäckig von der SSD und ignoriert die SD-Card. Warum?

Analyse

Schuld sind die Partition-UUIDs! Die SSD habe ich vor eineinhalb Jahren mit dem SD Card Copier geklont. Die Option New Partition UUIDs habe ich nicht verwendet, ich sah keinen Grund dazu. Jetzt liegt folgendes Problem vor: Die SSD und die vom Rasbperry Pi Imager erzeugte SD-Card haben die gleichen Partition-UUIDs!

lsblk -o NAME,PARTUUID,UUID,MOUNTPOINT

  NAME          PARTUUID     UUID                                   MOUNTPOINT
  mmcblk0                                                            
  ├─mmcblk0p1   8a676486-01  1E1E-DAB6                              /boot/firmware
  └─mmcblk0p2   8a676486-02  b8316dab-786b-45e8-815c-3d4bbf198d98    

  nvme0n1                                                            
  ├─nvme0n1p1   8a676486-01  1E1E-DAB6                               
  ├─nvme0n1p2   8a676486-02  b8316dab-786b-45e8-815c-3d4bbf198d98   /
  └─nvme0n1p3   8a676486-03  293896b6-33ee-43de-87d4-56944456cec6 

Deswegen sind die UUIDs in /etc/fstab und in /boot/firmware/cmdline.txt nicht eindeutig:

cat /etc/fstab

  proc                  /proc           proc    defaults          0       0
  PARTUUID=8a676486-01  /boot/firmware  vfat    defaults          0       2
  PARTUUID=8a676486-02  /               ext4    defaults,noatime  0       1


cat /boot/firmware/cmdline.txt

  console=serial0,115200 console=tty1 root=PARTUUID=8a676486-02 rootfstype=ext4 \
    fsck.repair=yes rootwait quiet splash plymouth.ignore-serial-consoles cfg80211.ieee80211_regdom=AT

Solange beide Datenträger verbunden sind, ist nicht vorhersehbar, welche Partitionen tatsächlich genutzt werden. Am einfachsten wäre es natürlich, das Kabel zur SSD vorübergehend zu trennen; das ist aber nicht empfehlenswert, weil es hierfür keinen richtigen Stecker gibt, sondern nur eine sehr filigrane Kabelpressverbindungen, die möglichst nicht anrührt werden sollte.

Lösung

Ich habe den Pi ohne SD-Karte neu gebootet und dann

  • die Filesystem-UUIDs geändert,
  • /etc/fstab angepasst und
  • /boot/firmware/cmdline.txt ebenfalls angepasst.

Im Detail: Da die ursprüngliche Partitionierung der SSD von der SD-Karte übernommen wurde, liegt eine MBR-Partitionstabelle vor. In diesem Fall ergeben sich die Partition-UUIDs aus der Disk-ID plus Partitionsnummer. Die Disk-ID (Hex-Code mit 8 Stellen) kann mit fdisk geändert werden:

fdisk /dev/nvme0n1

  Welcome to fdisk (util-linux 2.38.1).
  Command (m for help): x.                   <-- aktiviert den Expertenmodus
  Expert command (m for help): i             <-- ID ändern
  Enter the new disk identifier: 0x1234fedc. <-- neue ID als Hex-Code
  Disk identifier changed from 0x8a676486 to 0x1234fedc.
  Expert command (m for help): r             <-- zurück ins Hauptmenü (return)
  Command (m for help): w                    <-- Änderungen speichern (write)

  The partition table has been altered.
  Syncing disks.

Mit fdisk -l vergewissern Sie sich, dass die Änderung wirklich funktioniert hat:

fdisk -l /dev/nvme0n1

  ...
  Disk identifier: 0x1234fedc

Weil der Datenträger in Verwendung ist, zeigt fdisk -l /dev/nvme0n1 weiter die alte UUID an. Sie müssen glauben, dass es funktioniert hat :-(

Bevor Sie einen Reboot machen, müssen Sie nun mit einem Editor auch /etc/fstab und /boot/firmware/cmdline.txt anpassen. In meinem Fall sehen die Dateien jetzt so aus:

cat /etc/fstab

  proc                  /proc           proc    defaults          0       0
  PARTUUID=1234fedc-01  /boot/firmware  vfat    defaults          0       2
  PARTUUID=1234fedc-02  /               ext4    defaults,noatime  0       1

cat /boot/firmware/cmdline.txt

  console=serial0,115200 console=tty1 root=PARTUUID=1234fedc-02 rootfstype=ext4 \
    fsck.repair=yes rootwait quiet splash plymouth.ignore-serial-consoles cfg80211.ieee80211_regdom=AT

Jetzt ist ein Reboot fällig, um zu testen, ob alles funktioniert. (Bei mir hat es im ersten Versuch NICHT funktioniert, weil ich bei fdisk das write-Kommando vergessen habe. Dann muss die SSD ausgebaut, ein USB-Gehäuse mit einem Computer verbunden und der Vorgang wiederholt werden.)

Ab jetzt sind die Partitions-UUIDs von SD-Karte und SSD voneinander unterscheidbar. Die Umschaltung des Boot-Systems mit raspi-config funktioniert, wie sie soll.

Quellen/Links

Remote Desktop und Raspberry Pi OS Bookworm

21. Oktober 2023 um 15:47

Die aktuelle Raspberry-Pi-Version verwendet auf den Raspberry-Pi-Modellen 4B, 400 sowie 5 Wayland als Default-Grafiksystem. Aus diesem Grund funktionieren viele Programme zur Fernwartung bzw. für Remote-Desktop-Funktionen nicht mehr wie gewohnt. Betroffen ist unter anderem RealVNC, bisher die Default-Lösung der Raspberry Pi Foundation. RealVNC verspricht etwas vage, im Verlauf des Jahres 2024 eine Wayland-kompatible Version ihrer Software zu veröffentlichen. An dieser Stelle erkläre ich Ihnen, was Sie tun können, wenn Sie nicht solange warten möchten.

Xorg versus Wayland

Das X Window System und der Xorg-Server bilden das traditionelle Grafiksystem von Linux. Es basiert auf einem Client/Server-Modell und hat sich jahrzehntelang bewährt. Allerdings ist der Xorg-Server mit vielen Altlasten und Sicherheitsproblemen verbunden. Die Software wird schon seit mehrere Jahren nicht mehr weiterentwickelt und kaum noch aktiv gewartet. Seine Zeit läuft ab.

Der Nachfolger von Xorg heißt Wayland ist dagegen »nur« ein neues Protokoll für die Kommunikation zwischen dem Wayland Compositor (einem Display-Server) und den Anwendungsprogrammen (Clients). Wayland bricht mit dem X Window System und verspricht ein System, das schlanker, sicherer und effizienter ist. Wayland gehört die Zukunft.

Zwar sind mittlerweile viele Programme Wayland-kompatibel, aber leider nicht alle. Besonders große Probleme gibt es bei Programmen, die den Bildschirminhalt auslesen wollen, also Tools für Screenshots, Screencasts, Screen Sharing und Remote Desktop. Derartige Funktionen sind auch unter Wayland möglich, müssen aber vollständig neu implementiert werden.

Aktuelles Grafiksystem ermitteln

Ob Ihr Raspberry Pi Wayland oder Xorg als Grafiksystem verwendet, stellen Sie am einfachsten mit einem Kommando im Terminal fest:

echo $XDG_SESSION_TYPE
  wayland

Im Desktop-Betrieb lauten die möglichen Antworten wayland oder x11. In einer SSH-Session im Textmodus lautet das Ergebnis dagegen tty.

Lösung 1: Xorg statt Wayland verwenden

Die bei weitem einfachste Lösung besteht darin, das Grafiksystem von Wayland zurück auf Xorg umzustellen. Dazu führen Sie in einem Terminal-Fenster sudo raspi-config aus und wählen zuerst den Menüpunkt Advanced Options, dann Wayland. Jetzt können Sie sich zwischen dem X11 Backend und dem Wayland Backend entscheiden. Gleichzeitig ändert sich auch der Window Manager (Openbox versus Wayfire). Optisch ergeben sich daraus aber nur geringe Unterschiede.

Die Einstellung wird in der Datei /etc/lightdm/lightdm.conf gespeichert:

# in der Datei /etc/lightdm/lightdm.conf
...
# für Wayland:
user-session=LXDE-pi-wayfire
# oder für X:
user-session=LXDE-pi-x

Die Umstellung des Grafiksystems wird erst nach einem Neustart wirksam. Die meisten Remote-Desktop-Tools inklusive RealVNC sollte nun wieder wie gewohnt funktionieren. Der RealVNC-Server ist standardmäßig installiert. Die Aktivierung kann aber nicht über das Raspberry-Pi-Konfigurationsprogramm erfolgen. Dessen VNC-Option gilt nur für wayvnc und muss deaktiviert (!) sein, sonst kommt es zu einem Port-Konflikt. Den RealVNC-Dienst aktivieren Sie anschließend wie folgt:

sudo systemctl enable --now vncserver-x11-serviced

Ein VNC-Icon im Panel zeigt an, dass der Start funktioniert hat, und gibt Aufschluss darüber, ob gerade eine Verbindung aktiv ist.

Allerdings gibt es auch hier eine Einschränkung: Der RealVNC-Server funktioniert nur in der 64-Bit-Version von Raspberry Pi OS Bookworm, nicht aber mit der 32-Bit-Version. Dieses Problem soll aber in naher Zukunft behoben werden.

Lösung 2: wayvnc

Wenn Sie bei Wayland bleiben, steht das neue Programm wayvnc zur Verfügung. Sie aktivieren es am einfachsten mit dem Programm Raspberry Pi-Konfiguration im Dialogblatt Schnittstellen, Option VNC.

Aktivierung des VNC-Servers im »Raspberry Pi-Konfigurationsprogramm«

Daraus resultiert die folgende Konfigurationsdatei /etc/xdg/autostart/wayvnc.desktop:

[Desktop Entry]
Type=Application
Name=wayvnc
Comment=Start wayvnc
NoDisplay=true
Exec=/usr/bin/wayvnc --render-cursor --keyboard=de
OnlyShowIn=wayfire

Jetzt brauchen Sie auf Ihrem Client-Rechner (auf dem Rechner, mit dem Sie Ihren Raspberry Pi steuern möchten), einen zu wayvnc kompatiblen VNC-Client. Der Raspberry-Pi-Blog empfiehlt das Programm vncviewer des Projekts TigerVNC. Die meisten Linux-Distributionen stellen ein entsprechendes Paket zur Verfügung. Für Windows und macOS (Intel) finden Sie hier Downloads.

Hier läuft der TigerVNC-Client auf meinem Notebook mit ArchLinux und ermöglicht die Fernsteuerung des Raspberry-Pi-Desktops

Bei meinen Tests unter Windows ist der Verbindungsaufbau mit dem Programm Remotedesktopverbindung gescheitert. Mit dem vncviewer von TigerVNC hat es dann aber funktioniert.

Sofern der Raspberry Pi mit einem eigenen Monitor verbunden ist, gilt für den Remote Desktop dieselbe Bildschirmauflösung. Wenn der Raspberry Pi dagegen »headless« läuft, können Sie die gewünschte Auflösung mit sudo raspi-config, Display Options, VNC Resolution einstellen (maximal 1920×1080, erfordert einen Reboot).

Quellen/Links

❌