Unified Extensible Firmware Interface (Magyar)

Fordítás állapota:
Ez az oldal az angol
Unified Extensible Firmware Interface
című oldal magyar nyelvre lefordított változata. Utolsó fordítás dátuma: 2026.02.10. Amennyiben a lefordítás időpontja óta az angol nyelvű oldalon történtek újabb
módosítások
, akkor Ön segíthet hozzászinkronizálni az angolhoz ezt a magyar nyelvű fordítást.
További oldalak az adott témakörben
EFI system partition (Magyar)
GUID Partition Table (Magyar)
Secure Boot (Magyar)
Unified kernel image (Magyar)
Az
Egységes Kiterjeszthető Firmware Felület
(Unified Extensible Firmware Interface, UEFI, egységes bővíthető firmware interfész)
egy interfész az operációs rendszerek és a firmware között. Szabványos környezetet biztosít egy operációs rendszer indításához (bootolásához) és előindítási (pre-boot) alkalmazások futtatásához.
Ez a módszer különbözik az
MBR boot kód
módszertől, amelyet a régi
BIOS
segítségével működő számítógépes rendszerek használtak. Tekintse meg az
Arch boot process
című cikket a különbségekért és az UEFI interfészt használó boot folyamatért. Az UEFI boot betöltők (nevezik még: UEFI boot loaderek, UEFI rendszerbetöltők megnevezéssel) beállítása érdekében tekintse meg az
Arch boot process#Rendszerbetöltő
című leírást.
Megjegyzés
A korai gyártói UEFI szoftveres implementációk több hibát tartalmazhatnak, mint a BIOS szoftveres implementációk. Amennyiben Ön megoldhatatlan problémákkal találkozik, akkor fontolja meg a hagyományos BIOS-alapú bootolás használatát az ilyen rendszereknél.
Az Apple UEFI szoftveres implementációja nem felel meg a szabványnak. Hacsak nincs kifejezetten jelezve, akkor ezek az utasítások általános jelegűek, és előfordulhat, hogy némelyikük nem működik, vagy eltér a
Mac
számítógépeken.
UEFI firmware bitszám
UEFI alatt minden programnak –legyen szó operációs rendszer memóriába történő betöltőjéről vagy legyen szó segédprogram memóriába történő betöltőjéről (például memóriatesztelő program vagy adat helyreállító program)– az UEFI firmware bitszámának/architektúrájának megfelelő efi alkalmazás kell, hogy legyen.
Az x86_64 számítógépes rendszerek túlnyomó többsége, beleértve az újabb Apple Mac számítógépeket is, x64 (64 bites) UEFI firmware-t használ. Az egyetlen ismert számítógépes eszközök, amelyek IA32 (32 bites) UEFI-t alkalmaznak, a régebbi (2008 előtti) Apple Mac számítógépek, az Intel Atom System-on-Chip számítógépes rendszerek (2013. november 2-án)
[1]
, valamint néhány régebbi Intel szerveralaplap, amelyekről ismert, hogy Intel EFI 1.10 firmware-vel működnek.
Az x64 UEFI firmware nem tartalmaz támogatást 32 bites EFI alkalmazások elindításához (ellentétben az x86_64 Linux és Windows verziókkal, amelyek ilyen támogatást biztosítanak). Ezért az EFI alkalmazást kifejezetten az adott firmware processzor bitszámára/architektúrájára kell forráskódból lefordítani.
Megjegyzés
Az IA32 UEFI-t használó számítógépes rendszerek esetében olyan
rendszerbetöltő
alkalmazás szükséges, amely támogatja a vegyes módú bootolást.
Firmware bitszámának ellenőrzése
A firmware bitszámát le lehet ellenőrizni egy már be bootolt operációs rendszerből.
Ellenőrzés Linux alól
Azokon a disztribúciókon, amelyek a 4.0 verziójú vagy az attól újabb Linux kernelt futtatják, az UEFI firmware bitszáma a sysfs interfészen keresztül található meg. Parancssorban Ön futtassa a következő parancsot:
$ cat /sys/firmware/efi/fw_platform_size
A fenti parancs lefutása
64
értéket ad vissza 64 bites (x64) UEFI esetén, vagy
32
értéket ad vissza 32 bites (IA32) UEFI esetén. Ha a fenti parancsban szereplő fájl nem létezik, akkor Ön nem
UEFI módban bootolta be az operációs rendszert
.
Ellenőrzés macOS alól
A 2008 előtti
Mac
számítógépek többsége IA32 EFI firmware-vel rendelkezik, míg a 2008 és az az utáni Mac számítógépek többsége x64 EFI-t használ. Minden olyan Mac számítógép, amely képes a Mac OS X Snow Leopard 64 bites kernel futtatására, x64 EFI 1.x firmware-vel rendelkezik.
Mac számítógépen az EFI firmware architektúrájának megállapítása érdekében írja be a következő parancsot a Mac OS X parancssorába:
$ ioreg -l -p IODeviceTree | grep firmware-abi
Ha a fenti parancs lefutása
EFI32
értéket ad vissza, akkor IA32 (32 bites) EFI firmware-ról van szó. Ha a fenti parancs lefutása
EFI64
értéket ad vissza, akkor x64 EFI firmware-ról van szó. A Mac számítógépek többsége nem rendelkezik UEFI 2.x firmware-vel, mivel az Apple EFI szoftveres implementációs nem teljesen felel meg a UEFI 2.x specifikációnak.
Ellenőrzés Microsoft Windows alól
A 64 bites Windows operációs rendszerek nem támogatják a 32 bites UEFI segítségével történő bootolást. Tehát ha Ön egy 32 bites Windows operációs rendszert bootolt be UEFI módban, akkor Önnek 32 bites UEFI-je van.
A bitszám ellenőrzése érdekében futtassa az
msinfo32.exe
alkalmazást. Az alkalmazásban a
System Summary
szakaszban nézze meg a "System Type" és a "BIOS mode" értékeit.
64 bites Windows, 64 bites UEFI esetében:
System Type: x64-based PC
és
BIOS mode: UEFI
. 32 bites Windows, 32 bites UEFI esetében:
System Type: x86-based PC
és
BIOS mode: UEFI
. Ha a "BIOS mode" nem
UEFI
, akkor a Windows nem UEFI módban lett be bootolva.
UEFI változók
Az UEFI változókat definiál, amelyeken keresztül az operációs rendszer kommunikálhat a firmware-vel. Az UEFI boot változókat a rendszerbetöltő (boot loader) használja, és az operációs rendszer csak a rendszer korai indulásakor (early system start-up) veszi igénybe őket. Az UEFI runtime változók (UEFI futásidejű változók) lehetővé teszik az operációs rendszer számára, hogy maga az operációs rendszer bizonyos firmware beállításokat kezelni tudjon. Például kezelni tudja az operációs rendszer az UEFI boot managert vagy az UEFI Secure Boot protokoll kulcsainak kezelését maga az operációs rendszer tudja kezelni. A változók listája lekérhető a parancssorban a következő parancs futtatásával:
$ efivar --list
UEFI változók támogatása a Linux kernelben
A Linux kernel az UEFI változók adatait az
efivarfs
(
EFI
VAR
iable
F
ile
S
ystem) interfészen keresztül teszi elérhetővé a felhasználói tér számára (
CONFIG_EFIVAR_FS
) – az
efivarfs
kernelmodullal csatolva a
/sys/firmware/efi/efivars
útvonalon – nincs maximális méretkorlátozás változónként, és támogatja az UEFI Secure Boot változókat. A 3.8 verziójú kernelben került bevezetésre.
Követelmények az UEFI változók támogatásához
A kernelt UEFI módban kell bootolni az
EFI boot stub
segítségével (opcionálisan egy
boot manager
használatával), vagy egy UEFI
rendszerbetöltő
(boot loader) által, nem pedig BIOS segítségével vagy CSM (Compatibility Support Module) segítségével, illetve nem az Apple Boot Campen segítségével, amely szintén egy CSM.
Az EFI Runtime Services támogatásnak jelen kell lennie a kernelben (
CONFIG_EFI=y
, ellenőrizze a meglétét a
zgrep CONFIG_EFI /proc/config.gz
paranccsal).
A
kernelparancssor
használatával
nem szabad
letiltani az EFI Runtime Services támogatást a kernelben. Például a
noefi
kernelparamétert
nem szabad
használni.
Az
efivarfs
fájlrendszert a
/sys/firmware/efi/efivars
útvonalon kell csatolni, ellenkező esetben kövesse
#Az efivarfs felcsatolása
című szakaszt ebben a cikkben.
Az
efivar
parancsnak hiba nélkül listáznia kell (
-l
/
--list
opcióval) az UEFI változókat.
Ha az UEFI változók támogatása a fenti feltételek teljesülése után sem működik, akkor próbálja meg az alábbi kerülőmegoldásokat:
Ha az UEFI változók listázása (
efivar -l
) az
efivar: error listing variables: Function not implemented
hibához vezet, és az operációs rendszer egy
valósidejű kernel
alatt van elindítva, akkor adja hozzá az
efi=runtime
paramétert a
kernelparaméterekhez
, majd indítsa újra az operációs rendszert (az efivarfs funkcionalitás alapértelmezetten le van tiltva ezeken a kerneleken).
Tekintse meg a
#Nem tudják módosítani az UEFI változóadatokat a felhasználói térben használható szoftverek
című szakaszt további hibaelhárítási lépésekért.
Az efivarfs felcsatolása
Ha az
efivarfs
nincs automatikusan csatolva a
/sys/firmware/efi/efivars
útvonalon a
systemd
által az operációs rendszer bootolása során, akkor Önnek manuálisan kell felcsatolnia annak érdekében, hogy az UEFI változókat elérhetővé tegye a
#Felhasználói tér szoftverei
számára, mint például az
efibootmgr
:
# mount -t efivarfs efivarfs /sys/firmware/efi/efivars
Megjegyzés
A fenti parancsot
mind
a
chroot
környezeten kívül
(azaz előtte),
mind pedig
a chroot környezeten belül
futtatni kell, ha van ilyen.
A kerneldokumentáció elolvasása érdekében tekintse meg az
efivarfs.html
weblapot.
Felhasználói tér szoftverei
Létezik néhány szoftver amely képes hozzáférni az UEFI változókhoz, valamint képes módosítani azokat. Név szerint ezek a következő szoftverek:
efivar
— Függvénykönyvtár és szoftver az UEFI változók kezelésére. (Az efibootmgr használja).
https://github.com/rhboot/efivar
||
efivar
efibootmgr
— Szoftver az UEFI Firmware Boot Manager beállításainak manipulálásához.
https://github.com/rhboot/efibootmgr
||
efibootmgr
uefivars
— Kiírja az UEFI változók listáját néhány további PCI interfésszel kapcsolatos információval. (Belsőleg az efibootmgr kódot használja).
https://github.com/fpmurphy/Various/tree/master/uefivars-2.0
||
uefivars-git
AUR
efitools
— Szoftver az UEFI secure boot platforms manipulálásához.
https://git.kernel.org/pub/scm/linux/kernel/git/jejb/efitools.git
||
efitools
Ubuntu's Firmware Test Suite
— Tesztelési szoftvercsomag, amely Intel/AMD PC firmware szoftvereken végez épségi ellenőrzéseket.
https://wiki.ubuntu.com/FirmwareTestSuite/
||
fwts-git
AUR
QEFI Entry Manager
— Qt-alapú grafikus felületű alkalmazás az EFI boot bejegyzések és EFI rendszerpartíciók kezelésére.
https://github.com/Inokinoki/QEFIEntryManager
||
qefientrymanager
AUR
efibootmgr
Önnek
telepíteni
kell az
efibootmgr
szoftvercsomagot.
Megjegyzés
Amennyiben az
efibootmgr
nem működik az Ön operációs rendszerén, akkor újraindíthatja a számítógépet bele az
#UEFI Shell
környezetbe, és ott használhatja a
bcfg
parancsot a boot loader-hez tartozó boot bejegyzés létrehozása érdekében.
Ha Ön nem tudja használni az
efibootmgr
parancsot, akkor néhány UEFI firmware lehetővé teszi a felhasználók számára, hogy közvetlenül kezeljék az UEFI boot bejegyzéseket a firmware boot felületén belül. Például egyes firmwarek rendelkeznek "Add New Boot Option" lehetőséggel, amely lehetővé teszi, hogy Ön kiválasszon egy helyi EFI rendszerpartíciót, és kézzel megadja az EFI alkalmazás helyét, pl.
\EFI\refind\refind_x64.efi
.
Az alábbi parancsok példaként a
rEFInd
rendszerbetöltőt (bootloadert) használják.
Önnek három dolgot kell ismernie ahhoz, hogy az
efibootmgr
alkalmazás használatával új boot bejegyzést hozzon létre:
Ismerni kell azt az adathordozót, amely tartalmazza az
EFI rendszerpartíciót
(ESP). Például:
/dev/sda
,
/dev/nvme0n1
.
Ismerni kell az ESP partíciónak a partíciószámát a szóban forgó adathordozón. Az
Y
a
/dev/sda
Y
vagy a
/dev/nvme0n1p
Y
megnevezésben.
Ismerni kell az EFI alkalmazás elérési útvonalát (az ESP partíció gyökérkönyvtárához viszonyítva).
Például, ha Ön egy boot bejegyzést szeretne hozzáadni a
/efi/EFI/refind/refind_x64.efi
számára, ahol a
/efi
könyvtárútvonal az ESP partíció csatolási pontja, akkor futtassa a következőt:
$ findmnt /efi
TARGET SOURCE    FSTYPE OPTIONS
/efi   /dev/sda1 vfat   rw,flush,tz=UTC
Ebben a példában a
findmnt(8)
azt jelzi, hogy az ESP partíció a
/dev/sda
adathordozón található, és az 1 partíciószámmal rendelkezik. Az EFI alkalmazás elérési útja
/EFI/refind/refind_x64.efi
az ESP paricipó gyökérkönyvtárához viszonyítva. Tehát Ön a következőképpen kellene, hogy létrehozza a boot bejegyzést:
# efibootmgr --create --disk /dev/sda --part 1 --loader '\EFI\refind\refind_x64.efi' --label 'rEFInd Boot Manager' --unicode
Tekintse meg az összes boot bejegyzést és a boot sorrendet:
# efibootmgr --unicode
A boot sorrend beállításához:
# efibootmgr --bootorder
XXXX
,
XXXX
--unicode
Ahol az
XXXX
az
efibootmgr
parancs előző kimenetében megjelenő szám.
Nem kívánt boot bejegyzés törlése:
# efibootmgr --delete-bootnum --bootnum
XXXX
--unicode
Tekintse meg az
efibootmgr(8)
man súgót vagy az
efibootmgr README
című weblapot a további információért.
Megjegyzés
Az UEFI specifikáció a
\
jelölésmódot (visszafelé dőlt perjelet) használja útvonal-elválasztóként, de az
efibootmgr
alkalmazás automatikusan képes átalakítani az UNIX-stílusú
/
útvonal-elválasztókat.
UEFI változóhozzáférés letiltása
Az UEFI-hez való hozzáférés potenciálisan az operációs rendszer szintjén túl is kárt okozhat. Vannak veszélyes UEFI sebezhetőségek, mint például a
LogoFAIL
, amely lehetővé teszi egy rosszindulatú szereplő számára, hogy teljes mértékben átvegye az irányítást a számítógép felett. Bizonyos esetekben, gyenge UEFI implementáció mellett, akár hardverszintű használhatatlanná tétel (bricking) is lehetséges
[2]
.
Mivel az UEFI változókhoz való hozzáférés nem szükséges a mindennapi rendszerhasználathoz, Ön letilthatja a hozzáférést annak érdekében, hogy elkerülje a potenciális biztonsági rések vagy véletlen károk bekövetkezését.
Lehetséges megoldások a következők:
Csatolja az
efivars
fájlrendszert csak olvasható módban az
fstab
használatával. Például:
efivarfs /sys/firmware/efi/efivars efivarfs ro,nosuid,nodev,noexec 0 0
Használja a
noefi
kernelparamétert
az operációs rendszer UEFI-hez való hozzáférésének teljes letiltásához.
Megjegyzés
Az ilyen beállítás mellett a UEFI
felhasználói térben futó szoftverei
nem használhatóak, ezért minden szükséges beállítást előre el kell végezni. Továbbá a UEFI-hez kapcsolódó parancsok (például
systemctl reboot --firmware-setup
) sem fognak működni.
UEFI Shell
Az UEFI Shell egy parancssor a firmware számára, amely lehetővé teszi EFI alkalmazások elindítását, beleértve az UEFI boot loaderek elindítását is. Ezenkívül az UEFI parancssor segítségével különféle egyéb információkat is lekérhetünk a rendszerről vagy a firmware-ről, mint például a memóriatérképet (memmap), boot manager változókat módosíthatunk (bcfg), particionáló programokat futtathatunk (diskpart), UEFI illesztőprogramokat tölthetünk be a memóriába, szöveges fájlokat szerkeszthetünk (edit), hexadecimálisan szerkeszthetünk (hexedit) stb.
UEFI Shell beszerzése
Ön BSD licencel ellátott UEFI Shell alkalmazást szerezhet be a TianoCore EDK2 projektből:
Shell v2:
Az Arch telepítő adathordozón:
/shellx64.efi
. Az ISO képfájl készítésekor készült
/usr/share/edk2-shell/x64/Shell_Full.efi
fájl másolata.
Az
edk2-shell
szoftvercsomag x64 Shell alkalmazást biztosít az x64 (64 bites) UEFI számára, és IA32 Shell alkalmazást biztosít az IA32 (32 bites) UEFI számára. A szoftvercsomag közvetlenül a legfrissebb TianoCore EDK2 kiadás forráskódjából van lefordítva.
Az
uefi-shell-git
AUR
szoftvercsomag x64 Shell alkalmazást biztosít az x64 (64 bites) UEFI számára, és IA32 Shell alkalmazást biztosít az IA32 (32 bites) UEFI számára. A szoftvercsomag közvetlenül a legfrissebb TianoCore EDK2 forráskódjából van lefordítva.
Shell v1:
Forráskódból előre lefordított UEFI Shell v1 bináris fájlok
a TianoCore projekttől (2014. január 10. óta upstream-ben már nem frissítve).
Szoftveresen javított (foltozott) shell-ek:
Forráskódból előre lefordított UEFI Shell v2 bináris fájl, amelyben a bcfg módosítva lett annak érdekében, hogy működjön a 2.3 előtti UEFI firmware-rel
[
Halott link
2023-07-30—HTTP 403]
– a Clover EFI boot loader-től.
Forráskódból előre lefordított UEFI Shell v2 bináris fájl, amely széles körű firmware kompatibilitást biztosít
– az OpenCore boot loader-ből. A kiadási archívumban:
EFI/OC/Tools/OpenShell.efi
.
A Shell v2 alkalmazás a legjobban a 2.3 UEFI verziójú és attól újabb UEFI verziójú rendszerekben működik, és ezekben a rendszerekben ajánlott a Shell v2 használata a Shell v1 helyett. A Shell v1 alkalmazásnak minden UEFI rendszerben működnie kell, függetlenül attól, hogy a firmware melyik specifikációs verziót követi. További információ:
ShellPkg
és az EDK2 levelezőlista bejegyzés—
UEFI shell beillesztése Linux disztribúció ISO-ba
.
UEFI Shell elindítása
Néhány Asus és más AMI Aptio x64 UEFI firmware‑alapú alaplap (Sandy Bridge óta) biztosít egy lehetőséget, amelynek a neve
Launch EFI Shell from filesystem device
(EFI Shell indítása a fájlrendszer eszközről). Az ilyen alaplapok esetében Ön
shellx64.efi
néven másolja át az x64 UEFI Shell fájlt az EFI rendszerpartíció gyökérkönyvtárába.
Tipp
Az Arch Linux telepítő adathordozó gyökérkönyvtárába megtalálható a
shellx64.efi
fájl.
Ha a
shellx64.efi
fájl az EFI rendszerpartíció gyökérkönyvtárában megtalálható, akkor a
rEFInd
és a
systemd-boot
automatikusan hozzáad az UEFI shell számára egy bootmenü bejegyzést.
Azok a számítógépes rendszerek, amelyek Phoenix SecureCore Tiano UEFI firmware‑t használnak, beágyazott UEFI Shell alkalmazással rendelkeznek, amely alkalmazás elindítható az
F6
,
F11
vagy az
F12
billentyűgomb segítségével.
Megjegyzés
Amennyiben Ön a fent említett módszerek egyikével se nem tudja közvetlenül elindítani az UEFI Shell alkalmazást a firmware menüjéből, akkor hozzon létre egy
FAT32
USB pendrive adathordozót, amelyre Ön
/USB_drive_mointpoint
/EFI/BOOT/BOOTx64.EFI
néven felmásolja az EFI bináris fájlt. Ez az USB pendrive adathordozó meg fog jelenni a firmware boot menüjében. A menüben ennek az opciónak az elindítása elindítja az UEFI Shell alkalmazást.
Fontos UEFI Shell parancsok
Az UEFI Shell parancsok általában támogatják a
-b
kapcsolót, amely minden oldal után megállítja a kimenetet. Futtassa a
help -b
parancsot az elérhető belső parancsok kilistázása érdekében. Az elérhető parancsok vagy a shell alkalmazásba vannak közvetlen beleépítve, vagy a shell alkalmazástól teljesen különálló EFI alkalmazások.
További információért tekintse meg az
Intel Scripting Guide 2008
[
Halott link
2023-07-30—HTTP 404]
című leírást és az
Intel "Course" 2011
[
Halott link
2023-07-30—HTTP 404]
című leírást.
bcfg
A
bcfg
módosítani tudja az UEFI firmware által az NVRAM-ba beleírt bejegyzéseket, ami az Ön számára lehetővé teszi a boot bejegyzések vagy a illesztőprogram opciók megváltoztatását. Ez a parancs részletesen le van írva a 96. oldalon (5.3 szakaszban) az
UEFI Shell Specification 2.2
című dokumentumban.
Megjegyzés
Ön kizárólag akkor próbálja meg a
bcfg
parancsot használni, amikor az
efibootmgr
nem tud működő boot bejegyzéseket létrehozni az Ön rendszerén.
Az UEFI Shell v1 hivatalos bináris fájl nem támogatja a
bcfg
parancsot. Tekintse meg az
#UEFI Shell beszerzése
című bejegyzést egy módosított UEFI Shell v2 bináris fájlért, amely működhet az UEFI 2.3 előtti firmware-ekben.
Az aktuális boot bejegyzések listájának megjelenítése érdekében a következő parancsot kell futtatni:
Shell> bcfg boot dump -v
Az rEFInd számára történő boot menübejegyzés hozzáadásához (például) a 4. opcióként (a számozás nullától kezdődik) a boot menüben, a következőket kell tenni:
Shell> bcfg boot add 3 FS0:\EFI\refind\refind_x64.efi "rEFInd Boot Manager"
Ahol az
FS0:
az EFI rendszerpartíció megfelelő leképezése, és az
FS0:\EFI\refind\refind_x64.efi
az elindítandó fájl.
Ha egy bejegyzést szeretne hozzáadni az operációs rendszer boot loader nélküli közvetlen bootolása érdekében, akkor tekintse meg az
EFI boot stub#bcfg
című leírást.
A 4. boot opció eltávolítása érdekében a következő parancsot kell futtatni:
Shell> bcfg boot rm 3
A harmadik (#3) boot opció a nulladik (#0) pozícióba (azaz az "első" vagy "alapértelmezett" bejegyzés az UEFI boot menüben) történő áthelyezése érdekében a következőt kell tenni:
Shell> bcfg boot mv 3 0
A bcfg súgószövegének megjelenítése érdekében a következő parancsot kell futtatni:
Shell> help bcfg -v -b
Illetve:
Shell> bcfg -? -v -b
map
A
map
megjelenít egy listát az adathordozóeszköz-hozzárendelésekről, tehát az elérhető fájlrendszerek (
FS0
) és adathordozó eszközök (
blk0
) neveit jeleníti meg.
Mielőtt Ön fájlrendszer-parancsokat futtatna, mint például
cd
vagy
ls
, Önnek át kell váltania a parancssort a megfelelő fájlrendszerre a fájlrendszer nevének begépelésével:
Shell> FS0:
FS0:\> cd EFI/
edit
Az
edit
egy alapvető szövegszerkesztőt biztosít, amelynek felülete hasonló a nano szövegszerkesztő felületéhez, de valamivel kevésbé funkcionálisabb mint a nano szövegszerkesztő kezelőfelülete. Az edit kezeli az UTF-8 karakterkódolást, valamint figyel az LF és CRLF sorelválasztásokra.
Például, annak érdekében, hogy az EFI rendszerpartíción (
FS0:
a firmware menüjében) az rEFInd
refind.conf
fájlját szerkesszük, a következőt kell tenni:
Shell> edit FS0:\EFI\refind\refind.conf
Súgótámogatásért nyomja le a
Ctrl + e
billentyűkombinációt.
UEFI‑illesztőprogramok
This article or section needs expansion.
Reason:
El kell magyarázni hogy, mik azok az UEFI‑illesztőprogramok, és hogyan kell használni őket. Az itteni íráshoz hozzá kell adni az efibootmgr
-r
/
--driver
opciójával történő automatikus UEFI‑illesztőprogram betöltési beállítást. (Discuss in
Talk:Unified Extensible Firmware Interface (Magyar)
)
Az UEFI‑illesztőprogramok olyan szoftverek, amelyek támogatnak bizonyos funkcionalitásokat. Például az NTFS fájlrendszerre leformázott partíciókhoz való hozzáférés általában nem lehetséges egy UEFI Shell-ből. Az
efifs
szoftvercsomag olyan illesztőprogramokat tartalmaz, amelyek sokkal több fájlrendszer olvasását támogatják egy EFI Shell-ből. Példa a használatra, amikor Ön ilyen illesztőprogramot egy olyan partícióra másol, amely elérhető egy UEFI Shell-ből. Ezután az UEFI Shell-ből olyan parancsok kiadása, mint például:
Shell> load ntfs_x64.efi
Shell> map -r
Miután a map parancs végrehajtásra került, a felhasználó képes lesz az UEFI Shell-ből hozzáférni az NTFS fájlrendszerre leformázott partíciókhoz.
Tipp
A
systemd-boot
az
esp
/EFI/systemd/drivers/
elérési útvonalról automatikusan betölti az UEFI‑illesztőprogramokat.
Az
rEFInd
alkalmazás automatikusan betölti a memóriába az UEFI‑illesztőprogramokat az ESP partíción tárolt saját telepítési könyvtárának
drivers
és
drivers_x64
alkönyvtáraiból. Például:
esp
/EFI/refind/drivers_x64/
. Beállítható úgy is, hogy további könyvtárakat vizsgáljon.
UEFI bootolható adathordozó
UEFI boot támogatás eltávolítása az optikai adathordozóról
Megjegyzés
Ez a szakasz csak a
CD/DVD
adathordozókról történő UEFI boot támogatás eltávolítását említi (optikai adathordozóról való bootolás EL Torito segítségével). Nem említi az USB flash adathordozókról történő bootolást.
Miután az ISO képfájlt az USB flash adathordozóra felmásolta, az USB flash adathordozón használjon partíciószerkesztőt az UEFI típusú adathordozó eszköz elrejtése érdekében. Távolítsa el az
EF
típusú partíciót. A partíciószerkesztőben
ne
fogadja el az ajánlatokat a GPT típusra való átalakításra.
A legtöbb 32 bites EFI Mac számítógép és néhány 64 bites EFI Mac számítógép nem hajlandó elindulni egy UEFI(X64)+BIOS bootolható CD/DVD adathordozóról. Ha Ön optikai adathordozót kíván használni a telepítéshez, akkor előfordulhat, hogy először el kell távolítani az UEFI támogatást.
Bontsa ki az ISO képfájlt, kihagyva az UEFI-specifikus könyvtárakat:
$ mkdir extracted_iso
$ bsdtar -x --exclude=EFI/ --exclude=loader/ -f archlinux-
version
-x86_64.iso -C extracted_iso
Ezután építse újra az ISO képfájlt, kizárva az UEFI optikai adathordozóról való bootolási támogatást, a
libisoburn
szoftvercsomagból származó
xorriso(1)
használatával. Ügyeljen arra, hogy a megfelelő kötetcímkét állítsa be, például
ARCH_202103
, ez az eredeti ISO képfájlon a
file(1)
segítségével szerezhető meg.
$ xorriso -as mkisofs \
    -iso-level 3 \
    -full-iso9660-filenames \
    -joliet \
    -joliet-long \
    -rational-rock \
    -volid "ARCH_
YYYYMM
" \
    -appid "Arch Linux Live/Rescue CD" \
    -publisher "Arch Linux <
https://archlinux.org
>" \
    -preparer "prepared by $USER" \
    -eltorito-boot syslinux/isolinux.bin \
    -eltorito-catalog syslinux/boot.cat \
    -no-emul-boot -boot-load-size 4 -boot-info-table \
    -isohybrid-mbr "extracted_iso/syslinux/isohdpfx.bin" \
    -output archlinux-
version
-x86_64-noUEFI.iso extracted_iso/
Írja ki az
archlinux-
version
-x86_64-noUEFI.iso
képfájlt optikai adathordozóra, és folytassa a telepítést a szokásos módon.
UEFI tesztelése natív támogatás nélküli rendszerekben
OVMF virtuális számítógépek számára
Az
OVMF
egy TianoCore projekt, amely lehetővé teszi az UEFI támogatást virtuális számítógépek számára. Az OVMF tartalmaz egy mintapéldány UEFI firmware-t és egy külön nem felejtő változótárat a
QEMU
számára.
Ön feltelepítheti az
edk2-ovmf
szoftvercsomagot az extra szoftvercsomag-tárolóból.
Önnek
javasolt
, hogy készítsen helyi másolatot a nem felejtő változótárról az Ön virtuális számítógépe számára:
$ cp /usr/share/edk2/x64/OVMF_VARS.4m.fd my_OVMF_VARS.4m.fd
Az OVMF firmware és a változótár használatához adja hozzá a következőket a QEMU parancshoz:
-drive if=pflash,format=raw,readonly,file=/usr/share/edk2/x64/OVMF_CODE.4m.fd \
-drive if=pflash,format=raw,file=my_OVMF_VARS.4m.fd
Például:
$ qemu-system-x86_64 -enable-kvm -m 1G -drive if=pflash,format=raw,readonly,file=/usr/share/edk2/x64/OVMF_CODE.4m.fd -drive if=pflash,format=raw,file=my_OVMF_VARS.4m.fd …
DUET csak BIOS rendszerek számára
A DUET egy TianoCore projekt volt, amely lehetővé tette egy teljes UEFI környezet láncbetöltését BIOS rendszerről, hasonló módon, mint a BIOS operációs rendszer bootolása. Ezt a módszert széles körben
megvitatják
. Előre elkészített DUET képfájlok letölthetőek az egyik
szoftvertárolóból
[
dead link
2023-04-07—404 Page Not Found]
. Olvassa el a DUET beállítására vonatkozó konkrét
utasításokat
[
dead link
2023-04-07—404 Page Not Found]
. Azonban 2018 novemberétől a DUET kódot eltávolították a TianoCore git tárolóból.
Ön kipróbálhatja a
Clover
boot loadert is, amely módosított DUET képfájlokat biztosít, amelyek tartalmazhatnak bizonyos rendszerspecifikus javításokat, és gyakrabban frissülnek, mint a gitlab szoftvertárolók.
Hibaelhárítás
Bootolás vissza az Arch Linuxba, amennyiben Ön a Windows rendszerben ragadt
Amennyiben Ön beragadt a Windows rendszerbe, és szeretne visszatérni az Arch Linux operációs rendszerbe, akkor érje el az
Advanced startup
menüt Windows rendszeren a
shutdown /r /o
Windows PowerShell parancs futtatása segítségével, vagy a
Settings > Update & Security > Recovery > Advanced startup
útvonalon, majd válassza a
Restart now
lehetőséget. Amikor elérte az
Advanced startup
menüt, válassza a
Use a device
opciót, amely valójában az UEFI bootolási lehetőségeket tartalmazza (nem korlátozódik USB adathordozóra vagy CD adathordozóra, hanem a merevlemezen lévő operációs rendszert is bootolhatja), és válassza az "Arch Linux" lehetőséget.
Belépés a firmware beállító menüjébe funkcióbillentyűk nélkül
Egyes laptopokon, mint például a
Lenovo XiaoXin 15are 2020
, az
F2
vagy
F12
billentyűgombok használata nem eredményez semmit. Ez a viselkedés esetleg kijavítható úgy, hogy a laptopot visszaküldi az OEM gyártóhoz, hogy megjavítsák az alaplap információit, de ez néha nem lehetséges vagy nem kívánatos. Azonban vannak más módszerek is a firmware-be történő belépésre:
A
systemctl
használatával történő belépés:
$ systemctl reboot --firmware-setup
. Ez újraindítja a számítógépet a firmware beállításba.
GRUB
használatával történő belépés: Nyomja meg a
c
billentyűgombot a parancssor elérése érdekében, majd a GRUB parancssorban használja az
fwsetup
parancsot a firmware menüjébe történő belépés érdekében.
Windows rendszeren: Lépjen be az
Advanced Startup
menübe. Tekintse meg a
#Bootolás vissza az Arch Linuxba, amennyiben Ön a Windowsban ragadt
című leírást.
Nem tudják módosítani az UEFI változóadatokat a felhasználói térben használható szoftverek
Ha bármely felhasználói térben futó szoftver nem képes módosítani az UEFI változóadatokat, akkor ellenőrizze, hogy léteznek-e
/sys/firmware/efi/efivars/dump-*
fájlok. Ha léteznek, akkor törölje őket, majd indítsa újra a számítógépet, majd próbálja meg újra a módosítást.
Ha az előbb leírt lépés nem oldja meg a problémát, akkor próbálja meg az
efi_no_storage_paranoia
kernelparaméterrel bootolni a rendszert, hogy letiltsa a kernel UEFI változó tárolóhely ellenőrzését, amely megakadályozhatja a UEFI változók írását/módosítását.
Figyelmeztetés
Az
efi_no_storage_paranoia
csak szükség esetén használható, és nem szabad normál bootolási opciónak meghagyni. Ennek a kernel parancssori paraméternek a hatása kikapcsolja azt a védelmet, ami azért lett bevezetve, hogy elkerülhető legyen a számítógépek használhatatlanná válása, amikor az NVRAM túlzottan megtelik. További információért tekintse meg az
FS#34641
hibával kapcsolatos bejegyzést.
Nem lehet új boot bejegyzést létrehozni az efibootmgr segítségével
Néhány kernelverzió és
efibootmgr
-verzió kombináció megtagadhatja az új boot bejegyzések létrehozását. Ez az NVRAM szabad területének hiánya miatt történhet. Ön megpróbálhatja a
#Nem tudják módosítani az UEFI változóadatokat a felhasználói térben használható szoftverek
című szakaszban leírtakat.
Valamint, megpróbálhatja az
efibootmgr
telepítését a
korábbi 0.11.0 verzióra visszaállítani
. Ez a korábbi verzió működik a Linux 4.0.6 verzióval. További információért tekintse meg az
FS#34641
hibával kapcsolatos megbeszélést, különösen a
záró megjegyzést
.
Megváltoztatja a Windows a boot sorrendet
Ha Ön a
Windows rendszerrel történő dual boot eljárást használja
, és az alaplapja azonnal a Windows rendszert bootolja ahelyett, hogy az Ön által választott EFI alkalmazást töltené be, akkor ennek több lehetséges oka és megoldása lehet.
Győződjön meg róla, hogy a
Gyors indítás
(Fast Startup) le van tiltva a Windows energiagazdálkodási beállításaiban.
Győződjön meg róla, hogy a
Secure Boot
le van tiltva a firmware menüjében (ha nem használ aláírt boot loadert).
Győződjön meg róla, hogy az UEFI boot sorrendben nincs első helyre állítva a Windows Boot Manager, például az
efibootmgr
használatával és az UEFI beállítási eszközében látható beállításokkal. Néhány alaplap ha érzékeli a beállításokat, akkor alapértelmezett viselkedés szerint felülírja a Windows által az efibootmgr alkalmazás segítségével beállított értékeket. Ez a viselkedés egy Packard Bell laptopon megerősítést nyert.
Ha az Ön alaplapja az alapértelmezett boot útvonalat tölti be (
\EFI\BOOT\BOOTx64.EFI
), akkor ezt a fájlt felülírhatta a Windows boot loader. Próbálja meg például az
efibootmgr
használatával beállítani a helyes boot útvonalat.
Ha az előző lépések nem működnek, akkor megadhatja a Windows boot loadernek, hogy egy másik EFI alkalmazást futtasson. Egy Windows rendszergazdai parancssorból:
bcdedit /set "{bootmgr}" path "\EFI\
path
\
to
\
app.efi
"
.
Alternatív megoldásként deaktiválhatja a Windows Boot Manager programot azáltal, hogy root felhasználóként futtatja a
efibootmgr -A -b
bootszám
parancsot. A
bootszám
helyére írja be a tényleges Windows Boot Manager boot számot. Ezt a számot megtekintheti, ha futtatja az
efibootmgr
parancsot opciók nélkül.
Alternatív megoldásként Ön beállíthat egy indítási szkriptet a Windows rendszerben, amely minden egyes Windows bootolásakor biztosítja, hogy a boot sorrend helyesen legyen beállítva.
Rendszergazdai jogosultságokkal nyisson meg egy parancssort. Futtassa a
bcdedit /enum firmware
parancsot, és keresse meg a kívánt boot bejegyzést.
Másolja ki az azonosítót, beleértve a kapcsos zárójeleket is. Például:
{31d0d5f4-22ad-11e5-b30b-806e6f6e6963}
.
Hozzon létre egy batch fájlt a
bcdedit /set "{fwbootmgr}" DEFAULT "
{copied-boot-identifier}
"
paranccsal.
Nyissa meg a
gpedit.msc
alkalmazást, majd a
Helyi számítógép házirend > Számítógép konfiguráció > Windows beállítások > Szkriptek (Indítás/Leállítás)
alatt válassza az
Indítás
lehetőséget.
A
Szkriptek
fül alatt válassza a
Hozzáadás
gombot, majd jelölje ki a batch fájlt.
Megjegyzés:
A Windows 10 Home hivatalosan nem tartalmazza a gpedit.msc alkalmazást, bár léteznek nem támogatott kerülő megoldások annak kézi telepítésére.
Alternatív megoldásként a Feladatütemező (Task Scheduler) is használható arra, hogy egy indítási szkriptet futtasson a Windows rendszerben:
Kövesse az 1–3. lépést a fentiek közül a batch fájl létrehozásához.
Futtassa a
taskschd.msc
alkalmazást, majd válassza a
Feladat létrehozása...
lehetőséget az
Művelet
menüből.
Az
Általános
fülön:
Adjon meg egy megfelelő
Nevet
és
Leírást
.
Győződjön meg róla, hogy a kiválasztott felhasználói fiók "Rendszergazda" legyen, ne pedig "Normál felhasználó".
Válassza a "
Futtatás, függetlenül attól, hogy a felhasználó be van-e jelentkezve vagy sem
" lehetőséget.
Válassza a "
Futtatás legmagasabb jogosultságokkal
" lehetőséget.
Az
Eseményindítók
fülön válassza az "
Indításkor
" lehetőséget a menüből, majd kattintson az
OK
gombra.
A
Műveletek
fülön kattintson az
Új...
gombra, majd a
Tallózás...
lehetőségre, és keresse meg az 1. lépésben létrehozott batch fájlt.
A
Feltételek
fülön vegye ki a jelölést az
Energia
beállításoknál, így a szkript akkor is futni fog, amikor a laptop akkumulátorról működik.
Kattintson az
OK
gombra, majd a rendszer kérésére adja meg a 4. lépésben kiválasztott felhasználói fiók jelszavát.
USB adathordozón fekete képernyő jelenik meg
Ez a probléma
KMS
hiba miatt fordulhat elő. Próbálja meg a
KMS letiltását
az USB bootolásakor.
Nem jelenik meg a firmware menüjében az UEFI boot loader
Néhány firmware nem támogatja az egyéni boot bejegyzéseket. Ehelyett csak előre rögzített boot bejegyzésekből bootolnak.
Egy tipikus megoldás az, amikor Ön nem támaszkodik az NVRAM-ban lévő boot bejegyzésekre, hanem a boot loader programot az EFI rendszerpartíció egyik általános tartalék útvonalára telepíti.
A következő szakaszok ismertetik a tartalék útvonalakat.
Alapértelmezett boot útvonal a cserélhető adathordozók számára
Az UEFI specifikáció meghatározza az EFI binárisok alapértelmezett fájlútvonalait a cserélhető adathordozókról történő bootolás számára. A vonatkozó útvonalak a következők:
esp
/EFI/BOOT/BOOTx64.EFI
útvonal az x64 UEFI számára.
esp
/EFI/BOOT/BOOTIA32.EFI
útvonal az IA32 UEFI számára.
Bár a specifikáció ezeket csak a cserélhető adathordozókhoz határozza meg, a legtöbb firmware támogatja ezek bootolását bármely adathordozóról.
Tekintse meg a megfelelő
boot loader
cikket arról, hogy miként telepítse vagy helyezze át a boot loadert az alapértelmezett/tartalék boot útvonalra.
Microsoft Windows boot loader helye
Bizonyos UEFI alaplapokon, például egyes Intel Z77 lapkakészlettel rendelkező lapokon, az
efibootmgr
vagy a
bcfg
parancsokkal az UEFI Shell-ből hozzáadott boot bejegyzések nem működnek, mert az NVRAM-hoz való hozzáadás után sem jelennek meg a boot menü listájában.
Ez a probléma azért jelentkezik, mert az alaplapok kizárólag a Microsoft Windows betöltésére képesek. A megoldás az, hogy a
.efi
kierjesztésű fájlt arra a helyre kell elhelyezni, amely helyet a Windows használja.
Másolja át a
BOOTx64.EFI
fájlt az Arch Linux telepítő adathordozóról (
FS0:
) a merevlemezén lévő
ESP
partíción (
FS1:
) belül a Microsoft könyvtárba. Ezt a műveletet úgy tegye meg, hogy elindítja az EFI shellt, és beírja:
Shell> mkdir FS1:\EFI\Microsoft
Shell> mkdir FS1:\EFI\Microsoft\Boot
Shell> cp FS0:\EFI\BOOT\BOOTx64.EFI FS1:\EFI\Microsoft\Boot\bootmgfw.efi
A számítógép újraindítását követően az NVRAM-hoz hozzáadott bejegyzéseknek meg kell jelenniük a boot menüben.
Beragadt a(z) UEFI/BIOS a betöltőképernyőn
Ez a jelenség egy visszatérő probléma az Acer laptopoknál, amely akkor fordul elő, amikor a
.efi
kiterjesztésű fájlok nincsenek manuális úton engedélyezve. Tekintse meg a
Laptop/Acer#Firmware Setup became inaccessible after Linux installation
című leírást.
Nem jelennek meg az UEFI menüjében az efibootmgr segítségével létrehozott boot bejegyzések
Előfordulhat, hogy az
efibootmgr
alkalmazás nem érzékeli az EDD 3.0-t, és ennek következtében használhatatlan boot bejegyzéseket hoz létre az NVRAM-ban. Részletekért tekintse meg az
efibootmgr issue 86
leírást.
A megkerülés érdekében, amikor Ön manuális úton hoz létre boot bejegyzéseket, adja hozzá a
-e 3
opciót az
efibootmgr
parancshoz. Például:
# efibootmgr --create --disk /dev/sda --part 1 --loader '\EFI\refind\refind_x64.efi' --label 'rEFInd Boot Manager' --unicode
-e 3
A boot loader telepítők, mint a
grub-install
és a
refind-install
javítása érdekében hozzon létre egy wrapper szkriptet
/usr/local/bin/efibootmgr
néven, és tegye
futtathatóvá
:
/usr/local/bin/efibootmgr
#!/bin/sh

exec /usr/bin/efibootmgr -e 3 "$@"
Eltűnik az UEFI boot bejegyzés a hivatkozott meghajtó eltávolítása után
Egyes firmware-ek eltávolítják azokat a boot bejegyzéseket, amelyek olyan meghajtóra hivatkoznak, amely nincs jelen az bootolás során. Amennyiben Ön gyakran csatlakoztat vagy választ le meghajtókat, illetve ha eltávolítható meghajtóról bootolja az operációs rendszert, akkor ez a viselkedés problémát okozhat.
A megoldás az, hogy a
boot loader
programot az
alapértelmezett/tartalék boot útvonalra
kell telepíteni.
Véletlenszerűen eltávolításra kerülnek a boot bejegyzések
Egyes alaplapok eltávolíthatják a boot bejegyzéseket az NVRAM szabad helyének hiánya miatt, ahelyett, hogy hibát jeleznének a létrehozáskor. Ennek megelőzése érdekében csökkentse a hozzáadott boot bejegyzések számát azzal, hogy minimalizálja a bejegyzés-létrehozási folyamatát, valamint csökkentse az automatikus meghajtó bootolási bejegyzések számát a
Compatibility Support Module (CSM)
által, az UEFI beállításokban történő letiltásával. Tekintse meg a
BBS#1608838
leírást.
Egy másik oka annak, hogy a boot bejegyzések eltávolításra kerülhettek, az a tény, hogy az UEFI specifikáció lehetővé teszi az OEM gyártók számára az "NVRAM karbantartás" végrehajtását a boot folyamat során. Ezek a gyártók a karbantartást egyszerűen végzik: Előre meghatározott, kódolt útvonalakon keresik az EFI alkalmazásokat az adathordozón. Ha nem találnak semmit, akkor arra a következtetésre jutnak, hogy nincs operációs rendszer az adathordozón, és törlik az NVRAM-ból az adathordozóhoz tartozó összes boot bejegyzést, mivel feltételezik, hogy az NVRAM sérült vagy elavult adatokat tartalmaz. Ha Ön nem tervezi a Windows telepítését, és közvetlenül a firmware-ből szeretné betölteni a Linux kernelt, akkor egy lehetséges kerülőmegoldás az
esp
/EFI/BOOT/BOOTx64.EFI
üres fájl létrehozása:
# mkdir -p
esp
/EFI/BOOT 
# touch
esp
/EFI/BOOT/BOOTx64.EFI
A létrehozás után állítsa vissza a törölt boot bejegyzést. A számítógép újraindítását követően az alaplap látni fogja a "Hamis OS" operációs rendszert, és nem törli az NVRAM-ban lévő más boot bejegyzéseket. Ön természetesen lecserélheti az ál-operációs rendszer betöltőt egy valódi EFI alkalmazásra, amennyiben megtartja a szabványos tartalék nevet.
Lenovo ThinkPad: A boot bejegyzések nem maradnak meg az "OS Optimized Defaults" miatt
This article or section is a candidate for merging with
Lenovo
.
Notes:
A márkaspecifikus problémáknak a dedikált oldalon kell szerepelniük. (Discuss in
Talk:Unified Extensible Firmware Interface (Magyar)
)
This article or section needs expansion.
Reason:
Hiányoznak a hivatkozások a "felhasználói jelentésekhez". (Discuss in
Talk:Unified Extensible Firmware Interface (Magyar)
)
Az újabb Lenovo ThinkPad laptopokon (például T16 Gen 2 AMD modelleken) a felhasználók arról számolnak be, hogy az egyedi UEFI boot bejegyzések (
efibootmgr
vagy
bootctl
segítségével létrehozva) minden bootoláskor automatikusan törlődnek, és csak a Windows Boot Manager, valamint a Lenovo saját boot bejegyzései (PXE, Recovery, Diagnostics) kerülnek visszaállításra.
Ezt a viselkedést a "Restart / OS Optimized Defaults" BIOS-beállítás okozza, amely minden újraindításkor visszaállítja az UEFI boot változókat a Windows számára optimalizált alapértelmezésekre.
Megoldás: Tiltsa le az "OS Optimized Defaults" beállítást a BIOS/UEFI beállításban. Ezt követően a manuális eljárással, kézzel létrehozott boot bejegyzések megfelelően megmaradnak, így a systemd-boot vagy más egyedi boot kezelők a kívánt módon működhetnek.
További olvasnivaló a témában
UEFI Forum
- contains the official
UEFI Specifications
- GUID Partition Table is part of UEFI Specification
UEFI boot: how does that actually work, then? - A blog post by AdamW
Linux Kernel UEFI documentation for x86_64 platforms
Intel's page on EFI
Intel Architecture Firmware Resource Center
[
dead link
2023-07-30—HTTP 404]
Matt Fleming - The Linux EFI Boot Stub
Matt Fleming - Accessing UEFI Variables from Linux
Rod Smith - Linux on UEFI: A Quick Installation Guide
UEFI Boot problems on some newer machines (LKML)
LPC 2012 Plumbing UEFI into Linux
[
dead link
2021-05-17—domain name not resolved]
LPC 2012 UEFI Tutorial : part 1
[
dead link
2021-05-17—domain name not resolved]
LPC 2012 UEFI Tutorial : part 2
[
dead link
2021-05-17—domain name not resolved]
Intel's TianoCore Project
for Open-Source UEFI firmware which includes DuetPkg for direct BIOS based booting and OvmfPkg used in QEMU and Oracle VirtualBox
FGA: The EFI boot process
Microsoft's Windows and GPT FAQ
Convert Windows x64 from BIOS-MBR mode to UEFI-GPT mode without Reinstall
Create a Linux BIOS+UEFI and Windows x64 BIOS+UEFI bootable USB drive
Rod Smith - A BIOS to UEFI Transformation
EFI Shells and Scripting - Intel Documentation
UEFI Shell  - Intel Documentation
UEFI Shell - bcfg command info
The bootstrap process on EFI systems