Eu tenho tentado encontrar uma maneira mais fácil de instalar o Windows e Linux de inicialização dupla no meu laptop, não necessariamente nessa ordem. O que geralmente precisamos fazer é instalar o Windows primeiro e, em seguida, instalar o linux e permitir que o GRUB manipule o Windows.
Então, o que estou tentando conseguir é encontrar uma maneira de ignorar esse processo de instalação traquina (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 posteriormente, mas é política da Microsoft monopolizar, neste caso, negar a existência de outros gerenciadores de inicialização no sistema).
Obtive uma cópia legal do Windows 8.1 e depois instalei-a em uma máquina virtual usando o VirtualBox. Em seguida, criei uma partição NTFS no disco rígido particionado GPT e copiei o conteúdo da partição do Windows da imagem .vdi para a partição recém-criada.
Claro, ainda não funciona. Não sei como substituir o bootmgr. Dá
File: \Boot\BCD
Status: 0xc000000e
Info: The Boot Configuration Data for your PC is missing or contains errors.
porque ele não consegue encontrar o arquivo da outra partição usada para inicialização, recuperação do sistema etc.
Agora, li que o bootmgr finalmente executa o winload.exe para inicializar o Windows. Não tenho idéia do que fazer a seguir.
Acho que deveria funcionar teoricamente porque tenho todos os arquivos necessários para executar o Windows. Também acho que não devo ser o único que pensou nisso e, portanto, posso estar perdendo algo muito básico aqui. Talvez já esteja pronto?
Eu tenho pouca ideia de como a inicialização funciona. O que eu consegui entender é que, quando você inicializa duas vezes o Windows e o Linux, liga o carregador de inicialização do Windows ao Linux. Então, o que estou tentando alcançar é de alguma forma se livrar do gerenciador de inicialização do Windows.
EDITAR
Eu estive olhando os arquivos binários bootmgre \Boot\BCD. bootmgrlê o arquivo BCD e lista suas opções, entre as quais você pode selecionar para inicializar.
Portanto, informações como a execução winload.exeresidem no arquivo BCD. Agora, acho que bootmgrele próprio é executado pelo syslinux usando o chain.c32módulo. O que estou tentando fazer é, de alguma forma, executar o gerenciador de inicialização do Windows, ou seja, winload.exediretamente do syslinux (se possível), ou modificar bootmgrpara que ele se execute winload.exe(cujo caminho estará diretamente no bootmgrexecutável) sem procurar o BCD ou qualquer outra coisa.
A hibernação (que requer um procedimento diferente) não me interessa nesta etapa.
Edite sua pergunta para nos informar o tipo de firmware e (se EFI) se você ativou o Compatibility Support Module na configuração do firmware
Meu firmware é EFI (com CSM ativado) e normalmente inicializo no Arch Linux usando o GRUB. Eu descobri que é bootmgrexecutado System32\winload.exeem sistemas legados e System32\winload.efina EFI.
Eu tenho 0.0idé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 realmente quero fazer é ignorar completamente o Gerenciador de Inicialização do Windows.
Se você tem alguma idéia de se existe uma maneira de executar isso a winload.efipartir do shell EFI (apenas uma suposição) ou alguma outra modificação no GRUB, para que ele inicialize o Windows no modo EFI sem o carregador de cadeia.
Quaisquer conselhos são bem-vindos.
Termo aditivo
As seguintes postagens no fórum podem fornecer algumas dicas úteis:
http://reboot.pro/topic/19371-chainload-directly-to-winloadexe/
1
O grub4dos agora pode carregar um carregador de inicialização em cadeia (como NTLDR ou BOOTMGR) porque pode atuar como uma substituição do código contido em um setor de inicialização "normal" (ou seja, algo como 300 bytes de código de máquina).
Esse código simplesmente define alguns parâmetros e depois chama o carregador.
Mesmo isso (não foi) fácil de entender e replicar com código diferente.
Um carregador de sistema NT como o BOOTMGR possui mais ou menos em um único .exe um sistema operacional "modo real" (não muito diferente do DOS) e recursos / ferramentas para analisar texto simples e seções do Registro, não é algo que possa ser recuperado. escrito do zero facilmente.
Os mocinhos do @ReactOS estão trabalhando para escrever o FREELDR (que visa substituir o NTLDR muito mais simples) desde ANOS (e acredite, existem entre os programadores do ReactOS alguns realmente bons e bons nisso).
Ela parece (mas não está documentado claramente) que conseguiram arrancar experimentalmente um Server 2003 com NTLDR.
2)
Com a introdução do suporte para (U) EFI, o BootMgr ajuda a abstrair a diferença entre BIOS e (U) EFI. Por exemplo, aqui estão duas sequências:
BIOS (PCAT) -> BootMgr { BootMgr stub -> embedded BootMgr.exe } -> WinLoad.exe -> Windows 64-bit (U)EFI -> BootMgFw.efi -> BootMgr.efi -> WinLoad.efi -> WindowsO WinLoad espera que um determinado ambiente (incluindo API) esteja presente. O BootMgr cuida disso, portanto [quase] o mesmo programa WinLoad funcionará em qualquer ambiente.
De fato, o (U) EFI define um método para armazenar e buscar parâmetros de inicialização, portanto, o BCD do BootMgr cobre o mesmo objetivo, independentemente do BIOS / (U) EFI.
Além das diferenças de BIOS e (U) EFI, o BootMgr permite fazer uma "escolha de inicialização", enquanto o WinLoad inicializa um sistema operacional específico que ele sabe como inicializar.
Dependendo da quantidade de ambiente que o WinLoad espera estar presente, pode ser possível invocar o WinLoad diretamente. O wimboot de Michael Brown invoca o BootMgr PE [1] diretamente, para que possa invocar o WinLoad diretamente, exceto que o WinLoad provavelmente deseja mais um ambiente. Você poderia tentar!
[1] Não deve ser confundido com o BootMgr que GRUB4DOS e Syslinux 'chain.c32 podem invocar. Esse BootMgr inclui um stub que sabe como chamar o BootMgr PE incorporado.
setuputilitário do firmware .