Comment 8 for bug 2004618

Hi Mustafa,

I think the symlink approach is a clever solution that avoids having to touch virtinst. However, I'm not excited about carrying more things in OVMF to resolve it. It seems like a nice solution if we could do it for *just focal*, but once VM XML starts including those symlink paths, we're basically stuck shipping them forever. So I think I prefer the virtinst regex update - unless you see some downsides I'm missing.

If we *do* end up using the symlink solution, I suggest one tweak to it. If we go that way, I think we'd be conceding that subdirectories - not filenames - are the correct way to distinguish new variants in the future. I think it would therefore make sense that we make the new files the "real" files, and use symlinks for the old paths, e.g. /usr/share/OVMF/OVMF_CODE_4M.fd -> ../4M/OVMF_CODE.fd. That should help imply to a future maintainer that these are just for backwards compat, and the directory approach should be used for new variants.

As for jammy - even though the current behavior is not *intended*, it doesn't seem necessarily *wrong*. Users may have grown accustomed to getting a SecureBoot VM by default, and changing that default in an SRU to "correct it" feels wrong, even if it makes jammy more consistent with focal and future releases (assuming we restore upstream-intended behavior there).

I've subscribed ubuntu-server to see if they have any preferences on how we proceed.