Linux, Raspberry Pi

Raspberry Pi OS Bullseye

14 Kommentare

Die Raspberry Pi Foundation hat eine neue Raspberry-Pi-OS-Version auf der Basis von Debian Bullseye freigegeben. Damit ändert sich Einiges: Zum einen natürlich eine Menge Versionsnummern dank des modernisierten Debian-Unterbaus, zum anderen aber auch durchaus wichtige technische Details. Z.B. verwendet Rasbperry Pi OS nun standardmäßig GTK3 und den Displaymanager Mutter — zumindest auf Rechnern mit 2 GByte. Aber der Reihe nach …

Update 7.12.2021: Die alte Raspberry-Pi-OS-Version (Buster) wird bis auf Weiteres mit Updates versorgt und erhält die Bezeichnung Legacy. Damit wird niemand zum Update auf die neue Version (Bullseye) gezwungen. Mehr Details können Sie im Blog von raspberrypi.com nachlesen.

Der PIXEL-Desktop von Raspberry Pi OS

Desktop

Auf dem Desktop gibt es nur wenige optische Änderungen:

  • Hinweise (Notifications) werden jetzt am rechten Bildschirmrand angezeigt. Diese Funktion kann bei Bedarf deaktiviert werden. Dazu öffnen Sie im Panel das Kontextmenü und führen Leisten-Einstellungen / Erscheinungsbild aus.

  • Zu den neuen Notifications zählt auch der Hinweis auf anstehende Updates. Ein Klick auf den Hinweis öffnet einen neuen, grafischen Update-Manager.

  • Im Dateimanager gibt es nur mehr zwei Darstellungsmodis: die Icon- und die Listenansicht.

Raspberry Pi OS hat jetzt einen grafischen Update-Dialog

Grafiksystem und Gtk

Der erste Eindruck täuscht aber. Hinter den Kulissen hat sich wesentlich mehr verändert als an der Oberfläche:

  • Für die Aktivierung des richtigen Grafikmodus ist jetzt der Kernel zuständig (Kernel Mode Setting, KMS). Dabei kommen offizielle Funktionen des Kernels zum Einsatz, nicht mehr wie bisher Raspberry-Pi-spezifische Funktionen, deren Code nicht öffentlich war (Quelle raspberrypi.com).

  • Raspberry Pi OS verwendet nun standardmäßig GTK3-Bibliotheken (bisher GTK2). Das vereinfacht die Realisierung optischer Effekte (z.B. abgerundeter Fensterecken). Viel wichtiger ist aber: GTK2 ist eine veraltete, nicht mehr aktiv gewartete Bibliothek. Immer mehr moderne Programme setzen GTK3 voraus. Insofern war der Umstieg auf GTK3 überfällig.

  • Auf Raspberry Pis mit zumindest 2 GByte RAM kommt der Fenstermanager Mutter zum Einsatz (bisher openbox). Auch hier gilt: Mutter ist moderner, zukunftssicherer. Bie Raspberry Pi Organisation bezeichnet den Umstieg auf Mutter als den ersten Schritt hin zur Ablöse von X durch Wayland. Einen konkreten Zeitplan für den Wechsel zu Wayland gibt es allerdings noch nicht, und es ist unklar, ob dieser überhaupt möglich ist. Selbst Mutter braucht so viel RAM, dass es nur auf großzügig mit RAM ausgestatteten Geräten zum Einsatz kommt.

  • RDP zickt: In der Vergangenheit reichte es aus, xrdp zu installieren, damit man sich mit Remotedesktopverbindung oder einem anderen RDP-Client am Raspberry Pi anzumelden. Gleich aus mehreren Gründen funktioniert das mittlerweile nicht mehr. Abhilfe: Richten Sie einen weiteren Benutzer ein und melden Sie sich damit an (statt mit pi). Mehr Details: https://pi-buch.info/aerger-mit-rdp

Kamera-Software

