Lese-Ansicht

Raspberry Pi: Umzug von SD-Karte auf SSD in wenigen Schritten

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.

$ git clone https://github.com/billw2/rpi-clone.git
$ cd rpi-clone
$ sudo cp rpi-clone /usr/local/sbin/sys-clone
$ sudo cp rpi-clone-setup /usr/local/sbin/sys-clone-setup

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

$ sudo systemctl stop cron
$ sudo systemctl stop nginx
$ sudo systemctl stop docker usw.

Schritt 4: Kopiervorgang starten

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.

The post Raspberry Pi: Umzug von SD-Karte auf SSD in wenigen Schritten first appeared on bejonet - Linux | Smart Home | Technik.

  •  

Fedora 40 & Gnome 46 vorgestellt - Hier spielt die Zukunft

💾

Wenn Du das Video unterstützen willst, dann gib bitte eine Bewertung ab, und schreibe einen Kommentar. Vielen Dank!

Links:
-------------------------------------

Fedora: https://fedoraproject.org/de/
Linux-Guides Merch*: https://linux-guides.myspreadshop.de/
Professioneller Linux Support*: https://www.linuxguides.de/linux-support/
Linux-Arbeitsplatz für KMU & Einzelpersonen*: https://www.linuxguides.de/linux-arbeitsplatz/
Linux Mint Kurs für Anwender*: https://www.linuxguides.de/kurs-linux-mint-fur-anwender/
Offizielle Webseite: https://www.linuxguides.de
Forum: https://forum.linuxguides.de/
Unterstützen: http://unterstuetzen.linuxguides.de
Mastodon: https://mastodon.social/@LinuxGuides
X: https://twitter.com/LinuxGuides
Instagram: https://www.instagram.com/linuxguides/
Kontakt: https://www.linuxguides.de/kontakt/

Inhaltsverzeichnis:
-------------------------------------

###


Musik:
-------------------------------------

Elektronomia - Sky High [NCS Release]
Music provided by NoCopyrightSounds.
Video Link: https://youtu.be/TW9d8vYrVFQ
Download Link: https://NCS.lnk.to/SkyHigh

Haftungsausschluss:
-------------------------------------
Das Video dient lediglich zu Informationszwecken. Wir übernehmen keinerlei Haftung für in diesem Video gezeigte und / oder erklärte Handlungen. Es entsteht in keinem Moment Anspruch auf Schadensersatz oder ähnliches.

*) Werbung
  •  

DVD-Sammlung auf Festplatte speichern

Es wird Zeit, sich von den Filmen auf DVD zu trennen und die Silberlinge auf Festplatte zu speichern. Lege die DVD am PC ein und starte den VLC-Player, den Rest erkläre ich Dir.

  •  

Ubuntu 24.04 LTS Beta ist verfügbar & Derivate

Das Ubuntu-Team hat die Beta-Version von Ubuntu 24.04 LTS Noble Numbat zur Verfügung gestellt. Sie hat sich wegen des xz-Problems bekanntlich etwas verzögert. Die Beta-Version bietet wie üblich nicht nur Abbilder für Ubuntu Desktop, Server und Cloud, sondern es gibt auch Images für die zahlreichen Derivate. Die Beta-Abbilder sollten keine sogenannten Showstopper haben und eine normale Nutzung sollte möglich sein. Allerdings ist es eine Beta-Version, die sich möglicherweise nicht für den produktiven Einsatz eignet. Noble Numbat bietet Linux-Kernel 6.8, GNOME […]

Der Beitrag Ubuntu 24.04 LTS Beta ist verfügbar & Derivate ist von bitblokes.de.

  •  

Ubuntu 24.04 Beta ist am Start

Eine Woche später als geplant wurde jetzt die Beta zu Ubuntu 24.04 LTS »Noble Numbat« freigegeben. Die stabile Veröffentlichung ist trotz der Verschiebung für den 25. April vorgesehen.

Quelle

  •  

Bildschirmaufnahme mit VokoscreenNG

Bildschirmaufnahme mit VokoscreenNG: Eine sehr einfach zu bedienende, junge Anwendung für die Aufnahme von Bild und Ton direkt vom Bildschirm. Sie ist erhältlich für Linux und Windows.

  •  

Linux-Desktop: Vier Prozent Marktanteil waren keine Einmonatsfliege

Während Linux das dominante Betriebssystem in vielen Bereichen ist, tut sich das freie System auf dem Desktop noch immer schwer. Jahrelang ein Nischendasein fristend, erreichte Linux in der weltweiten Verbreitung laut statcounter.com im Februar 2024 erstmals die 4-Prozent-Hürde und konnte diese Marke im Folgemonat halten.

  •  

