# auf größere NVME umziehen und booten

## michael_w

Hallo,

ich habe im Rechner eine NVME (Samsung 960 Pro 1 TB) stecken, die wird jetzt aber voll. Von daher würde ich gern auf eine andere (größere) NVME (Samsung 980 Pro 2 TB) "umziehen" ohne Neuinstallation.

Beim lesen im Netz gibt es da wohl 2 Möglichkeiten, die eine ist via dd, die andere via rsync. Was ist der bessere Weg Eurer Meinung nach?

Der PC hat 2 M2 Slots, meine Vorgehensweise war jetzt, die größere NVME in den 2. Slot und dann kopieren (dd oder rsync). Leider hab ich dann schon beim booten ein Problem. Der PC kommt über das Grub Menu nur bis zum Anfang der boot Sequence, dann ist Schluss:

kernel panic - not syncing: VFS: unable to mount root fs on unknown-block (0,0)

Lösungsversuch:

https://wiki.gentoo.org/wiki/Knowledge_Base:Unable_to_mount_root_fs

geht leider nur auf grub und nicht auf grub2 eine

Die Frage die sich mir stellt, ist das ein Hardware oder ein Software Problem? Weil, ich stecke ja lediglich eine  neue NVME in einen 2. Slot und boote dann. Der Bootloader (grub) wird j auch gefunden und dort müsste doch die 1. NVME drin stehen, tut sie ja auch, weil ich mit einem leeren 2. Slot ohne Probleme von der 1. NVME booten kann. 

Das Ganze könnte ich jetzt umgehen, indem ich von einem USB Stick boote, danach 1. NMVE auf 2. "kopieren" per dd, 2. NMVE in den 1. Slot und booten (in der Hoffnung, das das dann funktioniert). 

Nächstes Thema ist dann die Partitionsgröße, mit rsync umgeht man das Problem, mit dd hat man eine kleinere Partition, wie vergrößern ohne Datenverlust? mit parted?

----------

## ManfredB

Ich kenne das, weil ich auch eine neue SSD im PC stecken habe,

die ersetzt eine SSD von kleinerer Größe.

Ich habe dann alles von der kleinen SSD auf die große SSD (1 TB) kopiert.

Dann habe ich jedes System erst einmal mit einer neuen fstab ausgestattet.

Danach in einer chroot-Umgebung

grub-mkconfig -o /boot/grub.grub.cfg

ausgeführt und das Ergebnis in die grub.cfg meines Bootloaders (UEFI) von ArchLinux

übertragen.

Die Systeme starten einwandfrei.

Aber ohne die Maßnahmen, die ich beschrieben habe, kann es nicht funktionieren,

denn auf der neuen Platte stimmt ja die alte UUID nicht mehr.

Viel Erfolg wüsche ich dir.

Gruß

Manfred

P.S. welchen Bootloader nutzt du denn?

----------

## firefly

Wie sieht die root= kernel parameter bei dir aus?.

Das kopieren eines systems auf ein neuen Datenträger ist recht einfach.

Man muss nur auf folgende Punkte achten:

Welcher bootloader wird verwendet

Welche Partitionstabellen Schema wird verwendet? (GPT oder MSDOS oft auch als MBR bezeichent)

Wie sieht das Partitionslayout aus?

Wird via uefi oder klassich "bios" geboootet?

Für das eigentliche kopieren kann man wie folgt vorgehen:

Das gleiche Partitionslayout auf dem neuen Datenträger erstellen. Der zusätzliche Platz dann entweder für root (/) oder /home verwenden.

Von einem Livesystem starten.

Von beiden Datenträgern die root partition mounten (in separate Verzeichnisse)

Die Daten der root partition auf die root partition des neuen Datenträgers kopieren (z.b. via rsync: rsync -aAXx <old root mount path> <new root mount path>

Wenn man z.b /home, /boot oder andere Verzeichnisse als separate Partitionen hat diese nun bei beiden Datenträgern mounten)

Den inhalt von den zusätzlichen Partitionen dann vom alten Datenträger auf den neuen kopieren.

Damit sind dann alle Daten auf dem neuen Datenträger.

Folgendes muss man dann auf dem neuen Datenträger anpassen

/etc/fstab damit auf die neuen Partitionen verwiesen wird (wenn LABEL; UUIDs verwendet werden)

Konfiguration des bootloaders, damit das rootfs des neuen Datenträgers referenziert wird.

Auf den neuen Datenträger den bootloader installieren.

Im BIOS/UEFI die boot reihenfolge ändern, damit der neue Datenträger als erstes geprüft wird.