In bisherigen Raspberry-Pi-OS-Versionen waren proprietäre Software-Treiber und die Programme raspistill und raspivid zuständig, um Fotos bzw. Videos von der Kamera aufzunehmen. Mit dem neuen Raspberry Pi OS wird die Kamera dagegen über die libcamera-Treiber des Kernels angesprochen. Dass im Zuge dieser Umstellung raspistill und raspivid einfach eliminiert wurden, wird viele Scripts vor Kompatibilitätsprobleme stellen. Ja, es gibt mit libcamera-still und libcamera-vid neue Kommandos, diese haben aber komplett andere Optionen. Dokumentation dazu finden Sie hier:

https://www.raspberrypi.com/documentation/accessories/camera.html#libcamera-and-libcamera-apps

Aus dem Konfigurationsprogramm ist die Option zur Kamerakonfiguration verschwunden. Dafür enthält /boot/config.txt jetzt den Parameter camera_auto_detect=1, der sich um die automatische Treiberkonfiguration kümmern soll. Tests zur Nutzung der Kamerafunktionen reiche ich später in einem eigenen Artikel nach, sobald ein neues Kameramodul bei mir eintrifft. Das alte hat überraschend seinen Geist aufgegeben.

Update 11.11.2021: Mittlerweile habe ich auch die neuen libcamera-Tools kurz dokumentiert:

https://pi-buch.info/fotos-und-videos-mit-den-libcamera-tools-aufnehmen

Versionsnummern

Viel getan hat sich bei den Versionsnummern des Software-Stacks. Die wichtigste Änderung für viele Raspberry-Pi-Anwender betrifft Python: Erstmals steht die veraltete Version 2 nicht mehr zur Verfügung. Das Kommando python startet nun Python 3.9 statt Python 2.7. Es ist zu befürchten, dass das bei vielen alten Programmen/Bibliotheken zu Problemen führt. Wirklich überrascht sollte aber keiner sein — vor dem Ende von Python 2 wurde ein Jahrzehnt lange gewarnt.

Basis             Desktop              Programmierung   Server
---------------   ------------------   --------------   --------------
Kernel     5.10   Chromium        92   bash       5.1   Apache     2.4
glibc      2.31   Gimp          2.10   gcc       10.2   CUPS       2.3
X-Server   1.20   LibreOffice    7.0   Java        11   MariaDB   10.5
Mesa       20.3   LXDE            11   PHP        7.4   OpenSSH    8.4
Systemd     247   VLC            3.0   Python     3.9   Samba     4.13

Die »Black-Screen-Edition«?

Ich hatte bei meinen Tests massive Probleme mit meinen Monitoren. Immer wieder passierte es, dass meine Monitore nach einer kurzen Darstellung des Raspberry-Pi-Logos einfach schwarz blieben. In allen Fällen lief der Raspberry Pi, d.h. eine SSH-Verbindung war möglich. Die Monitore erhielten offenbar auch ein Signal, d.h. sie wechselten nicht wie sonst automatisch in den Stand-by-Modus oder schalteten sich aus.

Für meine Tests habe ich einen Pi 4B der ersten Generation (1 GB RAM) sowie ein Modell 400 verwendet. Als Monitore kamen ein moderner LG-4k-Monitor (Modell 27UL850-W) sowie ein uralter Benq-Monitor (G2400-WT) zum Einsatz.

Dass während des Bootprozesses keine Meldungen des Kernels bzw. von systemd angezeigt werden, ist beabsichtigt, auch wenn ich mir nicht sicher bin, dass das eine gute Idee ist. Abhilfe: Entfernen Sie quiet splash aus der Datei /boot/cmdline.txt. Eine echte Lösung des Problems ist dies aber nicht: Während der ersten Sekunden sind nun diverse Meldungen sichtbar. Danach wird der Monitor schwarz. Eine Weile später (nach ca. 10 bis 15 Sekunden) erscheint der Desktop — oder auch nicht.

Manchmal half es, den Monitor einfach kurz aus und wieder ein zu schalten.

