Est-il possible de démarrer Windows 8.1 sans son propre gestionnaire de démarrage?


10

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 bootmgret \Boot\BCD. bootmgrlit 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.exerésident dans le fichier BCD. Maintenant, je pense que bootmgrlui-même est exécuté par syslinux en utilisant le chain.c32module. 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.exedirectement à partir de syslinux (si possible), ou de le modifier bootmgrpour qu'il s'exécute winload.exelui-même (dont le chemin sera directement dans l' bootmgrexé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 bootmgrs'exécute System32\winload.exesur les systèmes hérités et System32\winload.efisur EFI.

J'ai une 0.0idé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.efipartir 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é.


1
Vous n'avez pas encore fourni suffisamment d'informations. Modifiez votre question pour indiquer aux répondeurs si cette machine possède un micrologiciel EFI ou un ancien micrologiciel de type PC / AT. En ce moment, vous parlez de programmes d'amorçage MBR sur des disques partitionnés EFI, ce qui est (à moins que l'un n'utilise l'un de mes programmes ou celui de H. Peter Anvin) et probablement pas la façon dont votre machine démarre .
JdeBP

La politique que vous décrivez ne
quitte

@JdeBP Vous avez raison. À un moment donné, j'utilisais les deux. J'utilisais syslinux avec la méthode pc \ at. J'ai ensuite installé GRUB sur une partition EFI. Mon ordinateur portable prend donc en charge les deux, mais j'ai eu le même résultat à chaque fois. J'essaierai de m'informer en attendant. D'un autre côté, comprenez-vous ce que j'essaie d'accomplir? Oubliant ce que j'ai décrit auparavant, vous pouvez peut-être me donner des conseils sur la faisabilité ou non.
osolmaz

Je n'ai pas demandé le type de firmware paresseusement. C'est une donnée vitale que vous devez fournir. Sans cela, les gens ne peuvent même pas commencer une bonne réponse. Modifiez votre question pour nous indiquer le type de micrologiciel et (si EFI) si vous avez activé le module de support de compatibilité dans l' setuputilitaire du micrologiciel .
JdeBP

@JdeBP J'ai édité la question.
osolmaz

Réponses:


5

Pour répondre à votre question d'origine, non. Windows ne peut pas être chargé sans passer par son propre chargeur de démarrage (dans le cas des installations UEFI, bootmgfw.efi). Cela est dû au fait que Windows s'attend à ce que le gestionnaire de démarrage soit présent ET appelle winload.efi. Si cela ne se produit pas, Windows se bloquera jusqu'à ce que vous résolviez le problème. Il y a plusieurs raisons à cela (pratiques et ignorantes). C'est principalement parce que Microsoft a écrit le gestionnaire de démarrage pour gérer toutes choses (chargement du système d'exploitation, chargement de l'environnement de récupération, environnement pseudo pré-os, etc.). La seule façon actuellement d'atteindre un semblant de raison est d'enchaîner la charge à l'aide de Grub-efi.


Avant d'accepter cela comme réponse, je dois demander: est-ce que la tâche serait fastidieusement difficile à réaliser, principalement en raison de la quantité de piratage de bas niveau nécessaire pour tromper tout programme impliqué dans le processus; la tromperie étant que Windows penserait toujours qu'il a été démarré avec son propre gestionnaire de démarrage, alors qu'en réalité c'était autre chose ... Et je suppose que chaque version de Windows nécessiterait des efforts distincts. Mais cela ne rend pas la tâche impossible, vraiment difficile, non?
osolmaz

3
Je ne dirais pas que c'est totalement impossible (en programmation), mais il faudrait inverser les appels que le bootmgfw.efi fait au système d'exploitation Windows. La quantité de piratage de bas niveau impliquée dans la nécessité de procéder à une rétro-ingénierie des appels de protocole de démarrage de bas niveau à un chargeur de système d'exploitation est extrêmement coûteuse en termes de temps. Il faudrait non seulement tromper Windows en lui faisant croire que bootmgfw.efi était là, mais aussi que le BCD existe et qu'il a été créé par ses propres outils et ainsi de suite.
ChrisR.

