SSD Partition rootfs neu aufsetzen

  • Mahlzeit!

    Ich habe einen Raspberry Pi 4 4 GB. Der Pi läuft ohne SD auf einer SSD. Das neueste Image Raspberry Pi OS light Bullseye 64 bit ist am Laufen.

    Folgendes Gedankenspiel versuche ich in die Tat umzusetzen.

    Ich suche nach einer Funktion, den Pi neu aufzusetzen, wie es Windows 10 beispielsweise mit eigenen Bordmitteln gewährleistet. Ich habe auf der SSD mehrere Partitionen. Ich habe vor, die Partition rootfs und ggf. auch die boot Partition neu "aufzusetzen", um dann ein frisches System zu haben. Die Daten der anderen Partitionen könnte ich auf diesem Wege dann behalten.

    Ich habe mir von einer separat neu eingerichteten SD Karte rootfs und boot per dd als .img gespeichert. Wenn ich diese Images nun auf mein Produktivsystem zurückflashe, bootet der Pi nicht mehr (grüne LED blinkt). Wo liegt der Fehler?

    Für Antworten und Alternativen bin ich offen und würde mich sehr freuen!

    LG Karel :)

  • Ich weiß nicht, warum in aller Welt die Leute so unglaublich Geil auf das Tool 'dd' sind.

    Dieses Tool kopiert in dem Modus, der verwendet wird, alle möglich Fehler des Datenträgers mit (ok, bei SSD sind das nicht mehr so viele), doch zum sauberen Kopieren von Daten von einem zu einem anderen Datenträger, inklusive der Rechte, gibt es bessere Programme. Sogar welche, die das kopierenbei einem laufenden System sauber ermöglichen.

    'dd' macht das nicht.

    Computer ..... grrrrrr

  • Deswegen schrieb ich ja, dass ich für Alternativen offen bin. Ist des das Vorgehen, losgelöst von 'dd' für dich nachvollziehbar?

    Ich habe, um ein PI-OS von einer SD auf eine SSD zu kopieren, einen anderen PI genommen, bei dem ich die jeweiligen Partitionen gemount hatte, um dann mittels "tar" die Dateien von der Quelle (im folgenden Befehl das aktuelle Verzeichnis) in das Ziel (im folgenden Befehl /target)zu kopieren.

    tar cf - * | ( cd /target; tar xfp -)

    Dann mussten auf den Ziel nur noch in der /boot/cmdline.txt und n der /etc/fstab des neuen Datenträgers die passenden PARTUUIDs eingetragen werden, so dass dann der PI von diesem Datenträger bootete.

    Dadurch, dass man z.B. das ganze nicht per DD macht, werden auch die UUIDs der Partitionen nicht nicht mit denen des alten Umgebung überschrieben.

    Computer ..... grrrrrr

  • Ich verstehe den TO zu 100%.

    Es ist echt nervig, wenn man sich nen Datenträger (hier SSD) unter einer älteren Version eingerichtet, /home auf eine eigene Partition ausgelagert, dann diverse Verzeichnisse liebevoll angelegt, gefüllt, verlinkt, das System/den User final eingerichtet und, und, und ... hat und dann, mit ner neuen Version, muss man das alles noch mal von vorne machen???

    Da ich auf allen Systemen Ubuntu Mate betreibe (auch auf den RPi4's) und auf den Raspis es das gleiche Dilemma ist wie auch mit Raspberry Pi OS - bei den PCs es aber schon beim Partitionieren ganz einfach ist, nur die Systempartition zu formatieren/aktualisieren, die ausgelagerte /home aber nur eingebunden werden muss - und beim Raspi bei allen mir bekannten Wegen (dd bewußt jetzt ignoriert, siehe Kommentar von rasp-Berlin) es eigentlich immer(!) auf "komplett Platt machen und alles neu aufsetzen" hinausläuft, wäre auch ich sehr an den Luxus einer individuellen Partitionierung und selektivem Auspielen der beiden Partitionen /boot und /root (oder wie immer die in den einzelnen Distros heißen) sehr interessiert.

    Was ich bisher so (anfangs vielleicht noch erfolgreich) probiert hatte bzw. noch ausprobieren/optimieren wollte:

    Bei kleinen SSDs geht es ja noch, wenn man vorher von der ausgelagerten ( :gk1: Idee: vor dem Image verkleinern? ist aber schon wieder von hinten über die Brust ins Auge...) /home ein Image zieht, die SSD dann mit dem Imager neu bespielt und vor dem ersten Booten mühsam /root wunschgemäß vergrößert, /home zurück speichert, (Idee: dann wieder Größe anpasst) und in der fstab einträgt, damit sie dann beim ersten Booten eingebunden ist, wenn man dann den User anlegt (bzw. in früheren Versionen von Raspberry Pi OS "umzieht").

    Das ist eine umständliche Lösung für kleine Datenträger (ich sag mal so bis 120GB - die Schmerzgrenze ist aber sicher sehr indiviuell gelegen), aber ab ner gewissen Größe zu zeitaufwändig.

    Alternativ
    kann man das neue System erst mal auf nen USB aufspielen, die beiden angelegten Partitionen als Image sichern und dann auf die SSD neu aussetzen - das große Problem dabei ist aber, dass man da in Probleme bei den Partitionsgrößen rennt (und da geht es um Sektoren, wenn ich mir das richtig zusammen gereimt habe). Ist man also schon wieder schnell nass.

    Theoretisch könnte man sich dieses Vorgehen von Anfang an angewöhnen (also bevor man eine /home überhaupt zum ersten Mal ausgelagert hat) immer den gleichen USB (mit der optimalen Größe für /boot und /root) und SSD nehmen, nach dem Neu-Bespielen des USB jedemal händisch die Größe von /root maximieren (aber es gibt keine Garantie, dass bei künftigen Versionen dieses Vorgehen erfolgreich bleibt, denn wenn sich die Größe von /boot ändert, kann alles für den Eimer gewesen sein...)

    Ah, und /home müsste man wohl besser als Primäre Partition (statt erweiterte) einrichten - und es wäre sinnvoll, etwas ungenutzen Platz zwischen /boot, /root "vorne" und /home "hinten" zu lassen, dann wäre eine Größenänderung bei den beiden ersten wohl nicht weiter tragisch.

    Alle meine (halbgaren) Lösungen und Ideen verlangen aber eine gewisse Grundkenntnis der Datenträgerverwaltung - Neulingen rate ich wegen den Gefahren durch Fehler, die man normalerweise macht, dringend ab. (Bei USBs ist ein totalverlust vielleicht noch zu verschmerzen, bei SSds finde ich, hört der Spaß aber echt auf - und das kann echt passieren, wenn es dumm läuft)

    Wenn endlich Ubuntu Mate 22.04 für den RPi4 rauskommt, werde ich den Ansatz mal testen (indem ich mal hin und her wechsle zwischen Mate und Raspi OS.

    Kann ja dann berichten, ob das "Geschwurbels" (eine saubere Lösung sieht definitiv anders aus) erfolgreich war.

    ---

    Kein Backup? Kein Mitleid :evil:
    [we all live in a yellow subroutine...]

  • Neu aufsetzen heisst fuer mich "neu installieren". Mir scheint Du verstehst unter "neu aufsetzen" ein clonen :conf: Warum willst Du "neu aufsetzen". U.U. gibt es einfachere Wege Dein Problem zu loesen ;)

    Hi framp!

    Neu aufsetzten heißt auch für mich neu installieren. :)

    Klar hat meine Vorgehensweise viel mit Klonen zu tun. Allerdings klone ich ja ein brandneues System damit auf meine "alte" SSD, ohne die anderen Partitionen zu verlieren. Vielleicht habe ich ja einen Nagel im Kopf. Aber mir fällt gerade keine andere Möglichkeit ein, das zu realisieren.

    Warum ich neu aufsetzen möchte ist, weil ich einfach ein frisches System haben möchte, welches nicht größer ist, als es sein muss, z.B. durch nicht mehr benötigte Programme. Ich möchte außerdem Linux besser kennen lernen und tüfteln und probieren. Ich habe riesen Spaß daran gefunden. Das System läuft indes einwandfrei.

  • Ich habe, um ein PI-OS von einer SD auf eine SSD zu kopieren, einen anderen PI genommen, bei dem ich die jeweiligen Partitionen gemount hatte, um dann mittels "tar" die Dateien von der Quelle (im folgenden Befehl das aktuelle Verzeichnis) in das Ziel (im folgenden Befehl /target)zu kopieren.

    tar cf - * | ( cd /target; tar xfp -)

    Dann mussten auf den Ziel nur noch in der /boot/cmdline.txt und n der /etc/fstab des neuen Datenträgers die passenden PARTUUIDs eingetragen werden, so dass dann der PI von diesem Datenträger bootete.

    Dadurch, dass man z.B. das ganze nicht per DD macht, werden auch die UUIDs der Partitionen nicht nicht mit denen des alten Umgebung überschrieben.

    mit tar. Alles klar. Den Vorschlag gucke ich mir in Ruhe genauer an!

  • Ich habe, um ein PI-OS von einer SD auf eine SSD zu kopieren, einen anderen PI genommen, bei dem ich die jeweiligen Partitionen gemount hatte, um dann mittels "tar" die Dateien von der Quelle (im folgenden Befehl das aktuelle Verzeichnis) in das Ziel (im folgenden Befehl /target)zu kopieren.

    tar cf - * | ( cd /target; tar xfp -)

    Dann mussten auf den Ziel nur noch in der /boot/cmdline.txt und n der /etc/fstab des neuen Datenträgers die passenden PARTUUIDs eingetragen werden, so dass dann der PI von diesem Datenträger bootete.

    Dadurch, dass man z.B. das ganze nicht per DD macht, werden auch die UUIDs der Partitionen nicht nicht mit denen des alten Umgebung überschrieben.

    Habe ich getestet. Wie realisierst du es, dass alte Dateien entfernt werden? So hängt 'tar' ja nur an, richtig?

  • Wie realisierst du es, dass alte Dateien entfernt werden? So hängt 'tar' ja nur an, richtig?

    Die Anpassung der beiden Dateien müsste man per 'sed' machen, den das 'tar' nimmt alle aus dem Quellverzeichnis und den Unterverzeichnissen, die nicht gemountet sind, und schreibt sie so, wie sie sind auf das Ziel (also auch Hard- und Softlinks) Inklusive der Rechte und Co. (wie es ist erweiterten Rechten ist, habe ich aber nicht ausprobiert)

    Computer ..... grrrrrr

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!