x86_64_v2: OVMF ships x86-64-v3 code (noarch, not rebuilt) — no UEFI guest can boot #1

New Issue

Closed

opened 2026-08-10 07:28:59 +00:00 by kyamaguchi · 6 comments

kyamaguchi commented 2026-08-10 07:28:59 +00:00

Copy Link

AlmaLinux 10's edk2-ovmf is a noarch package, so it is not rebuilt for the
x86_64_v2 variant — the x86_64_v2 repositories serve the same binary as the
standard x86_64 ones. That binary contains BMI1 instructions, so on a CPU that
only implements x86-64-v2 the firmware triple-faults immediately after SEC and the
guest never boots.

The x86_64_v2 variant exists to support pre-v3 CPUs, but its UEFI firmware does not
run on them, which makes UEFI virtualization unusable on such hosts.

ipxe-roms-qemu has the same problem for the same reason (also noarch); details
at the end. The two compound: fixing only edk2-ovmf still leaves every libvirt guest
hanging, because libvirt always attaches a NIC and OVMF always loads its option ROM.

The failure is silent — nothing on the guest serial console, nothing in dmesg, no
SELinux AVC. The VNC console just shows Guest has not initialized the display (yet)
while the vCPU spins at 100%.

Affected environment

• AlmaLinux 10.2, x86_64_v2 variant (repos are ?arch=x86_64_v2)
• edk2-ovmf-20251114-5.el10_2.2.noarch
• qemu-kvm-18:10.1.0-16.el10_2.2.alma.1.x86_64_v2, libvirt 11.10.0
• CPU: Intel Celeron J4125 (Goldmont Plus). No avx, avx2, bmi1, bmi2,
  abm/lzcnt, fma, f16c. ld.so --help reports x86-64-v2 (supported) as the
  highest level.

Any x86-64-v2-only CPU should reproduce (Goldmont / Goldmont Plus / Silvermont based
Atom, Celeron and Pentium Silver; early Nehalem/Westmere-era parts, etc.).

Steps to reproduce — no v2-only hardware required

TCG lets you subtract CPU features, so this reproduces on any machine:

cp /usr/share/edk2/ovmf/OVMF_VARS.fd /tmp/vars.fd
qemu-kvm -nodefaults -machine q35,smm=off -m 1024 -display none \
  -accel tcg -cpu max,avx=off,avx2=off,bmi1=off,bmi2=off,abm=off,fma=off,f16c=off \
  -drive if=pflash,format=raw,readonly=on,file=/usr/share/edk2/ovmf/OVMF_CODE.fd \
  -drive if=pflash,format=raw,file=/tmp/vars.fd \
  -debugcon file:/tmp/ovmf.log -global isa-debugcon.iobase=0x402

/tmp/ovmf.log fills with nothing but the SEC entry banner, repeated forever:

SecCoreStartupWithStack(0xFFFCC000, 0x820000)
SecCoreStartupWithStack(0xFFFCC000, 0x820000)
...            (32170 iterations in a 40 s run)

Remove bmi1=off and the same command reaches the UEFI boot manager normally.
bmi1=off alone is sufficient to reproduce; bmi2=off or abm=off alone are not.

Evidence

Firmware / accelerator matrix, same host, same disk:

Firmware	Accel / CPU	Result
edk2-ovmf el10_2.2	KVM, -cpu host (J4125)	SEC reset loop
edk2-ovmf el10_2.2	KVM, -cpu Nehalem / host-model	SEC reset loop
edk2-ovmf el10_2.2	TCG, -cpu max	boots
edk2-ovmf el10_2.2	TCG, -cpu max,bmi1=off	SEC reset loop
edk2-ovmf from el9 (20241117-8.el9)	KVM, -cpu host (J4125)	boots
SeaBIOS (seabios-bin)	KVM, -cpu host (J4125)	boots — KVM itself is fine

The x86_64_v2 repository ships the identical file as the standard x86_64
repository, confirming that no separate v2 build exists:

2981261a5991538ef2c9026a85aae2806fcd59712f76d45fbf7699a8208d1966  OVMF_CODE.fd  (x86_64_v2 repo)
2981261a5991538ef2c9026a85aae2806fcd59712f76d45fbf7699a8208d1966  OVMF_CODE.fd  (x86_64 repo)

Root cause

edk2.spec does export the distro flags:

export EXTRA_OPTFLAGS="%{optflags}"

but EXTRA_OPTFLAGS is only consumed by BaseTools/Source/C/Makefiles/header.makefile,
i.e. the host build tools. The firmware itself is compiled with EDK2's own flag set
(tools_def.template), which contains no -march. An actual firmware compile line
from the build log:

gcc -g -Os -fshort-wchar -fno-builtin -fno-strict-aliasing -Wall -Werror \
    -include AutoGen.h -fno-common -fstack-protector -ffunction-sections \
    -fdata-sections -m64 "-DEFIAPI=__attribute__((ms_abi))" \
    -maccumulate-outgoing-args -mno-red-zone -mcmodel=small -fpie \
    -flto -mno-mmx -mno-sse ...

