FIPS/OEM installation compatibility is unclear to the end-user

re Subiquity:
> Messaging should clearly indicate that installing the oem packages will make the environment incompatible with fips/RT kernel/ etc.

I would like to see a more precise list of these incompatibilities, as I am not familiar with them.
Who can provide that information?

The issue arises with any package leveraging the GRUB_FLAVOUR_ORDER cfg. While originally requested by the FIPS team to ensure the env didn't accidentally boot to -generic, it was later implemented by the oem packages to ensure the oem kernel was preferred. The fact that it prefers oem when both are installed is only due to the cfg file names.

Subiquity just offers to install the oem packages if ubuntu-drivers finds a match on the hardware. The issue here is "Hey would you like to install some special hardware enablement drivers?" isn't necessarily indicative that you would no longer be able to install fips. This should more clearly convey what's happening here.

This issue has a capture of the some of the pages I'm talking about:
https://github.com/canonical/subiquity/pull/1196

That is going to be a really hard label to write.
Not in terms of the code change, that's the easy part, how does one explain to end users that some GRUB_FLAVOUR_ORDER kernels are OK and some aren't? GRUB_FLAVOUR_ORDER is not a detail many users want to think about, they just want hardware to work.

If this problem were more limited in scope we could say something like "Third-party drivers should not be installed on systems that will be used for FIPS or the real-time kernel." But as is this is too open-ended - if we phrase this incorrectly it is going to sound like every kernel is a problem.

> "Third-party drivers should not be installed on systems that will be used for FIPS or the real-time kernel."

This may be sufficient. We're already talking about a fairly extreme edge case here. The footprint of hardware that triggers the ubuntu-drivers criteria that also is intended to use FIPS later is already quite small. If we ever add additional packages that leverage GRUB_FLAVOUR_ORDER in the future, we could add information as needed?

The subiquity piece of this is likely the smallest part. The `aggressive` installs of the oem packages in already-configured desktop instances via update-manager is the bigger headache.( i.e. running fips fine, then oem packages `randomly` install, and I lose compliance without being aware.)

https://github.com/canonical/subiquity/pull/1358

We discussed this on the UA team and we believe we can warn the user of the potential problems of enabling FIPS we using a OEM kernel, but we don't think we should block this on the UA side, since users could still be aware of the risk and follow through with the procedure.

However, before we deliver this through UA, we believe we need to sort the GRUB_FLAVOUR_ORDER scenario. Otherwise we will warn the user and even if they want to proceed with FIPS, the will end up in the OEM kernel regardless.

But let us know if you think we should definitely block enabling FIPS on a machine running a OEM kernel.

I'd (personally) be much more on board with a warning vs a hard block as well.

The GRUB_FLAVOUR_ORDER issue was met with some resistance by both the FIPs team and the OEM team. From what I gathered, GRUB_FLAVOUR_ORDER was originally implement for the FIPS kernel, but later leveraged by OEM.

The OEM supersede was preferred by the OEM team, as OEM packages are intended to be temporary (and only for critical functionality issues) until adopted upstream, after which they are intended to be removed (?).

The argument from the FIPs side more leans towards the `forced` OEM installs. This falls outside of the UA client's responsibility though, as it can trigger before or after ua enablement via ubuntu-drivers-common.

I'd agree that we'd want a definitive decision on preferred preference before pulling the trigger on the UA changes though.

Is there a future where we can remove this warning?

The version of Subiquity on Jammy has some differences in the driver screen, so that's done here.
https://github.com/canonical/subiquity/pull/1369

Hi, I'm picking this back up from the pro-client side. I'll likely add a warning message along the lines of "OEM kernel detected. The FIPS kernel won't boot as long as the OEM kernel is installed. Replacing the OEM kernel with the FIPS kernel may result in less support for your hardware. Continue? (y/N)"

But before I do I want to ask: Are you aware of any developments or changes in what the GRUB_FLAVOUR_ORDER is today or what it is supposed to be between these two kernels?