Sicher ist, dass die Probleme mit dem neuen Raspberry Pi OS zu tun haben; ich habe die gleiche Hardware auch schon mit der vorigen Version des Betriebssystems verwendet und hatte nie derartige Probleme. Trotzdem bleibt unklar, ob die Fehler nur spezifisch bei meiner Hardware auftreten oder ob auch andere Raspberry-Pi-Anwender betroffen sind. Ein diesbezüglicher Twitter-Post erhielt kaum Resonanz.

Problematisch ist in diesem Zusammenhang auch die Veränderung der Bildschirmauflösung: Bei Systemen mit 2 GB RAM oder mehr (also Gtk3) wird die Änderung erst nach einem Reboot wirksam. Das ist nicht nur unpraktisch, sondern auch äußerst problematisch, wenn die gewählte Auflösung am Bildschirm nicht angezeigt werden kann. Mit Pech bleibt der Bildschirm dann ganz einfach schwarz — ohne eine einfache Möglichkeit, die Änderung der Auflösung rückgängig zu machen. Definitiv nicht benutzerfreundlich!

Wenn »Mutter« als Window Manager läuft (auf allen Pis mit 2 GByte RAM oder mehr), erfordert der Wechsel der Bildschirmauflösung einen Neustart mit ungewissem Ausgang

Abhilfe schafft dann nur die Veränderung der Datei /home/pi/.config/monitors.xml via SSH oder auf einem zweiten Linux-Rechner. (Unter macOS oder Windows können Sie auf direkt auf der SD-Karte auf die Partition mit dem Linux-Dateisystem ja gar nicht zugreifen.)

Ich kann mich nicht erinnern, wann ich zuletzt so viel Zeit damit vergeudet habe, um einfach nur ein Bild am Monitor zu sehen. Meine Vermutung ist, dass der ganze Ärger mit dem neuen Kernel Mode Switching (KMS) zu tun hat, das in Raspberry Pi OS Bullseye erstmals aktiv ist und möglicherweise noch nicht in allen Fällen perfekt funktioniert. (Grundsätzlich ist KMS natürlich eine gute Sache: Es ermöglicht einen flicker-freien Bootprozess und erleichtert die Nutzung der Grafikfunktionen ohne Closed-Source-Treiber.)

Sonstiges

  • Bei RP-Modellen ab 2 GByte RAM ist eine Drehung der Bildschirmdarstellung nicht mehr möglich (z.B. für einen Monitor in Portrait-Modus). Laut der Diskussion auf raspberrypi.com liegt das Problem beim Window Manager Mutter.

  • Auch die neue Raspberry-Pi-OS-Version verbleibt in der 32-Bit-Welt. Eine 64-Bit-Version wäre möglich, aber die Entwickler sehen keine großen Performance-Vorteile. Außerdem würde eine 64-Bit-Version zwei unterschiedliche Betriebssystemversionen je nach CPU erfordern. (Nur die aktuellen Raspberry-Pi-Modelle haben eine 64-Bit-CPU.) Wer also Docker oder ähnliche Funktionen am Raspberry Pi mit einem 64-Bit-Stack ausführen muss, ist mit alternativen Betriebssystemen wie Ubuntu besser bedient.

  • Die CPUs auf aktuelle Raspberry-Pi-Modelle mit 2, 4 oder 8 GByte erreichen nun automatisch eine Taktfrequenz von 1,8 GHz. Voraussetzung dafür ist die auf den neuen Platinen integrierte Switch-mode Power Supply (Quelle: raspberrypi.com).

  • Die Raspberry Pi Foundation rät dringend davon ab, ein Update von Raspberry Pi OS Buster auf die neue Bullseye-Edition zu versuchen — und ich schließe mich diesem Ratschlag an. Grundsätzlich ist so ein Update relativ einfach möglich, in dem Sie in /etc/atp/sources.list jeweils buster durch bullseye ersetzen und dann ein Update aller Pakete durchführen. (So ein Update ist zeitaufwändig — rechnen Sie zumindest mit 30 Minuten, während der Sie immer wieder Rückfragen beantworten müssen.) Aufgrund der vielen grundlegenden Änderungen zwischen den beiden Versionen sind Kompatibilitätsprobleme zu erwarten. Deswegen ist es sicherlich vernünftig, ein Backup aller relevanten Dateien durchzuführen und dann (idealerweise auf eine zweite SD-Karte) die neue Version von Raspberry Pi OS zu installieren.

