Unified Extensible Firmware Interface (Magyar) - ArchWiki

Jump to content

# Unified Extensible Firmware Interface (Magyar)

From ArchWiki
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 VARiable FileSystem) 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

1. 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.
2. 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).
3. 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.
4. 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.
5. 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:

1. 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).
2. 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-gitAUR

- 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-gitAUR

- 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 || qefientrymanagerAUR

#### 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:

1. Ismerni kell azt az adathordozót, amely tartalmazza az EFI rendszerpartíciót (ESP). Például: `/dev/sda`, `/dev/nvme0n1`.
2. Ismerni kell az ESP partíciónak a partíciószámát a szóban forgó adathordozón. Az `Y` a `/dev/sdaY` vagy a `/dev/nvme0n1pY` megnevezésben.
3. 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-gitAUR 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.
  1. Rendszergazdai jogosultságokkal nyisson meg egy parancssort. Futtassa a `bcdedit /enum firmware` parancsot, és keresse meg a kívánt boot bejegyzést.
  2. Másolja ki az azonosítót, beleértve a kapcsos zárójeleket is. Például: `{31d0d5f4-22ad-11e5-b30b-806e6f6e6963}` .
  3. Hozzon létre egy batch fájlt a `bcdedit /set "{fwbootmgr}" DEFAULT "{copied-boot-identifier}"` paranccsal.
  4. 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.
  5. 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:
  1. Kövesse az 1–3. lépést a fentiek közül a batch fájl létrehozásához.
  2. Futtassa a taskschd.msc alkalmazást, majd válassza a Feladat létrehozása... lehetőséget az Művelet menüből.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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

Category:

- Boot process (Magyar)

Hidden categories:

- Pages with dead links
- Pages or sections flagged with Template:Expansion
- Pages or sections flagged with Template:Merge

Unified Extensible Firmware Interface (Magyar)
Add topic