personalisiertes Stretch klonen und von USB booten

[fischig]

Ich will ein personalisiertes stretch mit diesem Kommando auf einen Usbstick schreiben:

Code: Alles auswählen

rsync -az -H --delete --numeric-ids /media/rootalt/ /media/rootneu/

Mit personalisiert meine ich: es geht nicht um irgendwelche von Debian bereitgestellten Installationsimages, sondern um ein von mir bereits auf dem Rechner, auf dem der Klon mal laufen soll, fertig eingerichtetes System.
Ich will grml-live benutzen, und beide Datenträger (HDD-Partition mit Stretch und Stick mit ext4-Partition) an aus dem Kommando ersichtlichen Mountpoints einhängen.

1. Frage
Kann das prinzipiell so funktionieren?
Hintergrund: Ich habe auf diese Weise schon mehrfach Debian-Systeme erfolgreich geklont, allerdings immer nur zwischen zwei HDDs.
Bei zwei gescheiterten Versuchen mit Sticks habe ich lediglich Schrott produziert.

Wenn es so funktionieren müsste:
2.Frage
Auf welche Rechte des gemounteten Sticks soll ich achten?

3.Frage
Hat es Konsequenzen, ob ich das rsync-Kommando als (grml-)root oder als user ausführe?

edit: „und von USB booten“ im Titel ergänzt

[rhHeini]

Der Stick sollte ext4 als Dateisystem haben, sonst kopierst Du die Rechte nicht mit bzw. verlierst die.

[hikaru]

Und du solltest das Ganze als root ausführen, sonst kannst du die User und Gruppen nicht korrekt setzen.
(Hinterher nicht vergessen, den Bootloader neu zu installieren!)

[fischig]

Ich wollt' mich eigentlich erst mal vergewissern, dass es prinzipiell so funktionieren sollte. Wie gesagt, ich hab's zwei-, dreimal versucht und anschließend waren die Sticks hinüber. Wenn ich ausschließe, dass ich da Müll bereits gekauft habe (Partitionieren und Kopieren lief eigentlich), dann muss ich ja irgendwas falsch gemacht haben.

Und du solltest das Ganze als root ausführen, sonst kannst du die User und Gruppen nicht korrekt setzen.

Ich ging davon aus, dass die gewählten rsync-Parameter das selbständig machen, aber danke für den Hinweis, ich werd's beherzigen.

ext4 ist drauf und dass das Elaborat noch nicht bootfähig ist, ist mir klar.

[fischig]

Noch was: Das Original-Stretch wird nicht auf der internen Platte sitzen, sondern wie der Stick über USB eingehängt werden. Gilt's dabei noch was Besonderes zu beachten?

[hikaru]

Wenn der Rechner direkt von dem Stick bootet, dann ist nichts zu beachten, außer, dass der Bootloader auch auf dem Stick landen muss.

[fischig]

Soweit bin ich doch noch gar nicht. Ich bin immer noch bei der Vorbereitung des rsync-Kommandos.

Wenn ich davon ausgehe, dass eher unwahrscheinlich ist, dass zwei Sticks bereits vor dem Kopieren defekt waren, dann muss irgend etwas anders schief gelaufen sein.

Bei meinen bisherigen (erfolgreichen) Klon-Aktionen mit rsync (ausschließlich mit HDDs) war immer der interne Datenträger irgendwie im Spiel. Es lief zwar immer über grml, aber entweder wurde von dem internen auf einen externen kopiert oder umgekehrt. Bei der aktuellen Aktion geht's um zwei externe Datenträger: einmal die über USB angeschlossene externe HDD mit dem System und einmal der USB-Stick auf den das kopiert werden soll. Der interne Datenträger der Maschine, auf der grml läuft, ist völlig unbeteiligt. Das geht mir duch den Kopf: Kann das beim Kopieren eine Rolle spielen?

[hikaru]

Mir ist dein Szenario nicht ganz klar:
1. Du hast einen alten Stick mit einer Debianinstallation, die auch bootfähig ist. Richtig?
2. Du hast einen neuen Stick, auf dem du zwar bereits eine Partitionstabelle* und ein ext-Dateisystem hast, der aber ansonsten leer ist. Auch richtig?
3. Nun mountest du die Dateisysteme beider Sticks von einem Live-System aus und willst mit rsync die Inhalte des alten, auf den neuen Stick kopieren. Hat das funktioniert?

Wenn du bisher dreimal mit "ja" geantwortet hast, wo ist dann das Problem?


*) Man kann Datenträger - insbesondere USB-Sticks - auch ohne Partitionstabelle, als "Superfloppy" einrichten. Die haben dann aber keinen Platz für einen Bootloader.

[MSfree]

Man kann Datenträger - insbesondere USB-Sticks - auch ohne Partitionstabelle, als "Superfloppy" einrichten. Die haben dann aber keinen Platz für einen Bootloader.