Das ist im groben der Ablauf, mit dem auch ich ein System auf einen neuen Datenträger übertragen haben

Details sind abhängig von deinem system

----------

## Christian99

 *michael_w wrote:*   

> Hallo,
> 
> ich habe im Rechner eine NVME (Samsung 960 Pro 1 TB) stecken, die wird jetzt aber voll. Von daher würde ich gern auf eine andere (größere) NVME (Samsung 980 Pro 2 TB) "umziehen" ohne Neuinstallation.
> 
> Beim lesen im Netz gibt es da wohl 2 Möglichkeiten, die eine ist via dd, die andere via rsync. Was ist der bessere Weg Eurer Meinung nach?

 

Ich würde sagen, es gibt keinen besseren Weg. Beide funktionieren, unterscheiden sich aber in details:

mit dd wird die komplette Platte 1:1 kopiert, danach muss man, beim umziehen auf eine größere Platte, noch den restlichen freien Platz auf der größeren Platte Partitionieren, sonst wird der nicht genutzt.

bei rsync wird der Inhalt (dateien/Verzeichnisse) kopiert. dazu muss man Partitionen/Dateisystem zuvor manuell anlegen. Dabei werden für die neuen Partitionen und Dateisystem auch neue UUIDS erzeugt, und man muss danach konfiguration (bootloader, fstab... ) entsprechend anpassen.

Bei dd werden die UUIDs einfach mit kopiert, was aber auch nicht immer gut ist, wenn man z.B. die alte platte weiter nutzen möchte.

Welchen weg man wählt hängt von der Situation/persönlichen vorlieben ab.

 *Quote:*   

> 
> 
> Der PC hat 2 M2 Slots, meine Vorgehensweise war jetzt, die größere NVME in den 2. Slot und dann kopieren (dd oder rsync). Leider hab ich dann schon beim booten ein Problem. Der PC kommt über das Grub Menu nur bis zum Anfang der boot Sequence, dann ist Schluss:

 

Hast du jetzt dd oder rsync verwendet? das ist schon interessant zu wissen. bei rsync musst du die neuen UUIDs entsprechend verwenden. Mit dd solltest du die alte SSD danach entfernen. sonst hast du doppelte FS/Partitions UUIDs. Weiß nicht genau, wie das gehandelt wird, aber gut ist das vermutlich nicht

 *Quote:*   

> 
> 
> kernel panic - not syncing: VFS: unable to mount root fs on unknown-block (0,0)
> 
> Lösungsversuch:
> ...

 

Das es für grub und nicht grub2 ist, ist nicht so relevant, da die Meldung vom kernel kommt. Heißt der kernel wurde von grub bereits geladen, aber mit falschen parametern. deswegen findet er kein rootfs

 *Quote:*   

> 
> 
> Die Frage die sich mir stellt, ist das ein Hardware oder ein Software Problem? Weil, ich stecke ja lediglich eine  neue NVME in einen 2. Slot und boote dann. Der Bootloader (grub) wird j auch gefunden und dort müsste doch die 1. NVME drin stehen, tut sie ja auch, weil ich mit einem leeren 2. Slot ohne Probleme von der 1. NVME booten kann. 

 

ziemlich sicher software. bei einem hardware problem hättest du vermutlich vorher beim kopieren schon Probleme gehabt.

 *Quote:*   

> 
> 
> Das Ganze könnte ich jetzt umgehen, indem ich von einem USB Stick boote, danach 1. NMVE auf 2. "kopieren" per dd, 2. NMVE in den 1. Slot und booten (in der Hoffnung, das das dann funktioniert). 
> 
> Nächstes Thema ist dann die Partitionsgröße, mit rsync umgeht man das Problem, mit dd hat man eine kleinere Partition, wie vergrößern ohne Datenverlust? mit parted?

 

das kopieren solltest du sowieso nicht von einen laufenden system aus machen. das kann zu inkonsistenzen im Inhalt führen, mit dd eher als mit rsync.

zum resizen der partition kann man vermutlich parted verwenden (damit kenn ich mich nicht aus), aber ich würde g/fdisk verwenden, je nach partitionstyp.

danach muss aber auch noch das dateisystem auf der partition vergrößert werden, das ist abhängig vom typ des dateisystems.

Ich würde erst mal schauen, ob die kernel parameter in der grub.cfg für dein setup stimmen. im besonderen root=...

----------

## Josef.95

Hi,

zum Daten rüber kopieren würde ich schlicht und einfach cp -a von einem Live-System aus nutzen.

