Eu tenho tentado criar uma maneira mais fácil de instalar o Windows e o Linux no meu laptop, não necessariamente nessa ordem. O que geralmente precisamos fazer é instalar o Windows primeiro, depois instalar o linux e permitir que o GRUB cuide do Windows.
Então, o que eu estou tentando conseguir é encontrar uma maneira de contornar esse processo de instalação irritante (windows) e apenas usar uma imagem para copiar diretamente na minha unidade. Isso também me permitiria manter meu gerenciador de inicialização (GRUB). (não que eu não possa restaurá-lo depois, mas é política da Microsoft monopolizar, neste caso, negar a existência de outros gerenciadores de inicialização no sistema).
Primeiramente, obtive uma cópia legal do Windows 8.1 e, em seguida, instalei-a em uma máquina virtual usando o VirtualBox. Em seguida, criei uma partição NTFS em meu disco rígido particionado GPT e copiei o conteúdo da partição Windows da imagem .vdi para a partição recém-criada.
Claro, isso não funciona ainda. Eu não sei como substituir o bootmgr. Isso dá
File: \Boot\BCD
Status: 0xc000000e
Info: The Boot Configuration Data for your PC is missing or contains errors.
porque não pode encontrar esse arquivo da outra partição que é usada para inicializar, recuperar o sistema, etc.
Agora, eu li que o bootmgr eventualmente executa o winload.exe para inicializar o Windows. Eu não tenho ideia do que fazer a seguir.
Eu acho que deveria funcionar teoricamente porque eu tenho todos os arquivos necessários para executar o Windows. Eu também acho que não deveria ser o único que pensou nisso e, portanto, posso estar perdendo algo muito básico aqui. Talvez já esteja feito?
Eu não tenho idéia de como o boot funciona. O que eu consegui entender é que quando você dual-boot Windows e Linux, você encadeia o gerenciador de inicialização do Windows para o Linux. Então, o que eu estou tentando alcançar é de alguma forma se livrar do bootloader do Windows.
EDITAR
Eu tenho visto os arquivos binários bootmgr e \Boot\BCD . bootmgr lê o arquivo BCD e lista suas opções, dentre as quais você pode selecionar para inicializar.
Portanto, informações como executar winload.exe residem no arquivo BCD. Agora, acho que bootmgr é executado pelo syslinux usando o módulo chain.c32 . O que eu estou tentando fazer é de alguma forma executar o bootloader do windows, ie winload.exe diretamente do syslinux (se possível), ou modificar bootmgr para que ele execute winload.exe (cujo caminho será diretamente no executável bootmgr ) sem procurar por BCD ou qualquer outra coisa.
A hibernação (que requer um procedimento diferente) não é uma preocupação para mim nesta etapa.
Edit your question to tell us the firmware type, and (if EFI) whether
you have enabled the Compatibility Support Module in the firmware's
setup
Meu firmware é EFI (com o CSM ativado) e normalmente inicializo no Arch Linux usando o GRUB.
Descobri que bootmgr executa System32\winload.exe em sistemas legados e System32\winload.efi em EFI.
Eu tenho 0.0 idéia do que fazer a partir daqui. Nos últimos 10 dias, tenho tentado fazer alterações no BCD e acho que estou prestes a alcançar o sucesso. Mas isso é irrelevante, porque o que eu realmente quero fazer é ignorar completamente o Gerenciador de Inicialização do Windows.
Se você tem alguma idéia se existe uma maneira de executar esse winload.efi do shell EFI (apenas um palpite), ou alguma outra modificação no GRUB para que ele inicialize o Windows no modo EFI sem o chainloader.
Qualquer conselho é bem-vindo.
Adendo
As seguintes postagens no fórum podem fornecer algumas informações úteis:
link
1.
The grub4dos right now can chainload a bootloader (like NTLDR or
BOOTMGR) because it can act as a replacement of the code contained in
a "normal" bootsector (i.e. something like 300 bytes of machine code).
This code simply sets a few parameters and then calls the loader.
Even that is (was) not easy at all to understand and replicate with
different code.
A NT system loader like BOOTMGR has more or less in a single .exe a
"real mode" operating system (not entirely unlike DOS) and
facilities/tools to parse both plain text and Registry hives, it is
not something that can be re-written from scratch easily.
The good guys @ReactOS are working on writing the FREELDR (which aims
to be a replacement for the much simpler NTLDR) since YEARS (and
believe me there are among the ReactOS programmers some really good
and good at it guys).
It seems (but it is not documented clearly) that they managed to
boot experimentally a Server 2003 with NTLDR.
2.
With the introduction of support for (U)EFI, BootMgr helps to abstract
the difference between BIOS and (U)EFI. For example, here are two
sequences:
BIOS (PCAT) -> BootMgr { BootMgr stub -> embedded BootMgr.exe } -> WinLoad.exe -> Windows
64-bit (U)EFI -> BootMgFw.efi -> BootMgr.efi -> WinLoad.efi -> Windows
WinLoad expects a certain environment (including API) to be present.
BootMgr takes care of this, so [almost] the same WinLoad program will
work in either environment.
In fact, (U)EFI defines a method for storing and fetching boot
parameters, so BootMgr's BCD covers that same purpose, regardless of
BIOS/(U)EFI.
But beyond BIOS and (U)EFI differences, BootMgr lets you make a "boot
choice," whereas WinLoad boots a particular operating system that it
knows how to boot.
Depending on how much of an environment WinLoad expects to be present,
it might be possible to invoke WinLoad directly. Michael Brown's
wimboot invokes the BootMgr PE[1] directly, so it could invoke WinLoad
directly, except that WinLoad probably wants more of an environment.
You could try it!
[1] Not to be confused with the BootMgr which GRUB4DOS and Syslinux'
chain.c32 can invoke. That BootMgr includes a stub which knows how to
invoke the embedded BootMgr PE.