So the compiler's built-in default decides the ISA baseline of the shipped binary,
and on a RHEL-10-baseline builder that default is x86-64-v3.

Note that EDK2 does disable SIMD explicitly (-mno-mmx -mno-sse), because firmware
cannot rely on FPU/SIMD state — but nothing guards against general-purpose ISA
extensions such as BMI1, which the compiler emits freely whenever the default
-march allows it. That is exactly the gap here.

Combined with BuildArch: noarch on the firmware subpackage, the result is a package
labelled architecture-independent whose payload is x86_64 machine code built for
whatever the builder's compiler defaulted to.

A plain rebuild fixes it — no spec or source change needed

Rebuilding the unmodified SRPM on an x86_64_v2 AlmaLinux 10 host is sufficient,
because that host's GCC defaults to -march=x86-64-v2:

$ gcc -Q --help=target | grep -- '-march='
  -march=                     x86-64-v2

dnf download --source --enablerepo=appstream-source edk2-ovmf
dnf builddep -y edk2-20251114-5.el10_2.2.src.rpm
rpmbuild --rebuild edk2-20251114-5.el10_2.2.src.rpm

Result — a different binary that boots on the v2-only CPU under KVM:

stock (v3): 2981261a5991538ef2c9026a85aae2806fcd59712f76d45fbf7699a8208d1966
local (v2): 42a534960cda4f02082eb378b7def35634133e7fb241d167748f411d74cebfdd

Suggested fix

1. Short term — rebuild edk2 on the x86_64_v2 builders and ship that binary in
   the x86_64_v2 repositories, even though the subpackage is noarch.
2. Longer term / upstream — pin the ISA baseline explicitly in the spec (e.g.
   -march=x86-64 or -march=x86-64-v2) instead of inheriting the builder's compiler
   default. A firmware image shipped as noarch should not silently depend on which
   machine built it.
3. Audit — any other noarch package carrying compiled x86_64 payloads is suspect.
   seabios-bin / seavgabios-bin appeared to work in our testing, but the whole class
   should be checked.

Same problem in ipxe-roms-qemu

ipxe-roms-qemu-20240119-5.gitde8a0821.el10.noarch ships efi-virtio.rom (the iPXE EFI
driver) with the same defect. ipxe.spec does not pass %{optflags} at all — it just
runs make %{?_smp_mflags} NO_WERROR=1 V=1 GITVERSION=... — so iPXE's own flags plus the
compiler default apply, and the subpackage is noarch too.

With working firmware but the stock ROM, OVMF faults while loading the option ROM of a
virtio-net device (1af4:1000):