Die ersten 512 Bytes einer "Superfloppy" sind immer für einen Bootloader reserviert. Es gibt aber seit dem Ende von lilo keinen Linuxloader mehr, der in diese 512 Bytes passen würde.

[rhHeini]

Bei meinen bisherigen (erfolgreichen) Klon-Aktionen mit rsync (ausschließlich mit HDDs) war immer der interne Datenträger irgendwie im Spiel. Es lief zwar immer über grml, aber entweder wurde von dem internen auf einen externen kopiert oder umgekehrt. Bei der aktuellen Aktion geht's um zwei externe Datenträger: einmal die über USB angeschlossene externe HDD mit dem System und einmal der USB-Stick auf den das kopiert werden soll. Der interne Datenträger der Maschine, auf der grml läuft, ist völlig unbeteiligt. Das geht mir duch den Kopf: Kann das beim Kopieren eine Rolle spielen?

Der einzige Unterschied zu einer internen HHD ist einfach das Du bei USB-Devices halt ein paar zusätzliche Schichten HW/SW dazwischen hast. Wenn da irgendetwas nicht ganz so tut wie vorgesehen kommt halt Murks raus. Da ist gar nichts geheimnisvolles dabei. Vor allem billige USB-Sticks sind öfters mal Elektronikschrott.
Egal ob dd oder rsync, man muss genau hinsehen auf Quelle und Ziel sowie die Optionen und die sauber spezifizieren.

[grubenlicht]

mal ganz unbedarft gefragt: Warum soll denn mit dem Terminal (rsync) gearbeitet werden? Solche Aktionen (ganze Partitionen) kopiere ich mit gparted, das zeigt mir in gewisser Weise auch optisch, ob ich das richtige gewählt habe.

[rhHeini]

Seit wann kann man mit gparted kopieren?

[grubenlicht]

k.A. ?schon immer?!

[rhHeini]

Hab gerade mal nachgesehen: im Partitions-Menu ist so eine Copy/Paste-Option drin. Hab ich aber immer auf Benennungen oder so etwas bezogen und noch nie für das Kopieren einer Partition genutzt.
Für mich ist gparted ein Tool zum Bearbeiten von Partitionseinstellungen und -Größen von Laufwerken, kein Kopiertool.

[fischig]

@hikaru

1. Du hast einen alten Stick mit einer Debianinstallation, die auch bootfähig ist. Richtig?

Nein. Die bootFÄHIGE Debianinstallation sitzt auf einer HDD. Die HDD ist nicht an die Maschine angeschlossen, über die mit grml und rsync kopiert werden soll.

2. Du hast einen neuen Stick, auf dem du zwar bereits eine Partitionstabelle* und ein ext-Dateisystem hast, der aber ansonsten leer ist. Auch richtig?

Richtig.

3. Nun mountest du die Dateisysteme beider Sticks von einem Live-System aus und willst mit rsync die Inhalte des alten, auf den neuen Stick kopieren.

Im Prinzip richtig, außer: das alte System sitzt auf einer HDD, nicht auf einem USB-Stick. und ich bin unsicher, ob dieser Unterschied relevant ist.

[grubenlicht]

Für mich ist gparted ein Tool zum Bearbeiten von Partitionseinstellungen und -Größen von Laufwerken, kein Kopiertool.

Deine Sache, für mich gehört das Kopieren ganzer Partitionen zum "Bearbeiten" von partitionierten Datenträgen halt dazu. Man kann sogar die Größe ändern beim Kopieren.
rsync steht für mich eher für das Syncronhalten zweierVerzeichnisse/Datenträger.
Jedem Tierchen sein Pläsierchen.

[grubenlicht]

Nein. Die bootFÄHIGE Debianinstallation sitzt auf einer HDD. Die HDD ist nicht an die Maschine angeschlossen, über die mit grml und rsync kopiert werden soll.

ähem, wie soll denn bitte synchronisiert werden, wenn die Quelle (Die bootFÄHIGE Debianinstallation sitzt auf einer HDD) nicht angeschlossen ist?

[fischig]

Die HDD ist nicht an die Maschine angeschlossen, über die mit grml und rsync kopiert werden soll.

Korrektur: die HDD ist nicht bootfähig an die Maschine angeschlossen, ...

[hikaru]

Nachdem nun also 1. richtiggestellt, sowie 2. und 3. bestätigt sind, wo ist das Problem?

Du machst nun das (als root):

Code: Alles auswählen

rsync -az -H --delete --numeric-ids /media/rootalt/ /media/rootneu/

Und danach ist auf rootneu nicht das Selbe wie auf rootalt?

[fischig]

Du machst nun das (als root):

Code: Alles auswählen

rsync -az -H --delete --numeric-ids /media/rootalt/ /media/rootneu/