Fazit

Viele technische Änderungen, die zusammen mit dem Umstieg auf die neue Basis Debian Bullseye durchgeführt wurden, sind aus Open-Source-Sicht erfreulich: Es kommen mehr Open-Source-Treiber als bisher zum Einsatz, Raspberry Pi OS ist näher an Linux-Standards und es gibt sogar einen (vager) Ausblick Richtung Wayland.

Zumindest bei meinen Tests sind allerdings auch erhebliche Probleme aufgetreten. (Ich habe natürlich auch andere Tests gelesen. Deren Autoren hatten offenbar weniger Probleme. Vielleicht liegt es an mir oder an meiner Hardware?)

Wie auch immer: Sie machen vermutlich nichts verkehrt, wenn Sie noch ein, zwei Monate abwarten, bevor Sie auf das neue Raspberry Pi OS Bullseye umsteigen.

Quellen, Links

Download der aktuellen Version (Bullseye) und der alten Legacy-Version (Buster):

Beschreibung von libcamera-Kommandos:

14 Gedanken zu „Raspberry Pi OS Bullseye“

  1. Hier ist wohl ein kleiner Gedankenfehler im Satz:
    „Wie auch immer: Sie machen vermutlich nichts verkehrt, wenn Sie noch ein, zwei Monate mit dem Umstieg auf das neue Raspberry Pi OS Bullseye umsteigen, sondern noch ein, zwei Monate abwarten.“

  2. Ich verwende den Raspberry im EDV-Unterricht an der HTL. Das neue „bullseye“ hat derzeit leider für meinen Einsatzbereich zwei Showstopper:

    Beim Einloggen via xrdp / Remotedesktopverbindung übers Netz bekommt der User „pi“ nur einen türkisen Bildhintergrund zu sehen, sonst nichts. Ich habe dann einen zweiten Account „testuser“ erstellt – mit diesem läuft alles wie gewohnt. Gibt es einen besseren Workaround?

    Die schon seit Jahren als „deprecated“ gekennzeichnete, aber trotzdem sehr gut für den Unterricht geeignete wiringPi-Libary (Arduino lässt grüßen) ist jetzt endgültig aus der Distribution hinausgeflogen. Wirklich brauchbaren Ersatz habe ich unter den deb-Packages nicht gefunden – entweder zu umständlich oder nur mit „sudo“ verwendbar. lgpio setzt auf dem neuen gpiochip-Interface auf und macht einen guten Eindruck. Sie muss aber aus den Quellen manuell gebaut und installiert werden. Offensichtlich legen die Entwickler den Schwerpunkt auf Python. Auch auf eine schöne C++-GPIO-Library warte ich schon seit Jahren.

    1. xrp: Ich hab’s noch nicht selbst getestet, aber von diesem Workaround habe ich auf anderen Seiten auch schon gelesen.

      wiringPi: Vielleicht https://airspayce.com/mikem/bcm2835/ ? Ist nicht großartig, aber für einfache Aufgabenstellungen OK. Aber natürlich nur C, nicht C++.

      1. Zum xrdp-Bug:

        1) In raspi-config muss das Auto-Login in den Desktop ausgeschaltet sein, sonst startet offenbar der Desktop des users „pi“, auch wenn kein Monitor angeschlossen ist. Bei xrdp kann aber ein user immer nur einmal eingeloggt sein.

        2)Der Start der Desktopumgebung erfolgt durch das Skript /usr/bin/startlxde-pi. (Ausschnitt:)

        TOTAL_MEM=$(vcgencmd get_config total_mem | cut -d= -f2)