!!!! X64 Exception Type - 06(#UD - Invalid Opcode)  CPU Apic ID - 00000000 !!!!
RIP  - 000000003EA1856E, CS  - 0000000000000038, RFLAGS - 0000000000010246
...
!!!! Find image based on IP(0x3EA1856E) 1af41000.efidrv
     (ImageBase=000000003E9F2000, EntryPoint=000000003E9F9B6E) !!!!

The vCPU then spins at a fixed RIP (CpuDeadLoop()), which is why the guest looks
"hung" rather than "crashed". This is easy to mistake for a libvirt bug: bare qemu-kvm
without a NIC boots fine, while every libvirt guest hangs.

A plain rpmbuild --rebuild of the unmodified ipxe SRPM on a v2 host fixes it too:

stock (v3): 0d846f8f53ac7911f854b4898a723c87f2d3daa408be1317d857d1764d5c3a1f  efi-virtio.rom
local (v2): e7195b6fe12fa9c6e17b3a88d023da34c2ef9b1b676d27ea80b79f284aafa821  efi-virtio.rom

romfile=	Result (same OVMF build, v2-only CPU, everything else identical)
stock efi-virtio.rom	#UD inside 1af41000.efidrv, then CpuDeadLoop()
locally rebuilt efi-virtio.rom	[Bds] Entry... → >>Start PXE over IPv4. — iPXE runs normally

I am happy to file that as a separate issue against rpms/ipxe if you prefer them
tracked separately.

Workarounds for users on v2-only hardware

• Rebuild both packages locally as shown above, or
• Extract OVMF_CODE.fd / OVMF_VARS.fd from the EL9 edk2-ovmf package and point the
  domain at them, and
• Disable the NIC option ROM in the guest (<rom enabled='no'/>, i.e. romfile=""),
  which is harmless unless PXE/HTTP boot is needed.

AlmaLinux 10's `edk2-ovmf` is a `noarch` package, so it is **not rebuilt for the `x86_64_v2` variant** — the `x86_64_v2` repositories serve the same binary as the standard `x86_64` ones. That binary contains **BMI1 instructions**, so on a CPU that only implements `x86-64-v2` the firmware triple-faults immediately after SEC and the guest never boots. The `x86_64_v2` variant exists to support pre-v3 CPUs, but its UEFI firmware does not run on them, which makes UEFI virtualization unusable on such hosts. `ipxe-roms-qemu` has the **same problem for the same reason** (also `noarch`); details at the end. The two compound: fixing only `edk2-ovmf` still leaves every libvirt guest hanging, because libvirt always attaches a NIC and OVMF always loads its option ROM. The failure is silent — nothing on the guest serial console, nothing in `dmesg`, no SELinux AVC. The VNC console just shows `Guest has not initialized the display (yet)` while the vCPU spins at 100%. ### Affected environment - AlmaLinux 10.2, **`x86_64_v2` variant** (repos are `?arch=x86_64_v2`) - `edk2-ovmf-20251114-5.el10_2.2.noarch` - `qemu-kvm-18:10.1.0-16.el10_2.2.alma.1.x86_64_v2`, `libvirt 11.10.0` - CPU: Intel Celeron J4125 (Goldmont Plus). No `avx`, `avx2`, `bmi1`, `bmi2`, `abm`/`lzcnt`, `fma`, `f16c`. `ld.so --help` reports `x86-64-v2 (supported)` as the highest level. Any `x86-64-v2`-only CPU should reproduce (Goldmont / Goldmont Plus / Silvermont based Atom, Celeron and Pentium Silver; early Nehalem/Westmere-era parts, etc.). ### Steps to reproduce — no v2-only hardware required TCG lets you subtract CPU features, so this reproduces on any machine: ```sh cp /usr/share/edk2/ovmf/OVMF_VARS.fd /tmp/vars.fd qemu-kvm -nodefaults -machine q35,smm=off -m 1024 -display none \ -accel tcg -cpu max,avx=off,avx2=off,bmi1=off,bmi2=off,abm=off,fma=off,f16c=off \ -drive if=pflash,format=raw,readonly=on,file=/usr/share/edk2/ovmf/OVMF_CODE.fd \ -drive if=pflash,format=raw,file=/tmp/vars.fd \ -debugcon file:/tmp/ovmf.log -global isa-debugcon.iobase=0x402 ``` `/tmp/ovmf.log` fills with nothing but the SEC entry banner, repeated forever: ``` SecCoreStartupWithStack(0xFFFCC000, 0x820000) SecCoreStartupWithStack(0xFFFCC000, 0x820000) ... (32170 iterations in a 40 s run) ``` Remove `bmi1=off` and the same command reaches the UEFI boot manager normally. **`bmi1=off` alone is sufficient to reproduce**; `bmi2=off` or `abm=off` alone are not. ### Evidence Firmware / accelerator matrix, same host, same disk: | Firmware | Accel / CPU | Result | |---|---|---| | `edk2-ovmf` el10_2.2 | KVM, `-cpu host` (J4125) | SEC reset loop | | `edk2-ovmf` el10_2.2 | KVM, `-cpu Nehalem` / `host-model` | SEC reset loop | | `edk2-ovmf` el10_2.2 | TCG, `-cpu max` | boots | | `edk2-ovmf` el10_2.2 | TCG, `-cpu max,bmi1=off` | SEC reset loop | | `edk2-ovmf` **from el9** (`20241117-8.el9`) | KVM, `-cpu host` (J4125) | boots | | SeaBIOS (`seabios-bin`) | KVM, `-cpu host` (J4125) | boots — KVM itself is fine | The `x86_64_v2` repository ships the *identical file* as the standard `x86_64` repository, confirming that no separate v2 build exists: ``` 2981261a5991538ef2c9026a85aae2806fcd59712f76d45fbf7699a8208d1966 OVMF_CODE.fd (x86_64_v2 repo) 2981261a5991538ef2c9026a85aae2806fcd59712f76d45fbf7699a8208d1966 OVMF_CODE.fd (x86_64 repo) ``` ### Root cause `edk2.spec` does export the distro flags: ```spec export EXTRA_OPTFLAGS="%{optflags}" ``` but `EXTRA_OPTFLAGS` is only consumed by `BaseTools/Source/C/Makefiles/header.makefile`, i.e. the **host build tools**. The firmware itself is compiled with EDK2's own flag set (`tools_def.template`), which contains **no `-march`**. An actual firmware compile line from the build log: ``` gcc -g -Os -fshort-wchar -fno-builtin -fno-strict-aliasing -Wall -Werror \ -include AutoGen.h -fno-common -fstack-protector -ffunction-sections \ -fdata-sections -m64 "-DEFIAPI=__attribute__((ms_abi))" \ -maccumulate-outgoing-args -mno-red-zone -mcmodel=small -fpie \ -flto -mno-mmx -mno-sse ... ``` So **the compiler's built-in default decides the ISA baseline of the shipped binary**, and on a RHEL-10-baseline builder that default is `x86-64-v3`. Note that EDK2 *does* disable SIMD explicitly (`-mno-mmx -mno-sse`), because firmware cannot rely on FPU/SIMD state — but nothing guards against **general-purpose ISA extensions such as BMI1**, which the compiler emits freely whenever the default `-march` allows it. That is exactly the gap here. Combined with `BuildArch: noarch` on the firmware subpackage, the result is a package labelled architecture-independent whose payload is x86_64 machine code built for whatever the builder's compiler defaulted to. ### A plain rebuild fixes it — no spec or source change needed Rebuilding the **unmodified** SRPM on an `x86_64_v2` AlmaLinux 10 host is sufficient, because that host's GCC defaults to `-march=x86-64-v2`: ``` $ gcc -Q --help=target | grep -- '-march=' -march= x86-64-v2 ``` ```sh dnf download --source --enablerepo=appstream-source edk2-ovmf dnf builddep -y edk2-20251114-5.el10_2.2.src.rpm rpmbuild --rebuild edk2-20251114-5.el10_2.2.src.rpm ``` Result — a different binary that boots on the v2-only CPU under KVM: ``` stock (v3): 2981261a5991538ef2c9026a85aae2806fcd59712f76d45fbf7699a8208d1966 local (v2): 42a534960cda4f02082eb378b7def35634133e7fb241d167748f411d74cebfdd ``` ### Suggested fix 1. **Short term** — rebuild `edk2` on the `x86_64_v2` builders and ship that binary in the `x86_64_v2` repositories, even though the subpackage is `noarch`. 2. **Longer term / upstream** — pin the ISA baseline explicitly in the spec (e.g. `-march=x86-64` or `-march=x86-64-v2`) instead of inheriting the builder's compiler default. A firmware image shipped as `noarch` should not silently depend on which machine built it. 3. **Audit** — any other `noarch` package carrying compiled x86_64 payloads is suspect. `seabios-bin` / `seavgabios-bin` appeared to work in our testing, but the whole class should be checked. ### Same problem in `ipxe-roms-qemu` `ipxe-roms-qemu-20240119-5.gitde8a0821.el10.noarch` ships `efi-virtio.rom` (the iPXE EFI driver) with the same defect. `ipxe.spec` does not pass `%{optflags}` at all — it just runs `make %{?_smp_mflags} NO_WERROR=1 V=1 GITVERSION=...` — so iPXE's own flags plus the compiler default apply, and the subpackage is `noarch` too. With working firmware but the stock ROM, OVMF faults while loading the option ROM of a virtio-net device (`1af4:1000`): ``` !!!! X64 Exception Type - 06(#UD - Invalid Opcode) CPU Apic ID - 00000000 !!!! RIP - 000000003EA1856E, CS - 0000000000000038, RFLAGS - 0000000000010246 ... !!!! Find image based on IP(0x3EA1856E) 1af41000.efidrv (ImageBase=000000003E9F2000, EntryPoint=000000003E9F9B6E) !!!! ``` The vCPU then spins at a fixed `RIP` (`CpuDeadLoop()`), which is why the guest looks "hung" rather than "crashed". This is easy to mistake for a libvirt bug: bare `qemu-kvm` without a NIC boots fine, while **every** libvirt guest hangs. A plain `rpmbuild --rebuild` of the unmodified `ipxe` SRPM on a v2 host fixes it too: ``` stock (v3): 0d846f8f53ac7911f854b4898a723c87f2d3daa408be1317d857d1764d5c3a1f efi-virtio.rom local (v2): e7195b6fe12fa9c6e17b3a88d023da34c2ef9b1b676d27ea80b79f284aafa821 efi-virtio.rom ``` | `romfile=` | Result (same OVMF build, v2-only CPU, everything else identical) | |---|---| | stock `efi-virtio.rom` | `#UD` inside `1af41000.efidrv`, then `CpuDeadLoop()` | | locally rebuilt `efi-virtio.rom` | `[Bds] Entry...` → `>>Start PXE over IPv4.` — iPXE runs normally | I am happy to file that as a separate issue against `rpms/ipxe` if you prefer them tracked separately. ### Workarounds for users on v2-only hardware - Rebuild both packages locally as shown above, or - Extract `OVMF_CODE.fd` / `OVMF_VARS.fd` from the EL9 `edk2-ovmf` package and point the domain at them, and - Disable the NIC option ROM in the guest (`<rom enabled='no'/>`, i.e. `romfile=""`), which is harmless unless PXE/HTTP boot is needed.

eabdullin commented 2026-08-12 14:29:06 +00:00

Owner

Copy Link

Hi.
Could you please check if it helps you?
edk2 - https://build.almalinux.org/build/74889
ipxe - https://build.almalinux.org/build/75251

You can add it as repo to your system

[AlmaLinux-10-x86_64_v2-74889-br]
baseurl = https://build.almalinux.org/pulp/content/builds/AlmaLinux-10-x86_64_v2-74889-br/
enabled = 1
name = AlmaLinux-10-x86_64_v2-74889-br

[AlmaLinux-10-x86_64_v2-75251-br]
baseurl = https://build.almalinux.org/pulp/content/builds/AlmaLinux-10-x86_64_v2-75251-br/
enabled = 1
name = AlmaLinux-10-x86_64_v2-75251-br

Hi. Could you please check if it helps you? edk2 - [https://build.almalinux.org/build/74889](https://build.almalinux.org/build/74889) ipxe - [https://build.almalinux.org/build/75251](https://build.almalinux.org/build/75251) You can add it as repo to your system ``` [AlmaLinux-10-x86_64_v2-74889-br] baseurl = https://build.almalinux.org/pulp/content/builds/AlmaLinux-10-x86_64_v2-74889-br/ enabled = 1 name = AlmaLinux-10-x86_64_v2-74889-br [AlmaLinux-10-x86_64_v2-75251-br] baseurl = https://build.almalinux.org/pulp/content/builds/AlmaLinux-10-x86_64_v2-75251-br/ enabled = 1 name = AlmaLinux-10-x86_64_v2-75251-br ```

eabdullin self-assigned this 2026-08-12 14:29:35 +00:00

kyamaguchi commented 2026-08-15 14:34:48 +00:00

Author

Copy Link

Sorry for the late reply — I only noticed your comment today, three days after you posted it.

Thank you for turning both packages around so quickly, and for pinning the baseline in the build flags rather than working around it downstream.

I tried to look at the repositories you pointed me to, but the baseurl seems to return 502 at the moment. dnf cannot fetch the metadata:

# dnf search edk2
AlmaLinux-10-x86_64_v2-74889-br                                                          155  B/s | 157  B     00:01
Errors during downloading metadata for repository 'AlmaLinux-10-x86_64_v2-74889-br':
  - Status code: 502 for https://build.almalinux.org/pulp/content/builds/AlmaLinux-10-x86_64_v2-74889-br/repodata/repomd.xml (IP: 2600:1f18:70b1:ad02:7eeb:3cf9:e691:b21a)
Error: Failed to download metadata for repo 'AlmaLinux-10-x86_64_v2-74889-br': Cannot download metadata for repo 'AlmaLinux-10-x86_64_v2-74889-br': Cannot download repomd.xml: Cannot download repodata/repomd.xml: All mirrors were tried

The same happens for the 75251 repository. Is this a temporary outage, or should I be fetching the packages from somewhere else?

Once the packages are downloadable I will find some time to try them on the affected machine (a Celeron J4125, x86-64-v2) and report back.

Sorry for the late reply — I only noticed your comment today, three days after you posted it. Thank you for turning both packages around so quickly, and for pinning the baseline in the build flags rather than working around it downstream. I tried to look at the repositories you pointed me to, but the baseurl seems to return 502 at the moment. `dnf` cannot fetch the metadata: ``` # dnf search edk2 AlmaLinux-10-x86_64_v2-74889-br 155 B/s | 157 B 00:01 Errors during downloading metadata for repository 'AlmaLinux-10-x86_64_v2-74889-br': - Status code: 502 for https://build.almalinux.org/pulp/content/builds/AlmaLinux-10-x86_64_v2-74889-br/repodata/repomd.xml (IP: 2600:1f18:70b1:ad02:7eeb:3cf9:e691:b21a) Error: Failed to download metadata for repo 'AlmaLinux-10-x86_64_v2-74889-br': Cannot download metadata for repo 'AlmaLinux-10-x86_64_v2-74889-br': Cannot download repomd.xml: Cannot download repodata/repomd.xml: All mirrors were tried ``` The same happens for the 75251 repository. Is this a temporary outage, or should I be fetching the packages from somewhere else? Once the packages are downloadable I will find some time to try them on the affected machine (a Celeron J4125, x86-64-v2) and report back.

eabdullin commented 2026-08-17 09:48:57 +00:00

Owner

Copy Link

Sorry for the late reply — I only noticed your comment today, three days after you posted it.

Thank you for turning both packages around so quickly, and for pinning the baseline in the build flags rather than working around it downstream.

I tried to look at the repositories you pointed me to, but the baseurl seems to return 502 at the moment. dnf cannot fetch the metadata:

# dnf search edk2
AlmaLinux-10-x86_64_v2-74889-br                                                          155  B/s | 157  B     00:01
Errors during downloading metadata for repository 'AlmaLinux-10-x86_64_v2-74889-br':
  - Status code: 502 for https://build.almalinux.org/pulp/content/builds/AlmaLinux-10-x86_64_v2-74889-br/repodata/repomd.xml (IP: 2600:1f18:70b1:ad02:7eeb:3cf9:e691:b21a)
Error: Failed to download metadata for repo 'AlmaLinux-10-x86_64_v2-74889-br': Cannot download metadata for repo 'AlmaLinux-10-x86_64_v2-74889-br': Cannot download repomd.xml: Cannot download repodata/repomd.xml: All mirrors were tried

The same happens for the 75251 repository. Is this a temporary outage, or should I be fetching the packages from somewhere else?

Once the packages are downloadable I will find some time to try them on the affected machine (a Celeron J4125, x86-64-v2) and report back.

Could you please check it now? We had an issue with our build system

> Sorry for the late reply — I only noticed your comment today, three days after you posted it. > > Thank you for turning both packages around so quickly, and for pinning the baseline in the build flags rather than working around it downstream. > > I tried to look at the repositories you pointed me to, but the baseurl seems to return 502 at the moment. `dnf` cannot fetch the metadata: > > ``` > # dnf search edk2 > AlmaLinux-10-x86_64_v2-74889-br 155 B/s | 157 B 00:01 > Errors during downloading metadata for repository 'AlmaLinux-10-x86_64_v2-74889-br': > - Status code: 502 for https://build.almalinux.org/pulp/content/builds/AlmaLinux-10-x86_64_v2-74889-br/repodata/repomd.xml (IP: 2600:1f18:70b1:ad02:7eeb:3cf9:e691:b21a) > Error: Failed to download metadata for repo 'AlmaLinux-10-x86_64_v2-74889-br': Cannot download metadata for repo 'AlmaLinux-10-x86_64_v2-74889-br': Cannot download repomd.xml: Cannot download repodata/repomd.xml: All mirrors were tried > ``` > > The same happens for the 75251 repository. Is this a temporary outage, or should I be fetching the packages from somewhere else? > > Once the packages are downloadable I will find some time to try them on the affected machine (a Celeron J4125, x86-64-v2) and report back. Could you please check it now? We had an issue with our build system

kyamaguchi commented 2026-08-17 14:45:54 +00:00

Author

Copy Link

Thank you for getting the repositories back up. Both test repos are reachable again, so I tried the
builds right away on the affected hardware. Both packages are confirmed fixed.

Test setup

Real hardware, no CPU feature masking — an Intel Celeron J4125 (Gemini Lake), which has no BMI1:

/usr/libexec/qemu-kvm -accel kvm -cpu host -machine q35 -m 1536 -nographic -no-reboot \
  -drive if=pflash,format=raw,unit=0,readonly=on,file=<OVMF_CODE.fd> \
  -drive if=pflash,format=raw,unit=1,file=<copy of OVMF_VARS.fd> \
  -drive file=haos_ova-18.2.qcow2,format=qcow2,snapshot=on,if=none,id=hd0 \
  -device virtio-blk-pci,drive=hd0 \
  -netdev user,id=n0 -device virtio-net-pci,netdev=n0,romfile=<1af41000.rom>

The guest is a Home Assistant OS image, i.e. an ordinary UEFI guest. Each combination was tested
from rpm2cpio-extracted files, so nothing on the installed system was changed while testing.

Results

#	edk2-ovmf	ipxe-roms-qemu	Result
A	my local v2 rebuild	my local v2 rebuild	guest boots — baseline, confirms the test rig is sound
B	20251114-5.el10_2.2	20240119-5.gitde8a0821.el10	no output at all, QEMU exits immediately (triple fault in SEC)
C	…5.el10_2.2.alma.1	20240119-5.gitde8a0821.el10	#UD, see below
D	…5.el10_2.2.alma.1	…el10.alma.1	guest boots to the login prompt

Case C is the interesting one. With the fixed firmware but the current iPXE ROM, EDK2 now gets far
enough to print its exception dump, and it names the faulting image:

!!!! X64 Exception Type - 06(#UD - Invalid Opcode)  CPU Apic ID - 00000000 !!!!
!!!! Find image based on IP(0x5EA1156E) 1af41000.efidrv (ImageBase=000000005E9EB000, EntryPoint=000000005E9F2B6E) !!!!

So edk2 and ipxe are two independent defects, and your two builds fix them independently.
Fixing only one of them is not enough — that may be worth knowing if anyone else reports this.

Static check

Disassembling the firmware volume and counting v3-only mnemonics, using the current package as a
control:

Binary	BMI1	BMI2	MOVBE
OVMF_CODE.fd — 5.el10_2.2	4	33	3
OVMF_CODE.fd — 5.el10_2.2.alma.1	0	0	0

Same figures for OVMF_CODE.secboot.fd. For ipxe-roms-qemu this method is inconclusive, because
the EFI ROMs embed a compressed payload and the instructions are not visible from outside. That is
why case C above matters: a boot test is the only way to confirm the iPXE side.

In production

I have installed both .alma.1 packages on the affected host and pointed my VM back at the
distro-provided /usr/share/edk2/ovmf/OVMF_CODE.fd. My local rebuilds are now removed entirely,
and the guest has been running normally since. Thank you for turning this around so quickly.

Thank you for getting the repositories back up. Both test repos are reachable again, so I tried the builds right away on the affected hardware. **Both packages are confirmed fixed.** ## Test setup Real hardware, no CPU feature masking — an Intel Celeron J4125 (Gemini Lake), which has no BMI1: ``` /usr/libexec/qemu-kvm -accel kvm -cpu host -machine q35 -m 1536 -nographic -no-reboot \ -drive if=pflash,format=raw,unit=0,readonly=on,file=<OVMF_CODE.fd> \ -drive if=pflash,format=raw,unit=1,file=<copy of OVMF_VARS.fd> \ -drive file=haos_ova-18.2.qcow2,format=qcow2,snapshot=on,if=none,id=hd0 \ -device virtio-blk-pci,drive=hd0 \ -netdev user,id=n0 -device virtio-net-pci,netdev=n0,romfile=<1af41000.rom> ``` The guest is a Home Assistant OS image, i.e. an ordinary UEFI guest. Each combination was tested from `rpm2cpio`-extracted files, so nothing on the installed system was changed while testing. ## Results | # | edk2-ovmf | ipxe-roms-qemu | Result | |---|---|---|---| | A | my local v2 rebuild | my local v2 rebuild | guest boots — baseline, confirms the test rig is sound | | B | `20251114-5.el10_2.2` | `20240119-5.gitde8a0821.el10` | **no output at all, QEMU exits immediately** (triple fault in SEC) | | C | **`…5.el10_2.2.alma.1`** | `20240119-5.gitde8a0821.el10` | **`#UD`, see below** | | D | **`…5.el10_2.2.alma.1`** | **`…el10.alma.1`** | **guest boots to the login prompt** | Case C is the interesting one. With the fixed firmware but the current iPXE ROM, EDK2 now gets far enough to print its exception dump, and it names the faulting image: ``` !!!! X64 Exception Type - 06(#UD - Invalid Opcode) CPU Apic ID - 00000000 !!!! !!!! Find image based on IP(0x5EA1156E) 1af41000.efidrv (ImageBase=000000005E9EB000, EntryPoint=000000005E9F2B6E) !!!! ``` So `edk2` and `ipxe` are two independent defects, and your two builds fix them independently. Fixing only one of them is not enough — that may be worth knowing if anyone else reports this. ## Static check Disassembling the firmware volume and counting v3-only mnemonics, using the current package as a control: | Binary | BMI1 | BMI2 | MOVBE | |---|---|---|---| | `OVMF_CODE.fd` — `5.el10_2.2` | 4 | 33 | 3 | | `OVMF_CODE.fd` — `5.el10_2.2.alma.1` | **0** | **0** | **0** | Same figures for `OVMF_CODE.secboot.fd`. For `ipxe-roms-qemu` this method is inconclusive, because the EFI ROMs embed a compressed payload and the instructions are not visible from outside. That is why case C above matters: a boot test is the only way to confirm the iPXE side. ## In production I have installed both `.alma.1` packages on the affected host and pointed my VM back at the distro-provided `/usr/share/edk2/ovmf/OVMF_CODE.fd`. My local rebuilds are now removed entirely, and the guest has been running normally since. Thank you for turning this around so quickly.

eabdullin commented 2026-08-20 10:03:45 +00:00

Owner

Copy Link

Thank you for confirming that the fix works for you!
I'll close that issue as fixed.
Packages with the fix will be released to the public repos in a week.

Thank you for confirming that the fix works for you! I'll close that issue as fixed. Packages with the fix will be released to the public repos in a week.

eabdullin closed this issue 2026-08-20 10:03:47 +00:00

kyamaguchi commented 2026-08-20 14:19:58 +00:00

Author

Copy Link

Thank you for the quick turnaround on this, and for closing the loop here.

Nothing further from my side: the affected host has been running the .alma.1 builds since the test, and I will pick the packages up from the public repos once they are released.

Thanks again for fixing both edk2-ovmf and ipxe-roms-qemu.

Thank you for the quick turnaround on this, and for closing the loop here. Nothing further from my side: the affected host has been running the .alma.1 builds since the test, and I will pick the packages up from the public repos once they are released. Thanks again for fixing both edk2-ovmf and ipxe-roms-qemu.

Sign in to join this conversation.

No Branch/Tag Specified

Branches Tags

c8

c9-beta

c8s

a10s

c10s

a10

c9s

c10

c10-beta

c9

a9

c8-beta

a8

imports/c9-beta/edk2-20241117-9.el9

changed/a10s/edk2-20260221-7.el10.alma.1

imports/c10s/edk2-20260221-7.el10

changed/a10s/edk2-20260221-6.el10.alma.1

changed/a10/edk2-20251114-5.el10_2.2.alma.1

imports/c10s/edk2-20260221-6.el10

imports/c10/edk2-20251114-5.el10_2.2

imports/c10s/edk2-20260221-5.el10

imports/c8/edk2-20220126gitbb1bba3d77-13.el8_10.10

imports/c10s/edk2-20260221-4.el10

imports/c10s/edk2-20260221-3.el10

imports/c10/edk2-20250523-2.el10_1.2

imports/c10s/edk2-20260221-2.el10

imports/c10-beta/edk2-20251114-5.el10_2

imports/c9-beta/edk2-20241117-8.el9

imports/c10s/edk2-20260221-1.el10

imports/c10s/edk2-20251114-5.el10

imports/c9/edk2-20241117-4.el9_7.3

imports/c10s/edk2-20251114-4.el10

imports/c10s/edk2-20251114-3.el10

imports/c10s/edk2-20251114-2.el10

imports/c10s/edk2-20251114-1.el10

imports/c9/edk2-20241117-4.el9

imports/c10s/edk2-20250822-4.el10

imports/c10s/edk2-20250822-3.el10

imports/c9/edk2-20241117-2.el9_6.1

imports/c10s/edk2-20250822-2.el10

imports/c10s/edk2-20250822-1.el10

imports/c9-beta/edk2-20241117-4.el9

imports/c8/edk2-20220126gitbb1bba3d77-13.el8_10.8

imports/c10/edk2-20241117-2.el10_0.1

imports/c10s/edk2-20250523-2.el10

imports/c10s/edk2-20250523-1.el10

imports/c10s/edk2-20250221-3.el10

imports/c10s/edk2-20250221-2.el10

imports/c10s/edk2-20250221-1.el10

imports/c9-beta/edk2-20241117-2.el9

imports/c10s/edk2-20241117-2.el10

imports/c9/edk2-20240524-6.el9_5.3

imports/c8/edk2-20220126gitbb1bba3d77-13.el8_10.4

imports/c10s/edk2-20241117-1.el10

imports/c10s/edk2-20240524-12.el10

imports/c10-beta/edk2-20240524-8.el10

imports/c9/edk2-20240524-6.el9_5

imports/c10s/edk2-20240524-11.el10

imports/c9/edk2-20231122-6.el9_4.4

imports/c10s/edk2-20240524-10.el10

imports/c10s/edk2-20240524-9.el10

imports/c9-beta/edk2-20240524-5.el9_5

imports/c9-beta/edk2-20240524-5.el9

imports/c10s/edk2-20240524-8.el10

imports/c8/edk2-20220126gitbb1bba3d77-13.el8_10.3

imports/c10s/edk2-20240524-7.el10

imports/c10s/edk2-20240524-6.el10

imports/c9/edk2-20231122-6.el9_4.3

changed/a9/edk2-20231122-6.el9_4.3.alma.1

imports/c10s/edk2-20240524-4.el10

imports/c8/edk2-20220126gitbb1bba3d77-13.el8_10.2

imports/c9/edk2-20231122-6.el9_4.2

changed/a9/edk2-20231122-6.el9_4.2.alma.1

imports/c10s/edk2-20240524-2.el10

imports/c8/edk2-20220126gitbb1bba3d77-13.el8_10

imports/c9/edk2-20231122-6.el9

changed/a8/edk2-20220126gitbb1bba3d77-6.el8_9.6.alma

changed/a9/edk2-20230524-4.el9_3.2.alma

imports/c8/edk2-20220126gitbb1bba3d77-6.el8_9.3

imports/c8/edk2-20220126gitbb1bba3d77-6.el8_9.1

imports/c9/edk2-20230524-4.el9_3

imports/c8-beta/edk2-20220126gitbb1bba3d77-6.el8

imports/c9-beta/edk2-20230524-3.el9

imports/c8/edk2-20220126gitbb1bba3d77-4.el8

imports/c9/edk2-20221207gitfff6d81270b5-9.el9_2

imports/c9-beta/edk2-20221207gitfff6d81270b5-7.el9

imports/c8-beta/edk2-20220126gitbb1bba3d77-4.el8

imports/c8s/edk2-20220126gitbb1bba3d77-4.el8

imports/c9/edk2-20220526git16779ede2d36-3.el9

imports/c8/edk2-20220126gitbb1bba3d77-3.el8

imports/c9-beta/edk2-20220526git16779ede2d36-3.el9

imports/c8-beta/edk2-20220126gitbb1bba3d77-3.el8

imports/c9/edk2-20220126gitbb1bba3d77-3.el9_0.1

imports/c8s/edk2-20220126gitbb1bba3d77-3.el8

imports/c9/edk2-20220126gitbb1bba3d77-3.el9

imports/c8/edk2-20220126gitbb1bba3d77-2.el8

imports/c9-beta/edk2-20220126gitbb1bba3d77-3.el9

imports/c8-beta/edk2-20220126gitbb1bba3d77-1.el8.test

imports/c8s/edk2-20220126gitbb1bba3d77-2.el8

imports/c9-beta/edk2-20220126gitbb1bba3d77-2.el9

imports/c8s/edk2-20220126gitbb1bba3d77-1.el8.test

imports/c9-beta/edk2-20210527gite1999b264f1f-7.el9

imports/c9-beta/edk2-20210527gite1999b264f1f-6.el9

imports/c8/edk2-20210527gite1999b264f1f-3.el8

imports/c8-beta/edk2-20210527gite1999b264f1f-3.el8

imports/c8-beta/edk2-20200602gitca407c7246bf-4.el8

imports/c8-beta/edk2-20200602gitca407c7246bf-2.el8

imports/c8-beta/edk2-20190829git37eef91017ad-4.el8

imports/c8-beta/edk2-20190308git89910a39dcfd-4.el8

imports/c8s/edk2-20210527gite1999b264f1f-3.el8

imports/c8s/edk2-20210527gite1999b264f1f-1.el8

imports/c8s/edk2-20200602gitca407c7246bf-5.el8

imports/c8s/edk2-20200602gitca407c7246bf-4.el8

imports/c8s/edk2-20200602gitca407c7246bf-3.el8

imports/c8/edk2-20200602gitca407c7246bf-4.el8_4.2

imports/c8/edk2-20200602gitca407c7246bf-4.el8_4.1

imports/c8/edk2-20200602gitca407c7246bf-4.el8

imports/c8/edk2-20200602gitca407c7246bf-3.el8

imports/c8/edk2-20190829git37eef91017ad-9.el8

Labels

Clear labels

No items

No Label

Milestone

Clear milestone

No items

No Milestone

Assignees

Clear assignees

No Assignees

eabdullin

2 Participants

Notifications

Subscribe

Due Date

The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: rpms/edk2#1

No description provided.