Schnelle Umpartitionierung ohne Datenverlust

Caramon2

Lieutenant
Registriert
Jan. 2004
Beiträge
973
Moin! :)

Als ich gestern die (etwas später schon defekte) 2 TB SSD partitioniert habe, fiel mir auf, dass ich mir die Partitionierung mit "sgdisk" noch mit "-a32" (16k Alignment) notiert hatte und die letzte Partition manuell mit "-7" habe enden lassen (7 Sektoren vor der GPT-Kopie, damit auch die letzte Partition durch glatte 4k teilbar ist). - Also habe ich das auch bei der 250 GB SSD (der bisherigen System-Kopie) so.

Inzwischen hatte ich aber herausgefunden, dass man mit "-I" auch das Ende am Alignment ausrichten kann und da 4k Alignment reicht, ergibt das "-Ia8"

Das wollte ich heute früh nach dem aufstehen kurz ändern. - Ich hatte noch nicht mal gefrühstückt: Die sprichwörtliche "kleine Fingerübung zum wach werden". ;)

Also PC gebootet, Laufwerk angeschlossen und die Partitionierung ausgelesen:
Code:
[user@linux ~]$ lw=/dev/sdc
[user@linux ~]$ sgdisk -p
Das "$lw" übersehen…
Code:
[user@linux ~]$ sgdisk -p $lw
Disk /dev/sdc: 488397168 sectors, 232.9 GiB
Model: Generic         
Sector size (logical/physical): 512/4096 bytes
Disk identifier (GUID): BBA3581D-0B86-4736-B79C-5EF33FF9A3DC
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 488397134
Partitions will be aligned on 64-sector boundaries
Total free space is 67108901 sectors (32.0 GiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1              64            2047   992.0 KiB   EF02  
   2            2048        33554431   16.0 GiB    8300  
   3       167772160       488397127   152.9 GiB   8300  
   4        33554432        67108863   16.0 GiB    8300  
   5        67108864       100663295   16.0 GiB    8300
Startsektor 64 = 32k = 16k Aligment, da die GPT die ersten 33 Sektoren belegt (statt 32 Sektoren und damit glatt durch 4k teilbar - da waren echte "Könner" am Werk…).

Dann die komplette GPT-Partitionierung inkl. Kopie gelöscht und das erst MiB der SSD getrimmt (ich will keine Artefakte):
Code:
[user@linux ~]$ sudo sgdisk -Z $lw
[sudo] Passwort für user: 
GPT data structures destroyed! You may now partition the disk using fdisk or
other utilities.
[user@linux ~]$ sudo blkdiscard $lw -vl 1M
/dev/sdc: 1048576 Bytes verworfen ab Position 0
Und die neue Partitionierung erstellt (einzige die BIOS-Grub-Partition bekommt einen neuen Anfang):
Code:
[user@linux ~]$ sudo sgdisk -Ia8 -n0:0:2047 -t1:0xEF02 -n0:0:+16383M -n0:80G:0 -n0:0:+16G -n0:0:+16G -p $lw
Creating new GPT entries in memory.
Disk /dev/sdc: 488397168 sectors, 232.9 GiB
Model: Generic         
Sector size (logical/physical): 512/4096 bytes
Disk identifier (GUID): BDBF0D9C-BD5C-4F8D-ABB1-478EBA4C4516
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 488397134
Partitions will be aligned on 8-sector boundaries
Total free space is 67108877 sectors (32.0 GiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1              40            2047   1004.0 KiB  EF02  
   2            2048        33554431   16.0 GiB    8300  
   3       167772160       488397127   152.9 GiB   8300  
   4        33554432        67108863   16.0 GiB    8300  
   5        67108864       100663295   16.0 GiB    8300  
The operation has completed successfully.
Startsektor 40.

Da alle "regulären" Partitionen unverändert blieben, wurde nichts beschädigt, so dass ich sofort Grub installieren und per VM einen Funktionstest durchführen konnte ("vms" = mit Snapshot-Option, damit Schreibzugriffe nur im RAM gepuffert, aber nicht wirklich umgesetzt werden):
Code:
[user@linux ~]$ sudo mount $lw"2" /mnt
[user@linux ~]$ sudo grub-install --recheck --target=i386-pc --boot-directory=/mnt/boot/ $lw
i386-pc wird für Ihre Plattform installiert.
Installation beendet. Keine Fehler aufgetreten.
[user@linux ~]$ sudo imount /mnt
sudo: imount: Befehl nicht gefunden
Fipptehler…
Code:
[user@linux ~]$ sudo umount /mnt
[user@linux ~]$ vms c
^Cqemu-system-x86_64: terminating on signal 2
Ups, war für die falsche Partition: Grub lasse ich imzwischen ja über LMDE laufen, da das bei jeder neuen Kernelversion Grub aktualisieren muss und es mir zu aufwändig wäre, dass dann immer bei Artix manuell machen zu müssen.

Also Partition 5 + Test:
Code:
[user@linux ~]$ sudo mount $lw"5" /mnt
[user@linux ~]$ sudo grub-install --recheck --target=i386-pc --boot-directory=/mnt/boot/ $lw
i386-pc wird für Ihre Plattform installiert.
Installation beendet. Keine Fehler aufgetreten.
[user@linux ~]$ sudo umount /mnt
[user@linux ~]$ vms c
^Cqemu-system-x86_64: terminating on signal 2
Kacke !!! - Das nutzt ja diesen elenden btrfs-@-Snapshot-Mist, da ich Timeshift testen wollte!

Timeshift nutze ich schon lange nicht mehr, da ich diesen Snapshot-Mist einfach nur behämmert umständlich finde, aber ich habe es nicht hinbekommen, auch diesen verdammten @-Kram wegzubekommen: Dann bootet es nicht mehr.

Also musste ich die Partition doch im Dateimanager öffnen, um den richtigen Pfad zu kopieren und habe dabei gesehen, dass obiges ein /boot/ erstellt hat, das ich dann auch gleich gelöscht habe + Test:
Code:
[user@linux ~]$ sudo mount $lw"5" /mnt
[user@linux ~]$ sudo grub-install --recheck --target=i386-pc --boot-directory=/mnt/@/boot/ $lw
i386-pc wird für Ihre Plattform installiert.
Installation beendet. Keine Fehler aufgetreten.
[user@linux ~]$ sudo rm -rf /mnt/boot
[user@linux ~]$ sudo umount /mnt
[user@linux ~]$ vms c

Endlich das richtige Bootmenü (booten funktioniert natürlich auch noch):

SoS-Grub.png

So sieht die Partitionierung grafisch aus:

SoS.png

Insgesamt hatte ich für alles ca. 7 Min. gebraucht.

Btw:

Mit diesem Snapshot-Kram werde ich mich nie anfreuden: Ich halte das für bekloppt, da wenn man sich das Dateisystem zerschießt (was gerade bei btrfs schnell passieren kann - gebranntes Kind…), auch die Snapshots weg sind.

Snapshots sind keine Sicherungen! - Höchstens eine Art Undo-Funktion.
 
  • Gefällt mir
Reaktionen: feris und ropf
@Caramon2 vielleicht wäre es gut den Beitrag als Leserartikel zu markieren?
 
  • Gefällt mir
Reaktionen: feris
Nur mal so als Idee, Partitionen sind überholt, man arbeitet schon seit längerem und moderner mit LVM. Auf Arbeit laufen all meine Server seit vielen Jahren nur noch darüber, nix mehr mit Partitionen.
 
LVM ist im Endeffekt aber auch eine Partitionierung der Datenträger, nur dass man die jederzeit dynamisch (über mehrere Datenträger) anspassen kann.
 
das 40-2047 kann man machen wenn man verpennt hat, das Grub (im Bios Modus) so ne Partition gerne hätte

aber sonst sollte die auch MiB Alignment haben rein aus Prinzip

Partitionen in falscher Reihenfolge (nummerierung anders als die platten abfolge) kann sehr verwirrend sein

Snapshot hast du recht, ist ein Schönwetter Ding. Auch bei deduplizierenden Backuplösungen. Da kannst 100 Kopien einer Datei haben wenn der eine gemeinsame Chunk kaputt ist dann ist es eben bei allen so. Deswegen ja immer mehrere voneinander unabhängige Backup
 
  • Gefällt mir
Reaktionen: Caramon2
Es hat glaube ich niemand behauptet, dass Snapshots Backups wären, es gibt doch sichtlich dort überhaupt keinen Zusammenhang von den Anforderungen her. Ein gutes Backup soll z.B. auch bei Blitzschlag Datenverlust verhindern. Wie sollen Snapshots das machen?

Snapshots sind für einfaches/schnelles "Undo" und Diff und Forking, wie schon gesagt, was im Zusammenhang mit Datenbanken oder VMs spannend ist. Z.B. systemd-nspawn oder auch Docker haben btrfs-Integration und können neue Maschinen aus einem Snapshot in Sekundenbruchteilen erzeugen.
 
@oicfar: Das fände ich übertrieben. Das war einfach nur eine Mail, die ich im Bekanntenkreis verschickt habe und dann auch hier ins Forum stellen wollte.

Mir geht es darum zu zeigen, was ich gemacht habe, um auch später darauf verweisen zu können, wenn mal die Sprache darauf kommt.

Besonders auch der durch diesen @-Kram provozierte Fehler: Jetzt habe ich endlich ein Praxisbeispiel dafür! :)

@nutrix: Ich bevorzuge schlank und effizient, weshalb ich alles möglichst einfach halte: Auch um unnötigen Overhead zu vermeiden und es so wartungsfreundlich wie möglich zu haben (z. B. von einem Livesystem).

Die 1. interne SSD, die nur die Artix- und die Home-Partition enthält, habe ich deshalb MBR-partitioniert, aber bei der ext., auf die auch beliebige Testinstallation kommen sollen, ist GPT das kleinere "Übel" gegenüber einer erweiterteren Partition: Da dort die logischen Laufwerke alle aufeinander aufbauen, werden alle folgenden mitgerissen, wenn eines davon beschäftigt wird: Das ist quasi russisches Roulette und die Datenträgervergewaltigung von Windows (kein Tippfehler) macht da besonders gerne Mist: Das habe ich selbst um im Bekanntenkreis schon mehrfach erleben müssen.

kieleich schrieb:
das 40-2047 kann man machen wenn man verpennt hat, das Grub (im Bios Modus) so ne Partition gerne hätte

Da kommt ja nur Grub rein: ca. 56k wenn man von xfs bootet, oder um die 150k, wenn man von btrfs bootet. Der Rest bleibt unbenutzt.

Früher hatte ich dehalb die erste "reguläre" Partition direkt anschließend beginnen lassen, aber dann ist mit aufgefallen, dass wenn ich die SSD am USB-HUB des TFTs booten will ( statt am Front-USB des PCs) das nicht funktioniert, wenn sie früher als Sektor 2048 beginnt. - Weshalb, weiß ich nicht.

Alle anderen Partitionen richte ich generell an glatte GiB aus, so dass das Alignment auf jeden Fall passt und ich es mir gut merken kann, falls ich die Partitionierung mal aus dem Kopf heraus wiederherstellen muss. Auf dem Grund nutze ich auch glatte 16 GiB für die Systempartitionen und variiere das ggfs. mindestens in 4 GiB (lieber 8 GiB) Schritten.

kieleich schrieb:
Partitionen in falscher Reihenfolge (nummerierung anders als die platten abfolge) kann sehr verwirrend sein
In diesem Fall nicht:
1, 2 und 3 sind fest, eben die Kopie meines Produktivsystems *), während der freie Bereich für beliebige Testinstallationen ist.

