Suche Einführung in gpart

Rakor

Rakor

Administrator
Teammitglied
Hallo zusammen!

Man liest ja überall, dass fdisk böse ist und um Himmels Willen nicht mehr verwendet werden soll. Abhilfe schafft hier, für den Profi, gpart. Nun muss ich leider sagen, dass ich aus der Manpage zu gpart nur noch mehr Fragezeichen sehen und der Schutzheilige der Suchenden "St. Google" mir leider auch keiner verständliche Einführung zu gpart geben konnte.

Kann mir jemand ein Stück Lektüre empfehlen nach welchem ich weiß mit gpart umzugehen? Da ich an der Manpage scheitere wäre evtl. auch was in deutscher Sprache ganz nett... Das erleichtert die Sache ungemein.

Danke für eure Tipps!

Edit: Ich will halt gerne wissen wie ich nun eine neue Festplatte oder ein USB-Stick partitionieren und formatieren kann/muss. Wie ich vorgehen muss wenn ich das Ding dann auch als Boot-Device nutzen will und so weiter....
 
Zuletzt bearbeitet:
Ich hab hier auch mal beschrieben, wie ich meine Systeme immer mit gpart installiere und grob was es so dabei macht. Vllt gibt dir das noch ein paar zusaetzliche Hinweise. Sonst finde ich aber die man page eigentlich recht gut beschrieben. Vllt solltest du dir einfach mal eine virtuelle Maschine aufsetzen und darin etwas rum experimentieren. Wenn man ein paar mal mit gpart gearbeitet hat, geht einem das wahrhaft in Fleisch und Blut ueber. ;)
 
Die gpart manpage finde ich ebenfalls nicht so wirklich hilfreich, vielleicht sollte die mal um ein paar weitere EXAMPLES erweitert werden...
 
Ich gebe dir recht, das man durchaus viel an Beispielen lernen kann, aber die man pages sind nicht dafuer da, das man alles was man so braucht einfach raus in eine Konsole kopieren kann.
 
Also ich habe vor einigen Monaten das erste Mal die HDDs für einen neuen FreeBSD-Server mit gpart eingerichtet und fand die bestehenden Beispiele in der man-Page als ausreichend.

c.
 
Zuletzt bearbeitet:
Also, da möchte ich Rakor eher zustimmen.
Es versteht sicher nicht jeder alle Texte gleich und das gilt nun mal auch für technische Beschreibungen. Was einer sofort versteht und verinnerlicht, das ist für einen anderen mitunter eine große Hürde. Und dann entwickelt sich ja jeder immer weiter (hoffentlich) und somit ist es natürlich auch für die Autoren der man-pages ein rechter Spagat, nicht zu ausufernd und deshalb unbegreiflich zu werden, aber auch ausreichend für Anfänger zu sein.

Als ich neulich selbst das neue gpart benutzen wollte und voller Enthusiasmus daran ging, eingedenks der früheren GNU/Linux Erfahrung mit parted/gparted, da verließ mich doch gleich der Mut und ich war wieder bei bsdlabel und co.
Dabei hatte ich die eben genannten Tools ja auch aus deren man und info Seiten verstehen können, zu mindest soweit, dass ich sie erfolgreich benutzen konnte.
Daher scheint es mir nun ebenfalls so, dass etwas in der man-page zu gpart schwierig zu verstehen ist. Irgendwo ist da eine Hürde, die es manchen Leuten schwer macht.

Für mich selbst kann ich sagen, dass ich in anderem Zusammenhang GEOM schon nicht verstanden habe. Vielleicht liegt hier das Problem und ich müsste eine einfachere, grundsätzliche Erklärung dazu lesen. Wenn von geom-providern geredet wird, also etwa auch Festplatten, dann zucke ich irgendwie schon innerlich zusammen. Außerdem habe ich mich noch nicht in GPT einarbeiten müssen und nur grob gelesen, was das ist. Vielleicht fehlen einfach solche Grundlagen und es liegt gar nicht an dem Text dieser man-page.
 
Hallo Leute,

ich danke für diese Info, ich habe genau das selbe problem, ich möchte meine Festplatte auf eine SSD umziehen und möchte die Partitionen in anderen Größen erstellen als im Original, somit muß ich auch per Hand(gpart) die Partitionen neu erstellen und dann umziehen.
Eine Frage noch zum umziehen, klappt das mit rsync oder ist da dump/restore besser?

Gruß ré
 
