J'ai essayé de trouver un moyen plus simple d'installer le double démarrage Windows et Linux sur mon ordinateur portable, pas nécessairement dans cet ordre. En règle générale, nous devons d'abord installer Windows, puis installer linux et permettre à GRUB de gérer Windows.
Donc, ce que j'essaie de faire, c'est de trouver un moyen de contourner ce processus d'installation fastidieux (Windows) et d'utiliser simplement une image pour copier directement dans mon lecteur. Cela me permettrait également de conserver mon gestionnaire de démarrage (GRUB). (non pas que je ne puisse pas le restaurer par la suite, mais c'est la politique de Microsoft de monopoliser, dans ce cas, nier l'existence d'autres gestionnaires de démarrage dans le système).
J'ai d'abord obtenu une copie légale de Windows 8.1, puis j'ai procédé à son installation sur une machine virtuelle à l'aide de VirtualBox. Ensuite, j'ai créé une partition NTFS sur mon disque dur partitionné GPT et copié le contenu de la partition Windows de l'image .vdi vers la partition nouvellement créée.
Bien sûr, cela ne fonctionne pas encore. Je ne sais pas comment remplacer bootmgr. Il donne
File: \Boot\BCD
Status: 0xc000000e
Info: The Boot Configuration Data for your PC is missing or contains errors.
car il ne peut pas trouver ce fichier à partir de l'autre partition qui est utilisée pour le démarrage, la récupération du système, etc.
Maintenant, j'ai lu que bootmgr exécute finalement winload.exe pour démarrer Windows. Je ne sais pas quoi faire ensuite.
Je pense que cela devrait fonctionner théoriquement car j'ai tous les fichiers nécessaires pour exécuter Windows. Je pense également que je ne devrais pas être le seul à avoir pensé à cela, et par conséquent il me manque peut-être quelque chose de très basique ici. Peut-être que c'est déjà fait?
Je n'ai aucune idée du fonctionnement du démarrage. Ce que j'ai réussi à comprendre, c'est que lorsque vous double-démarrez Windows et Linux, vous enchaînez le chargeur de démarrage Windows à Linux. Donc, ce que j'essaie de faire, c'est de me débarrasser du chargeur de démarrage Windows.
ÉDITER
J'ai regardé les fichiers binaires bootmgr
et \Boot\BCD
. bootmgr
lit le fichier BCD et répertorie vos options, parmi lesquelles vous pouvez choisir de démarrer.
Ainsi, des informations telles que l'exécution winload.exe
résident dans le fichier BCD. Maintenant, je pense que bootmgr
lui-même est exécuté par syslinux en utilisant le chain.c32
module. Ce que j'essaie de faire, c'est en quelque sorte d'exécuter le chargeur de démarrage de Windows, c'est-à-dire winload.exe
directement à partir de syslinux (si possible), ou de le modifier bootmgr
pour qu'il s'exécute winload.exe
lui-même (dont le chemin sera directement dans l' bootmgr
exécutable) sans chercher BCD ou autre chose.
L'hibernation (qui nécessite une procédure différente) ne me concerne pas à ce stade.
Modifiez votre question pour nous indiquer le type de micrologiciel et (si EFI) si vous avez activé le module de support de compatibilité dans la configuration du micrologiciel
Mon micrologiciel est EFI (avec CSM activé), et je démarre normalement dans Arch Linux en utilisant GRUB. J'ai découvert que bootmgr
s'exécute System32\winload.exe
sur les systèmes hérités et System32\winload.efi
sur EFI.
J'ai une 0.0
idée de quoi faire d'ici. Depuis 10 jours, j'essaie d'apporter des modifications au BCD et je pense que je suis sur le point de réussir. Mais ce n'est pas pertinent, car ce que je veux vraiment faire, c'est contourner complètement le Gestionnaire de démarrage Windows.
Si vous avez une idée s'il existe un moyen d'exécuter cela à winload.efi
partir du shell EFI (juste une supposition), ou une autre modification de GRUB pour qu'il démarre Windows en mode EFI sans le chargeur de chaîne.
Tous les conseils sont les bienvenus.
Addenda
Les messages suivants du forum peuvent fournir des informations utiles:
http://reboot.pro/topic/19371-chainload-directly-to-winloadexe/
1.
Le grub4dos peut actuellement charger en chaîne un chargeur de démarrage (comme NTLDR ou BOOTMGR) car il peut agir comme un remplacement du code contenu dans un secteur de démarrage "normal" (c'est-à-dire quelque chose comme 300 octets de code machine).
Ce code définit simplement quelques paramètres, puis appelle le chargeur.
Même cela n'est (n'était) pas du tout facile à comprendre et à reproduire avec un code différent.
Un chargeur de système NT comme BOOTMGR a plus ou moins dans un seul .exe un système d'exploitation "en mode réel" (pas tout à fait différent de DOS) et des installations / outils pour analyser à la fois le texte brut et les ruches du Registre, ce n'est pas quelque chose qui peut être écrit à partir de zéro facilement.
Les bons gars @ReactOS travaillent à l'écriture du FREELDR (qui vise à remplacer le NTLDR beaucoup plus simple) depuis des ANNÉES (et croyez-moi, parmi les programmeurs ReactOS, certains sont vraiment bons et bons dans ce domaine).
Il semble (mais ce n'est pas clairement documenté) qu'ils ont réussi à démarrer expérimentalement un serveur 2003 avec NTLDR.
2.
Avec l'introduction de la prise en charge de (U) EFI, BootMgr aide à résumer la différence entre le BIOS et (U) EFI. Par exemple, voici deux séquences:
BIOS (PCAT) -> BootMgr { BootMgr stub -> embedded BootMgr.exe } -> WinLoad.exe -> Windows 64-bit (U)EFI -> BootMgFw.efi -> BootMgr.efi -> WinLoad.efi -> Windows
WinLoad attend qu'un certain environnement (y compris l'API) soit présent. BootMgr s'en charge, donc [presque] le même programme WinLoad fonctionnera dans les deux environnements.
En fait, (U) EFI définit une méthode pour stocker et récupérer les paramètres de démarrage, donc le BCD de BootMgr couvre ce même objectif, indépendamment du BIOS / (U) EFI.
Mais au-delà des différences BIOS et (U) EFI, BootMgr vous permet de faire un «choix de démarrage», tandis que WinLoad démarre un système d'exploitation particulier qu'il sait démarrer.
Selon la quantité d'un environnement que WinLoad attend d'être présent, il peut être possible d'appeler directement WinLoad. Le wimboot de Michael Brown invoque directement le BootMgr PE [1], il pourrait donc appeler WinLoad directement, sauf que WinLoad veut probablement plus d'un environnement. Vous pouvez l'essayer!
[1] À ne pas confondre avec le BootMgr que GRUB4DOS et chain.c32 de Syslinux peuvent invoquer. Ce BootMgr comprend un stub qui sait comment appeler le PE BootMgr intégré.
setup
utilitaire du micrologiciel .