Von dem Problem habe ich nur durch Dritte erfahren, konnte es aber leicht lösen.  Stellt Euch mal vor Ihr kauft Euch eine NVMe SSD  und Euer Bios kann die nicht booten, was macht Ihr dann  ?

Das Problem

Es soll Motherboards geben, die zwar einen passenden Port für die NVMe SSD haben, aber leider vergessen haben, daß man ja auch davon booten können müßte. Wenn man jetzt nur so eine NVMe SSD hat, ist man sprichwörtlich gearscht. Falls man nicht vor hat, seinen Rechner per USB Stick zu booten und von der LiveDisk mit der SSD zu spielen, wird das eine sehr frustrierende Neuanschaffung.

Die Idee

Aber halt! Wenn man das System von einem USB Stick booten kann, könnte man dann nicht auch NUR davon booten ohne die Livedisk zu starten ?

Die Lösung

Na ja, vom Prinzip her schon, aber USB-Stick, das muß doch besser gehen. Ja geht es, aber ihr braucht dafür eine normale SSD oder HD, die kann aber ganz winzig sein, Hauptsache 512 MB passen drauf!

Bei der Installation Eures OSes wählt man für /, Swap und /home die neue NVMe SSD aus. Normal partitionieren und formatieren, soweit nichts besonderes.

Die /boot Partition kicken wir jetzt aber nicht auf die NVMe sondern die alte/kleine SSD. Dort wird auch der Bootloader installiert. Linux ist es nämlich völlig egal, wo die Partionen liegen, Hauptsache der Bootloader kann es finden und das kann er ja dann. Problem gelöst.

Sein System auf die neue NVMe umstellen, ohne neu zu installieren

Wie man eine defekte Bootpartition fixen kann, hatte ich schon mal thematisiert, daher setzte ich das Wissen jetzt bei Euch voraus. Wie man unschwer erkennen kann, habe ich hier den Booteintrag in Grub vor mir :

menuentry 'Fedora (4.14.4-200.fc26.x86_64) 26 (Twenty Six)' --class fedora --class gnu-linux --class gnu --class os --unrestricted $menuentry_id_option 'gnulinux-4.13.8-100.fc25.x86_64-advanced-e62edbbe-a1ae-4242-bca5-1249d6f2df67' {
 load_video
 set gfxpayload=keep
 insmod gzio
 insmod part_msdos
 insmod ext2
 set root='hd2,msdos1'
 if [ x$feature_platform_search_hint = xy ]; then
 search --no-floppy --fs-uuid --set=root --hint-bios=hd2,msdos1 --hint-efi=hd2,msdos1 --hint-baremetal=ahci2,msdos1 221608f2-5914-4619-9ef7-6dfddf233fd4
 else
 search --no-floppy --fs-uuid --set=root 221608f2-5914-4619-9ef7-6dfddf233fd4
 fi
 linux /vmlinuz-4.14.4-200.fc26.x86_64 root=/dev/mapper/luks-ffbd61f2-4c1e-4dc8-b12b-c89e9f69c9fa ro rd.driver.blacklist=nouveau modprobe.blacklist=nouveau vconsole.font=latarcyrheb-sun16 rd.luks.uuid=luks-ca1f019d-39ce-4cf8-b522-f6d3e63ebe2a rd.luks.uuid=luks-ffbd61f2-4c1e-4dc8-b12b-c89e9f69c9fa rhgb quiet splash audit=0 rd.driver.blacklist=nouveau nouveau.modeset=0 modprobe.blacklist=nouveau LANG=de_DE.UTF-8
 initrd /initramfs-4.14.4-200.fc26.x86_64.img
}

Ok, meine Systempartition ist vollverschlüsselt, daher habe ich da die LUKS-ID stehen. Auf einem „normalen“ System könnte das so aussehen :

menuentry 'Fedora (4.14.6-200.fc26.x86_64) 26 (Twenty Six)' --class fedora --class gnu-linux --class gnu --class os --unrestricted $menuentry_id_option 'gnulinux-4.7.10-100.fc23.x86_64-advanced-dca7eea1-687e-476a-a9a0-c41ef0329113' {
 load_video
 set gfxpayload=keep
 insmod gzio
 insmod part_msdos
 insmod ext2
 set root='hd0,msdos1'
 if [ x$feature_platform_search_hint = xy ]; then
 search --no-floppy --fs-uuid --set=root --hint='hd0,msdos1' dca7eea1-687e-476a-a9a0-c41ef0329113
 else
 search --no-floppy --fs-uuid --set=root dca7eea1-687e-476a-a9a0-c41ef0329113
 fi
 linux /boot/vmlinuz-4.14.6-200.fc26.x86_64 root=UUID=dca7eea1-687e-476a-a9a0-c41ef0329113 ro rhgb quiet audit=0 LANG=de_DE.UTF-8
 initrd /boot/initramfs-4.14.6-200.fc26.x86_64.img
}

Alles was man machen muß, ist die UUID der Partition zu ändern und schon bootet das System als System von der anderen SSD. Wie bekommt man die jetzt, nachdem man die NVMe SSD partitioniert und formatiert hat ?

UUID ermitteln

# blkid
/dev/xvda1: UUID=“dca7eea1-687e-476a-a9a0-c41ef0329113″ TYPE=“ext4″ PARTUUID=“000af34a-01″
/dev/xvda2: UUID=“262b5659-4c18-4d8b-89e9-d9ba932e77c0″ TYPE=“swap“ PARTUUID=“000af34a-02″
/dev/xvdb: UUID=“65d31ff9-53c9-4e0b-8a52-0a16622c82d9″ TYPE=“ext4″

Mit dem gleichen Befehl bekommt man auch die LUKS ID mitgeteilt, so man denn eine verschlüsselte Luks-Partition hat:

/dev/mapper/luks-ca1f019d-39ce-4cf8-b522-f6d3e63ebe2a: UUID=“46da0d80-21fb-45b7-8567-ba047de66cb6″ TYPE=“swap“
/dev/mapper/luks-ffbd61f2-4c1e-4dc8-b12b-c89e9f69c9fa: UUID=“e62edbbe-a1ae-4242-bca5-1249d6f2df67″ TYPE=“ext4″

(Zwischenfrage aus dem Publikum: Wieso verschlüsselst Du auch SWAP ?  Antwort: Weil in dem ausgelagerten Speicher Klartext steht und man sich andernfalls eine Sicherheitslücke ins Haus holt. )

Natürlich muß man sein System noch ein bisschen pimpen, damit es später nicht wieder von der alten Systempartition auf der „alten SSD“ booten, nur weil der Kernel neu erstellt wurde 😀 Folgende Punkte sind zu manipulieren:

/etc/fstab
/etc/mtab
/etc/default/grup

Also alle alten UUID/LUKS-IDs durch die neuen ersetzen. Das ist ein ganz schöner Schock, wenn man seine neue SSD im Betrieb hat und dann ein paar Tage später der Rechner wieder auf einem alten Stand ist 😀