es wird mit rsync klappen, -a ist da gut für.
ob dump/restore besser ist, weiß ich nicht, denn ich habe es bisher nicht benutzt.
Ich glaube aber, wenn ich diese manpage richtig verstehe, dass dump filesystem-zentrisch arbeitet und also das komplette Dateisystem überspielt. rsync kümmert sich nur um die Dateien und kann deshalb auch von einem Dateisystem (ufs) auf ein anderes (ext) übertragen und alle Attribute beibehalten.
Dafür kann dump einen snapshot erstellen und somit einen Umzug live machen, was ich bei rsync für sehr kritisch halte (bei Dateien, die tatsächlich im Gebrauch sind).
Ob dump auch die "Nullen" überträgt (also die noch unbenutzten Teile eines angelegten Dateisystems), weiß ich nicht. Dann müsste das Ziel immer wenigstens gleich groß der Quell-Partition sein. Bei rsync braucht das Ziel nur so groß zu sein, wie tatsächlich Platz benutzt wird.
 
dump/restore ist besser. Liegt dem System schon bei und kopiert erweiterte Dateiattribute (z.B. +schg) mit.

Bitte berichtigen wenn ich falsch liege. :)
 
pit234a schrieb:
[...]
Zum Vergrößern anklicken....

dump ist in JEDER Hinsicht besser. Lies einfach das Handbuch. Es erklärt auch dem einfachsten Menschen warum das so ist. Und nebenbei... ja dump kann Sparse-Dateien sichern und ja, restore (Gegenstück zu dump) restauriert auf beliebige Dateisysteme. Es restauriert auf Dateibäume und nicht auf Partitionen.

Am besten gefällt mir diese Passage im Handbuch, die so ziemlich ALLES sagt:
18.12.7 Which Backup Program Is Best?

dump(8) Period.
Zum Vergrößern anklicken....
 
#> recoverdisk ALTEFESTPLATTE NEUEFESTPLATTE
#> recoverdisk /dev/ad0 /dev/da0

Ist auch ne recht gute Alternative!
 
nakal schrieb:
dump ist in JEDER Hinsicht besser. Lies einfach das Handbuch. Es erklärt auch dem einfachsten Menschen warum das so ist. Und nebenbei... ja dump kann Sparse-Dateien sichern und ja, restore (Gegenstück zu dump) restauriert auf beliebige Dateisysteme. Es restauriert auf Dateibäume und nicht auf Partitionen.

Am besten gefällt mir diese Passage im Handbuch, die so ziemlich ALLES sagt:
Zum Vergrößern anklicken....

du magst es glauben oder nicht: ich habe es gelesen. Allerdings auf Deutsch und lass mich mal kopieren, was dabei bei mir hängen geblieben ist:

Im Gegensatz zu anderen Backupprogrammen sichert dump ein ganzes Dateisystem auf einem Gerät. Es ist nicht möglich nur einen Teil des Dateisystems, oder einen Verzeichnisbaum, der mehr als ein Dateisystem umfasst, zu sichern.
Zum Vergrößern anklicken....
Die man-page hatte ich auch so verstanden.
Aber, wie gesagt, ich habe es noch nie probiert und kann deshalb nur wenig dazu sagen.

Ich glaube aber, dass folgendes grundlegend anders ist und und möchte das nachfragen, um Missverständnissen vorzubeugen:

rsync überträgt die Dateien mit ihren Attributen (so gewollt). Es kann Links als Links übertragen oder ihnen folgen. Im Ziel landen also wieder Dateien. Deshalb nenne ich rsync immer gerne das etwas bessere cp, denn damit ist das am ehesten vergleichbar.
dump erzeugt nicht Dateien? Oder?
Ich denke, dump erzeugt so etwas wie ein Image des Dateisystems, halt Blockweise geschrieben und deshalb vielleicht eher mit dd zu vergleichen. Ich sehe sehr wohl, dass dump sehr anders als dd ist, aber das gilt ja ähnlich auch für rsync und cp.
Ich sehe dump daher eher im Umfeld von Datensicherung und Wiederherstellung.

Was ich aber nicht verstanden habe und vielleicht vollkommen falsch sehe: Ein mit dump erzeugtes Image, das meinetwegen ufs war, erzeugt durch restore auch wieder ufs? Ich kann mir das nicht anders vorstellen, denn wenn die Blöcke gesichert werden ist die Information des Dateisystems selbst ja enthalten, oder?

rsync, cp, tar, die sehe ich eher für Übertragung von Dateien an.
Die Aufgaben sind leicht unterschiedlich und überlappen sicherlich. Sie können jedenfalls eine Datei von ufs auch nach ext oder was auch immer übertragen, wenn das Hostsystem dieses filesystem beherrscht. Wenn ich das richtig verstehe, liegt hier einer der wesentlichen Unterschiede zu dump.

Wenn, wie gesagt, wenn ich das richtig deute (und wenn nicht, erfahre ich das ja gleich, endlich) und ich ein System auf unterschiedlichen Partitionen habe und feststellte, dass meine /usr/home doch etwas zu klein war und meine /usr/local deutlich zu groß gewesen ist und ich das nun auf der neuen Platte korrigieren will, könnte ich dann die zu große Partition /usr/local mit viel freiem Platz darin mittels dump/restore auf meine neue /usr/local übertragen, obwohl die deutlich kleiner ist? Wenn Blockweise genommen wird, was das alte Filesystem anbietet und dabei auch die leeren Stellen übertragen werden (so habe ich das eben verstanden), dann sollte das doch nicht möglich sein?

