Hallo, guten Tag. Ich habe jetzt eine gute abgestimmte SD für den Raspi fertig mit RS232 und PLus4-Emu usw. Weil diese jetzt Super funktioniert möchte ich eine zweite SD anlegen bzw die komplette erste SD auf die zweite funktionsfähig übertragen die dann beim reinstecken wie die erste SD startet und ihre Arbeit fehlerfrei macht. Wie geht das bitte. Mit welchen programm? Ich habe auch Win32Diskmaker und SD Cart Formatter am laufen. Danke.
Ich nehm dazu den Win32DiskImager. Duerfte unzaehlige Programme geben, mit denen das geht.
> Mit welchen programm?
Der erfahrene Unixuser nimmt dafuer natuerlich dd.
Olaf
Win32Diskmaker funktioniert hier bei mir. Dauert allerdings ne Weile, wenn die SD-Karte etwas groesser ist, da er immer die komplette Karte einliest und zurueck schreibt, auch wenn die nur zu 20% belegt ist. Wenn da jemand ne Loesung hat, die das umgeht, waere auch mir geholfen... :-)
Evlt. Partition verkleinern und dann nur die Partitionstabelle und Partition kopieren.
Andi M. schrieb: > Wenn da jemand ne Loesung hat, ... Moegliche Loesungvariante entfaellt bei journalenden Dateisystemen mit Verzeichnisbackup.
Olaf schrieb: > Der erfahrene Unixuser nimmt dafuer natuerlich dd. Aber nur der erfahrene! Der Unerfahrene bootet Windows und nimmt Win32DiskImager ;-)
peter bierbach schrieb: > gute abgestimmte SD für den Raspi fertig mit RS232 und PLus4-Emu usw. > Weil diese jetzt Super funktioniert möchte ich eine zweite SD anlegen ansible ist sonst eine super möglichkeit, änderungen an einem system mit einer zentralen verwaltung reproduzierbar zu machen. hab das in meiner alten firma für server und entwicklerrechner eingesetzt.
@ quotendepp Nomen est omen. Es ist schön, wenn Nick und Beitrag zusammenpassen.
mit Clonezilla kann man auch SD-Karten duplizieren, geht schneller als alles kopieren, da nur die belegten Sektoren dupliziert werden.
J. D. schrieb: > @ quotendepp > Nomen est omen. Es ist schön, wenn Nick und Beitrag zusammenpassen. jo mei, wenn moanst
Ich habe mir die Frage auch schon gestellt und unter "nichttriviale Probleme" abgeheftet. Das Hauptproblem ist, dass sich SD-Karten leider doch unterscheiden, auch wenn sie nominell die gleiche Speicherkapazität haben. Sowohl dd als auch Win32DiskImager versagen dann. Einfachste Lösung wäre natürlich Kopie auf eine größere Karte. Skaliert nur leider nicht, irgendwann gibt es keine größere mehr. Was bei mir funktioniert hat: Verkleinerung des Images mit https://github.com/Drewsif/PiShrink Hat auch den Vorteil, dass man damit Images gut fürs Backup vorbereiten kann. CloneZilla könnte ich mir als Lösung vorstellen, habe es aber nicht selbst für diesen Zweck getestet. Trivial ist das wie gesagt nicht, Tools wie https://github.com/billw2/rpi-clone haben bei mir beim Verkleinern Datenschrott erzeugt. Gut möglich, dass Clonezilla auch Fehler produziert. Also unbedingt die Kopie sorgfältig testen.
Wo finde ich hier den Befehl von sd zu sd kopiren. Finde nur Img auf die Sd zu bringen? Win32DiskImager Danke.
peter bierbach schrieb: > Wo finde ich hier den Befehl von sd zu sd kopiren. > Finde nur Img auf die Sd zu bringen? > > Win32DiskImager > > Danke. Mit dem DiskImager kannst du keine 2 Karten gleichzeitig ansprechen. Also erst eine Karte lesen und als ".img" speichern, dann andere Karte rein und das ".img" darauf schreiben.
Felix hat recht, die Kapazität der leeren SD muss genau gleich oder größer sein als die alte, sonst melden die Kopierprogramme einen Fehler. Zum Verkleinern würde ich unter Linux gparted benutzen. Zur Not mit einer Live-CD wie Knoppix oder Ubuntu-Install
hiermit kannst du aus einem laufenden Raspi System eine neue SD-Karte klonen, die nicht mal die gleiche Größe haben muss. https://github.com/billw2/rpi-clone
> Sowohl dd als auch Win32DiskImager versagen dann.
Tja, das Schicksal kann so hart sein! Im Zweifel wuerde
ich dann mal empfehlen es damit zu probieren die Partitionen
neu anzulegen und alles mit cp -a zu kopieren.
Oder sich mit tar zu beschaeftigen.
Und dann noch mal in /etc/fstab vorbeischauen ob dort alles passt.
Ihr wolltet Linux? Also nutzt es auch. :-)
Olaf
Wie sieht es eigentlich mit dem Alignment bei solchen Klonaktionen aus? Siehe: https://wiki.ubuntuusers.de/Installation_auf_Flashmedien/
Olaf schrieb: > Ihr wolltet Linux? Also nutzt es auch. :-) Sehr schön formuliert. Absolut richtig, sehe es genau so. peter bierbach schrieb: > Wie geht das bitte. > Mit welchen programm? Ich nutze seit Jahren BerryBoot. Damit ist Multi instance, Backup, Restore, Imaging, Cloning möglich. Mit BerryBoot dürfte jeder Otto-Nichtlinux zurechtkommen. https://www.berryterminal.com
QQ schrieb: > Wie sieht es eigentlich mit dem Alignment bei solchen Klonaktionen aus? Wie soll es denn aussehen? Cloning ist natürlich 1:1. Am Alingment ändert sich nichts. I.d.F. kümmert man sich vorher drum. Oder besser, stellt sich die Frage ob eine SDcard das richtige Speichermedium ist.
quotendepp schrieb: >
1 | > man dd |
2 | > |
3 | > dd if=/dev/... of=/dev/... bs=... |
4 | > |
Vergiss sync am ende nicht. Ansonsten denkt man die SD Karte wurde komplett beschrieben und steckt sie möglicherweise aus während noch Daten Kopiert werden. Der Nachteil der dd Methode ist das diese eventuell langsamer ist, da diese die ganze SD-Karte kopiert, dies wäre aber nicht unbedingt nötig, dafür ist sie sehr zuverlässig. @peter bierbach Wenn du kein Linux-PC hast kannst du immernoch den Raspberry Pi nehmen auf dem wahrscheinlich ein Linux läuft?
Name schrieb: > @peter bierbach > Wenn du kein Linux-PC hast kannst du immernoch den Raspberry Pi nehmen > auf dem wahrscheinlich ein Linux läuft? Mit rsync bekommt man das laufende OS (mounted filesystem) auch on-the-fly mit einem Einzeiler schön gesichert.
BerryBoot Was macht das Programm genau? Ein neues LINUX? Danke.
peter bierbach schrieb: > BerryBoot > Was macht das Programm genau? > Ein neues LINUX? Nein, das hat doch Mister A. schon geschrieben: Mister A. schrieb: > Ich nutze seit Jahren BerryBoot. > Damit ist Multi instance, Backup, Restore, Imaging, Cloning möglich.
Danke. Habe ich jetzt erkannt. Es können Linux-Systeme ausgesucht werden.
Der Raspi braucht keinen BootBlock oder PartSektor. Wichtig ist das die PARTUUID der Speicherkarte mit den folgenden zwei Dateien auf der Speicherkarte passt. Abfrage: blkid /dev/mmcblk0p1: LABEL_FATBOOT="boot" LABEL="boot" UUID="F661-303B" TYPE="vfat" PARTUUID="2daa6bdf-01" /dev/mmcblk0p2: LABEL="rootfs" UUID="8d008fde-f12a-47f7-8519-197ea707d3d4" TYPE="ext4" PARTUUID="2daa6bdf-02" Datei1: /etc/fstab PARTUUID=2daa6bdf-01 /boot vfat defaults 0 2 PARTUUID=2daa6bdf-02 / ext4 defaults,noatime 0 1 Datei2: /boot/cmdline.txt dwc_otg.lpm_enable=0 console=serial0,115200 console=tty1 root=PARTUUID=2daa6bdf-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait
peter bierbach schrieb: > BerryBoot > Was macht das Programm genau? Nennen wir es mal einen grafischen Bootmanager mit Tools, um mehrere Distributionen als Multiboot auf einer SDcard verwalten und starten zu können. Zusätzlich können die Konfigurationsdateien sehr einfach bearbeitet werden, damit sich die verschiedenen Betriebssysteme nicht in die Quere kommen. Nutzung von SDcard und/oder USB-Stick oder USB-Disk ist ebenfalls möglich. Die Distributionsimages (ISO Installationsmedien) können per klick heruntergeladen und integriert werden. Wechsel auf eine andere Distro unter Beibehaltung der Datenpartition ist ebenfalls möglich. Eigentlich ist alles selbsterklärend. Berryboot herunterladen, auf eine leere SDcard oder USB-Stick entpacken, booten, einrichten.
:
Bearbeitet durch User
BerryBoot klingt ziemlich genial, werde ich beim nächsten Projekt mal evaluieren. Die Frage ist trotzdem, wie das Tool beim Clonen vorgeht. Kann es ein Image fehlerfrei verkleinern? Falls nicht, ist das Problem der inkompatiblen Karten ja nicht gelöst. Ein Backup ließe sich dann nur auf die exakt gleiche Karte oder eine größere rückspielen. Das Grundproblem lässt sich nur durch stabile Verkleinerung des Images lösen. Und das am besten außerhalb des laufenden Systems. Nach meinen Erfahrungen muss ich vor den ganzen live-System-Lösungen warnen, das produziert (oft unbemerkt) Datenmüll. Konkret also dd aus dem laufenden System, rsync, cp oder https://github.com/billw2/rpi-clone Da das Betriebssystem während dieser Maßnahmen weiterläuft und auf das Filesystem schreibt, sind Inkonsistenzen vorprogrammiert. Stabil laufen dagegen Tools, die von außen auf dem nicht laufenden Filesystem arbeiten UND Filesystem und Partitionsschema stabil beherrschen. Ob das unter Windows oder Linux passiert, ist völlig egal.
Mit dem Etcher kann man auch (Micro) SD-Karten klonen.
Felix schrieb: > Nach meinen > Erfahrungen muss ich vor den ganzen live-System-Lösungen warnen, das > produziert (oft unbemerkt) Datenmüll. Konkret also dd aus dem laufenden > System, rsync, cp oder https://github.com/billw2/rpi-clone > Da das Betriebssystem während dieser Maßnahmen weiterläuft und auf das > Filesystem schreibt, sind Inkonsistenzen vorprogrammiert. Das trifft aber nur für dd und Konsorten zu. Alles was mit rsync und cp kopiert wird (incl. https://github.com/billw2/rpi-clone) kann kein kaputtes Filesystem hinterlassen. Das man während diesen Aktionen nichts und nicht mal eine GUI laufen lassen sollte dürfte klar sein. Ich habe mit rpi-clone noch nie Probleme gehabt. Und so was wie log-Dateien kopiert rpi-clone nicht mit.
Felix schrieb: > Die Frage ist trotzdem, wie das Tool beim Clonen vorgeht. Bevor das OS hochgefahren ist, also nicht live oder active, wird die / eingehängt und mit tar/bzip/gzip zusammen gepackt. Die relevanten Verzeichnisse für einen full backup sind bereits vorselektiert. Weitere können noch ein-/ausgeschlossen werden. Beim Restore ist es dann umgekehrt. Das image ist entsprechend den Nutzdaten komprimiert. Partitionsgrößen spielen daher keine Rolle. Nur bei der kompletten SDcard-copy kommt dd zum Einsatz. Dann muss das Ziel natürlich mindestens genauso groß sein. Der normale Installer einer Distribution macht ja auch nichts anderes als /target zu füllen. Ich habe berryboot bei der Arbeit noch nicht unter die Haube geschaut (im weiteren Terminal), vermute dass er einfach nur ein rsync + bzip ausführt.
:
Bearbeitet durch User
temp schrieb: > hiermit kannst du aus einem laufenden Raspi System eine neue SD-Karte > klonen, die nicht mal die gleiche Größe haben muss. > > https://github.com/billw2/rpi-clone 1827 Codezeilen für das Herzstück :)
1 | rsync_file_system() |
2 | {
|
3 | src_dir="$1" |
4 | dst_dir="$2" |
5 | |
6 | qprintf " => rsync $1 $2 $3 ..." |
7 | |
8 | if [ "$3" == "with-root-excludes" ] |
9 | then
|
10 | rsync $rsync_options --delete \ |
11 | $exclude_useropt \ |
12 | $exclude_swapfile \ |
13 | --exclude '.gvfs' \ |
14 | --exclude '/dev/*' \ |
15 | --exclude '/mnt/clone/*' \ |
16 | --exclude '/proc/*' \ |
17 | --exclude '/run/*' \ |
18 | --exclude '/sys/*' \ |
19 | --exclude '/tmp/*' \ |
20 | --exclude 'lost\+found/*' \ |
21 | $src_dir \ |
22 | $dst_dir |
23 | else
|
24 | rsync $rsync_options --delete \ |
25 | $exclude_useropt \ |
26 | --exclude '.gvfs' \ |
27 | --exclude 'lost\+found/*' \ |
28 | $src_dir \ |
29 | $dst_dir |
30 | fi
|
31 | qecho "" |
32 | }
|
temp schrieb: > Alles was mit rsync und cp > kopiert wird (incl. https://github.com/billw2/rpi-clone) kann kein > kaputtes Filesystem hinterlassen. Das man während diesen Aktionen nichts > und nicht mal eine GUI laufen lassen sollte dürfte klar sein. > Ich habe mit rpi-clone noch nie Probleme gehabt. Und so was wie > log-Dateien kopiert rpi-clone nicht mit. Was stusst du da zusammen? Erklär mal bitte - kaputtes Filesystem - keine GUI benutzen - das nicht vorhandene exclude /var/log
Mister A. schrieb: > Was stusst du da zusammen? Bleib mal schön auf dem Boden, oder haben dir deine Eltern keinen Anstand beigebracht? Mister A. schrieb: > Erklär mal bitte > - kaputtes Filesystem wenn im laufenden Betrieb mit dd und konsorten kopiert wird könne kaputte Filesysteme auf dem Ziel entstehen. Das wird auf Blockdeviceebene kopiert und damit vorbei am Filesystem. Beim rsync-Clonen passiert das nicht. Oder hast du Schwierigkeiten meinen Text oben zu lesen? > - keine GUI benutzen Alles was noch läuft, also auch die GUI mit dem Fenstermanager und alles was dazu gehört können ja noch Änderungen schreiben. Bei einem rsync-Clone im laufenden Betrieb sollte das System nach Möglichkeit so statisch wie möglich bleiben. Was gibts da nicht zu verstehen? > - das nicht vorhandene exclude /var/log Bei mir gibt es das Mister A. schrieb: > 1827 Codezeilen für das Herzstück :) hast du damit ein Problem? Ich nicht. Aber es interessiert mich auch nicht was du machst bzw. gut oder schlecht findest.
temp schrieb: > Bleib mal schön auf dem Boden, oder haben dir deine Eltern keinen > Anstand beigebracht? Würdest du bitte meine Eltern aus deinen Postings weglassen. Die schreiben hier nicht. Anständig gefragt habe ich auch, weil ich deinen Stuss (Behauptung) nicht verstehe oder nachvollziehen kann. Bleib sachlich statt persönlich. Wahrscheinlichkeitstheorien sind meist lang und trocken.
raspiBackup ist eigentlich dafuer gedacht ein laufendes Image zu sichern. Du kannst das Backup aber auch wieder auf ein beliebiges Device restoren und damit clonen und der ganze UUID Anpassungskram wird automatisch erledigt :-) Und Du solltest nicht den Backuptyp dd nutzen ... tar oder rsync ist wesentlich sicherer.
:
Bearbeitet durch User
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.