Beachte aber, um auch die .files mitzubekommen setze in der Shell vorher 

```
shopt -s dotglob
```

 und kopiere dann zb via 

```
cd /mnt/new-disk

shopt -s dotglob

cp -a /mnt/old-disk/* .
```

Hab das hier so schon mehrfach erfolgreich gemacht - tut gut :)

----------

## mike155

Sehe ich genauso wie Josef.95. Wenn ich auf SSDs oder NVMes kopiere, versuche ich dd zu vermeiden. Wenn man dd doch verwendet, sollte man hinterher unbedingt die Dateisysteme mounten und fstrim laufen lassen, damit die SSD/NVMe die nicht belegten Sektoren wieder freigeben kann.

----------

## firefly

kopieren via dd ist eh problematisch wenn die beiden Datenträger unterschiedliche größen haben.

Wenn der ziel datenträger größer ist, nutzt man nicht die volle kapazität. Um diese nutzen zu können muss man nachträglich die Partition(en) und das Dateisystem/die Dateisysteme vergrößern.

Wenn der ziel datenträger kleiner ist, dann bricht das kopieren mit einem fehler ab und man hat nur datenschrott

Ob man jetzt cp -a oder rsync verwendet um die daten zu kopieren ist da echt geschmacksache.

Hat aber gegenüber dd grundlegen den vorteil, dass man auch das Partitionslayout ändern kann wenn gewünscht.

----------

## mike155

@michael_w: ich weiß nicht genau, wo Du jetzt stehst. 

Ein genereller Tipp: falls Du mit der neuen NVMe nicht mehr booten kannst - und das das einzige Problem ist - könntest Du einen USB-Stick mit SystemRescue erstellen. Im dortigen Boot-Menü gibt es eine Option "Auf Festplatte installiertes System booten". Damit könntest Du Dein System booten. Du erhältst Dein normales System, aber mit dem SystemRescue Kernel. Dann könntest Du alle notwendigen Einstellungen vornehmen und auch grub-mkconfig und grub-install aufrufen (je nachdem, wie Du grub konfiguriert und installiert hast).

----------

## michael_w

Hallo in die Runde, 

ich Danke Euch allen für die hilfreichen Anmerkungen zwecks kopieren der Daten. Ich werd das irgendwie hinbekommen und hier berichten. 

Ich hatte oben noch einen weiteren Punkt angesprochen, aber offenbar habe ich mich undeutlich ausgedrückt. 

Es besteht hier noch unabhängig vom kopieren der Daten folgendes Problem; ich habe ein funktionierenden PC mit Gentoo Linux auf der 1. NVME, das bootet ohne Probleme und alles ist gut. Jetzt nehme ich die neue NVME (2 TB), stecke sie in den 2. Slot (auf der NVME ist noch nix drauf, quasi fabrikneu) und schon bekomme ich beim booten den kernel panic.  Wieso ist das so? Was ist da der Grund dafür?

Der entsprechende Abschnitt in der grub.cfg sieht so aus:

```

menuentry 'Gentoo GNU/Linux, mit Linux 5.13.4-gentoo' --class gentoo --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-5.13.4-gentoo-advanced-17cdbd01-c19d-4185-9ebc-15f64848b2d5' {

        load_video

        set gfxpayload=keep

        insmod gzio

        insmod part_msdos

        insmod ext2

        search --no-floppy --fs-uuid --set=root ff77632c-122b-499f-a6cb-4cfcdbe7af3d

        echo    'Linux 5.13.4-gentoo wird geladen …'

        linux   /vmlinuz-5.13.4-gentoo root=/dev/nvme0n1p4 ro  quiet splash

}

```

----------

## firefly

vermutlich wird die NVME im slot 2 als erstes vom system erkannt.

-> die neue NVME ist dann /dev/nvme0nxxx.

besser wäre es wenn du GPT als partitionsschema nutzen würdest, dann könntest du mit root=PARTUUID=<uuid der partition> nutzen dann ist es egal in welcher reihenfolge die devices erkannt werden.

Was auch geht, benötigt aber ein initramfs/initrd die root partition via Filesystem UUID oder Filesystem Label anzusprechen.

Aber in egal welchen fällen must du wahrscheinlich auch die /etc/fstab anpassen (wenn du zusätzliche partitionen hast z.b. für /home) und dort /dev/nvme0nXXX verwendest

Wie sieht eigentlich das partitionslayout aus? (Ausgabe von fdisk -l /dev/nvme0n1)

----------

## mike155