rsync macht auch nicht vor eingebundenen Medien halt. Es werden sogar gemountete Freigaben vollkommen mit kopiert, wenn der mountpoint innerhalb des ausgewählten Verzeichnisses liegt. Das ist vielleicht gut, zu wissen.
 
Nein, so ist das nicht. Dump dumpt zwar ganze Dateisysteme aber ein Restore erzeugt nur Dateien und Verzeichnisse, damit kannst du dann auch von UFS auf ZFS umziehen. Dump umgeht meines Wissens nach nicht das VFS, hat technisch also eigentlich nichts mit dd gemeinsam.

Die Einschränkung, dass dump nur ganze Partitionen dumpt, kann man wahrscheinlich mit einem Nullfs Mount umgehen.

Das einzige was an restore etwas nervt, ist dass es die Rechte der Wurzel nicht wieder herstellt. Wenn du es also benutzt um mehrere Partitionen umzuziehen, muss man also immer Manuell die Rechte der Wurzelverzeichnisse anpassen.
 
Kamikaze schrieb:
Nein, so ist das nicht. Dump dumpt zwar ganze Dateisysteme aber ein Restore erzeugt nur Dateien und Verzeichnisse, damit kannst du dann auch von UFS auf ZFS umziehen. Dump umgeht meines Wissens nach nicht das VFS, hat technisch also eigentlich nichts mit dd gemeinsam.

Die Einschränkung, dass dump nur ganze Partitionen dumpt, kann man wahrscheinlich mit einem Nullfs Mount umgehen.

Das einzige was an restore etwas nervt, ist dass es die Rechte der Wurzel nicht wieder herstellt. Wenn du es also benutzt um mehrere Partitionen umzuziehen, muss man also immer Manuell die Rechte der Wurzelverzeichnisse anpassen.
Zum Vergrößern anklicken....

Ah, dann ist dump/restore (wohl vor allem restore) aber doch deutlich intelligenter, als ich dachte und es wird mir gleich viel sympathischer.


Aber damit führt das dann schön zurück zu dem Thema, dass manchmal man-pages und auch weiterführende Lektüre aus einfachen Gründen heraus falsch verstanden oder ausgelegt werden. Eine einzige Zeile wie deine eben, hätte genügt und ich hätte das gleich besser verstanden. Dabei darf mir niemand mangelnden Willen vorwerfen, wenn ich da was nicht verstehe, dann deshalb, weil mein Horizont nicht weit genug reicht. Sowas gibt es ja, offenbar auch unter Leuten, die unixartige Systeme mögen.

Danke für die Aufklärung.
 
Nun Danke für eure Hilfe. Ich denke mir geht es da so ähnlich wie pit234a. Zeilen abschreiben kann ich auch, aber ich würde eben gerne verstehen was und warum es da so vor sich geht. Ich hatte mit GPT bisweilen nix am Hut und GEOM ist mir auch bis heute noch irgendwie suspekt. Sicher interessant... aber auch suspekt...

So verstehe ich nicht genau warum ich denn nun eine freebsd-boot-Partition benötige?! Mein laufendes System hat doch auch keine und rennt.... ^^

Naja also der Hintergrund all dieser Bemühungen war ja mein Vorhaben ein Livesystem zu bauen. Ich bin nun ein wenig weiter gekommen (hoffe ich) und ich hoffe mal wieder, dass ich da bisweilen nix allzu falsch gemacht habe. Wer mal sehen will, ich hab folgendermaßen partitioniert: http://denkrobat.de/wiki/index.php/FreeBSD_auf_USB-Stick#Partitionieren
 
So wie ich das sehe ist GPT halt komplexer und so braucht man auch mehr Code um den loader zu finden. In den MBR der GPT Partition ("pmbr") schreibst du nur ein Stueck Code rein, was in der Lage ist die boot Partition zu finden. Darin versteht dann gptboot voellig GPT und weiss genug ueber die bsdlabel und UFS, um dann letzendlich stage 3, also den loader aufzurufen. Sogesehen ist das einfach nur ein 'kickstart'. Ein weiterer Vorteil ist auch, das man hier keinen Platzbeschraenkungen mehr unterliegt und so den ueberwiegenden Teil in C schreiben kann, ohne darauf zu achten wieviel Byte das Programm nun gross wird.
Aber Achtung: Du kannst die boot Partition nicht beliebig gross machen, denn pmbr ueberprueft das. Nur der Programierer weiss wohl warum? Vllt gibts da noch weitere Beschraenkungen, weil der MBR der GPT Partition auch nur 512 Byte gross sein darf. *shrug*
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben