Skip to content

Automatically use the default location of the OVMF files on Windows #469

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
Closed
nicholasbishop opened this issue Jul 26, 2022 · 0 comments · Fixed by #474
Closed

Automatically use the default location of the OVMF files on Windows #469

nicholasbishop opened this issue Jul 26, 2022 · 0 comments · Fixed by #474

Comments

@nicholasbishop
Copy link
Member

From #463 (comment):

I did have to copy over the edk2/ovmf files to the uefi-test-runner folder and rename them, on a standard Qemu on Windows install they're located in C:\Program Files\qemu\share\ and named edk2-x86_64-code.fd or edk2-i386-code.fd for x86. There wasn't a corresponding vars.fd file for x86_64, but using the i386 version worked fine.

Following the changes in #463, we can update the OvmfPaths code in xtask/src/qemu.rs to find these files automatically.
@nicholasbishop nicholasbishop mentioned this issue Jul 26, 2022
Merged
nicholasbishop added a commit to nicholasbishop/uefi-rs that referenced this issue Jul 30, 2022
@nicholasbishop
xtask: Rework the OVMF search to make it more robust
23233d9 
Prior to this commit we assumed that OVMF files for a given guest arch
have consistent file names across host operating systems, varying only
in the directory path. This turns out not to be a good assumption
though; the locations and names of OVMF files installed by system
packages very a lot between operating systems.

To make it easier to figure out where stuff is, add a number of
OS-specific functions that provide the fulls OVMF code and vars
paths. For now these functions cover Arch, CentOS, Debian/Ubuntu,
Fedora, and Windows. A selection of candidate paths is then collected
(one set of paths for Linux, a different set for Windows) and searched.

Along with the above changes, the `--ovmf-dir` option has been replaced
with separate `--ovmf-code` and `--ovmf-vars` options. When set, these
paths will be used instead of searching the candidate paths.

The `uefi-test-runner` directory is no longer automatically searched for
OVMF files since we no longer assume we know what these files would be
named. Hopefully the improved candidate search makes this moot, and the
`--ovmf-code`/`--ovmf-vars` options can still be used to search there if
desired.

Fixes rust-osdev#469
nicholasbishop added a commit to nicholasbishop/uefi-rs that referenced this issue Jul 30, 2022
@nicholasbishop
xtask: Rework the OVMF search to make it more robust
c032040 
Prior to this commit we assumed that OVMF files for a given guest arch
have consistent file names across host operating systems, varying only
in the directory path. This turns out not to be a good assumption
though; the locations and names of OVMF files installed by system
packages very a lot between operating systems.

To make it easier to figure out where stuff is, add a number of
OS-specific functions that provide the fulls OVMF code and vars
paths. For now these functions cover Arch, CentOS, Debian/Ubuntu,
Fedora, and Windows. A selection of candidate paths is then collected
(one set of paths for Linux, a different set for Windows) and searched.

Along with the above changes, the `--ovmf-dir` option has been replaced
with separate `--ovmf-code` and `--ovmf-vars` options. When set, these
paths will be used instead of searching the candidate paths.

The `uefi-test-runner` directory is no longer automatically searched for
OVMF files since we no longer assume we know what these files would be
named. Hopefully the improved candidate search makes this moot, and the
`--ovmf-code`/`--ovmf-vars` options can still be used to search there if
desired.

Fixes rust-osdev#469
nicholasbishop added a commit to nicholasbishop/uefi-rs that referenced this issue Jul 30, 2022
@nicholasbishop
xtask: Rework the OVMF search to make it more robust
caf2690 
Prior to this commit we assumed that OVMF files for a given guest arch
have consistent file names across host operating systems, varying only
in the directory path. This turns out not to be a good assumption
though; the locations and names of OVMF files installed by system
packages very a lot between operating systems.

To make it easier to figure out where stuff is, add a number of
OS-specific functions that provide the fulls OVMF code and vars
paths. For now these functions cover Arch, CentOS, Debian/Ubuntu,
Fedora, and Windows. A selection of candidate paths is then collected
(one set of paths for Linux, a different set for Windows) and searched.

Along with the above changes, the `--ovmf-dir` option has been replaced
with separate `--ovmf-code` and `--ovmf-vars` options. When set, these
paths will be used instead of searching the candidate paths.

The `uefi-test-runner` directory is no longer automatically searched for
OVMF files since we no longer assume we know what these files would be
named. Hopefully the improved candidate search makes this moot, and the
`--ovmf-code`/`--ovmf-vars` options can still be used to search there if
desired.

Fixes rust-osdev#469
@nicholasbishop nicholasbishop mentioned this issue Jul 30, 2022
Merged
nicholasbishop added a commit to nicholasbishop/uefi-rs that referenced this issue Jul 30, 2022
@nicholasbishop
xtask: Rework the OVMF search to make it more robust
0b14271 
Prior to this commit we assumed that OVMF files for a given guest arch
have consistent file names across host operating systems, varying only
in the directory path. This turns out not to be a good assumption
though; the locations and names of OVMF files installed by system
packages very a lot between operating systems.

To make it easier to figure out where stuff is, add a number of
OS-specific functions that provide the fulls OVMF code and vars
paths. For now these functions cover Arch, CentOS, Debian/Ubuntu,
Fedora, and Windows. A selection of candidate paths is then collected
(one set of paths for Linux, a different set for Windows) and searched.

Along with the above changes, the `--ovmf-dir` option has been replaced
with separate `--ovmf-code` and `--ovmf-vars` options. When set, these
paths will be used instead of searching the candidate paths.

The `uefi-test-runner` directory is no longer automatically searched for
OVMF files since we no longer assume we know what these files would be
named. Hopefully the improved candidate search makes this moot, and the
`--ovmf-code`/`--ovmf-vars` options can still be used to search there if
desired.

CI changes:
* The aarch64 job has been simplified a bit since the system location of
  the files is now sufficient for `cargo xtask run` to work.
* The ia32 job now explicitly sets the location of the downloaded OVMF
  files.

Fixes rust-osdev#469
nicholasbishop added a commit to nicholasbishop/uefi-rs that referenced this issue Aug 3, 2022
@nicholasbishop
xtask: Rework the OVMF search to make it more robust
81f8380 
Prior to this commit we assumed that OVMF files for a given guest arch
have consistent file names across host operating systems, varying only
in the directory path. This turns out not to be a good assumption
though; the locations and names of OVMF files installed by system
packages very a lot between operating systems.

To make it easier to figure out where stuff is, add a number of
OS-specific functions that provide the fulls OVMF code and vars
paths. For now these functions cover Arch, CentOS, Debian/Ubuntu,
Fedora, and Windows. A selection of candidate paths is then collected
(one set of paths for Linux, a different set for Windows) and searched.

Along with the above changes, the `--ovmf-dir` option has been replaced
with separate `--ovmf-code` and `--ovmf-vars` options. When set, these
paths will be used instead of searching the candidate paths.

The `uefi-test-runner` directory is no longer automatically searched for
OVMF files since we no longer assume we know what these files would be
named. Hopefully the improved candidate search makes this moot, and the
`--ovmf-code`/`--ovmf-vars` options can still be used to search there if
desired.

CI changes:
* The aarch64 job has been simplified a bit since the system location of
  the files is now sufficient for `cargo xtask run` to work.
* The ia32 job now explicitly sets the location of the downloaded OVMF
  files.

Fixes rust-osdev#469
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

QEMU/OVMF improvements nicholasbishop/uefi-rs
1 participant
@nicholasbishop