Přesun UEFI Win10 SATA -> NVMe, BIOS bez bootu z NVMe

[redustin]

Je tedy následující postup správný?

EFI bios spustí EFI binárku grubu na zařízení, na které vidí (USB, SATA). Grub si načte konfiguraci + moduly ze stejného zařízení, aby zvládl načíst image kernelu. Tady v tom okamžiku by teoreticky už kernel mohl být na NVMe, ale grub NVMe (ze záhadného důvodu) neumí. Tedy image kernelu musí být na zařízení, které grub umí přečíst (tedy opět nějaká boot partišna na USB/SATA). Image potřebuje  cmdline parametr root, kde najde root. Ten už může být na NVMe (v parametru root specifikovaný UUID partišny na NVMe), protože root bude hledat kernel a ten už má podporu NVMe zakompilovanou. Je to tak správně?

Jak to probíhá v případě bootu windows efi grubem? Co vlastně grub pro start windows spouští?

[Reklama]

[CHe]

Hej, Linux sedí.

Windows z grubu buď cez chainloader (odovzdá riadenie MS boot loaderu, ktorý si zavedie windows) alebo ntldr (zavedie windows priamo z konkrétnej NTFS partície bez MS boot loadera; vyžaduje okrem ntldr ešte grub modul pre čítanie NTFS). V každom prípade, oba varianty vyžadujú, aby mal grub (priamo alebo cez niektorý modul) prístup k zariadeniu s tou win inštaláciou.

[redustin]

Díky moc.

Z diskuse https://superuser.com/questions/1782009/can-grub-access-an-nvme-drive-when-the-bios-lacks-support-for-it#comment2878536_1782025 mi vychází, že podpora NVMe v grubu teoreticky lze, ale nikdo driver nenapsal https://superuser.com/questions/1782009/can-grub-access-an-nvme-drive-when-the-bios-lacks-support-for-it#comment2878536_1782025 . Nicméně pokud jsem to pochopil dobře, to by stejně fungovalo jen pro linux, protože windows se zavádí voláním biosu INT 13h https://wiki.osdev.org/Disk_access_using_the_BIOS_(INT_13h), tudíž i bios musí ten disk vidět. Ale možná je to u windows jinak...

[Michal Šmucr]

Co řeší GRUB dál při bootování Linuxu s initrd a jádrem, že umí mdraid atp. je pro zavedení Windows (resp. jakékoliv EFI binárky) úplně nepodstatné.
Všechno mimo Linux jádra, tzn. i třeba memtest, Windows boot loader (bootmgfw.efi), jakákoliv další EFI binárka.. se zavádí přímo chainloaderem. Tzn. to blokové zařízení s FAT32 partišnou, kde to je, musí být dostupné z EFI.
Tzn. to omezení, když EFI "nevidí" NVMe zařízení (nebo třeba něco za HW RAIDem, iSCSI LUN), protože nemá odpovídající ovladač, to podle mě neobjede.

