Prevenzione e ripristino di crisi senza problemi
Se un aggiornamento del firmware ha esito negativo, i risultati possono essere devastanti. Al meglio, l'aggiornamento ha esito negativo, ma il sistema è resiliente e recupera senza che l'utente finale diventi consapevole. Al peggio, è possibile che un aggiornamento del firmware non riuscito possa causare un sistema inutilizzabile, richiedendo all'utente finale di restituire il proprio sistema al rivenditore o al produttore per la riparazione. Quest'ultimo caso è quello che chiamiamo una crisi.
Una crisi può causare un aggiornamento del firmware non riuscito o a causa del firmware incompatibile con Windows o altri aspetti del sistema. Questa sezione illustra le funzionalità progettate per impedire e ripristinare le crisi derivanti dagli aggiornamenti del firmware non riusciti. La nostra aspettativa è che la copertura del test di aggiornamento del firmware da parte dell'autore del firmware impedisce la maggior parte delle crisi risultanti dal firmware incompatibile.
Per offrire un'esperienza ottimale per gli utenti finali, i seguenti requisiti di prevenzione e ripristino di crisi devono essere soddisfatti per il meccanismo di aggiornamento del pacchetto del driver del firmware. Questi requisiti non impediscono soluzioni di prevenzione o ripristino di crisi aggiuntive.
Criteri di preinstallazione
Quando il firmware di sistema esegue l'aggiornamento effettivo, è necessario eseguire una serie di controlli di preinstallazione che devono essere eseguiti. Il firmware di sistema deve eseguire questo controllo per assicurarsi che sia disponibile una potenza sufficiente per completare l'aggiornamento. È inoltre consigliabile eseguire i controlli per ognuno degli aggiornamenti prima che venga applicato l'aggiornamento se sono presenti più aggiornamenti del firmware. L'elenco di elementi da controllare e convalidare viene fornito nella tabella seguente. Tutti i controlli devono essere eseguiti se applicabile. Non esiste alcun ordine specifico per l'esecuzione dei test.
| Tipo di controllo | Description |
|---|---|
| Potenza | Il sistema deve avere almeno il 25% di carica della batteria. L'alimentazione tethered (alimentazione tramite cavo USB e/o alimentazione AC) non è necessaria. In un ambiente di test/laboratorio è accettabile non avere ancora una batteria ancora in grado di consentire gli aggiornamenti del firmware fino a quando viene fornita l'alimentazione con tethered. Tuttavia, una differenziazione deve essere effettuata tra una batteria non carica e nessuna batteria presente. |
| Sicurezza | Verificare che il payload della capsula di aggiornamento sia firmato correttamente. Verificare che tutti i file EFI basati su PE nel payload siano firmati correttamente con un certificato EFI appropriato |
| Integrità | Eseguire un controllo di integrità sul payload dell'aggiornamento del firmware. |
| Versione | Verificare che il firmware applicato non esegue il downgrade del firmware corrente, installato oltre il valore LowestSupportedFirmwareVersion. |
| Archiviazione | I controlli seguenti vengono eseguiti in base all'hardware del sistema C'è spazio sufficiente per i backup del firmware corrente che verrà sostituito C'è spazio sufficiente nel dispositivo per ospitare il nuovo firmware. |
Qualsiasi errore deve causare un codice di errore ultimo tentativo appropriato. Per altre informazioni, vedere le informazioni sul codice di errore last tentativo nella definizione della tabella ESRT e lo stato di aggiornamento del firmware.
Se vengono applicati più aggiornamenti e alcuni passano i controlli di preinstallazione e altri non, il firmware della piattaforma può procedere con l'aggiornamento del firmware per le risorse che hanno passato i controlli di preinstallazione. Tuttavia, qualsiasi risorsa che non ha superato il controllo di preinstallazione non deve essere aggiornata.
Criteri di post-installazione
Dopo l'installazione del firmware (dispositivo o sistema), è necessario verificare che la nuova immagine del firmware aggiornata sia quella prevista. Questo è ridurre al minimo i rischi di eventuali danneggiamenti introdotti durante il processo di aggiornamento effettivo (ad esempio bit in flash ROM, rumore su un bus durante l'aggiornamento e così via).
Il processo di aggiornamento deve verificare che il firmware aggiornato superi i controlli di integrità. Se ha esito negativo, deve essere ripristinato eseguendo il rollback all'ultima versione valida nota del firmware.
Qualsiasi errore deve causare un codice di errore ultimo tentativo appropriato. Per altre informazioni, vedere le informazioni sul codice di errore last tentativo nella definizione della tabella ESRT e lo stato di aggiornamento del firmware.
Ripristino da errori di installazione e avvio
Per impedire a un sistema di raggiungere uno stato non avviabile, il meccanismo di aggiornamento del firmware deve soddisfare i requisiti seguenti nei casi in cui gli aggiornamenti del firmware non riescono a installare o in casi in cui il sistema non riesce a eseguire correttamente l'avvio.
Nelle sezioni seguenti viene usato il termine "commit" per descrivere il firmware. Una volta eseguito il commit del firmware, il firmware viene considerato completamente installato e non verrà eseguito automaticamente il rollback dal firmware a causa di un errore di avvio e così via. Il firmware "Uncom commit" descrive il firmware parzialmente aggiornato e può potenzialmente essere eseguito il rollback in una versione precedente nei casi in cui l'aggiornamento del firmware non può essere completato o un errore viene rilevato dal firmware di aggiornamento( ad esempio, controllo CRC non valido nell'aggiornamento. Se il firmware viene eseguito il commit è qualcosa che il firmware deve tenere traccia internamente e non viene acquisito come parte di ESRT.
Aggiornamento del firmware non riuscito
Se non è possibile installare un singolo sistema o un firmware del dispositivo o è stato installato in modo errato (ad esempio, a causa di un certo tipo di danneggiamento o di una perdita di energia durante l'installazione dell'aggiornamento), l'aggiornamento può essere riprovato fino a un totale di tre (3) tentativi, incluso il primo tentativo. Se i tentativi aggiuntivi verranno eseguiti dal firmware, il sistema non deve avviare windows tra uno dei tentativi. Se tutti i tentativi hanno esito negativo, il firmware di aggiornamento deve eliminare l'aggiornamento. Se l'aggiornamento è stato applicato parzialmente, il firmware deve eseguire il rollback alla versione precedente. Il firmware deve eseguire il rollback alla versione precedente senza alcuna interazione dell'utente. L'errore di aggiornamento non influisce sugli altri aggiornamenti in sospeso; Gli aggiornamenti del firmware in sospeso devono essere tentati.
Dopo aver elaborato tutti gli aggiornamenti, UEFI riprenderà l'avvio di Windows. Il firmware UEFI deve verificare che tutti gli aggiornamenti del firmware non inviati siano stati installati correttamente per attenuare i problemi a causa della perdita di energia (UEFI non dovrebbe mai tentare di avviare Windows con firmware parzialmente scritto).
Le possibili cause dell'errore di installazione includono, ma non sono limitate ai problemi seguenti:
| Causa dell'errore di installazione | Codice di errore |
|---|---|
| Risorse insufficienti | STATUS_INSUFFICIENT_RESOURCES |
| Perdita di energia | STATUS_INSUFFICIENT_POWER |
| Errore hardware | STATUS_POWER_STATE_INVALID |
L'aggiornamento del firmware ha esito positivo, ma Windows non riesce ad avviare
Il firmware UEFI non è responsabile del rollback del firmware aggiornato dopo il commit. La logica di failover esistente in Windows invierà l'utente finale all'ambiente di ripristino di Windows (WinRE) dopo due tentativi di avvio non riusciti. WinRE potrebbe o non essere stato avviato correttamente. L'utente finale deve eseguire un passaggio di ripristino manuale per ripristinare il proprio sistema o dovrà restituire il dispositivo al rivenditore/produttore.
Le possibili cause per questa classe di errore includono, ma non sono limitate a:
Firmware incompatibile con i driver del sistema operativo.
Firmware incompatibile con i componenti del sistema operativo.
Se un fornitore di hardware decide di implementare una logica aggiuntiva per determinare se Windows è stato avviato correttamente, è accettabile. Come accennato in precedenza, l'aspettativa è che la copertura dei test di aggiornamento del firmware da parte dell'autore del firmware impedisce la maggior parte delle crisi risultanti dal firmware incompatibile.
Articoli correlati
Creazione di un pacchetto di driver di aggiornamento
Elaborazione degli aggiornamenti