*) die ich auch an anderen PCs boote: Die meinen davon noch BIOS-PCs, die nur innerhalb der ersten 128 GiB booten können, weshalb ich die Home-Partition ans Ende gesetzt habe - Auch deshalb kein UEFI-Boot. Aber das ist sowieso eine Seuche, die immer wieder ärger macht (besonders wenn man von einer ext. SSD an beliebigen PCs booten möchte), weshalb ich generell darauf verzichte: Ein UEFI ohne CSM ist für mich ein no go!

Bei der 2 TB hatte ich die Home-Partition deshalb bei 128 GiB beginnen: Mehr freizulassen würde keinen Sinn machen.
Ergänzung ()

GrumpyCat schrieb:
Es hat glaube ich niemand behauptet, dass Snapshots Backups wären, es gibt doch sichtlich dort überhaupt keinen Zusammenhang von den Anforderungen her.
Otto Normalo weiß davon nicht und will es auch nicht wissen: Hauptsache es funktioniert und ist schön bequem: Siehe meine Signatur.
 
mibbio schrieb:
LVM ist im Endeffekt aber auch eine Partitionierung der Datenträger,
Nope, ist es nicht, da es Volumes verwaltet und einen Abstraktionsschicht darüberpackt, und man nicht mal mehr partitionieren braucht, sondern direkt Laufwerke ohne Partitionen verwenden kann. Sprich, LVM ist wesentlich flexibler und dynamischer als eine fixe Partitionstabelle auf einem Datenträger.
Ergänzung ()

