Festplatten unterliegen einem natürlichen Verschleiß. Mit der Zeit können sogenannte Bad Sektoren entstehen – fehlerhafte Speicherbereiche, die nicht mehr zuverlässig gelesen oder beschrieben werden können. Eine regelmäßige Überprüfung kann helfen, Datenverlust frühzeitig zu erkennen und entsprechende Maßnahmen einzuleiten.
Was sind Bad Sektoren?
Bad Sektoren sind physisch oder logisch beschädigte Bereiche auf einem Datenträger. Physische Defekte entstehen durch Abnutzung, mechanische Schäden oder Produktionsfehler. Logische Bad Sektoren hingegen resultieren meist aus Softwareproblemen oder Stromausfällen und lassen sich mitunter korrigieren.
Analysewerkzeuge unter Linux
Linux bietet verschiedene Werkzeuge zur Analyse und Erkennung defekter Sektoren. Eines der bekanntesten Tools ist badblocks.
Ein einfacher Check lässt sich wie folgt durchführen:
sudo badblocks -vsn /dev/sdX
Ersetzt man dabei /dev/sdX durch das entsprechende Gerät, erhält man einen Überblick über den Zustand der Sektoren. Hierbei sucht badblocks gezielt nach defekten Blöcken der Festplatte.
Dabei sollte beachtet werden, dass dieser Vorgang – je nach Größe des Datenträgers – einige Zeit in Anspruch nehmen kann.
Fazit
Die regelmäßige Analyse auf Bad Sektoren ist ein wichtiger Bestandteil der Systempflege. Frühzeitig erkannte Fehler ermöglichen rechtzeitige Backups und gegebenenfalls den Austausch der betroffenen Hardware. Open-Source-Werkzeuge wie badblocks bieten unter Linux zuverlässige Möglichkeiten zur Diagnose – ganz ohne proprietäre Software.
Wer gerne das Image des offiziellen Raspberry Pi OS an seine Bedürfnisse anpassen möchte, kann sich dabei ab sofort vom Werkzeug rpi-image-gen helfen lassen.
Raspberry Pi OS »Bookworm« verwendet bekanntlich auf den Modellen 4* und 5 standardmäßig Wayland. Dabei kam als sogenannter »Compositor« das Programm Wayfire zum Einsatz. (Der Compositor ist unter anderem dafür zuständig, Fenster am Bildschirm anzuzeigen und mit einem geeigneten Fensterrahmen zu dekorieren.)
Mit dem neuesten Update von Raspberry Pi OS ändern sich nun zwei Dinge:
Anstelle von Wayfire kommt ein anderer Compositor zum Einsatz, und zwar labwc (GitHub).
Wayland kommt auf allen Raspberry Pis zum Einsatz, auch auf älteren Modellen.
Wenn Sie auf Ihrem Raspberry Pi das nächste Update durchführen, werden Sie bei nächster Gelegenheit gefragt, ob Sie auf labwc umstellen möchten. Aktuell werden Sie keinen großen Unterschied feststellen — labwc sollte genau wie wayfire funktionieren (vielleicht ein klein wenig effizienter). Langfristig haben Sie keine große Wahl: Die Raspberry Pi Foundation hat angekündigt, dass sie sich in Zukunft auf labwc konzentrieren und wayfire nicht weiter pflegen wird. Nach der Auswahl wird Ihr Raspberry Pi sofort neu gestartet.
Sie haben die Wahl: Wollen Sie X verwenden oder Wayland mit labwc
Alternativ können Sie die Einstellung auch mit sudo raspi-config durchführen. Unter Advanced Options / Wayland haben Sie die Wahl zwischen allen drei Optionen.
Einstellung des Grafiksystems in raspi-config
Bei meinen Tests stand nach dem Umstieg auf labwc nur noch das US-Tastatur-Layout zur Verfügung. Eine Neueinstellung in Raspberry Pi Configuration löste dieses Problem. Auch die Monitor-Konfiguration musste ich wiederholen. Dabei kommt auch ein neues Tool zum Einsatz(raindrop statt bisher arandr), das optisch aber nicht von seinem Vorgänger zu unterscheiden ist.
Ansonsten habe ich bei meinen Tests keinen großen Unterschied festgestellt. Alles funktioniert wie bisher.
Wenn es um den Raspberry Pi und DynDNS geht, empfehle ich gerne, wie im Artikel „Nextcloud auf dem RasPi – Teil 4“ beschrieben, als DynDNS-Anbieter den Dienst dnsHome.de. Privatanwender kommen hier in den Genuss, eine kostenlose DynDNS für kleinere Projekte nutzen zu können. Dieser Dienst arbeitet einwandfrei und sorgt dafür, dass u. a. eigene Cloud-Server nach der Zwangstrennung des Internetanbieters stets erreichbar bleiben. Durch den ständigen Abruf der öffentlichen IP und der Übermittlung bei Änderung dieser an den DynDNS-Anbieter wird sichergestellt, dass der Server über eine Subdomain immer erreichbar bleibt.
Darstellung DynDNS. Quelle: Wikipedia
Nun kam es aber bei einer von mir aufgesetzten Installation in einem Telekom-Netz vor, dass die von dnsHome empfohlene Konfiguration
# Configuration file for ddclient generated by debconf
#
# /etc/ddclient.conf
protocol=dyndns2
ssl=yes # Erst ab ddclient Version 3.7 möglich, bitte prüfen
daemon=3600
use=web, web=ip.dnshome.de
server=www.dnshome.de
login=SUBDOMAIN.DOMAIN.TLD
password=PASSWORT
SUBDOMAIN.DOMAIN.TLD
des ddclients nicht funktionierte. Wo lag das Problem? Der Eintrag
web=ip.dnshome.de
ermittelt in diesem Netz nicht wie gewünscht die IPv4-, sondern die IPv6-Adresse und leitet diese an dnsHome weiter. Somit wurde die Verbindung der Subdomain zum Server gestört. Natürlich gibt es auch hierfür eine einfache Lösung. Durch den Austausch des zuvor erwähnten Eintrags durch
Bereits zum zweiten Mal im noch jungen Jahr erhöht die Raspberry Pi Foundation die Preise für die Modellreihen 4 und 5. Szene-Kenner Jeff Geerling sieht das Ende der Hobbyistenszene rund um die beliebten SBCs.
Heute möchte ich kurz erzählen, welche Schwierigkeiten ich beim Upgrade auf Nextcloud 31 Hub 10 zu bewältigen hatte.
Das Upgrade auf Nextcloud 31 war in meinem Fall mal wieder von einigen Hürden umstellt. Meine ersten Versuche, die Nextcloud auf Version 31.0.0 Stable zu heben, waren zwar von Erfolg gekrönt, jedoch sperrte ich damit meinen WebAuthn-Zugang zu meinen Daten. Weitere Versuche bei den Neuerscheinungen 31.0.1 und 31.0.2 liefen ebenfalls ins Leere.
Nun, mit Version 31.0.3, wurde das WebAuthn-Problem jedoch gefixt. Nach der Reparatur der Datenbank und dem Einspielen fehlender Indizes blieb noch eine zu beseitigende Fehlermeldung übrig. Es handelt sich um ein falsches Zeilenformat in der Datenbank.
Dieser Konflikt kann aber schnell gelöst werden, indem man ein Skript mit folgendem Inhalt erstellt und dieses im Nachgang im Home-Verzeichnis ausführt. Dazu wechselt man in dieses:
cd ~/
Dann öffnet man den Editor:
sudo nano database.sh
fügt folgenden Inhalt ein und speichert mit Ctrl + o:
#!/bin/bash
# Prompt for database credentials
read -p "Enter Database Name: " DB_NAME
read -p "Enter Username: " DB_USER
read -s -p "Enter Password: " DB_PASS
echo
# Generate ALTER TABLE statements and execute them
mysql -u "$DB_USER" -p"$DB_PASS" -e "
SELECT CONCAT('ALTER TABLE `', TABLE_NAME, '` ROW_FORMAT=DYNAMIC;')
FROM INFORMATION_SCHEMA.TABLES
WHERE TABLE_SCHEMA = '$DB_NAME'
AND ENGINE = 'InnoDB';
" -B -N | while read -r sql; do
mysql -u "$DB_USER" -p"$DB_PASS" -e "$sql" "$DB_NAME"
done
Mit Ctrl + x verlässt man den Editor wieder. Nun wird das Skript mit
sudo chmod +x database.sh
ausführbar gemacht und mit
sudo ./database.sh
gestartet. Während der Ausführung werden Datenbankname, Benutzername und Passwort abgefragt. Sind die Eingaben richtig, sind die Datenbank am Ende gefixt und die Fehlermeldung verschwunden.
Nachdem unsere Community-Cloud das vorab letzte Software-Upgrade und eine neue SSD erhalten hatte, wurde es nun Zeit auch die Hardware auf eine neue Stufe zu heben. Da wir der Meinung waren, dass hierzu ein Raspberry P4 4 Modell B mit 8GB völlig ausreicht, haben wir uns bewusst für dieses Gerät entschieden. Eingepackt in ein passiv gekühltes Metallgehäuse wird uns diese Kombination, so hoffe ich, die nächste Zeit zuverlässig begleiten.
Da ein Upgrade der installierten Software vom Raspberry Pi 3 auf den Raspberry Pi 4 wenig sinnvoll und auch fast unmöglich umzusetzen ist, war die Idee, die Datenbank und das Datenverzeichnis der Nextcloud in eine Neuinstallation (64-Bit) einzubinden.
Für den Wechsel auf 64-Bit hätte eigentlich parallel zum bestehenden System eine Neuinstallation auf dem erwähnten Raspberry Pi durchgeführt werden müssen. Hier konnte ich mir die Arbeit aber ein wenig erleichtern, indem ich die MicroSD meiner eigenen Cloud klonen konnte. Auf dem geklonten System waren so nur einige Anpassungen vorzunehmen, bevor das neue Gerät an Stelle des 32-Bit-Systems in Betrieb genommen werden konnte.
Aufnahme mit Wärmebildkamera (Raspberry Pi 4 – passive Kühlung)
Die aus dem Raspberry Pi 3 gesicherte Datenbank wurde in den Raspberry Pi 4 eingelesen und die Daten-SSD in die /etc/fstab eingebunden. Danach wurde der ddclient mit der DynDNS neu konfiguriert. Ein neues Zertifikat wurde erstellt und die automatische Upgrade-Routine hierzu angepasst. Zum Schluss mussten nur noch die Ports im Speedport-Router für die neue Hardware freigegeben werden.
Fazit
Der Aufwand hat sich in dem Sinne gelohnt, da dieses nun mittlerweile über fünfeinhalb Jahre existierende Projekt, zukunftssicher weiterbetrieben werden kann.
Im vorherigen Beitrag habe ich euch gezeigt wie ihr den Hauppauge WinTV-soloHD oder Hauppauge WinTV-dualHD unter Linux einrichtet. Hinweis: Für Raspberry Pi OS 10 „Buster“ gibt es derzeit (Stand: Januar 2021) keine eigenen Tvheadend...
Die im Oktober 2025 erschienene Neuauflage des Raspberry Pi OS, basierend auf Debian 13 „Trixie“, dürfte einige Nutzer überrascht haben. In den Medien wurde darüber nur wenig berichtet – auch an mir war die Veröffentlichung zunächst vorbeigegangen.
Trotzdem habe ich nicht gezögert, das neue System mithilfe des Raspberry Pi Imager auf eine microSD-Karte zu schreiben. Ziel war es wie gewohnt, eine sogenannte headless-Installation vorzubereiten – also ohne Monitor und Tastatur. Die weitere Einrichtung sollte anschließend bequem per SSH (Secure Shell) erfolgen.
Der Vorgang wurde auf einem Notebook mit Ubuntu 24.04 LTS und dem über die Paketverwaltung installierten Raspberry Pi Imager (Version 1.8.5) durchgeführt. Nach dem Flashen wurden die Karte in den Raspberry Pi eingesetzt und das System gestartet. Doch eine Verbindung per SSH war danach nicht möglich.
Ursache und Lösung
Die Ursache für dieses Verhalten war schnell gefunden: Raspberry Pi OS 13 erfordert für die korrekte Vorkonfiguration den Raspberry Pi Imager in Version 2.0 oder höher. Und genau hier beginnt das Problem – zumindest für Linux-Nutzer.
Während Windows-Nutzer den neuen Imager bereits komfortabel nutzen können, hinkt die Linux-Unterstützung deutlich hinterher. Bislang steht weder ein aktuelles .deb-Paket noch eine Snap-Version zur Verfügung. Das sorgt in der Linux-Community verständlicherweise für Kopfschütteln – gerade bei einem Projekt wie dem Raspberry Pi, das tief in der Open-Source-Welt verwurzelt ist.
AppImage als Ausweg
Glücklicherweise bietet der Entwickler ein AppImage des neuen Imagers an. Dieses lässt sich unter Ubuntu und anderen Distributionen unkompliziert starten – ganz ohne Installation. Damit ist es wie gewohnt möglich, WLAN-Zugangsdaten und SSH vor dem ersten Start zu konfigurieren.
Fazit
Wer Raspberry Pi OS 13 „Trixie“ headless nutzen möchte, sollte sicherstellen, dass der Imager in Version 2.0 oder neuer verwendet wird. Für Linux-Nutzer führt der Weg aktuell nur über das bereitgestellte AppImage. Es bleibt zu hoffen, dass die offizielle Paketunterstützung für Linux bald nachgereicht wird.
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:
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!
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:
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.
Die derzeitige Speicherkrise verschont auch den Raspberry Pi nicht. Die Preise ziehen zwischen 5 und 25 US-Dollar an. Neu ist ein RasPi 5 mit 1 GB RAM für 45 USD.
Weil Mike Schilli hoch über der Stadt wohnt und von Natur aus neugierig ist, schreibt er ein Go-Programm für den Raspberry Pi Zero, das neu auftauchende WLAN-Router erkennt und per SMS meldet.
Screen Sharing mit dem Raspberry Pi war schon immer ein fehleranfälliges Vergnügen. In der Vergangenheit hat die Raspberry Pi Foundation auf die proprietäre RealVNC-Software gesetzt. Zuletzt war RealVNC aber nicht Wayland-kompatibel. Die Alternative ist wayvnc, ein Wayland-kompatible VNC-Variante: Wie ich unter Remote Desktop und Raspberry Pi OS Bookworm schon berichtet habe, ist wayvnc aber nicht mit allen Remote-Clients kompatibel, insbesondere nicht mit Remotedesktopverbindung von Microsoft.
Anfang Mai 2024 hat die Raspberry Pi Foundation mit Raspberry Pi Connect eine eigene Lösung präsentiert. Ich habe das System ausprobiert. Um das Ergebnis gleich vorwegzunehmen: Bei meinen Tests hat alles bestens funktioniert, selbst dann, wenn auf beiden Seiten private Netzwerke mit Network Address Translation (NAT) im Spiel sind. Das Setup ist sehr einfach, als Client reicht ein Webbrowser. Geschwindigkeitswunder sind aber nicht zu erwarten, selbst im lokalen Netzwerk treten spürbare Verzögerungen auf.
Der Zugriff auf den Raspberry-Pi-Client erfolgt hier in einem Fenster des Webbrowsers Google Chrome unter macOS
Voraussetzungen
Raspberry Pi Connect setzt voraus, dass Sie die aktuelle Raspberry-Pi-Version »Bookworm« verwenden und dass der PIXEL Desktop in einer Wayland-Session läuft. Das schränkt die Modellauswahl auf 4B, 400 und 5 ein. Ob Ihr Desktop Wayland nutzt, überprüfen Sie am einfachsten im Terminal:
echo $XDG_SESSION_TYPE
wayland
Gegebenenfalls können Sie mit raspi-config zwischen Xorg und Wayland umschalten (Menüpunkt Advanced Options / Wayland).
Installation
Die Software-Installation verläuft denkbar einfach:
Nach der Installation erscheint ein neues Icon im Panel des PIXEL Desktops. Über dessen Menüeintrag Sign in gelangen Sie auf die Website https://connect.raspberrypi.com/sign-in. Dort müssen Sie eine Raspberry-Pi-ID einrichten. Die Eingabefelder sind auf ein Minimum beschränkt: E-Mail-Adresse, Passwort (2x) und Name. Fertig!
Bevor Sie Raspberry Pi Connect nutzen können, müssen Sie eine Raspberry Pi ID einrichten.
Fernzugriff
Um nun von einem anderen Rechner auf den PIXEL Desktop Ihres Raspberry Pis zuzugreifen, melden Sie sich dort ebenfalls auf der Website https://connect.raspberrypi.com/sign-in an. Dort werden alle registrierten Geräte aufgelistet. (Mit einer Raspberry-Pi-ID können als mehrere Raspberry Pis verknüpft werden.)
Remote-Verbindungsaufbau im Webbrowser
Praktische Erfahrungen
Bei meinen Tests hat Raspberry Pi Connect ausgezeichnet funktioniert. Der Verbindungsaufbau war problemlos. Der Desktop-Inhalt erscheint in einem neuen Browser-Fenster. Der Desktop-Inhalt wird automatisch auf die Fenstergröße skaliert. Die Bedienung ist denkbar simpel. Über zwei Buttons können Texte über die Zwischenablage kopiert bzw. eingefügt werden.
Raspberry Pi Connect testet beim Verbindungsaufbau, ob sich der Raspberry Pi und Ihr Client-Rechner (z.B. Ihr Notebook) im gleichen Netzwerk befinden. Wenn das der Fall ist, stellt der Client eine direkte Peer-to-Peer-Verbindung zum Raspberry Pi her. Nach dem Verbindungsaufbau fließen keine Daten mehr über den Raspberry-Pi-Connect-Server. Die Verbindungsgeschwindigkeit ist dann spürbar höher. Dennoch ist es empfehlenswert, die Bildschirmauflösung auf dem Raspberry Pi nicht höher einzustellen als notwendig.
Wenn sich Ihr Pi und Ihr Client-Rechner dagegen in unterschiedlichen (privaten) Netzwerken befinden, agiert ein Server der Raspberry Pi Foundation als Relay. Sowohl der Bildschirminhalt als auch alle Eingaben werden verschlüsselt nach Großbritannien und wieder zurück übertragen. Selbst wenn alle Geräte eine gute Internetverbindung haben, ist ein gewisser Lag unvermeidlich.
Details über die Art der Verbindung erfahren Sie, wenn Sie den Mauszeiger auf das Schloss-Icon im Screen-Sharing-Fenster bewegen.
Wenn Sie den Mauszeiger über das Schloss-Icon bewegen, erscheint ein Info-Text zum Status der Verbindung
Wenn die Remote-Desktop-Verbindung nicht im lokalen Netzwerk stattfindet, fließt der ganze Netzwerkverkehr über einen Relay-Server in Großbritannien. Dabei kommt das Protokoll Traversal Using Relays around NAT (kurz TURN) zum Einsatz. Die Daten werden TLS-verschlüsselt.
Der entscheidende Schwachpunkt des Systems besteht darin, dass es aktuell nur einen einzigen TURN-Server gibt. Je mehr gleichzeitige Remote-Desktop-Verbindungen aktiv sind, desto langsamer wird das Vergnügen … (Und besonders schnell ist es schon im Idealfall nicht.)
Fazit
Raspberry Pi Connect punktet vor allem durch seine Einfachheit.
Am Raspberry Pi reicht es aus, rpi-connect zu installieren.
Die Raspberry-Pi-ID kann rasch und unkompliziert eingerichtet werden.
Die Anwendung im Webbrowser funktioniert plattformübergreifend und einfach.
Allzu hohe Performance-Anforderungen sollten Sie nicht haben. Die Nachlaufzeiten bei Mausbewegungen und gar beim Verschieben eines Fensters sind beachtlich. Für administrative Arbeiten reicht die Geschwindigkeit aber absolut aus.
Schließlich bleibt abzuwarten, wie gut die Software skaliert. Aktuell befindet sich Raspberry Pi Connect noch in einem Probebetrieb. Soweit sich der Raspberry Pi und der Client-Rechner nicht im gleichen lokalen Netzwerk befinden, werden die Bildschirmdaten über einen Relay in Großbritannien geleitet. Aktuell gibt es genau einen derartigen Relay. Je mehr Anwender Raspberry Pi Connect gleichzeitig nutzen, desto langsamer wird es. Die Raspberry Pi Foundation lässt sich aktuell überhaupt offen, ob es den Relay-Betrieb dauerhaft kostenlos anbieten kann.
Die in den letzten Monaten gestiegenen Preise für Arbeitsspeicher wirken sich jetzt auch auf den Raspberry Pi aus: Einige Modelle kosten ab sofort bis zu 10 US-Dollar mehr.
Die in den letzten Monaten gestiegenen Preise für Arbeitsspeicher wirken sich jetzt auch auf den Raspberry Pi aus: Einige Modelle kosten ab sofort bis zu 10 US-Dollar mehr.
Ab sofort gibt es ein Update für Raspberry Pi OS. Die neueste Version bietet Linux-Kernel 6.6 LTS. Es gibt auch weitere Verbesserungen. Ich habe gerade ein Upgrade auf meinem Raspberry Pi 5 (der als Desktop-Ersatz richtig Spaß macht) durchgeführt und damit auch das Kernel-Upgrade erhalten. Die Basis hat sich nicht geändert und ist weiterhin Debian GNU/Linux 12 Bookworm. Unter der Haube ist aber nun Linux-Kernel 6.6 LTS. Aktualisiert wurden auch die beiden offiziell unterstützten Browser. Mit der März-2024-Variante von Raspberry […]
Der Raspberry Pi hat sich in den letzten Jahren von einem kleinen Minicomputer für Bastler und Nerds zu einem vollwertigen und verhältnismäßig leistungsfähigem Rechner entwickelt. Nicht wenige Anwender freuen sich darüber, für wenig Geld einen vollwertigen Miniserver zu bekommen.
Beim Einsatz des Raspberry Pi für den produktiven Einsatz als Server ist zu beachten, dass auch die angeschlossene Hardware hierfür geeignet sein sollte. Ein Gehäuse, bei dem er Pi überhitzt, ist genau so schädlich wie eine SD-Karte als Festplatte, da diese nicht für den Dauerbetrieb geeignet ist.
Durch den Einsatz rund um die Uhr gibt es sehr viele Schreib- und Lesevorgänge auf der SD-Karte. Hierfür sind diese Karten aber nur bedingt geeignet. Bei den ersten Raspberry Pi Generationen hatte ich sehr häufig Datenverlust, weil die SD-Karte den Geist aufgegeben hat.
Inzwischen läuft auf dem Pi bei mir eine Instanz von Home Assistant. Hier werden rund um die Uhr Daten aufgezeichnet und Automationen ausgeführt. Auch andere Dienste laufen hier, von denen ich keinen Ausfall erleiden möchte.
Außerdem sind die Lese- und Schreibgeschwindigkeiten einer SD-Karte sehr limitiert. Eine moderne SSD ist um ein Vielfaches schneller. Das wird vor allem dann deutlich, wenn man in Home Assistant Datenmengen abfragt, z.B. Diagramme anzeigt. Ladezeiten von mehreren Sekunden sind dann keine Seltenheit.
Die Konsequenz daraus ist, dass ich den Raspberry von einer SD-Karte auf eine SSD-Karte umziehen möchte. Dadurch, dass hier ein Produktivsystem läuft, möchte ich alle Installationen, Daten und Einstellungen möglichst verlustfrei auf das neue Medium umziehen. Wie ich das gemacht habe, erfahrt hier in folgendem Tutorial.
Schritt 0: Geschwindigkeit testen (optional)
Um einen Geschwindigkeitsvorteil in messbare Größen zu fassen, kann man als Referenz einen Geschwindigkeitstest der SD-Karte machen. Mit dem folgenden Befehl werden Beispieldateien geschrieben. Der Befehl gibt aus, wie schnell die Geschwindigkeit dabei war.
$ dd if=/dev/zero of=/tmp/speedtest1.img bs=20MB count=5
5+0 records in
5+0 records out
100000000 bytes (100MB, 95 MiB) copied, 11.9403 s, 8.4 MB/s
Wenn der Umzug fertig ist, kann man diesen Test wiederholen. Bei mir kam ich von ca. 8,4 MB/s Schreibgeschwindigkeit auf 168 MB/s. Das hat sich mal gelohnt!
Schritt 1: SSD erstmals anschließen
In meinem Fall handelt es sich um eine externe SSD, die über USB 3.0 angeschlossen wird. Nachdem ich sie angesteckt habe, prüfe ich ob sie rechtmäßig erkannt wird, indem ich den folgenden Befehl eingebe und in der Ausgabe nach der SSD suche.
$ lsblk
Schritt 2: Installation von RPi-clone
Auf Github gibt es ein kleines Projekt, das viele Funktionen beinhaltet. Das Programm kopiert den Inhalt der SD-Karte auf die SSD, sodass von ihr gebootet werden kann und alle Einstellungen vorhanden sind.
Schritt 3: Services stoppen und Kopiervorgang starten
Am besten ist es, wenn kein Service mehr läuft und der Kopiervorgang ungestört durchlaufen kann. Daher erst prüfen, was alles läuft, danach einzeln beenden
Aus dem Check von Schritt 1 kennen wir bereits die Bezeichnung der Festplatte. Auf diese müssen wir nun verweisen mit dem Befehl:
$ rpi-clone sda
Der Wizard hält zunächst an und berichtet uns über den Zustand des Systems. Wenn alles korrekt ist, kann der Vorgang mit der Eingabe von „yes“ gestartet werden.
Schritt 5: Raspberry Pi herunterfahren und von SSD booten
Nach Ende des Kopiervorgangs fährt man den Raspberry Pi herunter.
$ sudo shutdown now
Anschließend von der Stromversorgung trennen, die SD-Karte entfernen, und die Spannungsversorgung wieder herstellen. Jetzt bootet der Raspberry von SSD und ist sehr viel schneller.
Wenn man seinen Raspberry Pi bei sich Zuhause für spezielle Dienste einsetzen möchte, ist es häufig sinnvoll, eine statische IP-Adresse zu vergeben. Man erreicht den Pi zwar in der Regel auch über den Hostnamen. Das ist unabhängig von seiner IP-Adresse, gelingt aber nicht immer. Manchmal muss man beispielsweise eine IP eingeben, oder der Hostname wird nicht korrekt aufgelöst.
Manchmal kann man über sein Netzwerk-Interface eine statische Adresse vergeben, wie etwa der Fritzbox. Ich möchte in dem heutigen Tipp aber zeigen, wie man das über den Raspberry einstellen kann.
Eigene IP-Adresse des Raspberry Pi herausfinden
Unter welchen internen IP-Adresse der Raspberry Pi erreichbar ist, sieht man am einfachsten mit folgendem Befehl. Meldet euch also entweder per SSH auf dem Pi an, oder öffnen ein Terminal auf der grafischen Oberfläche des Raspberry OS und gebt folgenden Befehl ein:
$ ifconfig
In der Ausgabe sieht man nun die Netzwerk-Schnittstellen sowie die jeweilige IP-Adresse.
Statische IP-Adresse am Raspberry Pi einstellen
Mit dem folgenden Befehl öffnet man den Netzwerkmanager von Raspberry OS. Dort kann man sich mit den Pfeiltasten durch das Menü bewegen, und am Ende die gewünsche IP-Adresse eingeben. Es ist hier besondere Vorsicht geboten, damit der Pi hinterher auch wieder im Netzwerk auftaucht. Ein Tippfehler könnte dazu führen, dass man ihn im Netzwerk nicht mehr findet und man per Monitor und Tastatur diesen Fehler korrigieren muss. Hab ich gehört….
$ sudo nmtui
Dort wählt man nun „Edit a connection“, wählt im folgenden Menü seine Schnittstelle aus (WLAN oder kabelgebundenes Netzwerk) und tippt dort seine Verbinungsdetails ein. Bei der IP sollte man hinten dran noch die Subnetzmaske angeben, also zum Beispiel 192.168.1.200/24 für die Subnetzmaske 255.255.255.0
Die Raspberry Pi Foundation gibt weitere Preiserhöhungen für viele ihrer Produkte bekannt. Der Grund sind die weiter steigenden Preise für Consumer-RAM an den Weltmärkten.
Die Raspberry-Pi-Entwickler offerieren bereits zwei SSDs für ihren Minicomputer. Zu denen gesellt sich ab sofort ein Modell mit 1 TByte Speicherplatz. Berappen muss man dafür rund 77 Euro.
Die Raspberry-Pi-Entwickler offerieren bereits zwei SSDs für ihren Minicomputer. Zu denen gesellt sich ab sofort ein Modell mit 1 TByte Speicherplatz. Berappen muss man dafür rund 77 Euro.
Zu den offiziellen Bildschirmen für den Raspberry Pi gesellt sich ab sofort ein Modell mit 5 Zoll. Es verfügt wie schon die erhältliche 7-Zoll-Variante über einen Touchscreen.
Zu den offiziellen Bildschirmen für den Raspberry Pi gesellt sich ab sofort ein Modell mit 5 Zoll. Es verfügt wie schon die erhältliche 7-Zoll-Variante über einen Touchscreen.
Heute möchte ich über ein Thema schreiben, das sicher den einen oder anderen Leser meines Blogs beschäftigt. Es geht um die Frage, wie man auf einer auf einem Raspberry Pi installierten Nextcloud ein RAID-System aufbaut, um Daten redundant auf dem Massenspeicher abzulegen.
Als Vorlage diente mir hierbei eine Anleitung von Daniel von der Firma apfelcast, die ich in Teilen etwas abgeändert habe.
Installation
Zuerst wird die Software mdadm auf dem Raspberry Pi installiert.
sudo apt-get install mdadm
Um diese zu aktivieren, muss der Raspberry Pi nach der Installation von mdadm neu gestartet werden.
sudo reboot
Danach schaut man nach den angeschlossenen Datenträgern. Ich setze voraus, dass man sich zuvor ausreichend mit dieser Materie auseinandergesetzt hat. Ein RAID-Level 1 erfüllt in unserem Fall alle Voraussetzungen für dieses Unterfangen.
Wenn zwei baugleiche SSDs mit identischer Speicherkapazität (z. B. 1 TB) angeschlossen sind, können diese mit folgendem Befehl identifiziert werden:
sudo lsblk
Beide Laufwerke werden als /dev/sda und /dev/sdb ausgegeben.
RAID-System
Raid-System
Nun werden alle Daten und Partitionen der SSDs gelöscht. Hierzu werden beide Befehle nacheinander ausgeführt:
sudo parted /dev/sda "rm 1"
sudo parted /dev/sdb "rm 1"
Ein abschließender Check gibt Gewissheit.
sudo lsblk
Bei Festplatten < 2 TB werden nun die MSDOS-Partitionstabellen erstellt.
sudo parted /dev/sda "mklabel msdos"
sudo parted /dev/sdb "mklabel msdos"
Bei Festplatten > 2 TB verwendet man hingegen folgende Befehle für GPT-Partitionstabellen.
sudo parted /dev/sda "mklabel gpt"
sudo parted /dev/sdb "mklabel gpt"
Anschließend werden die ext4-Partitionen auf beiden Datenträgern erstellt.
sudo parted /dev/sda "mkpart primary ext4 1M -1"
sudo parted /dev/sdb "mkpart primary ext4 1M -1"
Nun wird RAID auf beiden Partitionen aktiviert.
sudo parted /dev/sda "set 1 raid on"
sudo parted /dev/sdb "set 1 raid on"
Anschließend kann der Status überprüft werden (siehe Screenshot).
sudo parted -s /dev/sda print
sudo parted -s /dev/sdb print
Check des Status nach Aktivierung der einzelnen Raid-Partitionen
Jetzt wird ein RAID-Level 1 erstellt, sodass beide Laufwerke zu einem zusammengeführt und so die Daten redundant gespeichert werden können. Falls eine SSD ausfällt, sollten somit keine Daten verloren gehen.
Anmelden