Jiná situace by mohla být s Cloverem resp. novějším OpenCore. OC má v distribuci přímo EFI ovladač, který by to mohl zpřístupnit. "X64/EFI/OC/Drivers/NvmExpressDxe.efi" (podle mě to vypadá jako vyzobané s některého EFI kitu od Intelu).
Pak má v sobě také runtime detekci toho Windows bootloaderu, tzn. pokud se pak někde na přístupné EFI partišně zjeví bootmgfw.efi v odpovídající adr. struktruře, tak se přidá do menu.
Sám jsem to neměl potřebu nikdy zkoušet, protože buď systém uměl NVMe, nebo jsem bootoval ze SATA zařízení, ale možná by to za pokus stálo.
Mělo by jít udělat nějaká základní instalace OC, bez těch macOS specifických nastavení.
Tzn. naformátovat nějakou flešku na GPT s EFI oddílem, rozbalit tam X64/EFI a pak dovnitř do adresáře OC zkopírovat ukázkový soubor sample.plist z Docs/Sample.plist jako config.plist. (tzn. finálně to bude <root>/EFI/OC/config.plist
To by mělo na začátek stačit, aby to prvotně naběhlo i bez dalšího nastavování. Po startu OC je tam pak další funkcionalita v menu přístupná, když se zmáčkne mezerník.

[Michal Šmucr]

Ještě odkaz:
https://github.com/acidanthera/OpenCorePkg

[Reklama]

[redustin]

Moc zajímavé, díky!

EFI má tedy stabilní ABI, že lze používat stejný modul/driver pro různé biosy/emulátory EFI?

[Michal Šmucr]

EFI má tedy stabilní ABI, že lze používat stejný modul/driver pro různé biosy/emulátory EFI?

V podstatě ano, je to poměrně hodně standardizované a modulární. Ovladače můžou být buď platform independent (v EFI byte code - EBC), nebo specfické pro konkrétní plafromu (x86-64, ARM64, Itanium..).
Jsou pak nějaké pevné věci z UEFI standardu, co konkrétní ovladač implementuje, takže např. u blokového zařízení jako je ten NVMe pak implementuje EFI_BLOCK_IO_PROTOCOL
https://github.com/kiznit/uefi-headers/blob/master/Include/Protocol/BlockIo.h

Za normálních podmínek, se ovladače zaregistrují a startují z paměti základní desky. Ale může to být i z paměti nějaké jiné rozšiřující PCI karty, jako např. RAID řadiče, síťovky atp.
V rámci spouštění jednotlivých fází v EFI a předávání řízení, ty ovladače startují v části DXE (driver execution environment).


Nikdy jsem pro to nic nevyvíjel, ale před lety jsem se v tom trochu hrabal, když jsem rozcházel Hackintosh. Nejdřív s Cloverem, pak s OC.
Ty jsou pak oba specifické tím, že právě ještě po svém spuštění dokáží dál podle konfigurace interagovat s těmi DXE ovladači, upravovat ACPI třeba formou DSDT tabulek, emulovat NVRAM z Apple atp. a celkově upravit prostředí než finálně zavedou ten nativní bootloader z macOSu.
Jinak jak jsem zmínil, neověřoval jsem sám, jestli se ten NVME ovladač zavede i před případným Windows bootem, který to podporuje, ale mohlo by to teoreticky zabrat.

[k3dAR]

Pořád nechápu, jak vlastně ten grub funguje. Umí md raid0-6, zfs, ale neumí NVMe? [...]

Grub umi raid ci zfs, protoze je umi a pouzije dostupne disky od BIOSu/UEFI....
Na to aby umel Grub videt NVMe ktere mu nedoda BIOS/UEFI, by musel mit primo vlastni ovladac na NVMe HW...

[RDa]

Pořád nechápu, jak vlastně ten grub funguje. Umí md raid0-6, zfs, ale neumí NVMe? [...]

Grub umi raid ci zfs, protoze je umi a pouzije dostupne disky od BIOSu/UEFI....
Na to aby umel Grub videt NVMe ktere mu nedoda BIOS/UEFI, by musel mit primo vlastni ovladac na NVMe HW...

Tak ono klidne nekdo muze udelat NVMe driver ... nebude to nikterak slozite, kdyz uz tam je AHCI driver, ktery taky pracuje podle PCI class ID (protoze HW API je fixni, podle standardu). To je prace na jednu spis seminarku nez bakalarku

https://git.savannah.gnu.org/cgit/grub.git/tree/grub-core/disk

[redustin]

V podstatě ano, je to poměrně hodně standardizované a modulární. Ovladače můžou být buď platform independent (v EFI byte code - EBC), nebo specfické pro konkrétní plafromu (x86-64, ARM64, Itanium..).
...

Skvělé, díky moc za detaily. Netušil jsem, jak je to bootování celé složité... Na ARMu je to taky takové maso? Tam mi přijde, že uboot není tak komplikovaný.

[redustin]

Pořád nechápu, jak vlastně ten grub funguje. Umí md raid0-6, zfs, ale neumí NVMe? [...]

Grub umi raid ci zfs, protoze je umi a pouzije dostupne disky od BIOSu/UEFI....
Na to aby umel Grub videt NVMe ktere mu nedoda BIOS/UEFI, by musel mit primo vlastni ovladac na NVMe HW...

Zmlsaný z linuxu jsem si myslel, že si grub2 detekuje disky sám... a ono očividně ne.

[redustin]

Tak ono klidne nekdo muze udelat NVMe driver ... nebude to nikterak slozite, kdyz uz tam je AHCI driver, ktery taky pracuje podle PCI class ID (protoze HW API je fixni, podle standardu). To je prace na jednu spis seminarku nez bakalarku

https://git.savannah.gnu.org/cgit/grub.git/tree/grub-core/disk

Údajně již patch do nějakého staršího grubu byl https://superuser.com/a/1825796 -> https://sourceforge.net/projects/grub4dosahcipatch/files/ , ale zapadlo to...

Škoda, to mi přijde docela klíčové, staršího kvalitního HW s UEFI ale bez bootu z NVMe je spoustu. Zde to je konkrétně Dell Precision T3610, který ač docela výkonný je velice tichý (skříň jako serverový tunel, tři velké pomaluběžné ventilátory vepředu a ani Xeon nemá větrák, jenom vhodně navržený chladič, hodně PCIe slotů na NVMe s dostatkem linek.

[redustin]

Mělo by jít udělat nějaká základní instalace OC, bez těch macOS specifických nastavení.
Tzn. naformátovat nějakou flešku na GPT s EFI oddílem, rozbalit tam X64/EFI a pak dovnitř do adresáře OC zkopírovat ukázkový soubor sample.plist z Docs/Sample.plist jako config.plist. (tzn. finálně to bude <root>/EFI/OC/config.plist
To by mělo na začátek stačit, aby to prvotně naběhlo i bez dalšího nastavování. Po startu OC je tam pak další funkcionalita v menu přístupná, když se zmáčkne mezerník.

Jaké jsou vlastně zkušenosti s OpenCore, je to použitelné pro normální PC? Nebo je to spíš jen specialitka, která by se musela pro konkrétní PC konfigurovat? Na Cloveru mě odradil ten obrovský seznam ACPI patchů (kvůli kterému windowsy nenabootovaly, protože jsem použil defaultní konfig s APCI vyladěným pro Mac. ACPI je pro mě nepřehledná džungle. Díky!

[Michal Šmucr]

Jaké jsou vlastně zkušenosti s OpenCore, je to použitelné pro normální PC? Nebo je to spíš jen specialitka, která by se musela pro konkrétní PC konfigurovat? Na Cloveru mě odradil ten obrovský seznam ACPI patchů (kvůli kterému windowsy nenabootovaly, protože jsem použil defaultní konfig s APCI vyladěným pro Mac. ACPI je pro mě nepřehledná džungle. Díky!

Na standardní boot Windows s OC nikdy nebyl problém. Na většině Hackintoshů, co jsem instaloval, byly také vždy ještě další disk s Windows 10 nebo 11. Je tam dynamická detekce toho Windows loaderu (nebo i třeba GRUBu), objevil se v nabídce - normálně to zavádělo. Ale jak jsem zmiňoval předtím, nikdy nebylo třeba řešit ten NVMe boot na stroji, co ho nativně nepodporuje, takže prakticky tohle vyzkoušené nemám.
U tech ACPI patchů a různých quirků, záleží jen co konkrétně povolíte, nemusí to dělat vůbec nic. Další věc samozřejmě je, že je to vždycky specifické pro konkrétní základní desku/čipset, a když se slepě použije nějaký hotový config z webu, nemusí to fungovat.

Nicméně právě oproti starému Cloveru jsou ty volby relativně dobře popsané (PDFko v adresáři Docs). Pro úpravy configu pak určitě doporučím ProperTree: https://github.com/corpnewt/ProperTree
To jde spustit všude, kde je Python s TK toolkitem na GUI.
Zásadní vlastnost, krom základní editace plistů, je to, že to umí upravit deklarace v OC config podle aktuálních souborů s ovladači, knihovnami a kexty v jeho adresářové struktruře.. (je to v menu File > OC Snapshot, resp. OC Clean Snapshot)

Tzn. například v ukázkovém configu jsou deklarace úplně všech ovladačů, co se distribuují s OC (sekce root > uefi > drivers )
Nicméně já třeba na boot nebudu v drivers/ chtít nic jiného než OpenRuntime.efi a NvmExpressDxe.efi
Takže odmažu všechy ostatní soubory ze struktury a spustím tu zmíněnou funkci clean snapshot, co ten config vyčistí.
Pak to můžu samozřejmě ještě dál doupravit.

[Martin-2]

Zdravím, klasika -...

V konfiguraci s NVME jsem to používal necelých 5 měsíců. Není mi jasné proč Vám to nejde jelikož u mě to bylo bez zádrhelu, ale spíše jsem chtěl upozornit, že ve finále jsem se vrátil zpět k sata ssd (nativní podpora) protože dobrá duše viděla flash disk a zamčela jej do šuplíku v domění, že jsou na tom nějaká citlivá data. Jak se to stalo podruhé tak jsem to celé vrátil na sata SSD

Na domácí použítí je to zajímavé ale to, že se tam ten flashdisk bude zobrazovat může nezkušené uživatele mást.
Rozhodně bych se tomuhle vyhnul ve firemním nasazení, tam si koledujete o zbytečné a nečekané problémy.

K praktičnosti. Na rychlost startovaní Windows 10 to nemělo téměř žádny vliv (běžný autostart-up bloatware). Jediný skutečný přínos bylo rychlejší kopírovaní dat (WD Blue cca 900-1000MB).

Zvažte jak to bude u Vás