You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
i think i can't add issues to oxidecomputer/EDK2 because it's a fork rather than a repo in its own right, so filing this here instead.
this is, fundamentally, the misbehavior that is noted in Omicron#5112: a boot device's description changed, its previous entry was removed, a new entry was added, and that new entry was after the EFI shell in boot order. we should make sure the EFI Internal Shell option is close to the last option, which will help keep guests from auto-discovering their way into not booting.
it seems extremely unlikely that someone would want to end up at the EFI shell specifically - in almost every case someone ends up in the EFI shell rather than their expected OS, it comes with a question of, "oh no, what did i break, and can i fix it?". now that users can specify a boot disk, and that boot order takes precedence over existing UEFI boot option variables, it is at least fixable! but it seems like a misbehavior to end up in that situation in the first place. if a user did want to get to the EFI shell, it probably would be through a procedure like booting a guest OS, modifying the UEFI BootOrder variable to move the EFI shell up, and then rebooting. or booting an instance with no disks.
in practice this would probably be some change to EDK2 around where the EFI Internal Shell option is added, but i couldn't figure out an obvious tiny change this morning.
overall this seems like pretty low priority, but nice to have.
The text was updated successfully, but these errors were encountered:
i think i can't add issues to oxidecomputer/EDK2 because it's a fork rather than a repo in its own right, so filing this here instead.
this is, fundamentally, the misbehavior that is noted in Omicron#5112: a boot device's description changed, its previous entry was removed, a new entry was added, and that new entry was after the EFI shell in boot order. we should make sure the
EFI Internal Shell
option is close to the last option, which will help keep guests from auto-discovering their way into not booting.it seems extremely unlikely that someone would want to end up at the EFI shell specifically - in almost every case someone ends up in the EFI shell rather than their expected OS, it comes with a question of, "oh no, what did i break, and can i fix it?". now that users can specify a boot disk, and that boot order takes precedence over existing UEFI boot option variables, it is at least fixable! but it seems like a misbehavior to end up in that situation in the first place. if a user did want to get to the EFI shell, it probably would be through a procedure like booting a guest OS, modifying the UEFI BootOrder variable to move the EFI shell up, and then rebooting. or booting an instance with no disks.
in practice this would probably be some change to EDK2 around where the
EFI Internal Shell
option is added, but i couldn't figure out an obvious tiny change this morning.overall this seems like pretty low priority, but nice to have.
The text was updated successfully, but these errors were encountered: