Package Details: edk2-ovmf-git r29698.6062002bd5-1

Git Clone URL: https://aur.archlinux.org/edk2-git.git (read-only, click to copy)
Package Base: edk2-git
Description: Firmware for Virtual Machines (x86_64, i686)
Upstream URL: https://github.com/tianocore/tianocore.github.io/wiki/OVMF
Licenses: BSD, MIT
Conflicts: ovmf
Provides: ovmf
Replaces: ovmf
Submitter: markzz
Maintainer: None
Last Packager: markzz
Votes: 31
Popularity: 0.000000
First Submitted: 2022-01-12 20:51 (UTC)
Last Updated: 2022-01-12 20:51 (UTC)

Pinned Comments

Latest Comments

1 2 3 4 5 6 .. 13 Next › Last »

Holo commented on 2022-04-22 06:41 (UTC)

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.

AkechiShiro commented on 2022-03-07 04:42 (UTC)

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 ?

ulidtko commented on 2022-01-13 10:16 (UTC)

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.

markzz commented on 2022-01-12 20:40 (UTC)

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. :)

realkstrawn93 commented on 2021-11-05 04:14 (UTC)

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.

ulidtko commented on 2021-05-04 16:16 (UTC)

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.

AbrarSyed commented on 2019-07-12 07:36 (UTC) (edited on 2019-07-12 07:39 (UTC) by AbrarSyed)

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
}

newsboost commented on 2019-06-23 13:44 (UTC) (edited on 2019-06-23 13:52 (UTC) by newsboost)

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...

JuniorJPDJ commented on 2019-01-14 13:26 (UTC)

markzz: thank you very much :)

markzz commented on 2019-01-14 01:16 (UTC)

JuniorJPDJ: Updated to fix this. In the future, if there's an issue with the build like this, please flag the PKGBUILD as out-of-date so that it will be apparent when I log into the AUR interface.