Oprava zavaděče GRUB v dual bootu Windows 11 a Zorin OS na dvou discích
22.08.2026
Skutečně provedený test opravy, kontroly EFI oddílů a samostatné zaveditelnosti obou fyzických disků
Windows 11 i Zorin OS byly na testovacím počítači fyzicky nainstalované, ale po zapnutí se spouštěl pouze Windows Boot Manager. Tento článek ukazuje, jak byla konkrétní konfigurace opravena aplikací Oprava zavaděče (Boot-Repair), jaké soubory vznikly na EFI oddílu linuxového disku a jak byly výsledky ověřeny s každým diskem zvlášť i s oběma disky současně.
Rozsah článku: Nejde o obecný návod k instalaci dual bootu. Postup popisuje pouze zdokumentovaný test, ve kterém byl Zorin OS již nainstalovaný na druhém interním disku, ale firmware jej nedokázal běžně zavést.
Oprava zavaděče GRUB v dual bootu Windows 11 a Zorin OS na dvou samostatných discích pomocí Boot-Repair, s vlastními EFI oddíly a nabídkou GRUB. Ilustrační obrázek vytvořený pomocí umělé inteligence.
Rychlá navigace:
- Jak problém vypadal
- Ověření, že Zorin OS skutečně existuje
- Kontrola obou EFI oddílů před opravou
- Kontrola UEFI záznamů před opravou
- Spuštění aplikace Oprava zavaděče
- Hlavní volby opravy
- Nejdůležitější nastavení – umístění GRUBu
- Další volby GRUBu a Secure Boot
- Co aplikace během opravy skutečně provedla
- Kontrola EFI oddílů po opravě
- První rozhodující test – pouze disk Verbatim se Zorin OS
- Kontrola firmwaru pouze s Verbatim
- Druhý rozhodující test – pouze disk HOGE s Windows
- Test s oběma připojenými disky
- Nastavení GRUBu jako výchozí zaváděcí cesty
- Výsledná nabídka GRUB
- Závěrečná kontrola obou EFI oddílů ze spuštěného Zorin OS
- Proč je fyzické odpojení druhého disku silnější test
- Výsledek praktického testu
Výchozí konfigurace testovacího počítače
Počítač obsahoval dva interní disky o kapacitě přibližně 512 GB.
Každý operační systém byl na vlastním fyzickém disku:
- HOGE H750 512 GB – Windows 11 Pro 24H2; Windows se normálně spouštěl.
- Verbatim Vi560 S3 512 GB – Zorin OS 18.1 Core; systém byl na oddílu ext4, ale neexistovala použitelná zaváděcí cesta, kterou by jej firmware z tohoto disku běžně spustil.
V následující tabulce jsou názvy zařízení použité v tomto konkrétním testu. U jiného počítače mohou být zcela jiné.
Bezpečnostní upozornění:
Výběr nesprávného systému, fyzického disku nebo EFI System Partition může poškodit zavádění funkčního operačního systému. Názvy /dev/sda a /dev/nvme0n1 platí jen pro tento test. Před opravou vždy určete vlastní disky podle modelu, velikosti, rozložení oddílů a obsahu – ne pouze podle názvu zařízení.
Co musí začátečník rozlišovat
Pro pochopení závady je důležité oddělit několik různých vrstev. Přítomnost souborů operačního systému na disku ještě automaticky neznamená, že firmware ví, jak je spustit.
- Datový nebo systémový oddíl obsahuje samotný operační systém. V tomto testu byl Zorin OS na /dev/sda2 se souborovým systémem ext4.
- EFI System Partition (ESP) je malý oddíl FAT32, ze kterého firmware UEFI načítá EFI spustitelné soubory. Verbatim měl vlastní ESP /dev/sda1, ale před opravou na něm nebyly vidět potřebné adresáře Zorinu ani standardní fallback cesta.
- EFI spustitelný soubor je soubor s příponou .efi, který umí UEFI spustit. Windows používá například EFI/Microsoft/Boot/bootmgfw.efi. V opravené cestě Zorinu se uplatnily mimo jiné shimx64.efi a grubx64.efi.
- GRUB je zavaděč a nabídka, která může spustit Zorin OS, nabídnout pokročilé volby a předat řízení Windows Boot Manageru.
- Windows Boot Manager je zavaděč Windows uložený na EFI oddílu disku HOGE.
- Pořadí zavádění v UEFI určuje, kterou dostupnou zaváděcí cestu firmware zkusí jako první. I když jsou oba zavaděče funkční, počítač může startovat přímo do Windows, pokud je Windows Boot Manager v pořadí před Zorinem.
Důležitý princip:
Kompletně nainstalovaný Zorin OS na ext4 oddílu /dev/sda2 nestačí. Firmware potřebuje na EFI oddílu dostupný EFI soubor a použitelnou cestu, přes kterou se k zavaděči dostane.
1) Jak problém vypadal
Po dokončení původní instalace Zorin OS se počítač restartoval, ale místo nabídky GRUB se automaticky spustil Windows 11. Ve Správě disků Windows byl přitom druhý fyzický disk zřetelně přítomný: obsahoval malý EFI oddíl a velký primární oddíl s nainstalovaným Linuxem.
To byl první důležitý rozdíl: problém nebyl v tom, že by systémový oddíl Zorinu chyběl. Systém byl na disku, ale nebyla k dispozici běžně použitelná zaváděcí cesta z firmwaru k Zorinu.
Pro zvětšení klikněte na obrázek.
Nabídka Boot Device po zapnutí nabízela pouze Windows Boot Manager na disku HOGE. Nebyla v ní použitelná položka pro spuštění Zorinu z Verbatimu.
2) Ověření, že Zorin OS skutečně existuje
Počítač byl spuštěn z instalačního USB Zorin OS do živého prostředí. Nejprve bylo nutné bezpečně určit, který fyzický disk a oddíl patří Zorinu a který Windows.
K tomu byly použity příkazy:
- lsblk -p
- lsblk -f
Výpis potvrdil následující rozložení:
- /dev/sda – Verbatim Vi560 S3 se Zorin OS.
- /dev/sda1 – EFI System Partition Verbatim, FAT32, UUID 0844-4BA7.
- /dev/sda2 – ext4 oddíl s UUID 9084d108-de57-4881-8730-8d74cc497f02 a s nainstalovaným Zorin OS.
- /dev/nvme0n1 – HOGE H750 s Windows 11.
- /dev/nvme0n1p1 – EFI System Partition Windows, FAT32, označení SYSTEM, UUID 0CEB-1262.
Pozor na Live USB:
Ve výpisu je navíc /dev/sdb – instalační USB Zorin OS. Nesmí být zaměněno s interním diskem Verbatim.
Aplikace Disky a správce souborů dále ukázaly, že oddíl /dev/sda2 skutečně obsahuje běžnou adresářovou strukturu nainstalovaného Linuxu – například boot, etc, home, usr a var. To je přímý důkaz přítomnosti systému, nikoli ještě jeho zaveditelnosti.
Pro zvětšení klikněte na obrázek.
3) Kontrola obou EFI oddílů před opravou
Dalším krokem byla kontrola obsahu obou EFI System Partition. Nešlo pouze o to, že oba malé oddíly existují, ale také o to, jaké zaváděcí soubory skutečně obsahují.
Na EFI oddílu Windows /dev/nvme0n1p1 byly v adresáři EFI vidět složky Boot a Microsoft. Tato část tedy obsahovala infrastrukturu Windows Boot Manageru.
Pro zvětšení klikněte na obrázek.
Na EFI oddílu Verbatim /dev/sda1 však na screenshotu před opravou nebyl vidět ani adresář EFI. Nebyly tedy vidět ani EFI/ubuntu, ani standardní fallback EFI/BOOT. Zobrazená byla pouze složka System Volume Information.
Pro zvětšení klikněte na obrázek.
Důležitá technická stopa v /etc/fstab
Boot-Info po opravě zachoval v souboru /etc/fstab původní komentář z instalace:
- # /boot/efi was on /dev/nvme0n1p1 during installation
Komentář ukazuje, že během instalace byl bod /boot/efi spojen s EFI oddílem disku HOGE, tedy s diskem Windows. Je to důležitá technická stopa při rekonstrukci událostí.
Co z toho nelze vyvodit:
Samotný komentář v /etc/fstab neprokazuje úplnou a přesnou příčinu původního selhání. Podklady potvrzují chybný výsledný stav, ale neumožňují s jistotou určit, proč instalace nevytvořila na Verbatimu použitelnou zaváděcí cestu.
4) Kontrola UEFI záznamů před opravou
V živém prostředí byl stav firmwarových záznamů zkontrolován příkazem:
- sudo efibootmgr -v
Výpis obsahoval několik starších položek s názvy Windows Boot Manager, BOOT GRUB 2 Loader a Zorin OS. Řada z nich však používala obecnou cestu VenHw(...) a neprokazovala funkční vazbu na současné EFI soubory na Verbatimu. Aktivní položka Boot0008 naopak přímo ukazovala na \EFI\Microsoft\Boot\bootmgfw.efi na EFI oddílu Windows. Boot0009 bylo živé USB.
Dva různé časové limity:
Řádek Timeout: 1 seconds patří firmwarovému správci UEFI. Není to odpočet nabídky GRUB. GRUB má vlastní nastavení GRUB_TIMEOUT=10 a nabídku zobrazuje deset sekund.
5) Spuštění aplikace Oprava zavaděče
V živém Zorin OS byla spuštěna aplikace Oprava zavaděče (Boot-Repair). Místo okamžitého provedení automatické opravy byly otevřeny Pokročilé volby. V této situaci bylo zásadní ověřit, který systém aplikace rozpoznala a který EFI oddíl použije jako /boot/efi.
Nejdříve kontrola, potom oprava:
Při práci se dvěma systémovými disky nestačí slepě potvrdit automatickou volbu. Vždy je nutné porovnat označení zařízení s vlastním rozložením disků.
6) Hlavní volby opravy
Na kartě "Hlavní volby" byly v praktickém testu aktivní zejména tyto volby:
- Přeinstalovat GRUB.
- Použít standardní EFI soubor.
- Zobrazit nabídku zavaděče po dobu 10 sekund.
Volba "Zálohovat a přejmenovat Windows EFI soubory" aktivní nebyla. Aktivní nebyla ani "oprava souborových systémů".
7) Nejdůležitější nastavení – umístění GRUBu
Karta Umístění GRUB byla pro celý test rozhodující.
Aplikace rozpoznala:
- OS zaváděný jako výchozí: sda2 (Zorin OS 18.1 (18)).
- Samostatný oddíl /boot/efi: /dev/sda1.
Tím byla oprava zacílena na nainstalovaný Zorin OS na /dev/sda2 a na vlastní EFI System Partition disku Verbatim /dev/sda1. EFI oddíl Windows /dev/nvme0n1p1 nebyl zvolen jako cílový /boot/efi.
8) Další volby GRUBu a Secure Boot
Na kartě Volby GRUB zůstala aktivní volba SecureBoot. Ostatní pokročilé zásahy – odstranění GRUBu před reinstalací, oprava FlexNet, odkomentování GRUB_GFXMODE, podpora ATA disků, přidání parametru jádra nebo odstranění starých jader – použity nebyly.
Secure Boot nebylo nutné vypínat:
Boot-Info na konci opravy zobrazil doporučení Secure Boot vypnout, ale v tomto praktickém testu zůstal Secure Boot zapnutý a výsledné zavádění Zorinu i GRUBu fungovalo. Vypnutí Secure Boot proto není součástí tohoto ověřeného postupu.
9) Co aplikace během opravy skutečně provedla
Po potvrzení opravy Boot-Repair pracoval s nainstalovaným Zorinem na /dev/sda2 a připojil /dev/sda1 jako jeho /boot/efi. Report potvrzuje přeinstalaci balíku grub-efi-amd64-signed a spuštění příkazu grub-install pro platformu x86_64-efi s podporou UEFI Secure Boot.
Boot-Repair zároveň změnil soubor /etc/fstab tak, aby se EFI oddíl Verbatim s UUID 0844-4BA7 připojoval jako /boot/efi:
- UUID=0844-4BA7 /boot/efi vfat defaults 0 1
Na /dev/sda1 vznikly mimo jiné tyto soubory:
- EFI/ubuntu/grubx64.efi
- EFI/ubuntu/mmx64.efi
- EFI/ubuntu/shimx64.efi
- EFI/ubuntu/grub.cfg
- EFI/BOOT/bootx64.efi a další standardní fallback soubory v EFI/BOOT.
Při aktualizaci konfigurace příkaz update-grub našel Windows Boot Manager na cestě:
/dev/nvme0n1p1@/efi/Microsoft/Boot/bootmgfw.efi
Výsledný soubor /boot/grub/grub.cfg obsahoval položky Zorin OS, Windows Boot Manager a UEFI Firmware Settings. Soubor /etc/default/grub měl nastaveno GRUB_TIMEOUT_STYLE=menu a GRUB_TIMEOUT=10.
Poznámka k EFI oddílu Windows:
Podle Boot-Info skončil pokus Boot-Repairu přejmenovat na HOGE soubor EFI/Boot/bootx64.efi na EFI/Boot/bkpbootx64.efi chybou Read-only file system; report tedy neprokazuje změnu tohoto zaváděcího souboru.
Co Boot-Repair v tomto prostředí neprovedl
Report během opravy opakovaně uvedl:
- EFI variables cannot be set on this system
- Locked-NVram detected
Z použitého živého prostředí tedy Boot-Repair nemohl zapsat EFI proměnné a nelze tvrdit, že přímo vytvořil nebo zaregistroval novou položku ubuntu do NVRAM UEFI. Funkčnost opravy stojí na prokázaných EFI souborech a následných praktických testech, nikoli na domněnce o úspěšném zápisu do NVRAM.
Proč pomáhá standardní fallback:
Volba Použít standardní EFI soubor vytvořila na Verbatimu také standardní cestu EFI/BOOT. Ta umožňuje firmwaru nalézt zaváděcí soubor i bez toho, aby článek musel předpokládat úspěšnou registraci nové položky v NVRAM. Podklady ale neurčují přesný mechanismus, kterým konkrétní firmware později zobrazil označení ubuntu.
10) Kontrola EFI oddílů po opravě
Po dokončení opravy byly znovu otevřeny oba EFI oddíly. Na HOGE byly na nejvyšší úrovni adresáře EFI/Boot a EFI/Microsoft, stejně jako před opravou. Screenshot porovnává viditelnou adresářovou strukturu; sám o sobě neporovnává jednotlivé soubory ani jejich časové údaje.
Pro zvětšení klikněte na obrázek.
Na Verbatimu byl rozdíl zásadní. V adresáři EFI byly nově vidět složky BOOT a ubuntu. Boot-Info současně potvrdil konkrétní soubory zavaděče uvnitř těchto složek.
Pro zvětšení klikněte na obrázek.
11) První rozhodující test – pouze disk Verbatim se Zorin OS
Počítač byl úplně vypnut a disk HOGE s Windows byl fyzicky odpojen. V počítači zůstal pouze Verbatim. Tento test odstranil možnost, že se Zorin při startu ve skutečnosti opírá o EFI oddíl Windows.
Po zapnutí se zobrazila nabídka GRUB. Obsahovala Zorin OS, pokročilé možnosti, Windows Boot Manager a UEFI Firmware Settings. Přítomnost položky Windows Boot Manager při odpojeném HOGE není důkazem, že je Windows v tuto chvíli dostupný. Položka už byla zapsána v konfiguraci GRUB v době, kdy byly oba disky připojené a update-grub Windows našel.
Rozhodující výsledek:
Samotný Verbatim zobrazil GRUB a z položky Zorin OS úspěšně spustil Zorin OS. Tím byla prakticky prokázána funkční zaváděcí cesta Zorinu na jeho vlastním fyzickém disku.
Po desetisekundovém odpočtu se jako výchozí položka spustil Zorin OS. Snímek uvítací obrazovky dokumentuje úspěšné dokončení startu nainstalovaného systému.
Pro zvětšení klikněte na obrázek.
12) Kontrola firmwaru pouze s Verbatim
Se samotným Verbatim firmware v nabídce Boot Device zobrazil ubuntu (P0: Verbatim Vi560 S3). Stejná cesta byla viditelná v nastavení UEFI a v části Boot Override.
Tento praktický výsledek nepopírá hlášení Boot-Repair o nemožnosti zapsat EFI proměnné. Dokládá pouze to, že konkrétní firmware po opravě dokázal na jediném připojeném Verbatimu nabídnout a spustit jeho zaváděcí cestu. Podklady neprokazují, jak přesně firmware popisek ubuntu vytvořil nebo obnovil.
13) Druhý rozhodující test – pouze disk HOGE s Windows
Následně byl počítač opět vypnut. Verbatim byl odpojen a v počítači zůstal pouze HOGE. Cílem bylo ověřit, že oprava nezpůsobila závislost Windows na linuxovém disku.
Boot Device Menu obsahovalo Windows Boot Manager na HOGE. Stejná položka byla první možností v nastavení UEFI a byla dostupná také v Boot Override.
Windows 11 Pro 24H2 se z jediného připojeného HOGE úspěšně spustil. Správa disků ve spuštěných Windows zobrazuje pouze tento disk s EFI oddílem, systémovým oddílem C a oddílem pro obnovení.
Pro zvětšení klikněte na obrázek.
14) Test s oběma připojenými disky
Po opětovném připojení obou fyzických disků firmware nabídl dvě samostatné zaváděcí cesty:
- Windows Boot Manager (HOGE H750 512GB)
- ubuntu (P0: Verbatim Vi560 S3)
Firmware nejprve upřednostnil Windows Boot Manager, takže bez zásahu spustil přímo Windows. Přes Boot Device Menu nebo Boot Override však bylo možné ručně zvolit Verbatim a otevřít GRUB.
15) Nastavení GRUBu jako výchozí zaváděcí cesty
Aby se při běžném zapnutí zobrazovala nabídka GRUB, bylo nutné změnit pořadí zavádění v UEFI. V nabídce pro Boot Option #1 byla vybrána cesta Hard Disk: ubuntu (P0: Verbatim Vi560 S3).
Výsledné pořadí bylo:
- Boot Option #1 – ubuntu (Verbatim Vi560 S3)
- Boot Option #2 – Windows Boot Manager (HOGE H750 512GB)
Změna byla uložena. Od této chvíle firmware při běžném startu nejprve předal řízení zavaděči na Verbatimu.
Názvy se u jiného počítače liší:
Nabídky, klávesy i způsob řazení se liší podle výrobce firmwaru. Výsledek tohoto jediného testu proto není univerzální zárukou pro každý počítač s UEFI.
16) Výsledná nabídka GRUB
Po uložení pořadí se při běžném zapnutí zobrazil GRUB s těmito položkami:
- Zorin OS
- Advanced options for Zorin OS
- Windows Boot Manager (on /dev/nvme0n1p1)
- UEFI Firmware Settings
Výchozí byl Zorin OS a nabídka měla vlastní desetisekundový odpočet. Po jeho uplynutí se automaticky spustil Zorin. Windows bylo možné spustit výběrem položky Windows Boot Manager.
17) Závěrečná kontrola obou EFI oddílů ze spuštěného Zorin OS
Po spuštění již nainstalovaného Zorin OS byly oba EFI oddíly zkontrolovány ještě jednou.
EFI oddíl HOGE /dev/nvme0n1p1 byl připojen ve správci souborů a v adresáři EFI byly vidět složky Boot a Microsoft.
Pro zvětšení klikněte na obrázek.
EFI oddíl Verbatim /dev/sda1 byl připojen přímo jako /boot/efi. V jeho adresáři EFI byly vidět složky BOOT a ubuntu. To odpovídá nové položce v /etc/fstab s UUID 0844-4BA7.
Pro zvětšení klikněte na obrázek.
18) Proč je fyzické odpojení druhého disku silnější test
Pouhé zobrazení položek Zorin OS a Windows Boot Manager v GRUBu dokazuje jen to, že konfigurace GRUB tyto položky obsahuje. Neprokazuje, na kterém fyzickém disku leží soubory nutné k prvotnímu spuštění.
Fyzické odpojení druhého disku tuto nejasnost odstraní:
- Když byl připojen pouze Verbatim, nemohl firmware ani GRUB použít EFI oddíl HOGE. Přesto se GRUB zobrazil a Zorin OS se spustil.
- Když byl připojen pouze HOGE, nemohl Windows Boot Manager použít žádný soubor z Verbatimu. Přesto se Windows 11 spustil.
Právě tato dvojice testů je nejsilnějším praktickým důkazem, že po opravě měl každý systémový disk použitelnou vlastní zaváděcí infrastrukturu.
19) Výsledek praktického testu
Po opravě byly postupně ověřeny všechny tři stavy:
- Pouze Verbatim připojen: zobrazil se GRUB a samostatně se spustil Zorin OS 18.1 Core.
- Pouze HOGE připojen: samostatně se spustil Windows 11 Pro 24H2.
- Oba disky připojeny: firmware nabídl Windows Boot Manager i ubuntu; po nastavení Verbatimu jako první volby se při běžném zapnutí zobrazil GRUB a z něj bylo možné spustit Zorin OS i Windows.
Boot-Repair vytvořil na /dev/sda1 potřebné soubory EFI/ubuntu a standardní fallback soubory EFI/BOOT, změnil připojení /boot/efi na UUID EFI oddílu Verbatim a vytvořil konfiguraci GRUB s Windows Boot Managerem.
Co tento test neprokazuje:
- Neprokazuje přesnou příčinu, proč původní instalace nevytvořila použitelnou zaváděcí cestu Zorinu.
- Neprokazuje, že Boot-Repair úspěšně zapsal novou položku ubuntu do NVRAM; report naopak uvádí nemožnost nastavit EFI proměnné a zamčenou NVRAM.
- Neprokazuje, že stejný postup dopadne totožně na každém firmwaru UEFI.
- Neznamená, že je při podobné opravě bezpečné vybírat oddíly podle názvů z tohoto článku. Každý počítač musí být identifikován samostatně.
20) Závěr
V tomto praktickém testu nebyl problém v absenci nainstalovaného Zorin OS. Systém existoval na ext4 oddílu /dev/sda2, ale před opravou na jeho vlastním EFI oddílu Verbatim nebyly vidět potřebné zaváděcí adresáře a firmware nabízel pouze Windows Boot Manager.
Oprava zavaděče zacílila Zorin OS na /dev/sda2, použila /dev/sda1 jako /boot/efi, vytvořila na něm EFI/ubuntu i standardní EFI/BOOT a vygenerovala nabídku GRUB obsahující také Windows Boot Manager.
Konečný závěr testu:
Oprava vytvořila funkční zaváděcí cestu Zorin OS na jeho vlastním fyzickém disku a prakticky potvrdila samostatnou zaveditelnost obou systémových disků.
Doporučené zdroje a dokumentace
- Zorin Help – Repair the Boot Loader – nejdůležitější externí zdroj pro tento článek. Oficiální dokumentace Zorin OS přímo popisuje situaci, kdy se po instalaci dual bootu spouští pouze Windows, a doporučuje spuštění Zorin OS z instalačního USB a použití aplikace Boot Repair.
Repair the Boot Loader – Zorin Help:
https://help.zorin.com/docs/getting-started/repair-the-boot-loader/
- Ubuntu Community Help Wiki – Boot-Repair – podrobněji vysvětluje účel Boot-Repairu, přeinstalaci GRUBu, diagnostiku Boot-Info a pokročilé možnosti včetně volby umístění GRUBu. Dobře podporuje praktickou část postupu. Jde o komunitní dokumentaci hostovanou na webu Ubuntu, nikoli o oficiální produktovou dokumentaci Canonicalu.
Boot-Repair – Ubuntu Community Help Wiki:
https://help.ubuntu.com/community/Boot-Repair
- GNU GRUB Manual 2.14 – oficiální dokumentace projektu GNU GRUB. Vysvětluje úlohu zavaděče, instalaci GRUBu, chain-loading dalších operačních systémů a podporu UEFI Secure Boot se shimem. Aktuální manuál dokumentuje GRUB 2.14 z ledna 2026.
GNU GRUB Manual:
https://www.gnu.org/software/grub/manual/grub/grub.html
- Ubuntu Manpages – efibootmgr – vhodný zdroj k příkazu efibootmgr -v, který je v článku použit. Dokumentace potvrzuje, že efibootmgr pracuje s položkami UEFI Boot Manageru, jejich pořadím a EFI proměnnými, a že potřebuje přístup k EFI non-volatile variables.
efibootmgr – Ubuntu Manpages:
https://manpages.ubuntu.com/manpages/noble/man8/efibootmgr.8.html
- Microsoft Learn – BCD System Store Settings for UEFI – velmi dobrý zdroj pro část týkající se Windows. Microsoft zde přímo uvádí, že Windows Boot Manager je v UEFI systému umístěn na systémovém oddílu a jeho cesta je \EFI\Microsoft\Boot\Bootmgfw.efi. To přesně odpovídá cestě nalezené při praktickém testu.
BCD System Store Settings for UEFI – Microsoft Learn:
https://learn.microsoft.com/en-us/windows-hardware/manufacture/desktop/bcd-system-store-settings-for-uefi?view=windows-11
- Ubuntu Community Help Wiki – UEFI – doplňkový zdroj k EFI System Partition, /boot/efi a instalaci GRUBu v režimu UEFI. Dokumentace mimo jiné popisuje samostatný /boot/efi oddíl v pokročilých volbách Boot-Repairu.
UEFI – Ubuntu Community Help Wiki:
https://help.ubuntu.com/community/UEFI
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: