1
Reihenfolge der Betriebssysteme im UEFI
Hallo,
ich nutze auf all meinen SSDs GPT und EFI-Partitionen (aber keine extra Boot-Partitionen; ist wohl ein Unterschied zu den EFI-Partitionen im Format fat32). Es kommt vor, dass sich die Reihenfolge der gefundenen Systeme im UEFI ändert und ich die manuell ändern muss. Gibt es eine bestimmte Rehenfolge an die sich das UEFI hält? Meist sind ja die SATA-Ports auch nummeriert. Zuerst alle Systeme auf der EFI an SATA0, dann die an SATA1? Wenn dem so ist und an SATA0 gibt es 2, wie dann weiter? Alphabetisch, also z. B. Ubuntu vor Windows?
ich nutze auf all meinen SSDs GPT und EFI-Partitionen (aber keine extra Boot-Partitionen; ist wohl ein Unterschied zu den EFI-Partitionen im Format fat32). Es kommt vor, dass sich die Reihenfolge der gefundenen Systeme im UEFI ändert und ich die manuell ändern muss. Gibt es eine bestimmte Rehenfolge an die sich das UEFI hält? Meist sind ja die SATA-Ports auch nummeriert. Zuerst alle Systeme auf der EFI an SATA0, dann die an SATA1? Wenn dem so ist und an SATA0 gibt es 2, wie dann weiter? Alphabetisch, also z. B. Ubuntu vor Windows?
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 6404130598
Url: https://administrator.de/forum/reihenfolge-der-betriebssysteme-im-uefi-6404130598.html
Ausgedruckt am: 26.12.2024 um 23:12 Uhr
1 Kommentar
Es kommt vor, dass sich die Reihenfolge der gefundenen Systeme im UEFI ändert und ich die manuell ändern muss.
In der Regel ändert sich die aber nur wenn sich Hardwaremäßig etwas ändert oder Partitionen verschwinden oder man manuell oder einer der installierten Bootmanager die Boot-Order im NVRAM ändert.Details dazu kannst du hier in den Referenz-Spezifikationen nachlesen:
https://uefi.org/specs/UEFI/2.10/03_Boot_Manager.html
The boot manager will attempt to load UEFI drivers and UEFI applications (including UEFI OS boot loaders) in an order defined by the global NVRAM variables. The platform firmware must use the boot order specified in the global NVRAM variables for normal boot. The platform firmware may add extra boot options or remove invalid boot options from the boot order list.
The boot sequence for UEFI consists of the following:
The boot order list is read from a globally defined NVRAM variable. Modifications to this variable are only guaranteed to take effect after the next platform reset. The boot order list defines a list of NVRAM variables that contain information about what is to be booted. Each NVRAM variable defines a name for the boot option that can be displayed to a user.
The variable also contains a pointer to the hardware device and to a file on that hardware device that contains the UEFI image to be loaded.
The variable might also contain paths to the OS partition and directory along with other configuration specific directories.
The boot sequence for UEFI consists of the following:
The boot order list is read from a globally defined NVRAM variable. Modifications to this variable are only guaranteed to take effect after the next platform reset. The boot order list defines a list of NVRAM variables that contain information about what is to be booted. Each NVRAM variable defines a name for the boot option that can be displayed to a user.
The variable also contains a pointer to the hardware device and to a file on that hardware device that contains the UEFI image to be loaded.
The variable might also contain paths to the OS partition and directory along with other configuration specific directories.
https://uefi.org/specs/UEFI/2.10/03_Boot_Manager.html#boot-manager-progr ...
The boot manager may perform automatic maintenance of the database variables. For example, it may remove unreferenced load option variables or any load option variables that cannot be parsed, and it may rewrite any ordered list to remove any load options that do not have corresponding load option variables. The boot manager can also, at its own discretion, provide an administrator with the ability to invoke manual maintenance operations as well. Examples include choosing the order of any or all load options, activating or deactivating load options, initiating OS-defined or platform-defined recovery, etc. In addition, if a platform intends to create PlatformRecovery#### , before attempting to load and execute any DriverOrder or BootOrder entries, the firmware must create any and all PlatformRecovery#### variables ( See Platform-Defined Boot Option Recovery ). The firmware should not, under normal operation, automatically remove any correctly formed Boot#### variable currently referenced by the BootOrder or BootNext variables. Such removal should be limited to scenarios where the firmware is guided by direct user interaction.
Gruß sid.
1