2

Vous devez ajouter le chargeur de démarrage Windows EFI à la liste des options de démarrage dans le micrologiciel UEFI. De cette façon, vous pourrez choisir si:

  1. GRUB2 doit être chargé ou
  2. le chargeur de démarrage Windows doit être chargé

Des options supplémentaires telles que le lecteur de DVD, les disques durs externes ou le démarrage réseau doivent également être visibles à ce stade. Le chargeur de démarrage UEFI réside généralement sur la partition \EFI( /boot/efi/). Comme vous venez de copier l'image du disque dur Windows sans installer correctement Windows, la partition EFI de votre machine actuelle peut ne pas contenir le chargeur de démarrage approprié. Il est donc nécessaire de

  1. Copiez le chargeur de démarrage sur la partition EFI
  2. Ajouter Windows comme option de démarrage aux côtés de GRUB2

Vous devriez alors être en mesure de choisir quel système d'exploitation est démarré en changeant simplement l'ordre de démarrage dans le BIOS. Sur mon ordinateur portable, appuyer sur F12fait apparaître un menu pour sélectionner le chargeur de démarrage à charger.

Pour ces étapes, j'utiliserai efibootmgret suivrai les étapes de ce tutoriel :

Vous devrez copier le fichier correspondant bootmgfw.efisur la partition EFI à \EFI\Microsoft\Boot\bootmgfw.efi, ou /boot/efi/Microsoft/Boot/bootmgfw.efilors de l'utilisation de Linux:

# mkdir -p /boot/efi/EFI/Microsoft
# cp -r Microsoft /boot/efi/EFI/Microsoft

où se Microsofttrouve un dossier contenant les fichiers EFI d'origine pour votre version de Windows.

Ensuite, vous devez ajouter le .efifichier aux entrées de démarrage UEFI en utilisant:

# efibootmgr -c -d /dev/sda -p 1 -l \\EFI\\Microsoft\\Boot\\bootmgfw.efi -L "Windows Boot Manager"

où bien sûr vous devez changer /dev/sdaet -p 1aux valeurs correctes pour votre périphérique de disque et le numéro de partition.

Notez ceci si vous avez un ordinateur portable Lenovo:

Notez également qu'au moins un fabricant (Lenovo) expédie des produits avec un bogue connu qui fait que le système refuse de démarrer à moins que le nom du chargeur de démarrage soit "Windows Boot Manager" ou "Red Hat Enterprise Linux".

Le démarrage de votre PC devrait alors montrer quelque chose comme ceci (si vous maintenez les touches correspondantes pendant le processus de démarrage):

Windows Boot Manager
ubuntu
USB CD
USB FDD
ATAPI CD
ATA HDD2

(etc.)

et bcdeditsur Windows montre ceci:

C:\WINDOWS\system32>bcdedit /enum firmware

Firmware Boot Manager
---------------------
identifier              {fwbootmgr}
displayorder            {bootmgr}
                        {bb086763-b111-11e2-bf8e-806e6f6e6963}
                        {8e7fb978-8bc8-11e2-bf2f-806e6f6e6963}
timeout                 0

Windows Boot Manager
--------------------
identifier              {bootmgr}
device                  partition=\Device\HarddiskVolume2
path                    \EFI\Microsoft\Boot\bootmgfw.efi
description             Windows Boot Manager
locale                  en-US
inherit                 {globalsettings}
integrityservices       Enable
default                 {current}
resumeobject            {ec215a09-8bc4-11e2-bf2b-0024d7eb75a4}
displayorder            {current}
toolsdisplayorder       {memdiag}
timeout                 2

(...)

Firmware Application (101fffff)
-------------------------------
identifier              {bb086763-b111-11e2-bf8e-806e6f6e6963}
device                  partition=\Device\HarddiskVolume2
path                    \EFI\ubuntu\grubx64.efi
description             ubuntu

