Moins Liste, auf einem mit 9.0 bestückten Rechner will ich eine zweite Festplatte für /home einrichten und dabei die bestehende partition / erweitern. Läßt sich das problemlos mit yast machen? Was gilt es zu beachten? hda2 = / hda3 = /home hda1 /swap hdb1 = 2. Festplatte Im Moment würde ich hda3 auf hdb1 kopieren, dann hda3 umounten und mit yast hda2 erweitern. Kann ich das so machen oder geht mir dann der Inhalt von hda2 verloren? Danke für jeden Tip. Christian
Christian Banek, Samstag, 18. Juni 2005 13:11:
auf einem mit 9.0 bestückten Rechner will ich eine zweite Festplatte für /home einrichten und dabei die bestehende partition / erweitern.
Das wäre ja an sich ein Fall für den LVM. Ob man den vernünftig über Yast bedienen kann weiß ich nicht.
hda2 = / hda3 = /home hda1 /swap
hdb1 = 2. Festplatte
Im Moment würde ich hda3 auf hdb1 kopieren,
...und die fstab entsprechend anpassen.
dann hda3 umounten und mit yast hda2 erweitern. Kann ich das so machen oder geht mir dann der Inhalt von hda2 verloren?
Tja, das käme auf einen Versuch an. Ich würde dringend zu einem Backup raten, mit dd oder so. -- Antworten an lists@feile.net werden in /dev/null archiviert! Bitte ggf. lists... durch mail... ersetzen. Andreas Feile www.feile.net
Am Samstag, den 18.06.2005, 13:55 +0200 schrieb Andreas Feile:
Christian Banek, Samstag, 18. Juni 2005 13:11:
auf einem mit 9.0 bestückten Rechner will ich eine zweite Festplatte für /home einrichten und dabei die bestehende partition / erweitern.
Das wäre ja an sich ein Fall für den LVM. Ob man den vernünftig über Yast bedienen kann weiß ich nicht.
Das scheint für eine root-Partition nicht ganz unproblematisch zu sein. Wenns anders geht, wäre es mir lieber.
hda2 = / hda3 = /home hda1 /swap
hdb1 = 2. Festplatte
Im Moment würde ich hda3 auf hdb1 kopieren,
...und die fstab entsprechend anpassen.
Klar.
dann hda3 umounten und mit yast hda2 erweitern. Kann ich das so machen oder geht mir dann der Inhalt von hda2 verloren?
Tja, das käme auf einen Versuch an.
Hab ich mehr als einen? Wohl kaum. Wenn ich das recht gelesen habe, dann passieren da ja zwei Dinge. Die Partitionstabelle wird verändert und der neu geschaffene Raum muss formatiert werden.
Ich würde dringend zu einem Backup raten, mit dd oder so.
Danke für den Hinweis.
-- Antworten an lists@feile.net werden in /dev/null archiviert! Bitte ggf. lists... durch mail... ersetzen.
Andreas Feile www.feile.net
Christian Banek, Samstag, 18. Juni 2005 14:18:
Tja, das käme auf einen Versuch an.
Hab ich mehr als einen? Wohl kaum.
Doch. Wenn Du Dir mit dd irgendwohin ein Image ziehst, dann kannst Du probieren, so oft Du willst. Etwa so: dd if=/dev/hda | zip | split -b 500m - /andere/platte/tmp/image. Dann kriegst Du Dateien wie image.aa, image.ab, usw., aus denen Du dann jederzeit Deine hda regenerieren kannst. Der Rückweg wäre dann etwas wie cat image.* | funzip | dd of=/dev/hda Bitte vorher manpages checken, obiges nur aus dem Kopf geschrieben!
Wenn ich das recht gelesen habe, dann passieren da ja zwei Dinge. Die Partitionstabelle wird verändert und der neu geschaffene Raum muss formatiert werden.
Im Prinzip ja. Allerdings ist es so, daß es Dateisysteme gibt, die man im Nachhinein vergrößern kann. Das heißt also (für den Fall, daß Deine Partitionen schön nacheinander auf der Platte liegen), daß Du die zweite Partition löscht, die Grenze der ersten auf die frühere Grenze der zweiten setzt, und daß Du dann Dein Filesystem einfach in den neu gewonnenen Platz hinein vergrößern könntest. xfs kann sowas (xfs_growfs), und reiser glaub ich auch. Wenn Du ein FS hast, welches solche Spielchen nicht unterstützt, dann wirst Du wohl die Daten vorher wegkopieren, das FS neu anlegen, und die Daten wieder draufkopieren müssen. Nur zum Verständnis: es wird zwar meistens so sein, aber es ist nicht zwingend, daß ein Dateisystem den kompletten Platz einer Partition verbraucht. Es ist durchaus eine 100 GB-Partition denkbar, auf der ein nur 50 GB großes FS liegt. -- Antworten an lists@feile.net werden in /dev/null archiviert! Bitte ggf. lists... durch mail... ersetzen. Andreas Feile www.feile.net
Hallo, Am Samstag, 18. Juni 2005 14:18 schrieb Christian Banek:
Am Samstag, den 18.06.2005, 13:55 +0200 schrieb Andreas Feile:
Christian Banek, Samstag, 18. Juni 2005 13:11:
auf einem mit 9.0 bestückten Rechner will ich eine zweite Festplatte für /home einrichten und dabei die bestehende partition / erweitern.
Das wäre ja an sich ein Fall für den LVM. Ob man den vernünftig über Yast bedienen kann weiß ich nicht.
Was soll hier LVM? Jedoch läßt sich LVM über Yast bedienen.
Das scheint für eine root-Partition nicht ganz unproblematisch zu sein.
Eben.
hda2 = / hda3 = /home hda1 /swap
hdb1 = 2. Festplatte
Warum nur primäre Partitionen? Filesystem und Größe der /home-Partition sollten möglichst übereinstimmen.
Im Moment würde ich hda3 auf hdb1 kopieren,
Die Kopie mit dd bei ungemounteten Partitionen. Dann fstab ändern und prüfen, ob hdb1 alles kann (bevor hda3 formatiert wird!!!).
und mit yast hda2 erweitern. Kann ich das so machen oder geht mir dann der Inhalt von hda2 verloren?
Die Vergrößerung von hda2 kannst Du mit Yast versuchen; das widerspricht aber der Regel, dass für Änderungen an Partitionen diese nicht gemountet sein sollen. Sonst ist Datenverlust nicht auszuschließen. Wenn es sich bei hda2 um die einzige root-Partition bzw. das einzige BS handelt, geht Dein Vorhaben nicht auf. Entweder Du verwendest das Reparatursystem der 9.0 und arbeitest mit fdisk zur Erweiterung und anschließendem Filesystemcheck _oder_ Du kopierst - bei ausreichendem Platz auf der hdb - die root-Partition darauf (fstab und Bootloader ändern), fährst hoch, änderst mit Yast die hda, kopierst / zurück, änderst Bootloader und freust Dich.
Tja, das käme auf einen Versuch an.
(Wenn die System- und Home-Daten gesichert sind.)
Hab ich mehr als einen?
Nein!
Wenn ich das recht gelesen habe, dann passieren da ja zwei Dinge. Die Partitionstabelle wird verändert und der neu geschaffene Raum muss formatiert
und eingeordnet werden (z.B. mit reiserfsck). Ich wünsche Dir Erfolg. Gruß H.-Peter
H.-Peter Baldamus, Samstag, 18. Juni 2005 17:34:
Im Moment würde ich hda3 auf hdb1 kopieren,
Die Kopie mit dd bei ungemounteten Partitionen.
dd ist hier ungeeignet. Lieber rsync oder tar oder zur Not auch cp.
Die Vergrößerung von hda2 kannst Du mit Yast versuchen; das widerspricht aber der Regel, dass für Änderungen an Partitionen diese nicht gemountet sein sollen. Sonst ist Datenverlust nicht auszuschließen.
Was ist das für eine Regel? In man xfs_growfs lese ich:
The filesystem must be mounted to be grown (see mount(8)).
Hab ich mehr als einen?
Nein!
Warum soll er nur einen Versuch haben? Mit einem vernünftigen Backup kann man probieren, so oft man will. Und nachdem man Festplattenplatz praktisch nachgeworfen bekommt, dürfte es doch auch kein Problem sein, sich ein solches anzufertigen. -- Antworten an lists@feile.net werden in /dev/null archiviert! Bitte ggf. lists... durch mail... ersetzen. Andreas Feile www.feile.net
Hallo Christian, hallo Leute, (ich antworte auf die Ursprungsmail, weil ich von den abenteuerlichen Vorschlägen im Rest des Threads Kopfweh bekomme...) Am Samstag, 18. Juni 2005 13:11 schrieb Christian Banek:
auf einem mit 9.0 bestückten Rechner will ich eine zweite Festplatte für /home einrichten und dabei die bestehende partition / erweitern. Läßt sich das problemlos mit yast machen? Was gilt es zu beachten?
hda2 = / hda3 = /home hda1 /swap
Welches Dateisystem? Davon ist die Wahl des Resize-Tools abhängig (resize2fs für ext2/3, resize_reiserfs, ...) Prinzipiell müsste die Größenänderung der Partition auch mit YaST gehen, wenn diese Option angeboten wird.
hdb1 = 2. Festplatte
Im Moment würde ich hda3 auf hdb1 kopieren,
Das geht am einfachsten mit dem in der SuSE Supportdatenbank im Artikel "maddin_kopieren" beschriebenen Verfahren. Die genaue URL habe ich leider gerade nicht parat, Google oder die Suchfunktion der SDB sollten helfen. Nochwas: vergiss bitte _alle_ in diesem Thread genannten weiteren Vorschläge. dd ist für ein Backup genauso ungeeignet wie die Komprimierung (egal ob zip oder gzip), da bereits ein gekipptes Bit das ganze Backup unbrauchbar machen kann! (Es ist übrigens auch egal, wie lang die Befehlszeile ist, in der zip oder gzip "versteckt" wurden ;-) Auch wenn .tar.gz ausnahmsweise nicht empfohlen wurde ;-) gilt der folgende FAQ-Eintrag sinngemäß: 6.1. Warum ist .tar.gz oder .tar.bz2 nicht fürs Backup geeignet? http://suse-linux-faq.koehntopp.de/q/q-backup-nicht_targz.html
dann hda3 umounten und mit yast hda2 erweitern. Kann ich das so machen oder geht mir dann der Inhalt von hda2 verloren?
Ein gewisses Risiko besteht bei Veränderungen am Dateisystem immer, aber grundsätzlich sollte es gehen. Ich würde allerdings eine andere Lösung vorschlagen: Lass die Partitionierung von hda wie sie ist und verwende die dann freie hda3 für das Verzeichnis /usr oder /opt (oder beide, einfach /opt nach /usr/opt kopieren und einen Symlink /opt -> /usr/opt setzen). Für genauere Ratschläge, welche Verzeichnisse für den Umzug in Frage kommen, müsste ich die Ausgabe von du -hs /* und df -h sehen. Zum Umkopieren siehe wiederum die SDB, Artikel maddin_kopieren. Gruß Christian Boltz PS: Ein Backup (auf CD oder einem anderen externen Medium) ist dringend anzuraten, auch wenn "eigentlich" alles funktionieren "müsste". --
Und fuer die Jahre-Hiersein finde ich die zwei Ergebnisse (unechte Mini-FAQ und Etikette) recht duenn!!!!!!!! Ich glaub es hackt. Du kannst ja das Geld zurück verlangen, wenn es Dir nicht paßt. [> toRBEN pOLLmann und Bernd Brodesser in suse-linux]
Christian Boltz, Sonntag, 19. Juni 2005 01:04:
(ich antworte auf die Ursprungsmail, weil ich von den abenteuerlichen Vorschlägen im Rest des Threads Kopfweh bekomme...) [...] Nochwas: vergiss bitte _alle_ in diesem Thread genannten weiteren Vorschläge. dd ist für ein Backup genauso ungeeignet wie die Komprimierung (egal ob zip oder gzip), da bereits ein gekipptes Bit das ganze Backup unbrauchbar machen kann!
Was ist denn an meinem Vorschlag so abenteuerlich, daß man gleich Kopfweh kriegen muß davon? Das mit dem gekippten Bit ist OK. Aber dd finde ich ist hier schon das Mittel der Wahl. Denn der OP will an seiner Partitionstabelle herumbauen, das Root-FS verändern, usw. Wenn's blöd läuft, dann bootet die Kiste am Schluß nicht mehr. Wenn er nun ein Image hat, dann zieht er es zurück, und kann von vorne anfangen. Natürlich kann man auch von allen Dateien ein Backup anlegen, und wenn alles schief läuft, dann partitioniert man neu, legt alle FS neu an, und kopiert die Daten zurück. Aber das ist doch wesentlich umständlicher. -- Antworten an lists@feile.net werden in /dev/null archiviert! Bitte ggf. lists... durch mail... ersetzen. Andreas Feile www.feile.net
Hallo Andreas, hallo Leute, Am Sonntag, 19. Juni 2005 03:19 schrieb Andreas Feile:
Christian Boltz, Sonntag, 19. Juni 2005 01:04:
(ich antworte auf die Ursprungsmail, weil ich von den abenteuerlichen Vorschlägen im Rest des Threads Kopfweh bekomme...) [...] Nochwas: vergiss bitte _alle_ in diesem Thread genannten weiteren Vorschläge. dd ist für ein Backup genauso ungeeignet wie die Komprimierung (egal ob zip oder gzip), da bereits ein gekipptes Bit das ganze Backup unbrauchbar machen kann!
Was ist denn an meinem Vorschlag so abenteuerlich, daß man gleich Kopfweh kriegen muß davon? Das mit dem gekippten Bit ist OK. Aber dd finde ich ist hier schon das Mittel der Wahl. Denn der OP will an seiner Partitionstabelle herumbauen, das Root-FS verändern, usw. Wenn's blöd läuft, dann bootet die Kiste am Schluß nicht mehr. Wenn er nun ein Image hat, dann zieht er es zurück, und kann von vorne anfangen.
Mit einen dateiweisen Backup geht das auch. (Ja, man muss dann den Bootloader neu installieren.) Diskimages würde ich nur empfehlen, wenn das Dateisystem eine Macke hat und man mehrere Chancen beim fsck haben will.
Natürlich kann man auch von allen Dateien ein Backup anlegen, und wenn alles schief läuft, dann partitioniert man neu, legt alle FS neu an, und kopiert die Daten zurück. Aber das ist doch wesentlich umständlicher.
Nur geringfügig - dafür ist es deutlich flexibler. Angenommen, bei der Größenänderung der Partition geht was schief - hilft es Dir wirklich, wenn Du die Daten mit alter Partitionierung zurückkopieren kannst? Die Partitionen haben dann immer noch die alte Größe und Du musst es nochmal versuchen. (Falls der Fehler bei der Umpartitionierung reproduzierbar ist, wird das eine Endlosschleife ;-) Mit einem dateiweisen Backup partitioniert man wunschgemäß (und kann sogar, falls gewünscht, auf ein anderes Dateisystem wechseln), kopiert dann alles zurück und richtet den Bootloader neu ein. Geht immer. Außerdem kann man das Backup auch später noch verwenden, falls man versehentlich einzelne Dateien gelöscht hat. Das Restaurieren einer Datei aus einem gesplitteten Diskimage (Komprimierung hin oder her) dürfte dagegen deutlich schwieriger werden... Gruß Christian Boltz --
... und der bildschirm unter kde3 ist sauschnell geworden im vergleich zur 7.3. Upps. Muß ich 'was b'sonderes beachten? Ich dachte eigentlich, daß der Monitor mit seinen 34 Kg nicht so schnell abhaut ... :-) [> Holger Poggel und Michael Nausch in suse-linux]
participants (4)
-
Andreas Feile -
Christian Banek -
Christian Boltz -
H.-Peter Baldamus