NVMe boot

Wenn ich das richtig verstanden habe, kann eine NVMe SSD nicht mit CSM starten, braucht also UEFI boot.

Braucht die für UEFI boot (grub2 als "1. stage bootloader") auch eine GPT oder geht das auch "klassisch" mit MBR?
Bei 500 GB ist von der Kapazität her keine GPT erforderlich, das greift erst bei > 2 TB.
MBR würde das Klonen der Betriebssysteme von der SATA SSD deutlich vereinfachen.
Hätte bei 500 GB GPT gegenüber MBR überhaupt signifikante Vorteile bei einem Multiboot-Szenario (ein oder zwei Linuxe, Windows 10)? Eine Windows 10 Neuinstallation soll vermieden werden.

"secure boot" soll nicht eingesetzt werden, da das für Linux und Windows 10 nicht gebraucht wird. Komme gerade nicht ans UEFI ran, weil ich auf der Kiste tippe. Beim Software-Ausprobierrechner ist "secure boot" separat abschaltbar.

Zitat von Smaecks

du wirst wohl oder übel nicht drum herum kommen deine festplatte auf gpt umzustellen, wenn du efi machen willst.

Umgestellt werden (im engeren Sinn) muss da nix, da die NVMe noch komplett leer ist (und auch noch gar nicht eingebaut ist).

Zitat von Smaecks

wenn ich das richtig verstehe sind windows und linux auf getrennten festplatten,

Nein, die liegen beide auf der 500 GB SATA SSD.

Zitat von Smaecks

os-probe sollte dein windows auf der zweiten festplatte erkennen und so starten.

Das hat zumindest eben auf dem Software-Ausprobierrechner funktioniert, obwohl auch dort Linux & Windows auf einer 500 GB SATA SSD versammelt sind. Der manuelle Eingriff danach wurde nötig, um für eine Linux-Inst. zwischen drei verschiedenen Kerneln (aktuell kompiliert, den davor kompiliert, Distro-Kernel als fallback) auswählen zu können.

Zitat von Smaecks

vielleicht gibts auch passende programme auf linuxssystemen? für mich war das zurückspielen von backups immer leichter...

Linux zu klonen ist nicht so das Ding. Wenn /boot auf einer eigenen Partition liegt, braucht man nicht mal einen Installationsdatenträger für einen emergency-boot. Das Klonen der Root-Partition erfolgt aus einem Live-Linux heraus. Quell- und Zielpartition einbinden, einmal cp -a starten und dann was anderes machen, bis das fertig kopiert hat. Das alles sollte grundsätzlich auch funktionieren, wenn die Quelle mit MBR un das Ziel mit GPT partitioniert sind (und die Zielpartition genug Platz für alle Daten der Quellpartition hat), da auf Dateisystemebene (hier: ext4) gearbeitet wird.

Bei Windows 10 wird es vermutlich nicht so einfach gehen. Das habe ich bisher immer mit dd geklont. Wenn gfdisk wie (schon länger) fdisk mit "1 MB alignment" arbeitet, könnte das vielleicht klappen, wenn eine exakt gleich große Partition für Windows auf der NVMe angelegt wird.

Bevor hier wieder etwas eskaliert oder missverstanden wird: Der aktuelle Plan ist GPT + grub2. grub2 läuft ja bereits auf dem Software-Ausprobierrechner und GPT wird sich irgendwann nicht vermeiden lassen – spätestens wenn doch mal eine SSD oder HDD > 2 TB Einzug halten sollte, was aber aktuell nicht ansteht. Momentan ist die EDV-Lage recht entspannt, also günstig für so eine Umstellung auf GPT + grub2 mit UEFI boot.

Wenn ich das richtig verstanden habe, braucht nur die SSD, die mit UEFI boot bestiefelt werden soll, GPT und die übrigen SSDs/HDDs können auf MBR verbleiben (oder später mal in aller Ruhe auf GPT umgestellt werden).

Die Radeon HD 7850 im Software-Ausprobierrechner ist 'n ziemlicher Klopper, den man i.d.R. nicht in einem Server haben möchte.
Deshalb bekam die ein BIOS-Update, das offensichtlich funktionierte. Linux und Windows laufen danach wie gewohnt. Wird im UEFI CSM=disabled gesetzt, startet die Kiste danach ohne Fehlermeldung, springt dann aber ins UEFI. Ist das das normale Verhalten, wenn keine mit GPT partitionierte SSD/HDD dran hängt und auch kein Wechseldatenträger eingesteckt oder eingelegt ist?
Außerdem besteht mit dem Verbleib der Radeon R7 240 im Server zumindest die Möglichkeit, da irgendwann später auch mal beizugehen.

Der Plan ist, das Ganze (mit SATA SSD statt NVMe SSD) im Software-Ausprobierrechner (Brett hat kein NVMe-Slot) durchzueiern und erst im zweiten Anlauf das auf dem Arbeitsrechner (mit NVMe SSD) zu machen.
Eine 500 GB SATA SSD wurde eben dafür frei geschaufelt.

