Arch Linux User Repository

It's been years since I used this, but I wanted to make a note.

The OVMF files from (what I recall to be this package) were different than for example edk2-ovmf-fedora-bin and the main version would freeze one me when attempting to do VFIO GPU pass-through.

So if you encounter unusual problems, try swapping the files out for a version from another distro like the fedora one maybe.

I tried making it work but couldn't in the end, but at least the package is more aligned with current versions and I've fixed the cd and patch issues.

Stuck on this:

build.py...
 : error 7000: Failed to execute command
        make tbuild [/home/user/AUR/edk2-git/src/edk2/Build/ArmVirtQemu-AARCH64/RELEASE_GCC5/AARCH64/CryptoPkg/Library/TlsLib/TlsLib]


build.py...
 : error F002: Failed to build module
        /home/user/AUR/edk2-git/src/edk2/CryptoPkg/Library/TlsLib/TlsLib.inf [AARCH64, GCC5, RELEASE]

- Failed -

Anyone willing to pick this up in the future should probably check out the official edk2 package - https://gitlab.archlinux.org/archlinux/packaging/packages/edk2/-/blob/main/PKGBUILD?ref_type=heads

OpenSSL at the moment needs to be downgraded to 3.4.1~, 3.5.0 is not supported at the moment too, I messed that one up in my attempts.

This no longer compiles. Same issue as the comment below by "AkechiShiro". I've tried editing the PKGBUILD file so we cd into "edk2" rather than "edk2-git" but no luck due to patches not being able to apply (I don't think the patch "edk2-git-202102-brotli-1.0.9.patch" is required anymore?).

I've had more success compiling by hand.

Hi,

At the moment, the build fails with this error :

==> Verifying source file signatures with gpg...
    openssl-1.1.1l.tar.gz ... Passed
==> Removing existing $srcdir/ directory...
==> Extracting sources...
  -> Creating working copy of edk2 git repo...
Cloning into 'edk2'...
done.
Updating files: 100% (8323/8323), done.
Switched to a new branch 'makepkg'
  -> Extracting openssl-1.1.1l.tar.gz with bsdtar
  -> Extracting brotli-1.0.9.tar.gz with bsdtar
==> Starting prepare()...
/home/xxxxx/.cache/paru/clone/edk2-git/PKGBUILD: line 75: cd: edk2-git: No such file or directory
==> ERROR: A failure occurred in prepare().
    Aborting...
error: failed to build 'edk2-git-r29698.6062002bd5-1 (edk2-ovmf-git)': 
error: packages failed to build: edk2-git-r29698.6062002bd5-1 (edk2-ovmf-git)

Maybe due to upstream changes ?

Great news, markzz! Looking forward to an updated build.

My rant below boils down to what the package provides. At time of writing, it only provided 2 files, OVMF_CODE.fd and OVMF_VARS.fd.

That isn't super-useful; what would be, is a single merged firmware file OVMF.fd ready to boot into QEMU with no fuzz.

Soon I'll be uploading an edk2-git set of packages that will replace this one. It should address some of the concerns below this comment.

realkstrawn93: This was due to edk2 being incompatible with Arch's version of brotli, which should be fixed in the new pkgbase.

Also, ulidtko, I never cared what every whatever thing on the internet says, you need to use your own brain. I know for a fact that this package worked back when it built properly. :)

Getting the following build failure:

brotli/c/dec/decode.c:2034:14: error: argument 4 of type ‘uint8_t ’ {aka ‘unsigned char ’} declared as a pointer [-Werror=vla-parameter]

My guess is that it's an upstream bug, but it's a showstopper nonetheless.

Can you please fix this so that it produces a single OVMF.fd file? Not (only) a pair of ovmf_{code,vars}_x64.bin like it does now.

Every damn readme, wiki, gist & blogpost says basically "just pass -bios /path/to/OVMF.fd & bob's your uncle, qemu runs uefi". Well. No such thing here.

I guess it's something extremely trivial, prolly just concatenation of two files (in the right order) -- but, all these .fdf & .dsc & obscure build workspaces and whatnot are extremely confusing. I don't need to learn all this to simply test if my usb stick will boot. A single ready-to-use file would help a lot.

For now, I've uninstalled this package and switched to extra/edk2-ovmf instead. It does provide both OVMF_CODE.fd and OVMF_VARS.fd -- but also a single OVMF.fd which Simply Works with Qemu.

Since this conflicts with extra/ovmf, it would be nice if it deposited the files in the same location so that I didn't have to modify my qemu config. A Simple symbolic link could do the trick, or installation to both locations?

package() {
  install -D -m644 "${srcdir}"/edk2/Build/OvmfX64/RELEASE_${_toolchain_opt}/FV/OVMF_CODE.fd "${pkgdir}"/usr/share/ovmf/ovmf_code_x64.bin
  install -D -m644 "${srcdir}"/edk2/Build/OvmfX64/RELEASE_${_toolchain_opt}/FV/OVMF_VARS.fd "${pkgdir}"/usr/share/ovmf/ovmf_vars_x64.bin
  install -D -m644 "${srcdir}"/edk2/OvmfPkg/License.txt "${pkgdir}"/usr/share/licenses/ovmf/License.txt

  # symlink
  mkdir -p "${pkgdir}"/usr/share/ovmf/x64
  ln -s /usr/share/ovmf/ovmf_code_x64.bin "${pkgdir}"/usr/share/ovmf/x64/OVMF_CODE.fd
  ln -s /usr/share/ovmf/ovmf_vars_x64.bin "${pkgdir}"/usr/share/ovmf/x64/OVMF_VARS.fd

  # or install to 2 spots
  install -D -m644 "${srcdir}"/edk2/Build/OvmfX64/RELEASE_${_toolchain_opt}/FV/OVMF_CODE.fd "${pkgdir}"/usr/share/ovmf/x64/OVMF_CODE.fd
  install -D -m644 "${srcdir}"/edk2/Build/OvmfX64/RELEASE_${_toolchain_opt}/FV/OVMF_VARS.fd "${pkgdir}"/usr/share/ovmf/x64/OVMF_VARS.fd
}

Hmm... The upstream URL points to something that says: "Whoops, we can't find that page"... I'm a bit confused about which of these packages to use for my virtual (Windows 10) machine:

aur/edk2-ovmf 20180815-1 (+9 0.01%) (Out-of-date 2019-05-23) 
   EDK2 ovmf firmware from Fedora 29 rpm
aur/ovmf-git 1:r25361.514c55c185-1 (+31 0.00%) (Installed: 1:r25460.83463154af-1)
   Tianocore UEFI firmware for qemu.
extra/ovmf 1:r25737.89910a39dc-1 (1.3 MiB 2.0 MiB) 
   Tianocore UEFI firmware for qemu.

I previously used aur/edk2-ovmf, but now it says out-of-date since about a month ago, so I'm wondering if I should just use ovmf-git and if that's safe (I have the impression that extra/ovmf is too old)...? Anyway, I would have no doubts continuing to use edk2-ovmf, if it wasn't flagged as out-of-date, for the past month...