Du hast Dich oben sehr ungenau ausgedrückt. Was Du vermutlich sagen wolltest: Grub wurde geladen und Grub hat dann den Kernel geladen. Und in dem Augenblick, als der Kernel das Root-Dateisystem mounten wollte, gab es die Meldung "kernel panic - not syncing: VFS: unable to mount root fs on unknown-block (0,0)". Richtig?

Also, dann ist Dein GRUB-Eintrag richtig, denn sonst würde der Kernel geladen werden. 

Der Kernel-Parameter "root=/dev/nvme0n1p4" funktioniert aber nicht. 

Vermutlich nennt Dein Kernel Deine erste NVMe jetzt nicht mehr nvme0n1, sondern nvme1n1.

Also gehe ins GRUB Boot-Menu, dann in den Edit-Modus und mache aus dem Parameter  "root=/dev/nvme0n1p4" ein  "root=/dev/nvme1n1p4" und boote.

Jetzt solltest Du etwas weiter kommen - bis zu der Stelle, an der die Root-Partition "rw" remountet wird - und auch weitere Partitionen gemountet werden. Damit das auch funktioniert, musst Du noch die Device-Namen in der /etc/fstab anpassen.

Falls Du keine Lust auf die Device-Naming-Spielchen haben solltest, kannst Du auch auf  Dateisysstem-/Partitions Labels/UUIDs wechseln - deshalb sind die eingeführt worden.  :Smile:  Falls Du das machst, musst Du aber doppelt und dreifach aufpassen, wenn/falls Du "dd" für das Kopieren verwendest - denn dann gäbe es in Deinem System mehrere Dateisysteme/Partitionen mit den gleichen Labels/UUIDs, was dann auch wieder zu Ärger und unerwünschten Nebenwirkungen führt...

----------

## ManfredB

Nur so nebenbei, was das Kopieren von SSD1 auf SSD2 betrifft.

Ich mache das so:

mounte die leere Partition auf der neuen SSD /mnt/gentoo, die zu kopierende Partition auf /root/tmp.

Dann öffne ich mc, links /root/tmp, rechts /mnt/gentoo.

Markiere links das gesamte System.

Per F5 starte ich die Kopie, das geht bei SSDs relativ schnell und funktioniert einwandfrei.

Mit dd arbeite ich nur auf Konsole, wenn ich zB eine iso auf einen USB-Stick kopieren will.

Vielleicht wirkt das jetzt wie ein wenig veraltet, aber ich wollte es zumindest einmal ansprechen.

Gruß

Manfred

----------

## mike155

 *Quote:*   

> Dann öffne ich mc, links /root/tmp, rechts /mnt/gentoo.

 

Werden dabei auch extended attributes und ACLs mitkopiert?

Wenn man eigene Dateien im Home-Verzeichnis kopiert, sind extended attributes und ACLs nicht so wichtig. Aber bei Systemdateien sollte man sichergehen, dass alles richtig ankommt...

Die Inhalte der Verzeichnisse /tmp, /proc, /run, /sys und /dev sollte man übrigens nicht kopieren. Hier muss nur das Verzeichnis selbst angelegt werden.

----------

## ManfredB

Hallo zusammen,

wenn ich es so durchführe, ist links alles leer und rechts alles voll.

Größe der Partitionen: links 30GB, rechts 30GB.

Bisher habe ich so noch keine Probleme gehabt.

Gruß

Manfred

----------

## Christian99

 *ManfredB wrote:*   

> Hallo zusammen,
> 
> wenn ich es so durchführe, ist links alles leer und rechts alles voll.
> 
> Größe der Partitionen: links 30GB, rechts 30GB.
> ...

 

Mag sein, dass es bisher keine Probleme gab. Aber wenn man das ganze System kopiert, wüsste ich schon gerne, dass spezielle Permissions und flags mit kopiert werden. dafür sind die -a/--archive flags von cp und rsync extra da. Weiß nicht, ob mc das macht.

Áußerdem würde ich kopieren statt verschieben bervorzugen. da hat man dann noch das original, falls man unterbrechen muss, es einen Fehler gibt, etc.

----------

## ManfredB

Sorry, in meinem konkreten Fall habe ich nicht verschoben, sondern kopiert.

Da kann ich nun nicht sagen, was beim Kopieren mitkommt oder bleibt.

Ich habe das in den letzten Tagen gemacht: SSD 500GB liefert, SSD 1 TB empfängt.

Es ist richtig, daß beim Kopieren nicht zu erkennen ist, was übergangen wird.

Das scheint bei den von euch genannten Prozessen mit dd anders auszusehen.

Gruß

Manfred

----------

