jpg153 wrote:Guten Abend allerseits
gparted sagt "msdos" Partitionstabelle. Heißt dann wohl MBR.
Kann mich auch nicht erinnern vorher schon mal über GPT gefallen zu sein..
Guten Morgen,
Wenn die neue SSD größer als 2 TiByte ist, geht es nicht ohne GPT (mMn).
Es kann alles manuell erledigt werden.
Der grobe Umzugsplan ist:
- SSD einbauen
SSD partionieren (fdisk, gparted)
Dateisysteme anlegen (mkfs.xfs, mkfs.ext2, mkfs.ext4)
Inhalte alter Partitionen auf neue kopieren (tar, rsync, cp, clonezilla)
Evtl. /etc/fstab und /etc/lilo.conf auf neuer SSD anpassen
lilo -v in chroot-Umgebung für neue SSD laufen lassen
Einen feineren Umzugsplan ergibt die Beachtung einiger Einzelheiten.
Beim Einrichten eines Dateisystems auf einer SSD darauf achten, dass die richtige Blockgröße verwendet wird (vornehmlich 4 KiByte). Dabei müssen die Partitionenanfänge auf 4-KiByte-Boundaries zu liegen kommen. Andernfalls wird der spätere Betrieb extrem langsam sein. Ebenfalls darauf achten, dass der erste nutzbare Block nicht der 63. (0-63) ist. Diese Block-/Sektornummer (Sektornummer bei HDD) passt zur Sektorgröße 512 Byte.
Auf der neuen SDD müssen also mindestens drei Partitionen eingerichtet werden, z.B. /dev/sdc1, /dev/sdc2 und /dev/sdc3 und mit den gewünschten Dateisystemen bestückt werden. Vielleicht auch eine Swap-Partition einrichten, dann könnte die Spielerei im RAM unterbleiben. Wenn EFI, dann müssen zuerst noch die diversen kleinen Partitionen vom Anfang der alten SSD, auf der neuen SSD angelegt werden und später auch deren Inhalte kopiert werden.
Nachdem die neue SSD eingebaut wurde und wenn später von der neuen SSD gebootet werden soll, muss evtl. im Bios diese als erste in der Bootreihenfolge eingetragen werden.
Hier zwei Möglichkeiten für den Umzug.
1. Möglichkeit
Es erfolgt der Einfachheit halber eine vollständige Salix-Installation auf diese neue SSD. Dabei werden alle gewünschten Partitionen erzeugt und ggf. mit den Dateisystemen bestückt, wie schon vielfach geübt. Alle weiteren schon existierenden Partitionen auf den anderen Datenträgern können hierbei mitberücksichtigt werden oder später in der neuen fstab nachgetragen werden. Kann von dieser Konstellation dann erfolgreich gebootet werden, wird in den Runlevel 1 gewechselt. Alle Partitionen, außer der Root-Partition, werden abgemeldet und nach unten stehendem Muster werden dann die Inhalte von /dev/sdb5 und /dev/sda1, die jetzt andere Gerätenummern haben können, an ihre neuen Plätze kopiert. Dann erneut vom Installationsmedium booten, bis eine Kommandozeile erreicht werden kann und darin in einer chroot-Umgebung die alte Root-Partition mit Ausnahme von '/boot', '/proc/', /etc/fstab und /etc/lilo.conf über die neue Root-Partition kopieren. Umzug fertig.
Dem tar kann über den Parameter "-X DATEI" mitgeteilt werden, welche Verzeichnisse und Dateien nicht mitkopiert werden sollen. Das unten stehende Muster in der 2. Möglichkeit kann dann so abgeändert werden:
Code: Select all
tar cpf - -X /mnt/old/die_nicht.lst * | tar xpC /mnt/new/
"die_nicht.lst" enthält dann zeilenweise: /boot /proc /etc/fstab und /etc/lilo.conf .
2. Möglichkeit
Die Partitionen erstellen. Anschließend würde folgendes den Rest erledigen (alles mit sudo-Präfix, oder als richtiger Root-Benutzer; alles am Besten in Runlevel 1; altes /home und altes /5gbstore müssen dabei abmontiert sein (umount)):
Code: Select all
mkdir /mnt/{old,new}
mount /dev/sdb1 /mnt/old
mount /dev/sdc1 /mnt/new # später neues /
cd /mnt/old
tar cpf - * | tar xpC /mnt/new/
sync
umount /mnt/old
umount /mnt/new
mount /dev/sdb5 /mnt/old
mount /dev/sdc2 /mnt/new # später neues /home
cd /mnt/old
tar cpf - * | tar xpC /mnt/new/
sync
umount /mnt/old
umount /mnt/new
mount /dev/sda1 /mnt/old
mount /dev/sdc3 /mnt/new # später neues /5gbstore
cd /mnt/old
tar cpf - * | tar xpC /mnt/new/
sync
umount /mnt/old
umount /mnt/new
Eines der tar in der Kette könnte mit dem "v"-Schalter ausgestattet werden, so dass die übertragenen Dateien angezeigt würden (z.B. tar cpvf ...). Die Ausgaben auf den Bildschirm verbrauchen aber viel mehr Zeit, als der eigentliche Übertragungsvorgang benötigt, so dass der Umzug sehr stark ausgebremst wird. Also besser Abstand nehmen.
Benötigte Partitionen wieder montieren. Dann fstab auf der neuen SSD anpassen. Die Nummerierung der neuen Partitionen wurde im obrigen Beispiel geändert. Das kann zusätzliches Editieren von Konfigurationsdateien nötig machen.
An dieser Stelle müsste bei Verwendung von lilo, dieser konfiguriert werden (/etc/lilo.conf), wenn von der neuen SSD gebootet werden soll. Wenn die neue SSD hinzukommt, die anderen SSDs/HDDs also bleiben, dann stellt sich auch noch die Frage, ob die neue SSD künftig die /dev/sda sein soll und die anderen Massenspeicher andere Gerätenummern erhalten sollen.
(3) zeigt eine Variante, die gut nachzuempfinden ist und bei der Grub zum Einsatz kommt. Wenn Grub nicht eingesetzt wird, geht es stattdessen mit Lilo weiter.
Komfortabler beim Kopieren kommt der Einsatz von Clonezilla. Dazu muss aber erst Clonezilla auf CD/DVD/USB-Stick gebracht werden. Einarbeitung und Handarbeit sind auch nötig. Aber trotzdem einmal genauer ansehen!
Ein paar weitere Zeilen Literatur:
1)
http://www.pcwelt.de/ratgeber/Linux-Mob ... 16721.html
2)
http://www.pcwelt.de/ratgeber/So_zieht_ ... 29352.html
3)
https://wiki.archlinux.de/title/Installation_umziehen
4)
https://wiki.ubuntuusers.de/Ubuntu_umziehen/
Ein Beispiel einer chroot-Umgebung, aber variabel, z.B.:
Code: Select all
mount -o bind /dev /mnt/new/dev
mount -t proc proc /mnt/new/proc
chroot /mnt/new /bin/bash
Bitte unbedingt alle Literaturhinweise lesen und sich bei der Arbeit sehr viel Zeit nehmen. Am Besten scheibt man sich bei einer komplexen Aufgabe alle Arbeitsschritte und Konfigurationsdaten haarklein in eine Datei und druckt sich diese.
Obriges hoffentlich ohne gröbere Fehler. Trotzdem, alles ohne Schießgewehr.