GRUB 2 kann, wenn es als EFI-Binary hinterlegt ist prinzipbedingt keine Betriebssysteme im "BIOS" mode booten. Was wirklich passiert ist, dass über das Hilfsprogramm os-prober andere Linux (eigentlich auch BSD, Windows im nicht UEFI mode) Installationen gefunden werden. Sollte eine Distribution aus was für Gründen auch immer nicht gefunden werden ist das ein Bug von os-prober und sollte dort reported werden (meist ist ne Korrektur ziemlich einfach). Die grub.cfg wird hierbei mit Hilfe von
grub-mkconfig -o /boot/grub/grub.cfg
erzeugt, das funktioniert eigentlich überall, wo GRUB2 verwendet wird, ist os-prober verfügbar werden die gefundenen Systeme mit eingetragen. Unter Debian oder Ubuntu gibts ein kleines Script names
update-grub
wo genau diesen Befehl aufruft. Hierbei werden die Scripte unter /etc/grub.d geparst zur erzeugung der Konfig. Alle anderen Distributionen, welche GRUB2 einsetzen könn(t)en ebenfalls os-prober verwenden.
Hierbei werden die Kernel direkt aus den Linux Partitionen geparst, wenn diese gebootet werden schaltet GRUB nicht etwa in den "BIOS" Mode zurück, nein das System bleibt im UEFI Mode. Es ist wichtig zu erwähnen, dass aktuelle Boards nur UEFI im 64 bit mode unterstützen. Bootet man trotzdem ein 32 bit Linux system ist es nicht unwahrscheinlich, dass nicht viel funktioniert. ACPI kann dann schon mal komplett fehlen, so dass man die Kiste nicht ausschalten kann bzw. nur 1 CPU Kern aktiv ist. Auch ist es unmöglich per Chainloader Win ohne UEFI zu booten (UEFI Windows Installationen findet os-prober nicht, dazu müsste die EFI Partition geparst werden und dort das EFI Binary gefunden werden, was aber nicht passiert).
Linux UEFI Stub
Auf etwas wo überhaupt nicht eingangen wird ist die Möglichkeit Linux Kernel direkt als EFI-Binary zu starten, entweder über eine EFI Shell, über einen direkten UEFI Eintrag mit Hilfe von efibootmgr oder mit einem ganz simplen EFI Bootloader wie gummiboot (die Konfigfiles sind wirklich nicht schwer zu schreiben, orientieren sind an GRUB 1 von der Syntax). Hierbei muss der Kernel (+ Initrd) in der EFI Boot Parition sein, auf Linux Partitionen kann mit dieser Variante nicht zugriffen werden. Dies funktioniert normalerweise erst ab Kernel 3.3, aber Debian Wheezy hat die nötigen Backports für 3.2 integriert - genauso wie die letzten Kanotix Releases. Bootet man ohne GRUB kann man durchaus bis zu 5-6 Sekunden einsparen.
UEFI Bugs
Dummerweise gibts immer wieder UEFI Bugs, die bei bestimmen Boards auftreten aber von den Support Abteilungen der Hersteller einfach ignoriert werden. Im dümmsten Falle kann man sein System komplett lahmlegen mit efibootmgr, so dass nur eine Neuprogrammierung des Firmware Chips hilft. Das is bei Desktop Boards oft nicht ganz so tragisch, wenn dieser gesockelt ist - aber bei Laptops kann das durchaus ziemlich nervtötend werden. Grundsätzlich gilt: Man sollte es tunlichst vermeiden mit efibootmgr -B Einträge zu löschen, welche vom Setup selbst hinzugefügt wurden und nicht durch die Installation eines Betriebssystems oder eigener Tests.
GRUB 2 kann, wenn es als EFI-Binary hinterlegt ist prinzipbedingt keine Betriebssysteme im "BIOS" mode booten. Was wirklich passiert ist, dass über das Hilfsprogramm os-prober andere Linux (eigentlich auch BSD, Windows im nicht UEFI mode) Installationen gefunden werden. Sollte eine Distribution aus was für Gründen auch immer nicht gefunden werden ist das ein Bug von os-prober und sollte dort reported werden (meist ist ne Korrektur ziemlich einfach). Die grub.cfg wird hierbei mit Hilfe von
grub-mkconfig -o /boot/grub/grub.cfg
erzeugt, das funktioniert eigentlich überall, wo GRUB2 verwendet wird, ist os-prober verfügbar werden die gefundenen Systeme mit eingetragen. Unter Debian oder Ubuntu gibts ein kleines Script names
update-grub
wo genau diesen Befehl aufruft. Hierbei werden die Scripte unter /etc/grub.d geparst zur erzeugung der Konfig. Alle anderen Distributionen, welche GRUB2 einsetzen könn(t)en ebenfalls os-prober verwenden.
Hierbei werden die Kernel direkt aus den Linux Partitionen geparst, wenn diese gebootet werden schaltet GRUB nicht etwa in den "BIOS" Mode zurück, nein das System bleibt im UEFI Mode. Es ist wichtig zu erwähnen, dass aktuelle Boards nur UEFI im 64 bit mode unterstützen. Bootet man trotzdem ein 32 bit Linux system ist es nicht unwahrscheinlich, dass nicht viel funktioniert. ACPI kann dann schon mal komplett fehlen, so dass man die Kiste nicht ausschalten kann bzw. nur 1 CPU Kern aktiv ist. Auch ist es unmöglich per Chainloader Win ohne UEFI zu booten (UEFI Windows Installationen findet os-prober nicht, dazu müsste die EFI Partition geparst werden und dort das EFI Binary gefunden werden, was aber nicht passiert).
Linux UEFI Stub
Auf etwas wo überhaupt nicht eingangen wird ist die Möglichkeit Linux Kernel direkt als EFI-Binary zu starten, entweder über eine EFI Shell, über einen direkten UEFI Eintrag mit Hilfe von efibootmgr oder mit einem ganz simplen EFI Bootloader wie gummiboot (die Konfigfiles sind wirklich nicht schwer zu schreiben, orientieren sind an GRUB 1 von der Syntax). Hierbei muss der Kernel (+ Initrd) in der EFI Boot Parition sein, auf Linux Partitionen kann mit dieser Variante nicht zugriffen werden. Dies funktioniert normalerweise erst ab Kernel 3.3, aber Debian Wheezy hat die nötigen Backports für 3.2 integriert - genauso wie die letzten Kanotix Releases. Bootet man ohne GRUB kann man durchaus bis zu 5-6 Sekunden einsparen.
UEFI Bugs
Dummerweise gibts immer wieder UEFI Bugs, die bei bestimmen Boards auftreten aber von den Support Abteilungen der Hersteller einfach ignoriert werden. Im dümmsten Falle kann man sein System komplett lahmlegen mit efibootmgr, so dass nur eine Neuprogrammierung des Firmware Chips hilft. Das is bei Desktop Boards oft nicht ganz so tragisch, wenn dieser gesockelt ist - aber bei Laptops kann das durchaus ziemlich nervtötend werden. Grundsätzlich gilt: Man sollte es tunlichst vermeiden mit efibootmgr -B Einträge zu löschen, welche vom Setup selbst hinzugefügt wurden und nicht durch die Installation eines Betriebssystems oder eigener Tests.
Vielen Dank für den informativen Thread