How to preserve the changes for x86_64-linux?

Development
1

Hello!

I’ve noticed reverts of commits more than once when tests for one of the processor architectures reveal an issue.

(as an example: edk2: 202502 -> 202411 by adamcstephens · Pull Request #386486 · NixOS/nixpkgs · GitHub)

And I’ve repeatedly wondered—is there a way to preserve the changes for x86_64-linux?

I might be wrong, but it seems to me that this is the most commonly used architecture, and it strikes me as odd that due to an issue with upstream code for a platform that the developer might not have even intended to support, other platforms suffer…

1 Like
2

You can write conditionals easily, and we do. Like if stdenv.isx86_64 && stdenv.isLinux then ... but splitting stuff a lot makes maintenance harder.

At a glance upstream’s intention is to support aarch64:

3

edk2 definitely supports aarch64, so this probably isn’t a good example. Reverting was the quickest way to unblock channels but I will revisit this with plans to move it forward again. Since upstream supports both architectures in this case I would prefer not splitting it or adding conditionals. That means x86 “suffers” some in this case.

This question comes up from time to time but I mostly see it from Linux users who don’t want to deal with Darwin. rfcs/rfcs/0046-platform-support-tiers.md at 25c3f524631000b851375e7b96223a56e71cc0e2 · NixOS/rfcs · GitHub covered the support tiers, though is slightly dated. In practice it seems to me that aarch64 Linux (and Darwin) are treated higher than listed there. Even if still at tier 2, aarch64 is actively used in our community and we should strive to keep it working.

4

I understand it
This post was my emotion after I get it again after this revert =)

operation failed: Unable to find 'efi' firmware that is compatible with the current configuration

Traceback (most recent call last):
  File "/nix/store/izgl0w8k3jrdskxzva6ijhxm33fkrj9a-virt-manager-5.0.0/share/virt-manager/virtManager/asyncjob.py", line 71, in cb_wrapper
    callback(asyncjob, *args, **kwargs)
  File "/nix/store/izgl0w8k3jrdskxzva6ijhxm33fkrj9a-virt-manager-5.0.0/share/virt-manager/virtManager/asyncjob.py", line 107, in tmpcb
    callback(*args, **kwargs)
  File "/nix/store/izgl0w8k3jrdskxzva6ijhxm33fkrj9a-virt-manager-5.0.0/share/virt-manager/virtManager/object/libvirtobject.py", line 57, in newfn
    ret = fn(self, *args, **kwargs)
          ^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/nix/store/izgl0w8k3jrdskxzva6ijhxm33fkrj9a-virt-manager-5.0.0/share/virt-manager/virtManager/object/domain.py", line 1384, in startup
    self._backend.create()
  File "/nix/store/lzwh2fpvim4rhxarmd35x68j6jhr27zi-python3.12-libvirt-11.0.0/lib/python3.12/site-packages/libvirt.py", line 1379, in create
    raise libvirtError('virDomainCreate() failed')
libvirt.libvirtError: operation failed: Unable to find 'efi' firmware that is compatible with the current configuration

Now I need to create empty VM and copy-paste xml tags with new paths to replace this

    <loader readonly="yes" secure="yes" type="pflash" format="raw">/nix/store/wkib4zpjcx9c6mlnkd0nvnlpg16fh13s-qemu-host-cpu-only-9.2.0/share/qemu/edk2-x86_64-secure-code.fd</loader>
    <nvram template="/nix/store/wkib4zpjcx9c6mlnkd0nvnlpg16fh13s-qemu-host-cpu-only-9.2.0/share/qemu/edk2-i386-vars.fd" templateFormat="raw" format="raw">/var/lib/libvirt/qemu/nvram/ubuntu24.04-clone_VARS.fd</nvram>

So, I am sorry

5

If you’re hardcoding the store path into your xml file, then you’ll be impacted in more cases than ugprades/downgrades of the edk2 package. Any other dependency in the tree could trigger this store path to change, causing this to break. You should count on it happening.

2 Likes
6

I did nothing with these VM settings, and they started to become broken after some of the libvirt/OVMF/edk2 upgrades. And I thought it was the only way to fix it =)

7

aarch64 is the most commonly used architecture these days no? Most cloud instances are aarch64-linux

8

@mjoerg Hi!
How can I fix it?