efi/preinstall: reordered some preinstall check actions

[ernestl]

Reordered some error-kinds actions according in accordance with prioritization guideline and use new helper to insert ActionProceed in accordance to the guideline.

This proposal is a result of discussions around action order that happened during review of Using the Snapd Error Kinds and Actions APIs.

It was also suggested that we do not need manual actions at all, given the current manual actions all have automatic PPI based counterparts, however I though to keep them in place for the moment while its still early days, so that we have an additional path to achieve actions.

Also corrected a few spelling mistakes.

[Copilot]

Pull request overview

This PR reorders action sequences in the preinstall check error handling system to prioritize automatic PPI-based actions over manual firmware settings actions. The PR also corrects multiple spelling and grammatical errors throughout the codebase.

Key changes:

• Automatic TPM actions (via PPI) are now listed before manual reboot-to-firmware-settings actions
• Added documentation explaining the rationale for action ordering
• Fixed numerous spelling errors in comments and error messages

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated no comments.

File	Description
efi/preinstall/errors.go	Corrected spelling errors in comments and error messages throughout the file
efi/preinstall/checks_context.go	Reordered action sequences to prioritize automatic actions and added documentation explaining the ordering rationale
efi/preinstall/actions.go	Fixed typos in action constant documentation

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[chrisccoulson]

I think this looks ok to me, but I am a bit confused about the user experience. Whilst I understand how ordering the returned errors will be presented (that's something I'm going to work on before Christmas), I'm still a bit unsure how this will be presented - ie, is the intention to only present the first action, and how are the others presented if there is more than one?

[ernestl]

I think this looks ok to me, but I am a bit confused about the user experience. Whilst I understand how ordering the returned errors will be presented (that's something I'm going to work on before Christmas), I'm still a bit unsure how this will be presented - ie, is the intention to only present the first action, and how are the others presented if there is more than one?

Hi @chrisccoulson, thanks for having a look. The basic UX was captured here: Using the Snapd Error Kinds and Actions APIs. (Requires your review).

• The installer handles a single error at a time, from the top down.
• For each error, it finds the associated actions (explicitly provided by secboot via snapd API or implicit as required for some special cases). Here the order of the actions as provided by secboot matters, and the installer will display the list of actions as options in that order. The user will pick the action they prefer from the list and press a button to kick it off.

[ZeyadYasser]

LGTM, Thank you!