1
Très bien expliqué, merci. Il y a quelques jours, j'ai réussi à faire la même chose, mais en utilisant toujours une partition distincte pour le gestionnaire de démarrage Windows EFI, et grâce au chargement de chaîne avec GRUB. Maintenant, j'ai appris que je pouvais également utiliser mon EPS d'origine. De plus, au lieu d'utiliser bcdedit, j'ai utilisé hivex pour corriger le BCD; J'ai l'intention d'écrire une collection d'outils gratuits pour pouvoir manipuler des fichiers BCD sous Linux. Mais ce que j'essaie de réaliser, c'est quelque chose de différent. Si bootmgfw.efi exécute en quelque sorte winload.efi, pourquoi ne pourrais-je pas exécuter winload.efi directement à partir de GRUB?
osolmaz

Oh je vois. Vous souhaitez donc ignorer le chargement du gestionnaire de démarrage Windows (bootmgfw.efi) et charger le chargeur de démarrage Windows (winload.efi) directement en lisant le BCD System Store? (En partant des définitions d' ici .) C'est intéressant, je n'ai jamais entendu parler de quelqu'un qui fait ça. Quelle est votre motivation, pourquoi est-il nécessaire de charger directement winload.efi? De plus, avez-vous une copie complète du \EFI\Boot\Microsoftdossier pour les tests (il y a quelques fichiers dedans)?
jmiserez

Eh bien, si j'y arrivais, je n'aurais même pas besoin de lire le BCD, je pourrais simplement ajouter une entrée dans GRUB pour la partition. (J'exclus l'hibernation et la récupération du système ici) Ma motivation est que, il serait beaucoup plus facile d'installer Windows sans se soucier de devoir le réparer plus tard. Utile pour les administrateurs système, les installations par lots, etc. (et pour moi ^^). Quant à savoir pourquoi charger directement winload.efi: traiter des fichiers de registre Windows fermés (binaires) est beaucoup plus fastidieux que de traiter des fichiers de configuration en texte brut comme GRUB. Il est simplement plus facile d'éliminer l'homme du milieu.
osolmaz

1
Je vois ce que tu veux dire, oui, ce serait très pratique. Je me demande si 1) il y a des variables que bootmgfw.efi transmet à winload.efi lors de son lancement, et 2) s'il pourrait y avoir un problème avec un démarrage sécurisé et une sorte de chaîne de certificats nécessaire. Avez-vous découvert ce que inherit {bootloadersettings}signifie réellement le magasin BCD?
jmiserez

1
3) Depuis que j'ai utilisé hivex, je peux deviner à quel objet cela correspond. Il y a un objet de paramètres «globaux» dans la ruche, et tous les autres objets ont une référence. Ce que je peux dire, c'est que deux objets suffisent pour démarrer dans Windows: 1: l'objet Windows Boot Manager avec la constante uuid {9dea862c-5cdd-4e70-acc1-f32b344d4795} 2: l'objet qui contient les informations de partition et le chemin du chargeur de démarrage pour votre racine Windows réelle. Le plus difficile a été de comprendre la structure des données binaires qui spécifiait la partition. Cela a été principalement fait par wodny: bitbucket.org/wodny/libbcd/src .
osolmaz

0

Vous pouvez faire des installations dans n'importe quel ordre, c'est-à-dire installer GNU / Linux puis Windows ou vice-versa.

Procédez simplement comme suit après avoir installé tous vos systèmes d'exploitation.

  1. Obtenez le "Boot Repair Disk" à partir d'ici. http://sourceforge.net/projects/boot-repair-cd/

  2. Créez une clé USB bootable en direct (Instructions sur pendrivelinux.com)

  3. Ou gravez le fichier ISO sur un CD.

  4. Démarrez-le et suivez les instructions à l'écran. Vous aurez un GRUB réinstallé contenant tous vos systèmes d'exploitation installés.

Bonne chance.


1
J'en suis conscient, ce que je veux, c'est quelque chose de différent. Je demande si Windows peut être démarré directement sans chargement de chaîne.
osolmaz
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.