RaspiOS installieren ohne komplette SD bzw. Datenträger(partition) dabei zu löschen

Heute ist Stammtischzeit:
Jeden Donnerstag 20:30 Uhr hier im Chat.
Wer Lust hat, kann sich gerne beteiligen. ;)
  • Hallo, ich hoffe ich habe im richtigen tread platziert.

    Ich hätte gerne gewusst, ob ich ein RaspiOS auf eine SD (bzw. SSD (spielt ja keine Rolle)) aufspielen kann, ohne das mit bei der Installation der ganze Datenträger gelöscht wird.

    Konkret habe ich auf meiner SSD 3 Partitionen - Die FAT und EXT4 für das RaspiOS und noch eine weitere, in diesem Falle eine NTFS - Spielt aber eigentlich keine Rolle.

    Wie kann ich bei einer kompletten Neuinstallation des RaspiOS eine Partition auf der Festplatte und somit die Daten darauf unberührt lassen?

    Mit dem Standard "Balena Etcher" geht das ja nicht, der killt immer den kompletten Datenträger.

    Kann ich das RaspiOS Image irgendwie zerlegen und jeweils in eine FAT bzw EXT4 Partition selbsständig kopieren - und...vermutlich muss ich dann noch die FAT Partition bootfähig machen - oder gibt es da andere Lösungen dafür, die nicht so kompliziert und arbeitsintensiv sind?

    Hat Jemand hierfür eine Lösung? - Wenn ich mir ein Windows installiere muss ich ja auch nicht automatisch alle Partitionen auf der Platte löschen, nur damit sich das Betriebssytem in ein bis zwei eigenen, neuen Partitionen anlegt.

    Über Sinn und Zweck kann man natürlich streiten - Allerdings probiere ich gerne aus und bin mit Linux nicht so bewandert, das ich mir immer mal wieder Fehler reinziehe, die ich aktuell nicht anders gelöst bekomme, als ein Betriebssystem wieder neu aufzuspielen.

    Freue mich auf eine Antwort, Gruß Dirk

  • RaspiOS installieren ohne komplette SD bzw. Datenträger(partition) dabei zu löschen? Schau mal ob du hier fündig wirst!

  • Kann ich das RaspiOS Image irgendwie zerlegen und jeweils in eine FAT bzw EXT4 Partition selbsständig kopieren -

    Gehen tut das schon. Aber nicht unter Windows.

    Und die beiden Zielpartitionen müssen vorher entsprechend eingerichtet (partitioniert) sein.

    Wie ist denn die Ausgabe von

    fdisk -l /dev/DeineSSD

    fdisk -l /Pfad/zum/ImageFile

    Eine andere Methode (Holzhammermethode) wäre den sichtbaren Speicherbereich der SSD auf die Installationsgrösse des Imagefiles einzuschränken, und nach flashen mit Etcher und Berichtigung der Partitionstabelle wieder auszudehnen.

    Servus !

    RTFM = Read The Factory Manual, oder so

  • Meine Theorie dazu ist (man möge mich berichtigen). Den Datenträger mit den drei Partitionen an ein Linux System anschliessen. Das aktuelle RaspberryPi OS Image auf das Linux System laden und mounten (ich hoffe das geht?). Dann die beiden (/boot und /) Partitionen auf Dateiebene (mit z.B. cp) auf den Datenträger mit den drei Partitionen kopieren.

    RaspberryPi OS hat noch einen Mechanismus, welcher beim (nur?) ersten Start versucht die Root Partition an das Ende des Datenträgers auszudehnen. Falls der anschlägt, wäre ggf. die dritte Partition weg. Für den Fall muss man Gegenmassnahmen treffen.

  • Dann die beiden (/boot und /) Partitionen auf Dateiebene (mit z.B. cp) auf den Datenträger mit den drei Partitionen kopieren.

    Nicht mit "cp" kopieren, auch weil "cp" für sich nicht durch den Verzeichnisbaum geht und auch, für sich, ohne weiteren Parameter, nicht die Dateirechte erhält.

    Mit

    Code
    tar cf - . | (cd /dst; tar xvf -)

    erhält man eine saubere Kopie des Verzeichnisses, und aller Unterverzeichnisse, Hard- und Softlinks, in dem man die Zeile aufruft und das Verzeichnung /dst

    Es werden dabei alle vorhandenen Dateien im Zielverzeichnis überschrieben, angepasste Config-Dateien sollte man also vorher sichern.

    (Die Zeile ist natürlich als 'root' auszuführen, wenn man das gesamte System kopieren will)

    Computer ..... grrrrrr

  • Gehen tut das schon. Aber nicht unter Windows.

    Und die beiden Zielpartitionen müssen vorher entsprechend eingerichtet (partitioniert) sein.

    Hi, RTFM - Ist mir klar, daß Windows dazu ungeeignet sein können - War ja nur ein Vergleich. Die Partitionen kann ich vorher partitionieren. Würde zB mit gparted aus einer Ubuntu Umgebung einer VM gehen.

    Zitat

    Eine andere Methode (Holzhammermethode) wäre den sichtbaren Speicherbereich der SSD auf die Installationsgrösse des Imagefiles einzuschränken, und nach flashen mit Etcher und Berichtigung der Partitionstabelle wieder auszudehnen

    Aber das wäre ja das Problem - meines Wissens nach, machen Programme wie Etcher alles Auf dem Speichermedium "platt" - Also zumindest dürften die Partitionstabellen gelöscht werden. Somit auch meine dritte Partition, die ja erhalten bleiben soll. Habe es zwar noch nicht probiert, aber natürlich könnte ich die Raspi Partitionen FAT und EXT4 auflösen, so das ein Etcher den freien Bereich wieder zur installation nutzen kann - Aber wie oben erwähnt, meine ich mich zu erinnern, das Etcher alles "platt" macht.

  • Meine Theorie dazu ist (man möge mich berichtigen). Den Datenträger mit den drei Partitionen an ein Linux System anschliessen. Das aktuelle RaspberryPi OS Image auf das Linux System laden und mounten (ich hoffe das geht?). Dann die beiden (/boot und /) Partitionen auf Dateiebene (mit z.B. cp) auf den Datenträger mit den drei Partitionen kopieren.

    Aber das wäre doch letztendlich ein Backup - Oder verstehe ich das falsch?

    Ein Backup würde in dem Falle aber nichts bringen, wenn das Betriebsystem bereits "beschädigt" ist. Höchstens natürlich man erzeugt immer wieder Backups und sichert diese, um dann im "Notfall" wieder zurückspielen zu können. Dummerweise wären 1:1 Backups aber dann glaube ich immer wieder so groß wie die (vergrößerte) Partition (auch wenn dort viele Bereiche noch leer sind). Es sei den beim Backup wird gepackt - Ein Packer xxxzip dürfte den leeren Bereich rausrechnen)

    Zitat

    RaspberryPi OS hat noch einen Mechanismus, welcher beim (nur?) ersten Start versucht die Root Partition an das Ende des Datenträgers auszudehnen. Falls der anschlägt, wäre ggf. die dritte Partition weg. Für den Fall muss man Gegenmassnahmen treffen

    Weiß ich jetzt nicht aus dem Stehgreif, aber ich glaube der Raspi mach es nicht automatisch, man muss es schon in der raspi-config anstoßen (oder so). Ich erweitere die EXT4 Partition immer extern mit gparted unter Ubuntu. Damit erstelle ich dann auch gleich meine dritte Partition.

  • Der Etcher macht alles platt. Warum flashst Du nicht das Betriebssystem erstmal auf Dein Laufwerk, startest davon, lässt den diesen "recize Vorgang" abschließen, ausschalten und auf einem anderen Linux oder Raspi via gparted die "root" Partition verkleinern. Aus dem "unallocated Diskspace dann eine ntfs Partition oder was auch immer erstellst.

  • Hi repa1971,

    das löst aber glaube ich nicht meine Frage - Oder?

    Ich möchte ein Raspi OS auf einen Datenträger installieren, auf dem zwar genug nicht zugewiesener Speicherplatz ist, aber ebenso bereits eine existierende Partition, die nicht angerührt werden sollte.

    Eine Partition vergrößeren/verkleinern war nie das Problem, sondern wie bekomme ich ein RaspiOS auf einen Datenträger ohne daß dabei vorhandene Partitionen zerstört werden.

  • Ich verstehe Dich schon. Von daher kannst Du den Etcher oder was auch immer nicht verwenden sondern musst alles händisch herum kopieren. Wenn das denn so funktionieren sollte.

  • Ich habe zwar keine praktischen Erfahrungen mit cp, aber ich hätte angenommen, das mit der Option -a, --archive und ggf. anderen Optionen(?) alle Dateien samt Attribute kopiert werden. Ist dem nicht so?

    Die tar Syntax ist mir auch fremd. Wird bei deinem Aufruf ein Archiv angelegt und dieses dann am Ziel wieder entpackt? MIt tar wird von Vorne bis Ende geschrieben und nicht auf Dateisystemebene?

    Eine weitere Alternative könnte rsync sein.

  • Aber das wäre doch letztendlich ein Backup - Oder verstehe ich das falsch?

    Ich denke schon. Du möchtest doch die letzte Partition (NTFS) nicht anfassen und nur die ersten beiden (/boot - FAT und / EXT4) für die "komplette Neuinstallation" benutzen. Das heruntergeladene aktuelle RaspberryPi OS Image ist ja immer (soweit mir bekannt) die Grundlage und einzige Möglichkeit für eine Neuinstallation. Sprich, wenn du die Daten von diesem Image kopierst, hast du das aktuelle RaspberryPi OS "installiert". Beim Booten sollte die Grundkonfiguration auftauchen, bzw. gemacht werden und dann das übliche apt update/dist-upgrade.

  • Wie ist denn die Ausgabe von

    fdisk -l /dev/DeineSSD

    fdisk -l /Pfad/zum/ImageFile

    Was für ein Imagefile?

    Das RaspiOS Image file liegt auf meiner Windows HD und das kann ich mit fdisk nicht ansprechen.

    Oder meinst Du die RaspiOS Partitionen SDA1 & SDA2?

    die wären hier:

    Die FAT Bootpartition

    Disk /dev/sda1: 256 MiB, 268435456 bytes, 524288 sectors

    Units: sectors of 1 * 512 = 512 bytes

    Sector size (logical/physical): 512 bytes / 512 bytes

    I/O size (minimum/optimal): 512 bytes / 33553920 bytes

    Disklabel type: dos

    Disk identifier: 0x00000000

    Die RaspiOS EXT4 Partition (wurde vergrößert)

    Disk /dev/sda2: 9,8 GiB, 10485760000 bytes, 20480000 sectors

    Units: sectors of 1 * 512 = 512 bytes

    Sector size (logical/physical): 512 bytes / 512 bytes

    I/O size (minimum/optimal): 512 bytes / 33553920 bytes


    Hier meine dritte große (NTFS) Partition.

    Disk /dev/sda3: 921,5 GiB, 989445750784 bytes, 1932511232 sectors

    Units: sectors of 1 * 512 = 512 bytes

    Sector size (logical/physical): 512 bytes / 512 bytes

    I/O size (minimum/optimal): 512 bytes / 33553920 bytes

    Disklabel type: dos

    Disk identifier: 0x00000000


    Hier die Zusammenstellung:

    Device Boot Start End Sectors Size Id Type

    /dev/sda1 8192 532479 524288 256M c W95 FAT32 (LBA)

    /dev/sda2 532480 21012479 20480000 9,8G 83 Linux

    /dev/sda3 21012480 1953523711 1932511232 921,5G 7 HPFS/NTFS/exFAT

  • Die tar Syntax ist mir auch fremd. Wird bei deinem Aufruf ein Archiv angelegt und dieses dann am Ziel wieder entpackt?

    Das tar vor der Pipe nimmt die Dateien vom aktuellen Verzeichnis (".") und schreibt sie nach STDOUT ("-"), nach der Pipe wird eine Subshell geöffnet, wechselt in das Zielverzeichnis und das 2. tar nimmt von STDIN die Archivinhalte/Dateien entgegen und schreibt sie dateiweise (entpackt, "x") auf das Dateisystem.

    Wenn du nichts zu sagen hast, sag einfach nichts.

  • Ich denke schon. Du möchtest doch die letzte Partition (NTFS) nicht anfassen und nur die ersten beiden (/boot - FAT und / EXT4) für die "komplette Neuinstallation" benutzen. Das heruntergeladene aktuelle RaspberryPi OS Image ist ja immer (soweit mir bekannt) die Grundlage und einzige Möglichkeit für eine Neuinstallation. Sprich, wenn du die Daten von diesem Image kopierst, hast du das aktuelle RaspberryPi OS "installiert". Beim Booten sollte die Grundkonfiguration auftauchen, bzw. gemacht werden und dann das übliche apt update/dist-upgrade.

    Ja genau die boot FAT und die OS EXT4 ersetzen.

    Du meinst also (als Beispiel), ich lasse mir mit Etcher eine neue zweite SD (SD2) o.ä. erstellen.

    Anschliesend lösche ich den kompletten Inhalt des alten RaspiOS auf der ersten SD (SD1), also der FAT und der EXT4.

    Danach kopiere ich den Inhalt aus FAT und EXT4 der SD2 in die eben gelöschten SD1 FAT und EXT4 Partitionen

    Richtig? - Ob das geht und das System startet ?

  • Danke llutz! "." und "-" kannte ich nicht in diesem Zusammenhang. Dateiweises lesen/schreiben, check. :) Ich nehme auch an, dass das Archiv nicht erst im Ganzen erstellt wird, sondern ein I/O Puffer benutzt wird.

  • Das Imagefile, das Du auf die SSD P1 und P2 installieren willst.

    Wenn Du remote (z.B. CIFS) keinen Zugriff hast, dann kopiere das .img auf die NTFS Partition Nr.3 der SSD.

    Servus !

    Ok, das wäre letztendlich das jungfräuliche RaspiOS Image (2020-08-20-raspios-buster-armhf.img).

    Habe es mal auf die NTFS Partition geschoben und mit fdsisk abgefragt.

    Das würde dann so aussehen:

    Disk /media/ntfs/RaspiOS.img: 3,6 GiB, 3821010944 bytes, 7462912 sectors

    Units: sectors of 1 * 512 = 512 bytes

    Sector size (logical/physical): 512 bytes / 512 bytes

    I/O size (minimum/optimal): 512 bytes / 512 bytes

    Disklabel type: dos

    Disk identifier: 0x58ce116e

Jetzt mitmachen!

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