Und danach ist auf rootneu nicht das Selbe wie auf rootalt?

Keine Ahnung. Ich fürchte aber ja.

Da zunächst kein Hinweis auf ein mögliches Problem kam, habe ich das rsync-Kommando mittlerweile ohne Auskunft angestoßen. Dummerweise habe ich auch versäumt, ihm den Parameter --progress mitzugeben. Der Rechner rödelt jetzt seit mehr als vier Stunden vor sich hin. Zu übertragen sind ca 20-40 GB/GiB (die genaue Zahl habe ich nicht notiert) und ich fürchte am Ende kommt genau das raus, was beim letzten Mal rauskam: Geschrotteter Stick.

[rhHeini]

Woran man auch denken muss: viele Sticks sind grottig langsam beim Schreiben, sobald der interne Cache so überhaupt vorhanden vollgeschrieben ist, besonders wenn viele kleine Dateien geschrieben werden müssen. In einem solchen Fall wird nach jeder Datei der Directory-Eintrag aktualisiert, macht zusätzlichen Overhead.

Dann kann es durchaus sein das die Daten noch nicht alle auf dem Stick sind auch wenn der Vorgang laut OS schon abgeschlossen ist. Zieh man den Stick dann vorschnell ab ist oft genug das Dateisystem kaputt.

[hikaru]

Wenn du zweistellige GB am Stück überträgst, kann es gerade bei billigen Sticks schon mal vorkommen, dass deren Controller wegen Überhitzung austeigt (und vielleicht nicht wiederkommt).
Ich würde vorschlagen, einen besseren Stick zu besorgen. Noch Besser wäre eine externe SSD. M.2-SSDs im passenden Gehäuse sind kaum größer als USB-Sticks.

[MSfree]

Code: Alles auswählen

rsync -az -H --delete --numeric-ids /media/rootalt/ /media/rootneu/

Ich sehe da ein "/" zu viel. Die Quelle sollte mit "/" am Ende angegeben werden, Das Ziel jedoch ohne "/" am Ende. Sonst befindet sich der Klon am Ende im Verzeichnis /media/rootneu/rootalt.

Code: Alles auswählen

rsync -az -H --delete --numeric-ids /media/rootalt/ /media/rootneu

[fischig]

Wenn du zweistellige GB am Stück überträgst, kann es gerade bei billigen Sticks schon mal vorkommen, dass deren Controller wegen Überhitzung aussteigt (und vielleicht nicht wiederkommt).

Na ja, es wäre dann bereits der dritte Stick in Folge. Das war ja der Ausgangspunkt meines Threads: Funktioniert auch mit Stick, was mit HDDs bisher problemlos funktionierte.

Noch Besser wäre eine externe SSD. M.2-SSDs im passenden Gehäuse sind kaum größer als USB-Sticks.

Erst mal eine neue mir sympathische alternative Idee. Mit M.2 habe ich keinerlei Erfahrung.
Wichtig wäre mir, dass ich die Maschine (auf der im Dauerbetrieb längst ein aktuelles bookworm auf der internen Platte läuft) mit dem vorhandenen stretch „von außen“ bei Bedarf booten kann und dafür nicht jedes mal die Systemplatte austauschen muss.

Aber warten wir erst mal ab, wie das Stick-Projekt tatsächlich endet.

edit:

Das Ziel jedoch ohne "/" am Ende.

Nach meinen diversen rsysnc-Erfahrungen vermute ich, dass der slash an dieser Stelle irrelevant ist. Aber ich werd's gelegentlich überprüfen.

[hikaru]

Ich sehe da ein "/" zu viel. Die Quelle sollte mit "/" am Ende angegeben werden, Das Ziel jedoch ohne "/" am Ende. Sonst befindet sich der Klon am Ende im Verzeichnis /media/rootneu/rootalt.

Code: Alles auswählen

rsync -az -H --delete --numeric-ids /media/rootalt/ /media/rootneu

Nein, das hier hier ist egal:

Code: Alles auswählen

$ mkdir -p rsync_test/a rsync_test/b
$ touch rsync_test/a/x
$ rsync -a rsync_test/a/ rsync_test/b/
$ ls rsync_test/*
rsync_test/a:
x

rsync_test/b:
x
$ touch rsync_test/a/y
$ rsync -a rsync_test/a/ rsync_test/b
$ ls rsync_test/*
rsync_test/a:
x  y

rsync_test/b:
x  y

Etwas Anderes wäre es, wenn du den "/" bei der Quelle weglassen würdest. Dann würden nicht die Inhalte der Quelle, sondern die Quelle selbst (samt Inhalten) im Ziel landen:

Code: Alles auswählen

$ rsync -a rsync_test/a rsync_test/b/
$ ls rsync_test/*
rsync_test/a:
x  y

$ ls rsync_test/b/
a  x  y
$ ls rsync_test/b/a
x  y