Slay the Spire 2 angekündigt – mit neuer Spiele-Engine

Ich bin ein ziemlicher Fan des Deckbau-Roguelike Slay the Spire. Ich habe das Spiel in einem Humble Bundle erworben und bereue es nicht. Das macht ziemlich Spaß. Das Entwickler-Team von Mega Crit hat nun Slay the Spire 2 angekündigt. So groß die Vorfreude auch ist, Du wirst Dich in Geduld üben müssen. Veröffentlichungsdatum für Slay the Spire 2 ist 2025. Auf Steam schreibt das Team, dass das Spiel komplett neu in einer neuen Spiel-Engine programmiert wurde. Mega Crit ist Sponsor […]

Der Beitrag Slay the Spire 2 angekündigt – mit neuer Spiele-Engine ist von bitblokes.de.

  •  

Podcast über xz-Backdoor und worüber wir reden müssen

Seit 1,5 Jahren produziere ich den Podcast Risikozone, in dem es um Themen der IT-Sicherheit und Open-Source-Software geht. Die xz-Backdoor ist natürlich ein heißes Thema, weswegen es in der heute veröffentlichten Episode 45 genau darum geht.

Die knapp einstündige Podcastepisode ist für alle interessant, die nochmals einen technisch orientierten Überblick über die Geschehnisse suchen. Da die Thematik recht komplex ist und aus verschiedenen Blickwinkeln beobachtet werden kann, können weitere Podcastepisoden hierüber noch folgen. Ich möchte aber darauf eingehen, dass man diese Backdoor nicht nur auf den Code beschränken sollte. Es gibt es viele verschiedene Ebenen, die allesamt jeweils Beachtung finden sollten:

  • die technische "Exploit"-Ebene
  • die zwischenmenschliche Ebene
  • die Ökosystem-Ebene

Technisch ist der Exploit ausgeklügelt: Die Backdoor beschränkt sich nicht nur auf die bloße Möglichkeit einer Remote-Code-Execution, sondern verwendet darüber hinaus noch ein eigenes Protokoll, mit dem die Befehle signiert und verschlüsselt innerhalb des unscheinbaren N-Wertes im Zertifikat eines SSH-Handshakes übermittelt werden. Durch die Signatur können nur Befehle ausgeführt werden, die mit einem (wahrscheinlich nur dem Angreifer bekannten) ED448-Schlüssel signiert wurden. Die Verschlüsselung erfolgt zwar mit einem statischen Schlüssel, der aus dem ED448-PubKey abgeleitet wird, erfüllt jedoch trotzdem seinen Zweck: Obfuskierung. Mit anderen Worten: wäre die Lücke nie aufgefallen, hätte man sie in der freien Wildbahn nahezu unmöglich durch Traffic-Analysen finden können.

Das ist allerdings nur die erste von drei Ebenen: die Art und Weise, wie die Lücke hereingeschummelt wurde, weist Komponenten des Social Engineering auf. Die Mühe, über mehrere Jahre eine Identität in verschiedenen Projekten mit teils anfangs legitimen Beiträgen aufzubauen, zeugt auch von einem Plan und Ausdauer.

Schlussendlich sollte man auch nicht vergessen, dass hier eine besondere Konstellation im Ökosystem ausgenutzt wurde. Am einfachsten (und auffälligsten) wäre es, eine solche Lücke in OpenSSH unterzubringen. Es wurde aber auf eine deutlich unbeachtetere und einfacher zu infiltrierende Variante ausgewichen. Die xz-Bibliothek wurde zudem nicht zum Einfallstor, weil OpenSSH darauf zurückgreift (das tut es nämlich nicht), sondern weil einige Distros systemd-notify reinpatchen, was wiederum auf die xz-Lib zurückgreift. Außerdem rüttelt dieser Fall an einem Grundpfeiler der IT-Sicherheits-Praktiken: Updates. Diese Hintertür fand geradezu durch die (häufigen) Updates der Rolling-Release-Distros Einzug - die stabilen Versionen waren noch verschont geblieben. Ist also (zu) häufiges Updaten nun auch nicht mehr richtig? Bringen bald Updates mehr Lücken als sie schließen?

Das alles macht es vor allem noch schwieriger, solche Angriffe zuverlässig zu erkennen. Zudem ist davon auszugehen, dass die Angreifer sich die Verteidigungsstrategie jetzt ganz genau anschauen. Die zukünftige Diskussion sollte sich also darauf konzentrieren, wie man diese Art von Angriffen detektiert und frühzeitig eindämmt.

  •  
❌