VNC=$(systemctl status vncserver-x11-serviced | grep -w active)
if [ $TOTAL_MEM -ge 2048 ] && [ -f /usr/bin/mutter ] && [ -z "$VNC" ] ; then
....
    exec /usr/bin/lxsession -s LXDE-pi -e LXDE
else
....
  exec /usr/bin/lxsession -s LXDE-pi -e LXDE -w openbox-lxde-pi

        Wenn alle drei Bedingungen der Zeile mit dem „if“ erfüllt sind, startet lxsession ohne die Option „-w openbox-lxde-pi“ (der Windowmanager zur Fensterdekoration ). Warum bekommt aber jeder user, der anders als „pi“ heißt, die Openbox? Ganz einfach: „vcgencmd“ liefert nur für „pi“ und „root“ eine numerische Antwort, sonst kommt eine Fehlermeldung. Die erste Bedingung ist dann nicht erfüllt.

        Der Seiteneffekt mit den Zugriffsrechten von „vcgencmd“ war wohl nicht beabsichtigt. Als Workaround würde sich anbieten, den VNC-Server zu starten, entweder mit systemctl enable… oder aus raspi-config heraus. Dann ist die letzte Bedingung im „if“ nicht leer und openbox wird ebenfalls gestartet. (Interessanterweise war es früher immer so, dass xrdp nicht funktionierte, wenn der VNC-Server lief.)

        Das lästige Popup zur Passwortabfrage zum Update der Repositories bei jedem Einloggen habe ich übrigens mit „apt remove lxplug-updater“ erledigt. So wird die Remotedesktopverbindung auch wieder brauchbar.

        2. Vielen Dank. Ich mache schon den ganzen Tag an diesem Problem rum. Dank der Beschreibung weiß ich jetzt endlich, wo ich ansetzen muss. Hat mich fast in den Wahnsinn getrieben. Bei mir war kein türkiser Hintergrund zu sehen sondern die Programmfenster waren ohne Titelleiste und Rahmen und haben sich oben links im Eck befunden.

  3. Hallo,
    also sie sind zwar nicht offiziell, vermutlich eher Betastatus, aber es gibt sehr wohl 64-bit-Versionen von RaspiOS:
    https://downloads.raspberrypi.org/raspios_arm64/images/
    Habe bei mehreren Pi4b damit keine Probleme, weder in der Buster, noch in der Bullseye-Version.

    Über den Verzeichnisbaum sind auch alte Images zu finden, auch für alle Versionen vom 32bit-RaspiOS.

    Auch konnte ich mit der Bullseye-Version, egal ob 32- oder 64-bit keine gravierenden Monitorprobleme feststellen und wenn doch, so waren diese durch ein HDMI-Kabel verursacht, das per Adapterstück an den Pi4 angeschlossen wurde, es trat dann kurzes „Flackern“ des Bildschirms auf, also einen sekundenweisen Bildausfall, dann aber wieder einwandfreie Anzeige. In diesem Falle der 4k-Auflösung geschuldet. Bei originalem Micro-HDMI auf HDMI treten hier keine Probleme auf.
    Bei einem FHD-Monitor klappt es auch mit dem Adapterstück ohne Probleme, es wird ja aber auch nur ein Viertel der Videobandbreite benötigt.

  4. Ich habe mein raspbian 64-bit auf meinem iMac als ISO gesichert, danach habe ich ebenfalls auf einem Duplikat-Stick einen Wechsel zu „bullseye“ gestartet. Es war gelinde gesagt eine Katastrophe, nicht einmal meine E-Mail-Adressen in Thunderbird waren noch vorhanden, mein „numlockx“ funktionierte nicht mehr, „Kodi“ ist noch nicht vorhanden, „Angry-IP-Scan“ Fehlanzeige, lediglich „pihole“ funktionierte noch, wenigstens etwas (die Aufzählung ist unvollständig).
    Jetzt kommt wieder mein alter Ursprungs-Stick zum Einsatz, vielleicht probiere ich es in 3 Monaten noch einmal.
    So lange wie „bullseye“ noch in den Kinderschuhen steckt, sollten doch zumindest die „Buster-Versionen“ über den Imager noch angeboten werden, aber wer will schon ein lauffähiges „raspbian-buster“ wenn es doch in „bullseye“ so viel zu probieren gibt?

  5. Habe mit aktuellem Bullseye folgende Probleme festgestellt:
    + Codelite installierbar, stürzt aber bei Programmstart ab
    + Repo Bullseye (Werkzeug synaptic):
    + + kein Stanis Python Editor installierbar
    + + kein Boa Constructor installierbar
    + + kein Winpdb installierbar
    + + für Python 2.7 kein Modul für die serielle Schnittstelle verfügbar
    + + für Python 2.7 kein wx und kein qwt verfügbar
    Mein Fazit: ich warte jetzt erst mal weitere Upgrades bei Bullseye ab und setze weiterhin auf den Vorgänger Buster
    + für Python 2.7 kein Modul für GPIO verfügbar

    1. Na ja, bei Python 2.7 ist das Ende nun einmal erreicht. Das kann man nicht Raspberry Pi OS ankreiden. Die Python-Community kommuniziert das seit einem Jahrzehnt, und das Raspberry-Pi-Umfeld hat diesbezüglich den Nutzungszeitraum ohnedies schon bis ans Limit erstreckt. Python 2.7 ist einfach tot.

  6. Hallo,
    kann es sein das es einen Fehler mit den .desktop Autostart gibt?
    Ich habe am meinem Infoboard einen Botton um die Seiten dann durchzublättern. Gestartet wurde mit Buster einwandfrei das Python Skript. Bei Bullseye führt das zu keinem Erfolg. Der manuelle Start ist möglich und funktioniert dann tadellos.
    Hat jemand da schon erfahrungen?

  7. (Leserzuschrift per Mail)

    Was mir gegenüber Buster am Meisten abgeht: Der Desktop-Pager. Soweit ich es verstanden habe, funktioniert der unter Mutter nicht mehr so, wie er soll. Man kann den Desktop-Pager nach wie vor in der Leiste aktivieren, das Problem ist einerseits, dass es kein Programm gibt, um Einstellungen vorzunehmen und andererseits spielt das System komplett verrückt, sobald man eine der 3 weiteren virtuellen Desktops aktiviert (es verschwindet beispielsweise einfach die Leiste und kommt dann erst nach einem Neustart wieder).

    Was das Problem mit dem schwarzen Monitorbild betrifft, ist das bei mir noch nicht vorgekommen. Dafür habe ich das (eher geringe) Problem, dass beim Scrollen von Webseiten im Firefox immer wieder mal Darstellungsfehler auftreten. Nicht tragisch, aber doch immer wieder ärgerlich, weil man dann erst wieder mühsam zurück- und dann wieder vor-scrollen muss, damit der Effekt verschwindet. Und dass der Monitor auch bei langer Inaktivität des Benutzers nicht in den StandBy-Modus geschaltet wird, ist mir auch schon unangenehm aufgefallen.

    Sie sehen, die Probleme treten nicht nur bei Ihnen auf, da scheint tatsächlich noch nicht alles so wirklich rund zu laufen. Ich habe übrigens einen RPi 400 …

    Trotzdem ist für mich der Vorteil dieser neuen Version größer als die Nachteile. Schon alleine, dass sowohl der Firefox als auch Thunderbird in deutlich aktuelleren Versionen zur Verfügung stehen, macht den Umstieg sinnvoll, finde ich. Und dazu noch eine Frage: Haben Sie eine Vermutung, warum am RPi mit dem Firefox etliche Webseiten nur in der Mobil-Version angezeigt werden? Beispiele: Google und Amazon sind die zwei bekanntesten Seiten. Anders als auf dem Android-Mobiltelefon kann man hier ja keine entsprechende Einstellung vornehmen …

Kommentare sind geschlossen.