Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

OVMF_(VARS|CODE).fd should be split from OVMF package #25854

Closed
clefru opened this issue May 17, 2017 · 0 comments
Closed

OVMF_(VARS|CODE).fd should be split from OVMF package #25854

clefru opened this issue May 17, 2017 · 0 comments
Assignees
@joachifm
Labels
6.topic: closure size The final size of a derivation, including its dependencies

Comments

@clefru
Copy link
Contributor

clefru commented May 17, 2017

In #25397, I introduced support in libvirtd for UEFI VM creation. @volth rightfully remarked that this brings closure-size up too much. Looking into OVMF shows that only 1MB out of the 114MB install size is needed to enable said UEFI VM creation. I think that we should look into splitting out OVMF_(CODE|VARS) from the rest package.
clefru referenced this issue May 17, 2017
@clefru
Introduce virtualisation.libvirtd.qemuOvmf.
df5d588
@joachifm joachifm added the 6.topic: closure size The final size of a derivation, including its dependencies label May 18, 2017
@joachifm joachifm mentioned this issue May 18, 2017
Merged
@joachifm joachifm self-assigned this May 18, 2017
bjornfor pushed a commit to bjornfor/nixpkgs that referenced this issue Jul 14, 2017
@joachifm @bjornfor
OVMF: separate output for ovmf binaries
1436cc4 
OVMF{,CODE,VARS}.fd are now available in a dedicated fd output, greatly
reducing the closure in the common case where only those files are used (a
few MBs versus several hundred MBs for the full OVMF).

Note: it's unclear why `dontPatchELF` is now necessary for the build to
pass (on my end, at any rate) but it doesn't make much sense to run this
fixup anyway,

Note: my reading of xen's INSTALL suggests that --with-system-ovmf should
point directly to the OVMF binary.  As such, the previous invocation was
incorrect (it pointed to the root of the OVMF tree).  In any case, I have
only built xen with `--with-system-ovmf`, I have not tested it.

Fixes NixOS#25854
Closes NixOS#25855

(cherry picked from commit 252dcd6)

[Bjørn: Conflicts in pkgs/applications/virtualization/xen/4.5.nix were
resolved by dropping the changes. In branch release-17.03
.../xen/4.5.nix doesn't use OVMF at all.]
@bjornfor bjornfor mentioned this issue Jul 14, 2017
Merged
8 tasks
adrianpk added a commit to adrianpk/nixpkgs that referenced this issue May 31, 2024
@adrianpk
OVMF: separate output for ovmf binaries
5f76983 
OVMF{,CODE,VARS}.fd are now available in a dedicated fd output, greatly
reducing the closure in the common case where only those files are used (a
few MBs versus several hundred MBs for the full OVMF).

Note: it's unclear why `dontPatchELF` is now necessary for the build to
pass (on my end, at any rate) but it doesn't make much sense to run this
fixup anyway,

Note: my reading of xen's INSTALL suggests that --with-system-ovmf should
point directly to the OVMF binary.  As such, the previous invocation was
incorrect (it pointed to the root of the OVMF tree).  In any case, I have
only built xen with `--with-system-ovmf`, I have not tested it.

Fixes NixOS#25854
Closes NixOS#25855

(cherry picked from commit 252dcd6)

[Bjørn: Conflicts in pkgs/applications/virtualization/xen/4.5.nix were
resolved by dropping the changes. In branch release-17.03
.../xen/4.5.nix doesn't use OVMF at all.]
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@joachifm joachifm

Labels
6.topic: closure size The final size of a derivation, including its dependencies
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@joachifm @clefru