Mit den beiden Anleitungen
https://www.redhat.com/sysadmin/bios-uefi
https://wiki.archlinux.org/title/GRUB
läuft es nun prinzipiell auf dem Software-Ausprobierrechner. Leider ist die Benutzbarkeit stark eingeschränkt, denn das grub-Menü wird nicht mittig auf dem Bildschirm dargestellt:

Dadurch ist z.B. die grub-shell unbenutzbar. Mal eben einen Kernel mit init 3 statt init 4 zu starten geht daher nicht.

System:
AMD FX-8350
AsRock 890FX Deluxe5 (UEFI aktuell)
HIS 7850 Fan 2GB GDDR5 PCI-E DVI/HDMI/2xMini DP (AMD Radeon HD7850; BIOS aktuell)
Samsung SynMaster 2443
GRUB-2.06

Probiert wurden bisher erfolglos:

• GRUB_GFXMODE mit verschiedenen Auflösungen (auch auto), die das VBE der Grafikkarte und auch der Monitor unterstützen
• Konfiguration ohne VBE-Auflösung mittels GRUB_TERMINAL=console
• Ersatz der Grafikkarte durch eine AMD Radeon R7 240
• CMOS-Reset (mit Radeon HD 7850 drin)

Zitat von Blue

uefi != uefi

Dass jedes UEFI 'ne eigene Wundertüte ist, ist bekannt.

Nachdem das Foto mal 'ne Weile "gesackt" war, kam eine Idee auf, woran es liegen könnte. Im UEFI war der "full screen mode" (aka "logo mode") deaktiviert und der POST-Screen zeigte auffällig breite "schwarze Ränder". Nach Aktivierung des "full screen mode" sieht das grub-Menü danach aus, dass jetzt tatsächlich die Anzeige mit der Auflösung 1920×1200 erfolgt.

grub ist jetzt benutzbar!

Da sind jetzt zwar auch wieder breite "schwarze Ränder", aber das liegt vermutlich daran, dass grub eben auch mit geringeren Auflösungen bis runter zu 640×480 benutzbar bleiben muss.

Das war 's: Software-Ausprobierrechner und Arbeitsrechner laufen jetzt mit UEFI boot (ohne "secure boot"!) & GRUB2, im Arbeitsrechner starten Linux und Windows von der eingebauten NVMe SSD.

Erkenntnisse:

• So eine Aktion erst mal auf einem Rechner durchzueiern, auf dessen Software es im Ernstfall "nicht so drauf ankommt", gestaltet das Ganze deutlich entspannter als gleich Gefummel am Produktivsystem.
• Ein zweites Gerät mit Internetzugang, das sich in unmittelbarer Nähe befindet, ist extrem hilfreich.
• Weder Linux noch Windows müssen neu installiert werden.
• Obwohl nicht neu installiert werden muss, werden Installationsdatenträger (DVD oder USB-Stick) für Linux und Windows benötigt.
• Es treten sowohl für Linux als auch für Windows zwischendurch Zirkelbezüge auf, die jeweils nur durch einen Start von einem Installationsdatenträger (Wechseldatenträger) gelöst werden können.
• Die Aktion fällt insgesamt unter die Rubrik "nicht trivial".
• „Ich bin zu alt für diesen Scheiß.“
• Etwas überspitzt formuliert: LILO ist ein Bootloader, GRUB ein Betriebssystem.

Zitat von Playitlouder

Die grub.cfg muss man normal nicht mal anfassen.

Wenn man nicht irgendetwas vorgekotztes, was eben nicht unbedingt den eigenen Wünschen entspricht, im grub-Menü stehen haben möchte, muss man das schon. Das meiste lässt sich über Einträge in /etc/default/grub gefolgt von grub-mkconfig -o /boot/grub/grub.cfg einstellen, aber eben nicht alles.

grub2 & efibootmgr mit installpkg zu installieren und lilo mit removepkg zu entfernen ist nicht das Ding.

Wenn man zuvor nur mit MBR gearbeitet hat, muss man sich nun mal in die Materie GPT einlesen. Das war vor zehn Jahren nicht anders als heute.

Knackpunkt mit den Zirkelbezügen ist die Umstellung von BIOS boot auf UEFI boot:
Um boot entries mit Bordmitteln ins NVRAM zu schreiben, muss zuvor mit UEFI gestartet worden sein.
Um mit UEFI von SSD zu starten, müssen zuvor boot entries ins NVRAM geschrieben worden sein.

Irgendwie war es ja klar:
Windows 10 startet mittlerweile in einen BSOD "Inaccessible boot device" error 0x0000001

Der Grund dafür ist nicht mehr nachvollziehbar. Bekannt ist nur, dass in den letzten Tagen irgendwelche Updates kamen.

Die Partition enthält noch Daten, die nach einer Windows 10-inst. aussehen, chkdsk vom USB-Stick aus finedet auch keine Fehler.

bcdboot schreibt zwar auf die efi-Partition, aber beim nächsten Start kommt wieder der o.g. BSOD.

Vor bcdboot wurden die Laufwerkbuchstaben entsprechend zugewiesen, also c: für die 2 Partition mit der Windows 10-Inst. auf der NVMe-SSD und d: für die FAT32-Datenpartition auf der SATA-SSD.