Duplicitní položky v UEFI Boot Menu: jak zjistit jejich původ a bezpečně je odstranit pomocí Linuxu
NÁVODY > KATEGORIE > Bios/Uefi + Hardware a Firmware
16.09.2026
Dvakrát stejný název v nabídce při startu počítače nemusí znamenat dvě instalace systému. Na testovacím počítači AceMagic vedla jedna položka Windows Boot Manager do běžných Windows 11 a druhá do prostředí pro obnovení WinRE. K odstranění nechtěné volby stačilo smazat přesně ověřený záznam v UEFI NVRAM. Soubory na EFI oddílu nebylo nutné mazat ani přesouvat.
V tomto návodu ukážu, jak jsem jednotlivé položky rozlišil, ověřil jejich funkci jednorázovým spuštěním a následně odstranil pouze tu, kterou jsem v nabídce nechtěl. Čísla položek a výsledky se vztahují ke konkrétnímu testu; na vašem počítači mohou být jiné.
Diagnostika shodně pojmenovaných zaváděcích položek pomocí Linuxu. Údaje na ilustraci nejsou výpisem z testovacího počítače. Ilustrační obrázek vytvořený pomocí umělé inteligence.
Rychlá navigace:
- Než začnete měnit nastavení UEFI
- Co se skutečně dělo na testovacím počítači
- NVRAM není EFI oddíl na disku
- Spusťte živý Linux v režimu UEFI
- Zjistěte stav disku a uložte výpis NVRAM
- Rozlište jednotlivé zaváděcí záznamy
- Ověřte funkci pomocí BootNext
- Proč jsem deaktivaci položky nakonec nepoužil
- Odstraňte pouze přesně identifikovaný záznam
- Zkontrolujte výpis i skutečné spuštění
- Proč neodstraňovat adresář OEM ani nepoužívat automatické čištění
- Co si z testu odnést
- Technické zdroje a další čtení
1. Než začnete měnit nastavení UEFI
STOP — zásah může znemožnit běžné spuštění systému
Návod je určen pokročilejším uživatelům. Odstraněním nesprávné položky můžete přijít o běžnou cestu ke spuštění Windows, Linuxu nebo obnovovacího prostředí. Samotné soubory systému přitom mohou na disku zůstat nepoškozené. Pokud nedokážete bezpečně určit číslo položky, její zařízení, EFI soubor a účel, zůstaňte u diagnostiky a nic nemažte.
- Připravte si ověřenou zálohu důležitých dat a možnost obnovy systému. Samotná záloha disku nenahrazuje záznam nastavení UEFI NVRAM.
- Mějte vyzkoušené zaváděcí USB s Linuxem a dostupné médium pro obnovu Windows. Musíte vědět, jak je na svém počítači spustit.
- Při použití BitLockeru nebo Šifrování zařízení si předem ověřte dostupnost správného obnovovacího klíče mimo opravovaný počítač. Změny zavádění mohou vyvolat jeho požadavek. Není to tvrzení, že se to při tomto testu stalo. [7]
- Poznamenejte si původní nastavení a výpisy. Provádějte vždy jen jednu změnu a ověřte její výsledek.
Při úpravě nabídky nemusíte nic instalovat na interní disk, měnit oddíly, vypínat Secure Boot ani mazat klíče TPM. Pokud počítač funguje a druhá položka představuje užitečný přístup k obnově, můžete ji jednoduše ponechat.
2. Co se skutečně dělo na testovacím počítači
Test proběhl na počítači AceMagic s procesorem Intel N95, 16 GB RAM, diskem HOGE H750 512 GB a jedinou instalací Windows 11 Pro 24H2. Pro diagnostiku jsem použil živý Zorin OS 18.1 Core z instalačního USB. Po obnově Windows ze zálohy se v jednorázové nabídce Boot Device, vyvolané klávesou F7, zobrazily dva názvy Windows Boot Manager pro stejný disk.
Jde o časovou souvislost, nikoli prokázanou příčinu. Z tohoto pozorování nelze určit, kdy a který program nebo firmware jednotlivé záznamy vytvořil. Nelze proto tvrdit, že je způsobila Clonezilla nebo Linux.
První, výchozí volba spustila Windows normálně až na pracovní plochu. Systém byl použitelný.
Pro zvětšení klikněte na obrázek.
Po restartu jsem klávesou F7 vyvolal nabídku „boot device“ a vybral druhou položku se stejným názvem.
Místo běžné pracovní plochy se otevřelo Windows Recovery Environment, zkráceně WinRE. Jde o prostředí pro obnovení a řešení potíží Windows. Nabízená oprava dvojici položek neodstranila.
3. NVRAM není EFI oddíl na disku
Při diagnostice je potřeba oddělit nastavení firmwaru od souborů na disku. Název, který vidíte při startu, je pouze popisek; o skutečné funkci rozhoduje také zařízení, cesta a navazující konfigurace zavaděče.
Přehled principů a význam proměnných popisuje dokumentace efibootmgr a specifikace UEFI; roli ESP vysvětluje také komunitní dokumentace Ubuntu. [1–4]
Adresáře na EFI oddílu
- EFI/Microsoft: v tomto testu obsahoval cestu k EFI zavaděči používanému pro běžné spuštění Windows.
- EFI/OEM: v tomto testu obsahoval druhý EFI zavaděč, jehož spuštění vedlo do WinRE. Název OEM sám o sobě nedokazuje, kdo jej vytvořil nebo jak má fungovat na jiném počítači.
- EFI/Boot: adresář určený také pro standardní výchozí zaváděcí cestu. Na 64bitové platformě x86 se používá název BOOTX64.EFI. Z přítomnosti adresáře nelze určit, který systém jeho obsah spouští. V tomto testu jeho konkrétní obsah nebyl předmětem ověření. [3]
Ve správci souborů Linuxu se cesty zapisují s lomítky, ve výpisech UEFI obvykle se zpětnými lomítky. EFI/Boot a EFI/OEM/BOOT nejsou stejný adresář: první je přímo pod EFI, druhý uvnitř OEM.
Počet složek v ESP nemusí odpovídat počtu voleb v Boot Menu. Firmware může pracovat s uloženými záznamy i s vlastní detekcí zařízení. Stejně tak výpis všech položek NVRAM nemusí být totožný s nabídkou, kterou firmware právě zobrazuje.
4. Spusťte živý Linux v režimu UEFI
Připojte připravené instalační USB a při zapnutí vyvolejte jednorázovou nabídku zavádění. Na testovaném AceMagic to byla klávesa F7; na jiných počítačích může být jiná. Vyberte zavádění USB v režimu UEFI.
V nabídce GRUB zvolte „Try or Install Zorin OS“, tedy „Vyzkoušet nebo nainstalovat Zorin OS“. Následně vyberte češtinu a „Vyzkoušet Zorin OS“. Instalaci na interní disk nespouštějte.
Terminál otevřete přes nabídku Zorin → Pomůcky → Terminál nebo například klávesami Ctrl+Alt+T. Následující kontrola pouze zjišťuje přítomnost rozhraní UEFI; nic nezapisuje: [4]
bash
ls /sys/firmware/efi
Pokud adresář neexistuje, nepokračujte změnami NVRAM. Vraťte se k výběru způsobu zavedení USB. Jestliže efibootmgr hlásí nepodporované EFI proměnné nebo odmítá přístup, nejdříve řešte tento problém. Chybu neobcházejte mazáním souborů v /sys/firmware/efi/efivars. Linuxová dokumentace před neuváženým mazáním EFI proměnných výslovně varuje. [6]
5. Zjistěte stav disku a uložte výpis NVRAM
Nejdříve si vypište zařízení, oddíly a jejich identifikátory.
Příkaz je pouze čtecí; nic neformátuje ani nemění:
bash
lsblk -o NAME,MODEL,SIZE,FSTYPE,PARTTYPE,PARTUUID,UUID,MOUNTPOINTS
V testu měl disk HOGE označení /dev/nvme0n1 a jeho ESP /dev/nvme0n1p1. Výpis uváděl velikost ESP 100M, tedy 100 MiB (přibližně 105 MB). Proto se údaj 105 MB v aplikaci Disky a údaj 100M v lsblk nevylučují. Oddíl měl souborový systém vfat, v aplikaci Disky upřesněný jako FAT32, a byl připojen v /media/zorin/SYSTEM.
Důležitý je PARTUUID: 1eb3a4ca-6fde-43c2-bef5-46bf48d3fac6. Tento identifikátor se shodoval s GUID v části HD(1,GPT,...) u obou sledovaných záznamů. Nezaměňujte jej s UUID souborového systému 0CEB-1262. Shoda PARTUUID umožnila přiřadit obě cesty ke stejnému ESP.
Pro základní přehled NVRAM použijte čtecí příkaz:
bash
sudo efibootmgr
Podrobnosti včetně cest získáte tímto čtecím příkazem.
Pro rozhodování o změně používejte právě podrobný výpis:
bash
sudo efibootmgr -v
Celý výstup si uložte do textového souboru na jiné dostupné médium. Uložte také výpis lsblk a původní BootOrder. Nenechávejte jedinou kopii v dočasném prostředí Live. Textový výpis je diagnostický záznam, nikoli automaticky obnovitelná záloha NVRAM.
Pro výpis a cílenou změnu NVRAM není nutné ESP připojovat. Já jsem jej při diagnostice připojil v aplikaci Disky, abych si prohlédl složky. Pokud jej také otevřete, nic v něm nemažte, nepřejmenovávejte ani nepřesouvejte. Windows oddíl není pro tento postup potřeba odemykat.
Pro zvětšení klikněte na obrázek.
6. Rozlište jednotlivé zaváděcí záznamy
Ve výchozím výpisu byly tyto hodnoty:
BootCurrent: 0009
Timeout: 1 seconds
BootOrder: 0008,0003,0009,0001,0000,0004,0006,0005,0002,0007
Timeout: 1 seconds
BootOrder: 0008,0003,0009,0001,0000,0004,0006,0005,0002,0007
- BootCurrent označuje položku použitou pro právě běžící systém. Zde 0009 odpovídalo instalačnímu USB.
- BootOrder je seznam čísel určující běžné pořadí pokusů o zavedení. Jeho obsah není seznamem instalací operačních systémů.
- BootNext, pokud je nastaven, určuje jednorázovou přednost pro následující start.
- Hvězdička za BootXXXX označuje aktivní atribut položky. Neprokazuje správnost souborů ani úspěšný start.
- Timeout je nastavení časového limitu zaváděcího správce UEFI. Nejde o časový limit nabídky GRUB. [1, 2]
Rozhodující části dvou záznamů vypadaly následovně.
Pro přehlednost je níže vynechána společná část HD(...) a doplňková binární data; nejde o úplný výpis:
- Boot0008* Windows Boot Manager
- \EFI\Microsoft\Boot\bootmgfw.efi
- Boot0003* Windows Boot Manager
- \EFI\OEM\BOOT\BOOTMGFW.EFI
Oba záznamy tedy používaly stejný zobrazovaný název a stejný ESP, ale odkazovaly na soubory v různých adresářích. To je podstatný rozdíl. Pouhé pořadí řádků v nabídce F7 nestačí jako spolehlivá identifikace pro mazání.
Proč ponechat záznamy VenHw
Výpis dále obsahoval Boot0000, Boot0001, Boot0002, Boot0004, Boot0005, Boot0006 a Boot0007.
Nesly názvy Windows Boot Manager, BOOT GRUB 2 Loader nebo Zorin OS a místo běžné souborové cesty zobrazovaly:
- VenHw(99e275e7-75a0-4b37-a2e6-c5385e6c00cb)
VenHw je vendor-specific hardwarová část UEFI device path. Tento zápis není cestou k běžnému souboru .efi. Bez znalosti jeho významu pro konkrétní firmware z něj nelze vyvodit, že jde o neškodný odpad. U uvedených položek nebyla ve výpisu hvězdička.
POZOR — neprovádějte hromadné čištění
Všechny uvedené položky VenHw(...) jsem ponechal v NVRAM. Nezabránily čisté nabídce "boot device" volanou klávesou F7 ani funkčnímu startu Windows. Test neprokázal jejich původ ani bezpečnost odstranění. Nemažte je jen podle stáří, názvu nebo chybějící hvězdičky.
7. Ověřte funkci pomocí BootNext
Než nějaký záznam odstraníte, ověřte, kam skutečně vede. BootNext umožní vybrat konkrétní číslo pro jediný následující start bez trvalého přeuspořádání BootOrder. Firmware má BootNext odstranit ještě před předáním řízení vybrané položce. [1, 3]
POZOR — i BootNext zapisuje do NVRAM
Jednorázový test je méně trvalý zásah než odstranění záznamu, není však bez rizika. Vybraný zavaděč se skutečně spustí. Předem musíte znát jeho původ, mít zachovanou funkční cestu do systému a možnost návratu přes Boot Menu. Nezkoušejte náhodné nebo neznámé položky. Oba následující testy provádějte odděleně, každý s vlastním restartem.
Test A ověřil běžné spuštění Windows
Účelem následujícího zápisu bylo nastavit BootNext na ověřovaný záznam 0008 s cestou do EFI/Microsoft. Rizikem je výběr nesprávného zavaděče pro další start a přepsání případné dřívější hodnoty BootNext. Číslo 0008 použijte jen tehdy, pokud mu na vašem počítači odpovídá správná cesta;
zde jde o přesný příkaz z testu:
bash
sudo efibootmgr -n 0008
Následovala pouze čtecí kontrola:
bash
sudo efibootmgr
Výpis obsahoval BootNext: 0008 a BootOrder zůstal beze změny. Po uložení práce jsem restartoval počítač a nechal jednorázovou volbu proběhnout bez ručního výběru jiné položky. Windows 11 normálně nastartoval.
Test B ověřil spuštění WinRE
Poté jsem se přes nabídku F7 vrátil do živého Zorin OS a znovu zkontroloval cesty příkazem sudo efibootmgr -v. Účelem dalšího zápisu bylo jednorázově spustit záznam 0003 vedoucí do EFI/OEM. I tento příkaz přepisuje BootNext a může při chybném čísle spustit jiný zavaděč.
V testu byl proveden až po potvrzení funkčního Boot0008:
bash
sudo efibootmgr -n 0003
Čtecí kontrola nastavení:
bash
sudo efibootmgr
Tentokrát výpis obsahoval BootNext: 0003. Po restartu se otevřelo WinRE. Pro samotné ověření stačí zjistit, co se spustilo; nespouštějte obnovu továrního nastavení, reinstalaci ani jiné opravné zásahy. K další práci se vraťte znovu do živého Linuxu.
Test určil chování obou cest, nikoli vnitřní příčinu rozdílu. Neprokazuje, zda jej způsobila konfigurace BCD, odlišný obsah loaderů nebo jiná návaznost. Boot0003 proto neoznačuji za vadnou položku. Může představovat záměrnou cestu k obnově, kterou jsem na tomto testovacím počítači nechtěl mít v nabídce.
Jak zrušit dosud neprovedenou jednorázovou volbu
Pokud si test rozmyslíte ještě před restartem, lze odstranit jen proměnnou BootNext. Následující zápis zruší plánovanou jednorázovou přednost; nemaže BootXXXX ani BootOrder. Rizikem je zrušení jiné záměrně naplánované volby, proto nejprve zkontrolujte aktuální výpis. Jde o možnost z dokumentace, nikoli o krok ověřovaný v popsaném testu. [2]
bash
sudo efibootmgr -N
Poté čtecím příkazem sudo efibootmgr ověřte, že řádek BootNext již není uveden.
bash
sudo efibootmgr
8. Proč jsem deaktivaci položky nakonec nepoužil
Původním záměrem bylo ověřenou položku nejdříve deaktivovat. Volba -A má změnit aktivní atribut záznamu, nikoli jej odstranit. Jde však stále o zápis do NVRAM: u nesprávné položky by mohl omezit běžné zavádění systému. Následující příkaz uvádím jako záznam neúspěšného pokusu, ne jako povinný krok návodu: [1, 2]
bash
sudo efibootmgr -b 0003 -A
V použité verzi 18 nástroje efibootmgr skončil pokus chybou:
efibootmgr: Boot entry 3 not foundCould not set active state for Boot0003: No such file or directory
Následný výpis přitom stále obsahoval Boot0003* i jeho číslo v BootOrder. Deaktivace tedy nebyla úspěšná. Nebyl dokončen ani původně zamýšlený test deaktivace a opětovné aktivace; jeho očekávané výsledky nelze vydávat za naměřené.
Stejný problém s přepínači -A i -a u verze 18 popisuje hlášení č. 186 přímo v projektu rhboot/efibootmgr. Autor hlášení uvádí chybu při změně aktivního stavu existující položky, zatímco vytváření a mazání záznamů fungovalo. Hlášení Ubuntu č. 2112632 navíc popisuje chybu vyhledávání položky ve funkci get_entry(). [5, 8]
Chování v tomto testu odpovídá uvedeným hlášením. Samotný text chyby ale není důkazem, že Boot0003 neexistuje, ani že UEFI obecně odmítá všechny zápisy. Také nelze tvrdit, že stejnou chybu musí mít každý distribuční balíček označený verzí 18; může obsahovat dodatečné opravy.
Verzi svého programu zjistíte pouze čtecím příkazem:
bash
efibootmgr --version
POZOR — neúspěšná deaktivace není pokyn k mazání
Pokud deaktivace selže, nemažte položku automaticky jako náhradu. Nejdříve musí být nezávisle ověřena její funkce a musíte se vědomě rozhodnout, že ji již v nabídce nepotřebujete.
9. Odstraňte pouze přesně identifikovaný záznam
Na testovacím počítači bylo nyní ověřeno, že Boot0008 spouští běžný Windows a Boot0003 vede do WinRE. Rozhodl jsem se odstranit pouze druhou cestu z nabídky. Tím jsem se současně vzdal tohoto konkrétního přímého vstupu do WinRE z nabídky "boot device" klávesou F7. Pokud takový vstup chcete zachovat, položku ponechte.
STOP — ověřte číslo a cestu bezprostředně před odstraněním
Číslo 0003 platilo pouze pro tento testovací počítač v zaznamenaném stavu. NESMÍTE je slepě kopírovat. Nejdříve spusťte následující čtecí příkaz a ověřte číslo BootXXXX, příslušné zařízení či PARTUUID a úplnou cestu k EFI loaderu. Stejný název Windows Boot Manager není dostatečný důvod k odstranění.
bash
sudo efibootmgr -v
- Potvrďte, že odstraňovaná položka je přesně ta, jejíž funkci jste již otestovali.
- Potvrďte, že zachovávaná funkční položka stále existuje a vede na správné zařízení a soubor.
- Uložte aktuální výpis a ověřte, že máte připravený návratový postup. Pokud se čísla nebo cesty změnily, zastavte se a proveďte identifikaci znovu.
Účelem následujícího zápisu je trvale odstranit jednu vybranou proměnnou BootXXXX a její výskyt z BootOrder. Rizikem je ztráta běžné zaváděcí cesty k systému nebo obnově při výběru nesprávného čísla. Přepínač -b vybírá položku, velké -B ji maže. Malé a velké písmeno nelze zaměnit. [1, 2]
bash
sudo efibootmgr -b XXXX -B
XXXX je zástupný text, nikoli hodnota k doslovnému spuštění. Nahrazuje se pouze číslem z vašeho právě ověřeného výpisu. Nejde o číslo oddílu ani o pořadové číslo řádku v Boot Menu.
V mém testu bylo cílem odstranění ověřené OEM cesty Boot0003. Následující příkaz provedl tento trvalý zápis a odstranil přímou volbu WinRE z nabídky "boot device" spoučtěnou klávesou F7; na jiném počítači by stejné číslo mohlo odstranit hlavní zavaděč.
Přesný provedený příkaz byl:
sudo efibootmgr -b 0003 -B
Příkaz uspěl. Nebylo nutné mazat ani přesouvat adresář EFI/OEM. Odstraněn byl zaváděcí záznam v NVRAM, nikoli jeho cílový EFI soubor, celý ESP nebo obnovovací oddíl Windows.
Po smazání záznamu jej nelze vrátit pouhou aktivací pomocí -a: už neexistuje. Jeho případné znovuvytvoření je samostatný zásah vyžadující přesné údaje. Tento návod jej netestoval, a proto zde není univerzální příkaz pro obnovu.
10. Zkontrolujte výpis i skutečné spuštění
Ihned po odstranění proveďte čtecí kontrolu:
bash
sudo efibootmgr -v
V testu Boot0003 zmizel ze seznamu záznamů i z BootOrder. Boot0008 zůstal aktivní a nadále odkazoval na cestu do Microsoft.
Pořadí před a po zásahu bylo následující:
Před:
0008,0003,0009,0001,0000,0004,0006,0005,0002,0007
Po:
0008,0009,0001,0000,0004,0006,0005,0002,0007
0008,0003,0009,0001,0000,0004,0006,0005,0002,0007
Po:
0008,0009,0001,0000,0004,0006,0005,0002,0007
Položky VenHw(...) zůstaly zachované. V této chvíli byl stále spuštěný živý Linux, takže BootCurrent: 0009 bylo očekávané a neznamenalo chybu.
Poté jsem ukončil živý systém, odpojil instalační USB a při dalším startu vyvolal nabídku "boot device" klávesou F7. Zůstal v ní jediný Windows Boot Manager pro disk HOGE.
Následně Windows 11 opět normálně nastartoval. Ověření skončilo až kontrolou skutečně běžícího systému, nikoli samotným úspěšným návratem příkazu.
Pro zvětšení klikněte na obrázek.
Tento výsledek dokládá funkční běžný start a čisté F7 Boot Menu na testovaném počítači. Není zárukou stejného chování všech UEFI ani důkazem, že položka nemůže být při budoucí opravě či změně konfigurace znovu vytvořena. Test rovněž nepotvrdil všechny další způsoby spuštění obnovy Windows.
POZOR — při odlišném výsledku nepokračujte v čištění
11. Proč neodstraňovat adresář OEM ani nepoužívat automatické čištění
Přesouvání adresářů bylo pouze experimentem
Při dřívější diagnostice na testovacím počítači jsem dočasně přesunul adresář Microsoft z ESP na externí flash disk. V nabídce zůstal jeden Windows Boot Manager a jeho spuštění vedlo do WinRE. Poté jsem Microsoft vrátil a dočasně přesunul OEM. Znovu zůstala jedna položka, tentokrát s běžným startem Windows.
Tento experiment pomohl rozlišit chování obou cest, ale není doporučeným postupem opravy. Přesunutí zavaděče jej činí nedostupným stejně jako jiné odstranění z původní cesty, byť může být přesun vratný. Na jiném počítači může dojít ke ztrátě přístupu k systému nebo obnově. K finálnímu řešení již přesun ani smazání EFI/OEM potřeba nebyly.
Přepínač -D neřeší stejná jména různých položek
Volba efibootmgr -D slouží podle manuálu k odstranění opakovaných položek v seznamu BootOrder. Jde o úpravu NVRAM, nikoli o pouhou kontrolu; mění seznam bez výběru jedné konkrétní nežádoucí zaváděcí cesty. V tomto návodu ji nespouštějte. [2]
Rozdíl si lze ukázat na jednoduchém příkladu: opakované číslo v seznamu 0008,0008,0003 je něco jiného než dva záznamy 0008 a 0003 se stejným popisem. V našem BootOrder se každé z těchto čísel vyskytovalo právě jednou. Oba záznamy navíc odkazovaly na různé EFI soubory, takže nešlo o totožné záznamy. Automatické odstranění duplicit v BootOrder proto tento problém neřeší.
Stejný princip se týká také Linuxu
Dvojí zobrazovaný název se může týkat i Linuxu. Při přípravě jsem narazil na cizí video s nabídkou obsahující dvě položky Fedora. Snímek však ukazuje pouze duplicitu názvu; bez výpisu NVRAM a testu neznáme její příčinu ani funkci jednotlivých voleb. Nelze podle něj určit, kterou položku odstranit.
Také u položek ubuntu, Fedora nebo jiné distribuce nejprve ověřte číslo, disk, oddíl, cestu k EFI souboru a skutečný výsledek zavedení. Čísla ani rozhodnutí z tohoto testu Windows na ně nepřenášejte.
12. Co si z testu odnést
Dvě položky Windows Boot Manager na testovaném AceMagic nebyly dvě totožné kopie jednoho záznamu. Boot0008 spouštěl Windows přes EFI/Microsoft, zatímco Boot0003 vedl přes EFI/OEM do WinRE. Rozlišení potvrdily oddělené testy pomocí BootNext.
Po neúspěšné deaktivaci ve verzi efibootmgr 18 jsem cíleně odstranil pouze Boot0003. Zmizel z NVRAM i BootOrder, v nabídce „boot device“ vyvolanou klávesou F7 zůstal jeden Windows Boot Manager a Windows normálně nastartoval. Adresář EFI/OEM nebylo nutné měnit a nejasné položky VenHw(...) zůstaly zachované.
Nejdůležitější pravidlo: o odstranění rozhoduje ověřená funkce konkrétního záznamu a vaše potřeba tuto cestu zachovat. Samotný duplicitní název není důvod k mazání.
13. Technické zdroje a další čtení
Praktické výsledky v článku vycházejí z vlastního testu na počítači AceMagic. Následující zdroje vysvětlují obecné principy a funkce nástrojů; nepotvrzují původ konkrétních OEM nebo VenHw záznamů tohoto počítače.
- Význam BootCurrent, BootOrder a BootNext, aktivní atribut a cílené odstranění položky.
- Referenční popis přepínačů -n, -N, -b, -B, -A, -a a -D.
- Definice zaváděcích proměnných, struktury zaváděcích voleb a pravidel pro výběr zavaděče. Specifikace je dostupná také přes rozcestník uefi.org/specifications.
- Komunitní dokumentace k režimu UEFI a EFI System Partition. Použita pro vysvětlení principů, nikoli jako návod ke změně režimu nebo instalaci systému.
- Primární hlášení projektu o selhání změny aktivního stavu existujících položek ve verzi 18.
- Rozhraní EFI proměnných a varování před neuváženým odstraňováním proměnných firmwaru.
- Situace vedoucí k požadavku obnovovacích údajů a důvod připravit je před změnami zavádění.
- Hlášení nefunkčních voleb Active a Inactive v balíčku 18-1build2 a popis problému ve funkci get_entry().
PODPOŘTE OTEVŘENÉ NÁVODY A DALŠÍ ROZVOJ WEBU LINUX PRO DOMÁCNOST:
Věřím v otevřené znalosti a v to, že kvalitní návody mají být dostupné bez reklam, rušivých prvků a zbytečného trackingu. Každý článek na webu Linux pro domácnost vzniká na základě rešerše, praktického testování na reálném nebo virtuálním počítači, ověřování v různých linuxových distribucích a pečlivého zpracování krok za krokem. Často jde o práci na několik hodin, někdy i několik dnů.
Pokud Vám některý návod pomohl, ušetřil čas nebo usnadnil řešení problému, budu rád za dobrovolnou finanční podporu. A pokud se Vám myšlenka tohoto webu líbí a chcete jeho tvorbu podporovat pravidelně, podívejte se prosím na stránku: