NVMe boot

[Blue]

uefi != uefi

besonders zu den x86_64 efi anfängen war das alles andere als geil. daher is die alte bulldozer kiste kein maßstab, da diese aus dem zeitraum stammt, das is nich unbedingt grub seine schuld, das hab ich auch schon mit dem Windows Boot so gesehen.

[Arnulf zu Linden]

(04.02.2022 15:52)Blue schrieb:  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.

[Blue]

(04.02.2022 17:09)Arnulf zu Linden schrieb:  

(04.02.2022 15:52)Blue schrieb:  uefi != uefi

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

Ich habe nicht gesagt das jedes UEFI ne Wundertüte ist, sondern alt vs neu. Aber ok.

[Arnulf zu Linden]

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.
  

[Playitlouder]

(05.02.2022 02:10)Arnulf zu Linden schrieb:  

• 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.
  

Naja du nutzt halt auch Slackware.
Grub installieren ist normal halt ne Sache von sudo grub-install, sudo update-grub (arch).
Die grub.cfg muss man normal nicht mal anfassen.
Dann noch Paket Manager Hooks einrichten, damit initramfs bei Updates neu gebaut werden.

Außerdem ist es schon etwas amüsant, dass du solche Probleme ungefähr 10 Jahre später als andere hast

[Blue]

yay -S grub2 efibootmgr

und der drops ist gelutscht bei arch, wüsste nicht das ich da noch was gemacht hab

[Smaecks]

es kann durchaus sein, dass beim übertragen der partitionen auf die neue ssd irgendwelche uuids kaputt gegangen sind, das man da dann mit den installationsmedien der jeweiligen betriebssystem ggf. etwas reparieren muss empfinde ich da noch als am verständlichsten. so kann ja slackware nicht den bootloader von windows und anderesrum reparieren...

schön ist es nicht, dafür hat man sich aber bei alten mbr systemen mit anderen schwierigkeiten rumgeschlagen.

[Arnulf zu Linden]

(05.02.2022 04:00)Playitlouder schrieb:  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.

[Arnulf zu Linden]

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.