DMW007 (17.03.2022)
-
11.01.2022, 14:49 #11
- Registriert seit
- 15.11.2011
- Beiträge
- 6.145
- Blog Entries
- 5
Thanked 9.130 Times in 3.005 PostsKurz gesagt liegt das daran, dass Microsoft bis heute keine Unterstützung für Linux-Dateisysteme eingebaut hat. Der Größenunterschied kommt von der Art, wie das Image aufgebaut ist. Die sichtbare Boot-Partition (bei dir D:)enthält unter Linux alles, was zum booten notwendig ist, wie z.B. den Linux-Kernel. Auf dem Raspberry Pi wird dafür i.d.R. FAT32 genutzt: Es ist vergleichsweise einfach zu implementieren und kann von allen Betriebssystemen gelesen werden. Diese Partition enthält nicht das gesamte Betriebssystem, ein paar Hundert MB reichen völlig aus.
Die zweite Partition (bei dir F:) ist für dich aus dem Anfangs erwähnten Grund unsichtbar, weil sie ein Linux-Dateisystem enthält und du Windows nutzt, welches das Dateisystem nicht unterstützt. Die Ext-Dateisysteme sind unter Linux verbreitet, das Raspberry Pi OS nutzt daher ext4:
Code:$ mount | column -t /dev/mmcblk0p2 on / type ext4 (rw,noatime)
Der Grund: Du flasht bei den meisten Pi-Betriebssystemen ein komplettes Datenträgerabbild. Ein Abbild ist immer so groß wie die Partition und schließt auch den leeren Speicher ein! Wenn ich also ein Image mit einer 32 GB großen Speicherkarte erstelle, ist das Image 32 GB groß, obwohl davon vielleicht nur ein paar Hundert MB belegt ist. Das bläht das Image unnötig auf, daher wird bei den Images vor der Veröffentlichung in der Regel folgendes gemacht: Man verkleinert die Partition auf die tatsächlich benötigte Größe, bevor man das Image erstellt. Somit ist das Image nur z.B. 400 MB MB groß.
Da die Speicherkarten von den Nutzern größer sind (z.B. 16 GB), läuft beim ersten Start des Pi ein Skript, welches die Partition auf die maximale Größe der SD-Karte vergrößert: Bei einer 16 GB Karte auf 16 GB, bei einer 64 GB Karte auf 64 GB usw. Daher ist ein Image, dass nach dem ersten Start erstellt wurde, genau so groß wie die Speicherkarte. Das kann man auch auf der Ausgabe sehen, wenn beim ersten Start ein Bildschirm am Pi angeschlossen ist:
Anschließend ist die Root-Partition so groß wie die Karte (32 GB) - in diesem Beispiel 29 GB:
Code:$ df -h Filesystem Size Used Avail Use% Mounted on /dev/root 29G 1.3G 27G 5% / /dev/mmcblk0p1 253M 49M 204M 20% /boot ...
-
28.01.2022, 22:21 #12
- Registriert seit
- 30.09.2021
- Beiträge
- 1.402
Thanked 32 Times in 30 PostsDanke für das Video. Wie soll man bei einer SSD vorgehen? Eine Sicherung finde ich hier auch wichtig. Soll hier auch wie bei der SD vorgegangen werden oder gibt er hierfür andere Möglichkeiten? Danke für die Info.
Kommentar von Karl Steiner.
-
29.01.2022, 01:03 #13
- Registriert seit
- 30.09.2021
- Beiträge
- 1.402
Thanked 32 Times in 30 PostsSo habe ich meine Images meiner SD-Karten vorher auch angefertigt bis ich bemerkt habe das es dadurch immer wieder mal nach ein Paar Wochen bis Monaten zu mir unerklärlichen defekten bzw. nicht mehr bootfähigen RaspiOsInstallatione*n geführt hat. Es ist besser diese Images direkt aus dem laufenden Raspberry Pi OS mit Hilfe der dort eingebauten Backupprogramms zu erledigen, dann kommt es auch nicht zu Fehlern. Das ist auch der Grund weshalb der offizielle Raspberry Pi Imager diese "Backup" funktion nicht unterstützt. Nachzulesen in deren Repo auf Github -> https://github.com/raspberrypi/rpi-imager/issues/228
Kommentar von CooperDuper3000.
-
11.02.2022, 12:05 #14
- Registriert seit
- 30.09.2021
- Beiträge
- 1.402
Thanked 32 Times in 30 PostsHallo, wie verhält es sich denn, wenn ich ein Image von einer 32 GB Karte später vielleicht mal auf eine 64 GB Karte klonen will? Oder umgekehrt, also 64 GB auf 32 GB. Funktioniert das ohne Probleme?
Kommentar von Mr. K.
-
11.02.2022, 23:57 #15
- Registriert seit
- 15.11.2011
- Beiträge
- 6.145
- Blog Entries
- 5
Thanked 9.130 Times in 3.005 PostsHi,
funktioniert beides, wenn du Linux nutzt. Dort kannst du die Dateisysteme auf die tatsächlich benötigte Größe verkleinern. Beispiel: 32 GB große Speicherkarte, davon sind 3 GB belegt. Erstellst du ein Image davon, belegt das erst mal 32 GB. Verkleinerst du es anschließend auf die tatsächliche Größe, ist es nur noch 3 GB groß. Dadurch kannst du es auf jede Karte kopieren, die mindestens so groß ist wie der belegte Speicher. In diesem Beispiel könntest du also auch eine 8 oder 4 GB Karte nehmen.
Durch das Verkleinern auf die tatsächliche Größe ist die Partition aber auch nur so groß. Bedeutet: Wenn du dieses verkleinerte 3 GB Image auf z.B. eine 64 GB Karte spielst, zeigt dir der Pi das als 3 GB Partition an. Durch das Erweitern auf die volle Größe wird daraus eine 64 GB Partition, auf der 3 GB belegt sind. Beim ersten Start einer frischen Installation macht der Pi das automatisch, müsstest du in diesem Falle manuell machen. Ist aber kein Hexenwerk und auch nur einmalig erforderlich, wenn du ein solches Image einspielst.
-
15.02.2022, 13:47 #16
Mit Linux ist das echt entspannt da kann man mit dd einfach ein Image schreiben und per Skript auf die belegte Größe reduzieren. Geht unter Windows halt nicht weil Microsoft keine Linux Dateisysteme unterstützt. Aber man kann sich ja ein Dualboot oder zumindest eine VM installieren und die Gelegenheit nutzen um es mal auszuprobieren. Dann ist man auch gleich sicherer und vor allem datenschutzfreundlicher unterwegs als mit Windows!
-
17.03.2022, 19:44 #17
- Registriert seit
- 30.09.2021
- Beiträge
- 1.402
Thanked 32 Times in 30 PostsVielen Dank für deine viele Arbeit! Kannst du auch erklären, wie ich ein eigenes Image vom PIOS erstellt werden kann, wenn es sich nicht auf einer SD-Karte sondern auf einer SSD-Festplatte befindet? Dort habe ich noch eine viele Daten, die ich nicht mit aus Image ziehen möchte. Ich nutze den Pi4 sehr zufriedenstellend als Desktop Rechner...da ich aber auch viel rumexperimentiere, gelingt es mir hin&wieder das System zu zerschießen...dann hätte ich gerne mein PI OS wieder zurück, ohne alles neu installieren zu müssen ...auf der SSD habe ich außerdem noch viele andere Daten (ca. 30GB), die ich nicht mit indas Image ziehen möchte. Den Verlust der Daten kann ich in Kauf nehmen, da es nur Back-up Daten meines NCP servers sind. Der ist aber auf einem anderen Gerät, und ich kann sie ohne weiteres wieder herstellen.
Kommentar von Chobber Redwing.
-
17.03.2022, 19:49 #18
- Registriert seit
- 15.11.2011
- Beiträge
- 6.145
- Blog Entries
- 5
Thanked 9.130 Times in 3.005 PostsDanke :) Im Grunde genau so, für Linux sind das alles "Block Devices", unabhängig davon ob das physische Gerät eine Karte, SSD oder HDD ist. Daten ausschließen kannst du mit der Methode allerdings nicht ohne weiteres, da dd komplette Partitionen kopiert. Am sinnvollsten wäre es, auf der SSD eine zweite Partition zu erstellen, auf die du deine Daten legst. Für eine Sicherung muss dann nur die kleinere (z.B.
sdasda1) Partition kopiert werden, nicht die zweite Daten-Partition (z.B.sdbsda2).
-
17.03.2022, 23:23 #19Walter P.Gast
Mit dieser Anwort bin ich aber nicht einverstanden. Eine Festplatte ist sda, aber die einzelnen Partitionen erhalten dann laufende Nummern mit sda1, sda2,... usw. und bei sdb genauso, dann sdb1, sdb2,...usw.
-
The Following User Says Thank You to Walter P. For This Useful Post:
-
17.03.2022, 23:29 #20
- Registriert seit
- 15.11.2011
- Beiträge
- 6.145
- Blog Entries
- 5
Thanked 9.130 Times in 3.005 PostsAW: Backup der SD-Karte des Raspberry Pi durch eine Image-Sicherung anlegen
Du hast Recht. Ich hatte beim Schreiben noch über ein zweites Laufwerk nachgedacht, sodass die Daten darauf ausgelagert wären. Mich dann aber dagegen entschieden, weil mir die Partitionierung sinnvoller erschien, ohne die Beispiele entsprechend anzupassen. Habe meinen Beitrag korrigiert, danke für deinen Hinweis!
Diese Seite nutzt Cookies, um das Nutzererlebnis zu verbessern. Klicken Sie hier, um das Cookie-Tracking zu deaktivieren.