Caramon2 schrieb:
Die 1. interne SSD, die nur die Artix- und die Home-Partition enthält, habe ich deshalb MBR-partitioniert
Warum? Das ist ebenso veraltet, und sollte durch GPT mit einer EPS geändert werden. Ist auch schon so lange Standard in Linux.
Caramon2 schrieb:
, aber bei der ext., auf die auch beliebige Testinstallation kommen sollen, ist GPT das kleinere "Übel" gegenüber einer erweiterteren Partition: Da dort die logischen Laufwerke alle aufeinander aufbauen, werden alle folgenden mitgerissen, wenn eines davon beschäftigt wird: Das ist quasi russisches Roulette und die Datenträgervergewaltigung von Windows (kein Tippfehler) macht da besonders gerne Mist: Das habe ich selbst um im Bekanntenkreis schon mehrfach erleben müssen.
Weil MBR mit erweiterten Partitionen auch schon lange out ist. Man heute keiner mehr, den ich kenne. GPT und LVM, mehr braucht es heute nicht mehr. Und Windows macht hier genauso viel oder wenig Mist wie jedes andere OS, das halte ich für eine Latrinenparole. Du kannst es mal mit Windows und Linux auf einer SSD/NVMe gegentesten (ich hatte es damals mal gemacht), da wirst sehen, daß logische Partitionen keinen Unterschied zu normalen Partitionen im Zugriff machen, wenn die Geschwindigkeit stimmt. Problem an der Stelle war eher am Controller bzw. Festplatte zu suchen. Heute mit SSD und Co. juckt der Zugriff gar nicht mehr.

