Ho cercato di creare un modo più semplice di installare Windows e Linux con doppio avvio sul mio laptop, non necessariamente in questo ordine. Quello che generalmente dobbiamo fare è installare prima Windows, quindi installare Linux e consentire a GRUB di gestire Windows.
Quindi, quello che sto cercando di ottenere è di trovare un modo per aggirare quel fastidioso processo di installazione (Windows) e basta usare un'immagine per copiare direttamente nel mio disco. Questo mi permetterebbe anche di mantenere il mio boot manager (GRUB). (non che non posso ripristinarlo in seguito, ma è la politica di Microsoft a monopolizzare, in questo caso negando l'esistenza di altri boot manager nel sistema).
Ho prima ottenuto una copia legale di Windows 8.1, quindi ho proceduto a installarlo su una macchina virtuale utilizzando VirtualBox. Quindi, ho creato una partizione NTFS sul mio disco rigido partizionato con GPT e copiato il contenuto della partizione Windows dall'immagine .vdi alla partizione appena creata.
Certo, non funziona ancora. Non so come sostituire bootmgr. Dà
File: \Boot\BCD
Status: 0xc000000e
Info: The Boot Configuration Data for your PC is missing or contains errors.
perché non riesce a trovare quel file dall'altra partizione che viene utilizzata per l'avvio, il ripristino del sistema, ecc.
Ora, ho letto che bootmgr alla fine esegue winload.exe per avviare Windows. Non ho idea di cosa fare dopo.
Penso che dovrebbe funzionare in teoria perché ho tutti i file necessari per eseguire Windows. Penso anche che non dovrei essere l'unico a pensarci, e quindi potrei mancare qualcosa di molto essenziale qui. Forse è già fatto?
Non ho idea di come funzioni l'avvio. Quello che sono riuscito a capire è che quando si esegue il dual-boot di Windows e Linux, si mette il bootloader di Windows su Linux. Quindi, quello che sto cercando di ottenere è in qualche modo sbarazzarsi del bootloader di Windows.
MODIFICARE
Ho visto i file binari bootmgr e \Boot\BCD. bootmgr legge il file BCD ed elenca le opzioni, tra le quali è possibile scegliere di avviarsi.
Quindi informazioni come l'esecuzione winload.exe risiede nel file BCD. Ora, penso bootmgr stesso viene eseguito da syslinux usando il chain.c32 modulo. Quello che sto cercando di fare è in qualche modo eseguire il bootloader di Windows, ad es. winload.exe direttamente da syslinux (se possibile), o modificare bootmgr in modo che venga eseguito winload.exe stesso (il cui percorso sarà direttamente nel bootmgr eseguibile) senza cercare BCD o altro.
L'ibernazione (che richiede una procedura diversa) non mi riguarda in questa fase.
Modifica la tua domanda per dirci il tipo di firmware e (se EFI) se hai abilitato il modulo di supporto di compatibilità nel firmware impostare
Il mio firmware è EFI (con CSM abilitato) e di solito avvio in Arch Linux utilizzando GRUB.
L'ho scoperto bootmgr esegue System32\winload.exe su sistemi legacy e System32\winload.efi su EFI.
io ho 0.0 idea su cosa fare da qui. Negli ultimi 10 giorni, ho cercato di apportare modifiche a BCD e penso che sto per raggiungere il successo. Ma questo è irrilevante, perché quello che voglio fare è ignorare del tutto il Boot Manager di Windows.
Se hai qualche idea se c'è un modo per eseguirlo winload.efi dalla shell EFI (solo una supposizione), o qualche altra modifica a GRUB in modo che avvii Windows in modalità EFI senza il chainloader.
Qualsiasi consiglio è benvenuto.
appendice
I seguenti post sul forum potrebbero fornire utili indicazioni:
http://reboot.pro/topic/19371-chainload-directly-to-winloadexe/
1.
Al momento grub4dos può eseguire il chainload di un bootloader (come NTLDR o BOOTMGR) perché può fungere da sostituto del codice contenuto in un "bootsector" "normale" (ad esempio qualcosa come 300 byte di codice macchina).
Questo codice imposta semplicemente alcuni parametri e quindi chiama il caricatore.
Anche questo è (non era) affatto facile da capire e replicare con codice diverso
Un caricatore di sistema NT come BOOTMGR ha più o meno in un unico .exe a sistema operativo "modalità reale" (non del tutto diverso dal DOS) e strutture / strumenti per analizzare sia gli hive del Registro di sistema che del Registro di sistema, lo è non qualcosa che può essere riscritto da zero facilmente.
I bravi ragazzi @ReactOS stanno lavorando alla scrittura di FREELDR (che mira essere un sostituto per il molto più semplice NTLDR) da ANNI (e credetemi, ci sono alcuni programmatori ReactOS davvero buoni e bravo ragazzi)
esso sembra (ma non è documentato chiaramente) a cui sono riusciti avviare sperimentalmente un Server 2003 con NTLDR.
2.
Con l'introduzione del supporto per (U) EFI, BootMgr aiuta ad astrarre la differenza tra BIOS e (U) EFI. Ad esempio, qui ci sono due sequenze:
BIOS (PCAT) -> BootMgr { BootMgr stub -> embedded BootMgr.exe } -> WinLoad.exe -> Windows 64-bit (U)EFI -> BootMgFw.efi -> BootMgr.efi -> WinLoad.efi -> WindowsWinLoad si aspetta che un certo ambiente (inclusa l'API) sia presente. BootMgr si occupa di questo, quindi [quasi] lo farà lo stesso programma WinLoad lavorare in entrambi gli ambienti.
Infatti, (U) EFI definisce un metodo per l'archiviazione e il recupero dell'avvio parametri, quindi il BCD di BootMgr copre lo stesso scopo, indipendentemente da BIOS / (U) EFI.
Ma oltre le differenze di BIOS e (U) EFI, BootMgr ti permette di fare un "boot" scelta ", mentre WinLoad avvia un particolare sistema operativo sa come fare il boot
A seconda della quantità di ambiente che WinLoad si aspetta di essere presente, potrebbe essere possibile invocare direttamente WinLoad. Michael Brown's wimboot richiama direttamente BootMgr PE [1], quindi potrebbe richiamare WinLoad direttamente, tranne che WinLoad probabilmente vuole più di un ambiente. Potresti provarlo!
[1] Da non confondere con BootMgr che GRUB4DOS e Syslinux ' chain.c32 può richiamare. Quel BootMgr include uno stub che sa come richiamare il BootMgr PE incorporato.
setup utilità.