Imponi a Windows Server 2008 di utilizzare il bootloader BIOS legacy anziché EFI

Abbiamo server UEFI e ci siamo imbattuti in una situazione in cui dobbiamo forzare l'avvio di Windows Server 2008 tramite il metodo BIOS legacy anziché tramite UEFI.

C'è un modo per dire a Windows Server 2008 (durante l'installazione o dopo l'installazione) di ignorare il fatto che si sta installando su una macchina EFI e invece installare e utilizzare il bootloader BIOS legacy?

Ho provato alcuni suggerimenti che non hanno aiutato:

• Formattare i dischi come partizioni MBR prima di installare Windows

  No, Windows rifiuta di installare:

• Installa Windows, migra la partizione su un disco MBR, ripara il sistema

  No, la console di riparazione del sistema si rifiuta di caricare. Si lamenta di non riconoscere la versione di Windows che sto tentando di riparare.

• Disabilita UEFI

  Se potessi disabilitare UEFI e rendere il sistema solo legacy, avrei. Tuttavia, i sistemi specifici che sto utilizzando (IBM HS22, x3690X5) sono solo UEFI con supporto legacy. Non puoi semplicemente disabilitare UEFI su di essi. Ciò richiederebbe un'implementazione completa del BIOS.

La soluzione!

Come sottolinea JdeBP, l'unico metodo utilizzato da Windows per determinare se utilizzare il bootloader EFI / GPT o BIOS / MBR è il metodo utilizzato per avviare il CD di installazione.

Combinando questo con il suggerimento di Weaver di creare un'immagine .iso senza la voce del catalogo di avvio 0xEF (molto più facile da eseguire mediante la modifica esadecimale piuttosto che rimasterizzare l'immagine, tra l'altro) ci porta a una risposta concisa e concisa:

Forzare l'avvio del supporto di installazione tramite BIOS, non tramite UEFI poiché questo è l'unico fattore di differenziazione utilizzato da Windows Installer per determinare quale schema di avvio utilizzare.

Microsoft non ti permetterà di compiere il tuo passo; quindi indirizza invece il tuo obiettivo.

Microsoft si confonde erroneamente con un disco rigido partizionato EFI con firmware EFI . Questo è, ovviamente, chiaramente sbagliato. È del tutto possibile - e in effetti sta diventando sempre più desiderabile in questi giorni - avere un disco partizionato EFI su una macchina che ha un vecchio firmware non EFI. In realtà, anche se ci sono volute più di due settimane per le persone qui a tirarti fuori l'obiettivo piuttosto che il passo, vuoi il contrario. Si desidera disporre di un vecchio disco partizionato MBR in stile PC / AT su un computer con firmware EFI. (Il firmware EFI stesso non ha alcun problema con entrambi i formati di tabella delle partizioni ed è effettivamente richiesto dalle specifiche EFI per capirli entrambi. È Microsoft che fa questo errore.) E lo desideri perché il software di qualcun altro non è in grado di comprendere la tabella delle partizioni EFI.

Una delle varie conseguenze dell'errore di Microsoft è che il programma di installazione di Windows NT 6.1 deve essere richiamato da un supporto di installazione che è stato a sua volta avviato dal vecchio firmware PC98, affinché accetti l'idea di installare Windows NT 6.1 su un disco partizionato con il vecchio schema di partizionamento PC / AT MBR. Sfortunatamente, se il disco di installazione di Windows NT viene avviato nel nuovo modo EFI, il programma di installazione penserà che ci sia un firmware EFI e quindi dichiara che non può essere installato su dischi rigidi partizionati non EFI.

Come sottolineato da Weaver, e come spiega la documentazione Microsoft , il CD-ROM di installazione è in realtà a doppio avvio. Come spiega Rod Smith , si può quindi costruire manualmente un disco di installazione di Windows NT 6.1 che si avvia alla vecchia maniera PC98. Il programma di installazione di Windows NT 6.1 consentirà quindi l'installazione su un vecchio disco rigido partizionato PC / AT MBR.

Tuttavia, sui sistemi privi di un modulo di supporto per la compatibilità , come dici tu, il tuo sistema non sarà d'aiuto . Il tuo sistema richiederà la versione EFI di Boot Manager di Microsoft, installata sulla partizione di sistema EFI, perché è così che il tuo firmware proverà ad avviare il sistema operativo. Ma quando il programma di installazione di Windows NT 6.1 viene avviato con un firmware non EFI, installa la versione non EFI di Boot Manager di Microsoft e non creerà una partizione di sistema EFI. Tale installazione in realtà non si avvia sul tuo computer e non sarai nemmeno in grado di completare la procedura di installazione. Infatti, poiché ti manca un CSM, non sarai nemmeno in grado di iniziarela procedura di installazione, perché non sarai nemmeno in grado di avviare il bootstrap nel vecchio modo PC98. Microsoft non ti permetterà di compiere il tuo passo, due volte.