Aber ja, Du hast ein Problem, wenn der Header der erweiterten Partition beschädigt wird.
https://de.wikipedia.org/wiki/Master_Boot_Record#Primäre_und_erweiterte_Partitionstabelle
Diese befindet sich im ersten Sektor der erweiterten Partition. Jede erweiterte Partitionstabelle definiert genau eine logische Partition und verweist bei Bedarf auf die nächste erweiterte Partitionstabelle. Die erweiterten Partitionstabellen funktionieren nach dem Prinzip der verketteten Liste, daher sind hinter den primären Partitionen beliebig viele logische Partitionen möglich.
Das ist das Problem, was Du vermutlich meinst. Aber dank GPT, was es auch schon recht lange gibt, ist das schon lange obsolet geworden, hier irgendwie erweiterte Partitionen nutzen zu müssen, wenn man mehr als 4 Partitionen braucht. Und durch LVM und SSDs ist es sowieso hinfällig geworden, zu partitionieren.
Caramon2 schrieb:
@oicfar: Das fände ich übertrieben. Das war einfach nur eine Mail, die ich im Bekanntenkreis verschickt habe und dann auch hier ins Forum stellen wollte.
Dann schreib doch Deinen Bekannten, daß sie gleich mal MBR und erweiterte Partitionen vergessen sollen und das alles per GPT und LVM möglich ist. 🤗
Caramon2 schrieb:
*) die ich auch an anderen PCs boote: Die meinen davon noch BIOS-PCs, die nur innerhalb der ersten 128 GiB booten können, weshalb ich die Home-Partition ans Ende gesetzt habe - Auch deshalb kein UEFI-Boot. Aber das ist sowieso eine Seuche, die immer wieder ärger macht (besonders wenn man von einer ext. SSD an beliebigen PCs booten möchte), weshalb ich generell darauf verzichte: Ein UEFI ohne CSM ist für mich ein no go!
Dann gewöhne Dich bitte mal zügig daran, da es - wie gesagt GPT mit EPS - auch für Linux gibt, und das ein wichtiges Sicherheitsfeature ist.
 
Zuletzt bearbeitet:
nutrix schrieb:
sondern direkt Laufwerke ohne Partitionen verwenden kann
"Oh die Platte ist frei, die formatier ich jetzt"

"Nanu wo ist das LVM hingekommen"

aber haupt sache 1 Megabyte gespart
 
  1. Ist das weder mir noch anderen, auch im professionellen Umfeld, so passiert
  2. Wenn man das selbst so macht, sollte man ja wohl wissen, was man da tut
  3. Wird ein Datenträger nicht einfach so formatiert, wenn er "in use" ist
 
"falsche platte formatiert" passiert ständig und mit Platten die von div Installern als "unpartitioniert" erkannt werden weil es absolut unüblich ist, es so zu machen, wird so was eben begünstigt

schlichtweg quatsch, das grub und das hier auch. macht keinen sinn da wegen 1 megabyte herum zu optimieren, da wird woanders viel mehr verbrannt. nur weils geht ist nicht automatisch eine gute idee
 
Wenn Du Dein System aufgesetzt hast, sorry, wie oft startest Du dann noch irgend einen Installer, der da was machen will? Selbst mit einer Partition, die Du dann nicht formatierst, hast Du doch das gleiche Problem. Aber ja, wer es mag, kann ja nach wie vor mit GPT eine Partition Typ LVM anlegen.

@Caramon2
Sehe ich das richtig, daß es bei Dir keine Partition SWAP gibt?
 
Zurück
Oben