Da schaue ich hier noch mal rein und stelle fest, es hat sich doch noch einiges getan ...
Bachsau hat geschrieben:Falsch. Die Spezifikation schreibt vor, dass EFI auch von MBR-Partitionierten Datenträgen booten können muss. Zu diesem Zweck wird aber nicht der MBR-Benutzt, sondern ebenfalls eine darauf angelegte FAT-Partition, für die sogar eine eigene Partitionskennung festgelegt wurde, und die den EFI-Bootloader enthält.
Doch, doch, damit hat Bachsau völlig recht, und meine Formulierung ist falsch (ich geb zu, das war Absicht, sonst wär der Text noch viel länger geworden).
Laut Spezifikation "sollte" es gehen. Und es gibt in der Tat einen neuen MBR-Partitionstyp "EF", in den man eine FAT-EFI-Systempartition legen können soll. Laut Spezifikation soll ein EFI dann auch ohne GPT einen EFI-Boot mit dem Loader aus dieser FAT-Partition ausführen.
Allerdings ist in der Spezifikation nur von den 4 MBR-Standard-Partitionen die Rede, die beliebten Logischen Partitionen fallen weg. Die können dem EFI allerdings auch egal sein, solange das Betriebssystem sie erkennt. Man müsste dann also eine FAT-Partition in eine der ersten drei (primären) Partitionen quetschen, was zwar von den Zahlen her noch "MBR" ist, vom Schema her aber ein "MBR mit nur drei freien Partitionen".
Das eine Problem dabei ist: niemand nutzt es. Ich kenne kein System, das auf einer MBR-Platte einen EFI-Loader installiert. Man müsste sich sowas schon per Hand basteln. Und grub-efi müsste sich dann auf einer MBR-Platte zurechtfinden können ... ich weiß nicht, ob es das kann. Ich finde dazu nur alte Erfolgsberichte mit Linux auf Apple Macs mit viel Handarbeit, und verstehe nicht, warum die überhaupt eine MBR-Partitionierung genommen haben.
Das andere Problem dabei ist: es scheint nicht (richtig) implementiert zu sein. Zumindest blenden alle EFIs, die ich bisher so ausprobiert habe (was nicht sooo viele sind) sämtliche MBR-Platten aus dem Boot-Menü aus, sobald man die CSM-Module deaktiviert. Das ändert sich auch nicht, wenn man eine EFI-Bootpartition mit EFI-Loader hinzufügt. Das mag an den individuellen Bugs der EFIs liegen, aber verlassen kann man sich darauf nicht.
Oder um mal das Arch-Wiki zu zitieren:
"It is recommended to use always GPT for UEFI boot as some UEFI firmwares do not allow UEFI-MBR boot."
https://wiki.archlinux.org/index.php/Un ... _Partition
Und ansonsten: man gewinnt dadurch nichts. Ein MBR-System mit BIOS-Boot kann man immer an einen anderen Rechner anschließen und dort booten, egal ob es ein EFI- oder ein BIOS-System ist. Bei einem MBR-System mit EFI-Boot hat man hingegen sozusagen die Nachteile aus beiden Welten vereint: man muss mit den Einschränkungen einer MBR-Partitionierung leben und ist auf ein unterstützendes EFI-Mainboard angewiesen und das Laden anderer BIOS-Boot-Systeme kann man auch knicken.
Also wer neugierig ist, darf damit gerne herumprobieren ... wenn es klappt, kann man damit ein EFI-Boot mit MBR-Partitionierung hinbekommen. Erfolgsmeldungen bitte hier rein!
Ach und wo ich gerade mal wieder mit Windows 8 herumgespielt habe ... mit gdisk scheint es ebenfalls möglich zu sein, eine MBR-Partitionstabelle in eine GPT umzuwandeln:
https://wiki.archlinux.org/index.php/GU ... MBR_to_GPT
Das befreit einen aber nicht von der Notwendigkeit, die Partitionen zusammenzuschieben und eine neue Partition für Grub oder EFI (oder beides) anzulegen. Das scheint mir der sinnvollere Weg zu sein, um Altsysteme mit MBR EFI-fitt zu machen, statt von seinen MBR-Partitionen noch eine abzuzwacken. (Bitte vorher unbedingt Backups machen!)
Maik aus MS hat geschrieben:Muss es nicht so sein:
Allerdings erlaubt die GPT bis zu 128 Partitionen und Partitionsgrößen über 2TB
Da hast du natürlich völlig recht! Ich habe es korrigiert
NAB hat geschrieben:Ich rate jedoch, wenn man sich für GPT entscheidet, am Anfang zwei Partitionen extra unterzubringen. Eine 1024 KB Partition für Grub, wie unter "Squeeze" beschrieben. Und eine 250 MB FAT Partition für EFI-Bootloader. Wenn ihr beide habt, könnt ihr später ohne viel Ärger zwischen EFI-Boot und BIOS-Boot hin- und herspringen.
Den Absatz muss ich auch noch mal überarbeiten.
Zum einen sind die zwei Partitionen natürlich nur dann sinnvoll, wenn man zwischen BIOS-Boot und EFI-Boot umschalten können will, was nur dann nötig ist, wenn es mit einem von beidem irgendwelchen Ärger gibt (zum Beispiel in Multi-Boot-Umgebungen).
Zum anderen habe ich gerade ein Mainboard mit Asrock EFI hier, das sich weigert per EFI-Boot zu booten, wenn die FAT-Partition nicht die erste Partition in der GPT ist. Mit Gigabyte war das kein Problem.
Lösen lässt sich das ganze übrigens, indem man zur SuperGrub2Disk greift ... davon gibt es inzwischen sogar ein EFI-Binary, das sich mit etwas Glück direkt vom USB-Stick booten lässt. Schafft man es, sein Debian damit zu booten, reicht ein "grub-install" und der Debian-Bootloader wird in das NVRAM des Mainboards eingetragen und lässt sich fortan als "grub" starten. (Bei einer Neu-Installation passiert das automatisch, ist also nichts, worüber man sich Gedanken machen muss, wenn man nicht gerade herumbastelt.)
Inzwischen habe ich mich auch mit "efibootmgr" näher angefreundet, dank der freundlichen Ubuntu-Dokumentation:
http://wiki.ubuntuusers.de/efibootmgr
(die Man-Page sollte man trotzdem mal lesen)
Damit kann man ausdrucksvollere Namen als "grub" in das Bootmenü des Mainboards eintragen, das Bootmenü sortieren, Bootloader von unterschiedlichen Festplatten (oder USB-Sticks) eintragen, oder den zweiten Bootloader seiner Raid1-Konfiguration im EFI hinterlegen. Eigentlich müsste es damit auch möglich sein, EFI-Loader von anderen FAT-Partitionen als der EFI-Systempartition in das Bootmenü zu schreiben ... das habe ich aber noch nicht getestet, und wie üblich dürfte es darauf ankommen, ob das Mainboard mitspielt.
Dabei ist mir noch aufgefallen, dass man seine GPT-Partitionstabelle (zumindest mit gparted) genau so versauen kann, wie das früher mit dem MBR der Fall war. Legt man auf einer leeren Festplatte erst eine Partition im hinteren Bereich der Festplatte an, so ist dieses die erste Partition (logisch, es gibt ja nur eine). Legt man danach noch eine weitere Partition im vorderen Bereich an, so ist und bleibt dieses die zweite Partition. Als ich also versucht habe, ganz an den Anfang der Festplatte noch eine FAT-Partition zu quetschen, war das dann trotzdem die Xte Partition, und nicht die erste.
Eigentlich müsste es leicht sein, die Partitionen umzunummerieren, aber ich habe kein idiotensicheres Programm dazu gefunden, und mein Risikobedürfnis war gering.
Und ganz unten an meinen Text habe ich noch einen Hinweis auf die neuen 32-Bit-UEFIs drangehängt - aber mir fehlt da selber der wirkliche Durchblick. Hat jemand Erfahrung damit, insbesondere unter Debian?
Ach, ehm ...
Lohengrin hat geschrieben:Ich habe hier einige Spiele, die auf Windows 98 gelaufen haben, aber auf Windows XP nicht mehr laufen. Leider kriege ich es nicht hin, in Virtualbox Windows 98 laufen zu lassen.
Guckst du mal hier:
http://ubuntuforums.org/showthread.php?t=774745
Nur dass bei kvm der Prozessor die 3D-Beschleunigung zu Fuß machen muss, aber für Virtualbox gibt's auch keine passenden 3D-Treiber.
Never change a broken system. It could be worse afterwards.
"No computer system can be absolutely secure." Intel Document Number: 336983-001
Nach dem letzten Windowsstart verschwand gar die Auswahl des Grub aus der Bootreihenfolge ganz. — Wann lernt Micro$oft eigentlich, daß es Anwender gibt, die selbst entscheiden wollen, was laufen soll?
