EDK2 prints, to the console, what boot options are being tried and if they've failed. we could adjust it to print that to the QEMU debug port as well, which we could watch for messages about Boot0001 and friends listed in an explicit boot order (if there is one) being tried and failed. that would at least be able to elevate #1181 into something Propolis could error!() about - otherwise the guest's state is a total unknown. as things stand, propolis-server's log really cannot give you much of an idea of if a guest booted "normally" or not. in the future that could become an ireport that makes its way out to some indicator in the console that an instance is probably in a bad state!
the problem here is that input from the QEMU debug port must be considered fully untrusted. guests could emit whatever they want to that port after booting. a bug in EDK2 allowing a crafted guest image to do bad things means we can't really trust anything "before" a guest booted either. this is all only informative and guessing at the guest's possible state, at best, and cannot be considered authoritative at all.
but if we could take a guess that we've tried and failed to boot the user's requested boot options, and instead failed into the UEFI shell, that'd be really helpful!
(this would have helped with the logs in #1181 just a smidge..)
EDK2 prints, to the console, what boot options are being tried and if they've failed. we could adjust it to print that to the QEMU debug port as well, which we could watch for messages about
Boot0001and friends listed in an explicit boot order (if there is one) being tried and failed. that would at least be able to elevate #1181 into something Propolis coulderror!()about - otherwise the guest's state is a total unknown. as things stand,propolis-server's log really cannot give you much of an idea of if a guest booted "normally" or not. in the future that could become an ireport that makes its way out to some indicator in the console that an instance is probably in a bad state!the problem here is that input from the QEMU debug port must be considered fully untrusted. guests could emit whatever they want to that port after booting. a bug in EDK2 allowing a crafted guest image to do bad things means we can't really trust anything "before" a guest booted either. this is all only informative and guessing at the guest's possible state, at best, and cannot be considered authoritative at all.
but if we could take a guess that we've tried and failed to boot the user's requested boot options, and instead failed into the UEFI shell, that'd be really helpful!
(this would have helped with the logs in #1181 just a smidge..)