Quindi concentrati sul tuo obiettivo, invece. L'obiettivo è consentire al cliente di distribuire Windows Server 2008 su macchine con firmware EFI da un'immagine di sistema. Pertanto, la domanda corretta che dovresti porre - del fornitore del software - è come far riparare quel software di imaging del disco vecchio / rotto in modo che non abbia problemi con la tabella delle partizioni EFI.

In breve, sì e no per alcuni motivi diversi. Se Windows si avvia da un disco GPT, deve provenire da UEFI. Il boot manager e il caricatore di Windows non possono essere avviati sul disco MBR da UEFI nativo . Tuttavia, se UEFI è configurato per la modalità di avvio del BIOS legacy, è possibile utilizzare un disco MBR per l'avvio. Ciò deriva dalla modalità di avvio di Windows (BIOS con MBR o UEFI con GPT) che dipende dall'ambiente in cui è invocato.

Continua a leggere per un po 'di tecnologia -

L'hardware fisico (o hardware virtuale, ma comunque hardware) firmware (BIOS / UEFI) fornisce l'ambiente operativo iniziale (strutture e convenzioni di dati relative all'avvio) e servizi firmware disponibili per le fasi successive del processo di avvio del sistema operativo.

BIOS / MBR

Nel caso di BIOS / MBR, avviare il primo settore del primo disco di avvio: il record di avvio principale (LBA 0) contiene una manciata di assembly x86 (16 bit 8088), quindi la tabella delle partizioni, quindi una firma). Il BIOS carica questo settore nella memoria e inizia l'esecuzione: il BIOS rinuncia al proprio controllo del codice del programma non appena viene coinvolto l'MBR.

http://mbr.adamsatoms.com/

http://www.ata-atapi.com/hiwmbr.html

L'assembly x86 (Intel 8088 nella maggior parte degli MBR) nell'MBR analizza la tabella delle partizioni, cerca una partizione attiva e passa al primo settore in quella partizione, chiamato record di avvio del volume. Il record di avvio del volume contiene un jmp di assembly x86, un blocco di parametri BIOS (non utilizzato dal BIOS di sistema, quindi un nome così confuso) e un altro gruppo di x86 che alla fine carica il boot loader del sistema operativo (NTLDR o BOOTMGR in ambienti Windows ) dal volume di avvio / partizione stessa.

NTLDR o BOOTMGR cambiano la CPU in modalità protetta, consultano la loro configurazione al momento dell'avvio (rispettivamente boot.ini o BCD, entrambi sul volume / partizione di avvio) e caricano NTOSKRNL dove il resto è cronologico.

http://technet.microsoft.com/en-us/library/cc781134%28WS.10%29.aspx

http://en.wikipedia.org/wiki/Windows_NT_startup_process

http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/bios-parameter-block.html

UEFI / GPT

Prima di tutto lasciatemi dire che non ho molta esperienza attiva con UEFI / GPT. Tuttavia, poiché l'ho usato e lo capisco per funzionare, la grande differenza (in relazione alla nostra conversazione) è che il controllo eseguibile non viene trasferito all'MBR.

Invece il firmware UEFI contiene il proprio boot manager. Questo boot manager esegue la scansione di dischi e supporti, - sorpassa l'MBR protettivo dei dischi formattati GPT, arriva all'intestazione GPT e quindi si tuffa nella partizione di sistema EFI (ESP) dove cerca i programmi eseguibili EFI - che dovrebbero essere caricatori di avvio del sistema operativo che avviano direttamente il sistema operativo, tuttavia, come abbiamo visto con gli ultimi eseguibili MS e Apple EFI, sono in realtà gestori di avvio che aggiungono un altro livello al processo e alla complessità.

http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/efi-boot-process.html

http://msdn.microsoft.com/en-us/windows/hardware/gg463525#X-201104111922443

Conclusione / TL; DR

Il punto da togliere a questo è che esiste un ambiente previsto in cui si aspettano di eseguire il boot manager del sistema operativo e il boot loader. Dai servizi a livello di firmware disponibili (interruzioni BIOS / UEFI), strutture di dati (variabili, convenzioni di stack, ecc.) E persino convenzioni di formattazione del disco. Non può essere modificato in fase di esecuzione - almeno non nel modo in cui lo capisco.

