He estado tratando de encontrar una forma más fácil de instalar el arranque dual de Windows y Linux en mi computadora portátil, no necesariamente en ese orden. Lo que generalmente tenemos que hacer es instalar Windows primero, y luego instalar Linux y permitir que GRUB maneje Windows.
Entonces, lo que estoy tratando de lograr es encontrar una manera de evitar ese molesto proceso de instalación (Windows) y simplemente usar una imagen para copiar directamente en mi disco. Esto también me permitiría conservar mi gestor de arranque (GRUB). (No es que no pueda restaurarlo más tarde, pero es política de Microsoft monopolizar, en este caso negar la existencia de otros gestores de arranque en el sistema).
Primero obtuve una copia legal de Windows 8.1, luego procedí a instalarla en una máquina virtual usando VirtualBox. Luego, creé una partición NTFS en mi disco duro con particiones GPT y copié el contenido de la partición de Windows de la imagen .vdi a la partición recién creada.
Por supuesto, aún no funciona. No sé cómo reemplazar bootmgr. Da
File: \Boot\BCD
Status: 0xc000000e
Info: The Boot Configuration Data for your PC is missing or contains errors.
porque no puede encontrar ese archivo de la otra partición que se usa para el arranque, la recuperación del sistema, etc.
Ahora, he leído que bootmgr finalmente ejecuta winload.exe para iniciar Windows. No tengo idea de qué hacer a continuación.
Creo que debería funcionar teóricamente porque tengo todos los archivos necesarios para ejecutar Windows. También creo que no debería ser el único que haya pensado en esto, y por lo tanto, puede estar perdiendo algo muy básico aquí. Tal vez ya está hecho?
Tengo poca idea de cómo funciona el arranque. Lo que logré entender es que cuando inicias dual Windows y Linux, encadenas el gestor de arranque de Windows a Linux. Entonces, lo que estoy tratando de lograr es deshacerme de alguna manera del cargador de arranque de Windows.
EDITAR
He estado mirando los archivos binarios bootmgry \Boot\BCD. bootmgrlee el archivo BCD y enumera sus opciones, entre las cuales puede seleccionar iniciar.
Entonces, la información como la ejecución winload.exereside en el archivo BCD. Ahora, creo que bootmgrsyslinux lo ejecuta utilizando el chain.c32módulo. Lo que intento hacer es ejecutar de alguna manera el gestor de arranque de Windows, es decir, winload.exedirectamente desde syslinux (si es posible), o modificarlo bootmgrpara que se ejecute winload.exesolo (cuya ruta estará directamente en el bootmgrejecutable) sin buscar BCD o cualquier otra cosa.
La hibernación (que requiere un procedimiento diferente) no me preocupa en este paso.
Edite su pregunta para decirnos el tipo de firmware y (si es EFI) si ha habilitado el Módulo de soporte de compatibilidad en la configuración del firmware
Mi firmware es EFI (con CSM habilitado), y normalmente inicio en Arch Linux usando GRUB. He descubierto que se bootmgrejecuta System32\winload.exeen sistemas heredados y System32\winload.efien EFI.
Tengo 0.0idea de qué hacer desde aquí. Durante los últimos 10 días, he estado tratando de hacer cambios en BCD y creo que estoy a punto de alcanzar el éxito. Pero eso es irrelevante, porque lo que realmente quiero hacer es evitar el Administrador de arranque de Windows por completo.
Si tiene alguna idea de si hay una manera de ejecutar eso winload.efidesde el shell EFI (solo una suposición), o alguna otra modificación a GRUB para que arranque Windows en modo EFI sin el cargador de cadenas.
Cualquier consejo es bienvenido.
Apéndice
Las siguientes publicaciones en el foro pueden proporcionar información útil:
http://reboot.pro/topic/19371-chainload-directly-to-winloadexe/
1)
En este momento, grub4dos puede cargar en cadena un cargador de arranque (como NTLDR o BOOTMGR) porque puede actuar como un reemplazo del código contenido en un sector de arranque "normal" (es decir, algo así como 300 bytes de código de máquina).
Este código simplemente establece algunos parámetros y luego llama al cargador.
Incluso eso (no) fue fácil de entender y replicar con código diferente.
Un cargador de sistema NT como BOOTMGR tiene más o menos en un solo .exe un sistema operativo de "modo real" (no del todo distinto de DOS) e instalaciones / herramientas para analizar tanto el texto sin formato como las colmenas del Registro, no es algo que se pueda recuperar escrito desde cero fácilmente.
Los buenos @ReactOS están trabajando en escribir FREELDR (que pretende ser un reemplazo para el NTLDR mucho más simple) desde AÑOS (y créanme que hay entre los programadores de ReactOS algunos muy buenos y buenos en eso).
Se parece (pero no se documenta claramente) que lograron arrancar de forma experimental un servidor 2003 con NTLDR.
2)
Con la introducción del soporte para (U) EFI, BootMgr ayuda a abstraer la diferencia entre BIOS y (U) EFI. Por ejemplo, aquí hay dos secuencias:
BIOS (PCAT) -> BootMgr { BootMgr stub -> embedded BootMgr.exe } -> WinLoad.exe -> Windows 64-bit (U)EFI -> BootMgFw.efi -> BootMgr.efi -> WinLoad.efi -> WindowsWinLoad espera que un determinado entorno (incluida la API) esté presente. BootMgr se encarga de esto, por lo que [casi] el mismo programa WinLoad funcionará en cualquier entorno.
De hecho, (U) EFI define un método para almacenar y recuperar parámetros de arranque, por lo que el BCD de BootMgr cubre el mismo propósito, independientemente del BIOS / (U) EFI.
Pero más allá de las diferencias de BIOS y (U) EFI, BootMgr le permite hacer una "elección de inicio", mientras que WinLoad inicia un sistema operativo particular que sabe cómo iniciar.
Según la cantidad de entorno que WinLoad espera que esté presente, es posible invocar WinLoad directamente. El wimboot de Michael Brown invoca el BootMgr PE [1] directamente, por lo que podría invocar WinLoad directamente, excepto que WinLoad probablemente quiera más de un entorno. ¡Podrías probarlo!
[1] No debe confundirse con el BootMgr que GRUB4DOS y Syslinux 'chain.c32 pueden invocar. Ese BootMgr incluye un código auxiliar que sabe cómo invocar el BootMgr PE incorporado.
setuputilidad del firmware .