Zwei Partitionen müssen vergrößert werden, spezielle Anforderungen
Zwei Partitionen müssen vergrößert werden, spezielle Anforderungen
Hi Leute,
ich möchte auf einem Laptop zwei Partitionen vergrößern. Die im Titel genannten "speziellen Anforderungen:
Es geht um sda7 und sda8. Beide Partitionen sind mit luks verschlüsselt, sda8 ist swap, sda7 ist "alles" (also /) und XFS. Wie gehe ich sinnvollerweise vor (alles von einem live-grml, denke ich)?
grml booten, sda8 löschen (und hinterher neu generieren), soweit klar. Aber dann?
Oder geht es auch ohne Löschen von sda8?
ich möchte auf einem Laptop zwei Partitionen vergrößern. Die im Titel genannten "speziellen Anforderungen:
Es geht um sda7 und sda8. Beide Partitionen sind mit luks verschlüsselt, sda8 ist swap, sda7 ist "alles" (also /) und XFS. Wie gehe ich sinnvollerweise vor (alles von einem live-grml, denke ich)?
grml booten, sda8 löschen (und hinterher neu generieren), soweit klar. Aber dann?
Oder geht es auch ohne Löschen von sda8?
Re: Zwei Partitionen müssen vergrößert werden, spezielle Anforderungen
Mach' auf jeden Fall vorher ein Backup!
Platz ist mittlerweile ja kein Problem mehr und mit dd kann man Images erstellen, die man notfalls auch mounten kann. Wie sieht es denn mit der aktuellen Version von gparted aus? Das ist doch bei grml dabei, oder nicht mehr?
Gruß
Gregor
Wenn man keine Probleme hat, kann man sich welche machen. ("Großes Lötauge", Medizinmann der M3-Hopi [und sog. Maker])
-
- Beiträge: 169
- Registriert: 03.09.2020 04:48:45
Re: Zwei Partitionen müssen vergrößert werden, spezielle Anforderungen
Ich mache schon mal was Ähnliches, wenn ich eine Debian-Installation auf eine andere Partition oder gar einen anderen Rechner kopiere. Dabei geht's normalerweise um ext2- oder ext3-Partitionen.
Zunächst mal starte ich ein Linux, das nicht dasselbe ist wie jenes, das ich kopieren will. Das kann ein zweites auf demselben Rechner installiertes Linux sein, oder auch eines von einer Live-CD. Dann lege ich mit dd eine Kopie der Partition an und überprüfe, ob ich die Kopie auch "mount-bar" ist. Wenn nicht, müsste ich abbrechen und 'rausfinden, wieso das nicht geht.
Nun gehe ich ggf. zum "Ziel-Rechner" und starte auch dort ein Linux, das nicht dort liegt, wo die kopierte Installation gleich hin kommt. Auch das kann eine Live-CD oder ein zweites installiertes Linux auf dem Ziel-Rechner sein.
Dann sorge ich dafür, dass die Partitionierung der Platte des Ziel-Rechners gesichert wird. Das mache ich auch mit dd, indem ich den Partitionssektor kopiere. Eine GPT-partitionierte Platte habe ich aber bisher nie so bearbeitet - keine Ahnung, ob das da auch geht.
Jetzt kann man schon mal die mit dd kopierte Partition auf dem Ziel-Rechner mounten und bei Problemen wieder nach dem Fehler suchen.
Spätestens an dieser Stelle sollte man die Platte des Ziel-Rechners "backuppen", denn im Folgenden finden Veränderungen auf der Ziel-Platte statt.
Jetzt ändere ich ggf. die Partitionierung der Ziel-Platte (z.B. wenn ich die Zielpartition vergrößern will). Dann kriegt die Zielpartition ggf. eine passende Formatierung. Bei mir muss für beide Dinge hier dann dasselbe Dateisystem benutzt werden, das ursprünglich für die zu Beginn mit dd gemachte Partitionskopie vorlag. Wahrscheinlich kann man zwar auch ein ext2- in ein ext3-Dateisystem umwandeln oder umgekehrt, ausprobiert habe ich das aber nie.
Ist nun die Zielpartition hübsch formatiert, dann wird sie gemounted. Anschließend kopiere ich mit cp -vuRp QUELLE/* ZIEL den Inhalt der dd-Kopie der ursprünglichen Partition auf die Zielpartition. QUELLE ist dabei das Verzeichnis, in dem die mit dd erstellte Partitionskopie gemountet wurde, und ZIEL ist der Name des Verzeichnisses, das den mount-point für die formatierte neue Partition darstellt. Ich kopiere also alle Dateien vom Verzeichnis QUELLE ins Verzeichnis ZIEL, mitsamt allen Unterverzeichnissen usw..
Nach dieser Kopieraktion muss ich ggf. noch einen Bootloader, die /etc/fstab und ähnlichen Kram anpassen, und dann kann ich das neue alte System schon mal starten. Danach tipp' ich mir beim Umkonfigurieren des Systems die Finger wund.
In ein oder zwei Fällen habe ich statt "cp -vuRp" auch mal "cp -vRp" gewählt, also alle evtl. auf der frisch formatierten Partition existierenden Dateien überschrieben. Das könnte für das ext3-Journal relevant sein. Genauer erforscht habe ich eventuelle Probleme damit aber nicht.
Mein Verfahren hat nur in zwei Fällen Probleme ausgelöst. In beiden Fällen wurden ext2-Partitionen alter Installationen von Debian 4.0_r8 (also steinaltes Zeuch) mit veränderter Größe irgendwo hin verpflanzt, wobei die Quelle kleiner als 2 GByte und das Ziel größer als 2 GByte waren, oder umgekehrt. Das führte dazu, dass das neue System fast bei jedem Booten, bei dem anschließend eine e2fsck-Prüfung des Dateisystems stattfand, Fehler meldete und ein Neubooten verlangte. Ich vermute, dass das mit der Größenveränderung über irgendeine kritische Grenze (meine Vermutung: die ominösen 2 GByte) hinweg zusammen hängt, habe es aber nie überprüft. Mit ext3-Partitionen trat es bisher nie auf, und für ein steinaltes Debian 4 habe ich kaum noch Verwendung. Da bin ich dann für 'ne Fehlersuche zu faul...
So würde ich es auch mit der Root-Partition im vorliegenden Fall versuchen, und dabei besonders auf ein möglichst funktionierendes Backup der Ursprungssituation Wert legen. Die Swap-Partition hingegen würde ich einfach in der neuen Größe neu erstellen und formatieren. Sowas hat bei mir normalerweise auch immer geklappt.
Zunächst mal starte ich ein Linux, das nicht dasselbe ist wie jenes, das ich kopieren will. Das kann ein zweites auf demselben Rechner installiertes Linux sein, oder auch eines von einer Live-CD. Dann lege ich mit dd eine Kopie der Partition an und überprüfe, ob ich die Kopie auch "mount-bar" ist. Wenn nicht, müsste ich abbrechen und 'rausfinden, wieso das nicht geht.
Nun gehe ich ggf. zum "Ziel-Rechner" und starte auch dort ein Linux, das nicht dort liegt, wo die kopierte Installation gleich hin kommt. Auch das kann eine Live-CD oder ein zweites installiertes Linux auf dem Ziel-Rechner sein.
Dann sorge ich dafür, dass die Partitionierung der Platte des Ziel-Rechners gesichert wird. Das mache ich auch mit dd, indem ich den Partitionssektor kopiere. Eine GPT-partitionierte Platte habe ich aber bisher nie so bearbeitet - keine Ahnung, ob das da auch geht.
Jetzt kann man schon mal die mit dd kopierte Partition auf dem Ziel-Rechner mounten und bei Problemen wieder nach dem Fehler suchen.
Spätestens an dieser Stelle sollte man die Platte des Ziel-Rechners "backuppen", denn im Folgenden finden Veränderungen auf der Ziel-Platte statt.
Jetzt ändere ich ggf. die Partitionierung der Ziel-Platte (z.B. wenn ich die Zielpartition vergrößern will). Dann kriegt die Zielpartition ggf. eine passende Formatierung. Bei mir muss für beide Dinge hier dann dasselbe Dateisystem benutzt werden, das ursprünglich für die zu Beginn mit dd gemachte Partitionskopie vorlag. Wahrscheinlich kann man zwar auch ein ext2- in ein ext3-Dateisystem umwandeln oder umgekehrt, ausprobiert habe ich das aber nie.
Ist nun die Zielpartition hübsch formatiert, dann wird sie gemounted. Anschließend kopiere ich mit cp -vuRp QUELLE/* ZIEL den Inhalt der dd-Kopie der ursprünglichen Partition auf die Zielpartition. QUELLE ist dabei das Verzeichnis, in dem die mit dd erstellte Partitionskopie gemountet wurde, und ZIEL ist der Name des Verzeichnisses, das den mount-point für die formatierte neue Partition darstellt. Ich kopiere also alle Dateien vom Verzeichnis QUELLE ins Verzeichnis ZIEL, mitsamt allen Unterverzeichnissen usw..
Nach dieser Kopieraktion muss ich ggf. noch einen Bootloader, die /etc/fstab und ähnlichen Kram anpassen, und dann kann ich das neue alte System schon mal starten. Danach tipp' ich mir beim Umkonfigurieren des Systems die Finger wund.
In ein oder zwei Fällen habe ich statt "cp -vuRp" auch mal "cp -vRp" gewählt, also alle evtl. auf der frisch formatierten Partition existierenden Dateien überschrieben. Das könnte für das ext3-Journal relevant sein. Genauer erforscht habe ich eventuelle Probleme damit aber nicht.
Mein Verfahren hat nur in zwei Fällen Probleme ausgelöst. In beiden Fällen wurden ext2-Partitionen alter Installationen von Debian 4.0_r8 (also steinaltes Zeuch) mit veränderter Größe irgendwo hin verpflanzt, wobei die Quelle kleiner als 2 GByte und das Ziel größer als 2 GByte waren, oder umgekehrt. Das führte dazu, dass das neue System fast bei jedem Booten, bei dem anschließend eine e2fsck-Prüfung des Dateisystems stattfand, Fehler meldete und ein Neubooten verlangte. Ich vermute, dass das mit der Größenveränderung über irgendeine kritische Grenze (meine Vermutung: die ominösen 2 GByte) hinweg zusammen hängt, habe es aber nie überprüft. Mit ext3-Partitionen trat es bisher nie auf, und für ein steinaltes Debian 4 habe ich kaum noch Verwendung. Da bin ich dann für 'ne Fehlersuche zu faul...
So würde ich es auch mit der Root-Partition im vorliegenden Fall versuchen, und dabei besonders auf ein möglichst funktionierendes Backup der Ursprungssituation Wert legen. Die Swap-Partition hingegen würde ich einfach in der neuen Größe neu erstellen und formatieren. Sowas hat bei mir normalerweise auch immer geklappt.
Re: Zwei Partitionen müssen vergrößert werden, spezielle Anforderungen
Dein Vorgehen ist viel zu umständlich und enthält teilweise überflüssige Aktionen. Voraussetzung für das Folgende ist immer ein Livesystem wie z.B. grml.
Möglichkeit a) - Quelle ist eine externe Festplatte /dev/sdc, Ziel ist /dev/sda:
ddrescue /dev/sdc /dev/sda --force
Möglichkeit b) - Quelle ist ein anderer Rechner, beide sind per LAN erreichbar:
Quellrechner: dd if=/dev/sda status=progress | nc 192.168.1.161 41339
Zielrechner: nc -lp 41339 | dd of=/dev/sdb status=progress
Das ist auf Platten-Ebene. Es gibt auch noch eine vergleichbare Möglichkeit, einfach die gemounteten Partitionen auf einen neu eingerichteten Rechner zu kopieren, dann muss dort aber vorher manuell partitioniert und grub eingerichtet werden:
Quelle: tar cfv - / --numeric-owner --exclude "/proc/*" --exclude "/sys/*" --exclude "/tmp/*" | nc ZIELRECHNER 4242
Auf dem Ziel auf die (formatierte und gemountete) Zielpartition wechseln, dort: nc -q 30 -l 4242 | tar xf -
Das geht aber ziemlich an meiner Fragestellung vorbei.
Möglichkeit a) - Quelle ist eine externe Festplatte /dev/sdc, Ziel ist /dev/sda:
ddrescue /dev/sdc /dev/sda --force
Möglichkeit b) - Quelle ist ein anderer Rechner, beide sind per LAN erreichbar:
Quellrechner: dd if=/dev/sda status=progress | nc 192.168.1.161 41339
Zielrechner: nc -lp 41339 | dd of=/dev/sdb status=progress
Das ist auf Platten-Ebene. Es gibt auch noch eine vergleichbare Möglichkeit, einfach die gemounteten Partitionen auf einen neu eingerichteten Rechner zu kopieren, dann muss dort aber vorher manuell partitioniert und grub eingerichtet werden:
Quelle: tar cfv - / --numeric-owner --exclude "/proc/*" --exclude "/sys/*" --exclude "/tmp/*" | nc ZIELRECHNER 4242
Auf dem Ziel auf die (formatierte und gemountete) Zielpartition wechseln, dort: nc -q 30 -l 4242 | tar xf -
Das geht aber ziemlich an meiner Fragestellung vorbei.
Re: Zwei Partitionen müssen vergrößert werden, spezielle Anforderungen
Du schreibst, du willst sda7/8 vergrößern. Aber wo nimmst du den Platz her? Liegen auf dem Speichermedium noch ungenutzte Blöcke herum?ich möchte auf einem Laptop zwei Partitionen vergrößern.
Generell sind die Schritte:
- Partition vergrößern
- luks vergrößern
- Dateisystem vergrößern (Ob und wie das bei xfs funktioniert? Keine Ahnung.)
Re: Zwei Partitionen müssen vergrößert werden, spezielle Anforderungen
Ja. Das System stammt von einer 512GB HDD, aktueller Datenträger ist eine 1TB SSD. Die muss gar nicht in Gänze genutzt werden, aber es geht halt jetzt.Tintom hat geschrieben:10.09.2020 13:15:52Du schreibst, du willst sda7/8 vergrößern. Aber wo nimmst du den Platz her? Liegen auf dem Speichermedium noch ungenutzte Blöcke herum?
Ah, guter Hinweis! luks vergrößern hätte ich vollkommen vergessen.dirk11 hat geschrieben:08.09.2020 22:36:59
- Partition vergrößern
- luks vergrößern
- Dateisystem vergrößern (Ob und wie das bei xfs funktioniert? Keine Ahnung.)
Partition vergrößern mit? gparted? fdisk?
Und dann der Rest womit?
-
- Beiträge: 169
- Registriert: 03.09.2020 04:48:45
Re: Zwei Partitionen müssen vergrößert werden, spezielle Anforderungen
Das funktioniert weder für mein noch für dein Problem, da beides eine komplette Platte statt Partitionen bearbeitet und außerdem keine Größenänderung erlaubt (oder Platz am Partitionsende verschwendet).dirk11 hat geschrieben:10.09.2020 10:33:14Möglichkeit a) - Quelle ist eine externe Festplatte /dev/sdc, Ziel ist /dev/sda:
ddrescue /dev/sdc /dev/sda --force
Möglichkeit b) - Quelle ist ein anderer Rechner, beide sind per LAN erreichbar:
Quellrechner: dd if=/dev/sda status=progress | nc 192.168.1.161 41339
Zielrechner: nc -lp 41339 | dd of=/dev/sdb status=progress
Die dritte Möglichkeit bei dir entspricht wohl dem Kopieren einzelner Dateien, verbessert durch Komprimieren und Auslassen unnötiger Dateien. Dass meine Rechner unter hoher Netzauslastung Fehler bei der Datenübertragung über's Netz machen und somit eine LAN-Verbindung Probleme machen könnte, konntest du natürlich nicht wissen. Daher mach' ich sowas nicht.
Nun, ich kenne bisher kein zuverlässiges Tool für Größenänderungen ganzer Partitionen, daher mache ich den umständlichen, aber funktionierenden Weg.Das geht aber ziemlich an meiner Fragestellung vorbei.
Re: Zwei Partitionen müssen vergrößert werden, spezielle Anforderungen
Okay, also Vergrößern einer SWAP-Partition geht meines Wissens nur über den Weg Partition löschen -> neue Partition anlegen -> SWAP-Partition mit mkswap erstellen. Wobei ich in diesem Fall eher die komplette Partition sparen und eine SWAP-Datei vorziehen oder ganz auf SWAP verzichten würde.dirk11 hat geschrieben:10.09.2020 17:25:03Ja. Das System stammt von einer 512GB HDD, aktueller Datenträger ist eine 1TB SSD. Die muss gar nicht in Gänze genutzt werden, aber es geht halt jetzt.Tintom hat geschrieben:10.09.2020 13:15:52Du schreibst, du willst sda7/8 vergrößern. Aber wo nimmst du den Platz her? Liegen auf dem Speichermedium noch ungenutzte Blöcke herum?
Bei Partitionen ist das ist im Grunde egal was du nimmst, beide Tools können das.dirk11 hat geschrieben:08.09.2020 22:36:59Ah, guter Hinweis! luks vergrößern hätte ich vollkommen vergessen.Tintom hat geschrieben:10.09.2020 13:15:52
- Partition vergrößern
- luks vergrößern
- Dateisystem vergrößern (Ob und wie das bei xfs funktioniert? Keine Ahnung.)
Partition vergrößern mit? gparted? fdisk?
Und dann der Rest womit?
Luks vergrößern geht mit cryptsetup
Dateisystem vergrößern geht mit xfs_growfs aus xfsprogs
Re: Zwei Partitionen müssen vergrößert werden, spezielle Anforderungen
Ja, wie gesagt, das dachte ich mir allein deshalb schon, weil es schwierig werden dürfte, die davor liegende Partition zu vergrößern, ohne die letze (Swap) Partition vorerst zu löschen.Tintom hat geschrieben:10.09.2020 22:20:43Okay, also Vergrößern einer SWAP-Partition geht meines Wissens nur über den Weg Partition löschen -> neue Partition anlegen -> SWAP-Partition mit mkswap erstellen.
Ok, danke. Werde mich nächste Woche damit beschäftigen.