Le tue opzioni?

Preinstallazione è possibile controllare l'installazione utilizzando BIOS / MBR o UEFI nell'avvio del BIOS legacy con MBR o UEFI con GPT.

Post-installazione - Potrebbero esserci alcune interessanti possibilità con la modifica offline del formato del disco (da MBR a GPT e da GPT a MBR), quindi l'avvio da una console di ripristino (in modalità UEFI o BIOS appropriata) e l'utilizzo di bcdboot e bcdedit per ottenere Windows boot manager impostato direttamente.

Aggiornamento del 09.09.2011

@MikeyB

Elencando le opzioni come le capisco, in realtà non fanno alcun suggerimento formale.

Tuttavia, dopo aver fatto un po 'più di ricerca su UEFI (ricorda che non ho molta esperienza attiva con esso) ho scoperto alcune curiosità sul boot manager UEFI e il supporto per l'avvio da CD / DVD.

Le specifiche di avvio di El Torito, del '95, sono ancora in circolazione oggi e vengono utilizzate con CD / DVD di avvio. Potrebbe essere necessario avviare un singolo CD / DVD su più architetture e mentre ISO 9660 è piuttosto indipendente dalla piattaforma, il codice eseguibile non lo è. Pertanto, le specifiche di avvio El Torito consentono più voci / immagini di avvio.

Queste voci / immagini contengono un ID piattaforma , destinato a indicare se una voce è per PC, PowerPC e altre architetture in modo che il BIOS (o il firmware) dell'architettura possa scegliere la voce di avvio corretta.

I PC x86 standard con un BIOS hanno un ID piattaforma El Torito di 0x00. L' ID piattaforma compatibile con UEFI è 0xEF - piuttosto creativo.

I BIOS standard per PC x86 ignorano tutte le altre voci tranne 0x00. I firmware UEFI che dispongono del supporto BIOS legacy (noto come Compatibility Support Module (CSM)) - mentre sono in grado di avviare 0x00, preferiranno una voce di avvio nativa 0xEF dal catalogo.

I supporti DVD di Windows 2008, 2008 R2 e 7 contengono un catalogo El Torito con immagini multiple con 0x00 e 0xEF. Lo 0x00 è il valore predefinito, ma un UEFI lo sovrasta se esiste uno 0xEF e sceglie la voce 0xEF, poiché è nativa.

Ciò che è possibile è creare un supporto che contenga solo l'ID piattaforma preferito nel catalogo di avvio di El Torito. Invece di un catalogo a più voci, creare un catalogo a voce singola con un ID piattaforma 0x00. Ciò dovrebbe forzare il firmware UEFI, se in realtà supporta l'avvio del BIOS legacy, per scegliere l'ID piattaforma 0x00 e avviare la voce di avvio del BIOS legacy sul supporto di Windows.

Come farlo?

Usando Oscdimg è possibile. Di seguito sono riportati alcuni esempi di persone che creano supporti UEFI solo per aggirare i limiti dell'implementazione UEFI di Apple. Si noti che questo è l'opposto di ciò che stiamo cercando di fare: vogliamo creare solo un BIOS, tralasciando la voce di avvio UEFI dal catalogo.

Solo UEFI (opposto) 1

Solo UEFI (opposto) 2

Il processo per creare supporti solo BIOS è simile con le modifiche agli argomenti -be -palle seguenti

-bC:\path\to\Etfsboot.com -p0x00

Una grande risorsa che ha fatto luce sulla follia scelta da Microsoft sul supporto di installazione di Windows è il documento Supporto e requisiti UEFI per i sistemi operativi Windows .

Un metodo semplice sarebbe semplicemente eseguire un'installazione di base di Windows su una macchina che non supporta EFI, acquisirla con il software dell'immagine e ripristinarla sull'hardware reale.

Una buona scelta potrebbe essere quella di creare l'installazione di base in una macchina virtuale. Nelle versioni precedenti (versione <6) di Windows non si adattava bene per essere spostato da un tipo di hardware a un altro. Con le versioni recenti Windows, purché il controller di archiviazione sia supportato nell'immagine, Windows farà un ottimo lavoro nell'adattarsi al nuovo hardware.

Il disco di installazione di Windows (ver> = 6) in genere include in genere un file WIM che è fondamentalmente solo un'immagine del sistema operativo.