You are not logged in.
Hello everyone,
I'm not sure if this is the correct subforum, so please excuse me if this is misplaced.
I recently upgraded my system. According to this page (looking at the date) the update of the OVMF package (extra) is the problem.
I use a Windows-VM with an UEFI firmware (ovmf) and PCI-passthrough. To set up the VM i follwed this tutorial. Everything worked fine before i made the upgrade, but if i try to start the VM now virt-manager gives me the following error:
Error starting domain: Path '/usr/share/ovmf/ovmf_code_x64.bin' is not accessible: No such file or directory
Traceback (most recent call last):
File "/usr/share/virt-manager/virtManager/asyncjob.py", line 89, in cb_wrapper
callback(asyncjob, *args, **kwargs)
File "/usr/share/virt-manager/virtManager/asyncjob.py", line 125, in tmpcb
callback(*args, **kwargs)
File "/usr/share/virt-manager/virtManager/libvirtobject.py", line 82, in newfn
ret = fn(self, *args, **kwargs)
File "/usr/share/virt-manager/virtManager/domain.py", line 1505, in startup
self._backend.create()
File "/usr/lib/python2.7/site-packages/libvirt.py", line 1069, in create
if ret == -1: raise libvirtError ('virDomainCreate() failed', dom=self)
libvirtError: Path '/usr/share/ovmf/ovmf_code_x64.bin' is not accessible: No such file or directory
And - indeed - the binary is missing. I checked out the following things:
[user@Machine ~]$ pacman -Qe | grep ovmf
ovmf 1:r23112.018432f0ce-1
[user@Machine ~]$ pacman -Ql | grep ovmf
ovmf /usr/
ovmf /usr/share/
ovmf /usr/share/licenses/
ovmf /usr/share/licenses/ovmf/
ovmf /usr/share/licenses/ovmf/License.txt
ovmf /usr/share/ovmf/
ovmf /usr/share/ovmf/x64/
ovmf /usr/share/ovmf/x64/OVMF_CODE.fd
ovmf /usr/share/ovmf/x64/OVMF_VARS.fd
[user@Machine ~]$ ls /usr/share/ovmf/
x64
[user@Machine ~]$ cat /etc/libvirt/qemu.conf
(....)
# This directory is used for memoryBacking source if configured as file.
# NOTE: big files will be stored here
#memory_backing_dir = "/var/lib/libvirt/qemu/ram"
#
nvram = [
"/usr/share/ovmf/ovmf_code_x64.bin:/usr/share/ovmf/ovmf_vars_x64.bin"
][user@Machine ~]$
So, the binary is actually missing. I did not delete anything, i guess the upgrade has changed a lot in ovmf. I tried downgrading the package by manually uninstalling it (pacman -R) and downloading older versions from this page. I tried several versions. pacman -U (package) tells me that some metadata is missing. Un-taring and using makepkg -si appears to work, pacman -Q is telling me that i use an older version, but the binary is still missing.
Here some other informations about the VM:
Hypervisor: KVM
Architecture: x86_64
Emulator: /usr/sbin/qemu-system-x86_64
Firmware: UEFI x86_64: /urs/share/ovmf/ovmf_code_x64.bin
Chipset: i440FX
Sadly, i cant change anything of these things.
Does anyone have an idea what to do about that? Please let me know if you need any further information.
Thanks in advance
Simulacrum
Last edited by Simulacrum (2018-02-16 06:10:27)
Offline
downloading older versions from this page.
While it's possible to get source files via that page to build an older version of the package, most of the time it's preferrable to use pre-built packages from your system's package cache, or Arch Linux Archive.
See https://wiki.archlinux.org/index.php/Do … g_packages
If the issue is caused by ovmf update, downgrading the package from e.g. ALA should get your VM back in working order.
However, from the page you linked, you can see any changes in arch packaging, and seems like the latest update that's causing your issue, is merely a version bump. There was no change in the way ovmf is packaged in arch, so I'd imagine the binary you're missing, was removed by upstream developers.
I have no experience with ovmf and couldn't find working URL for upstream development, so I can't really help futher than this..
Offline
I forgot to mention that. The pacman cache sadly just contained the newest version:
[user@Machine ~]$ ls /var/cache/pacman/pkg/ | grep ovmf
ovmf-1:r23112.018432f0ce-1-any.pkg.tar.xz
But: It finally worked by downgrading via ALA. Thanks for the hint. I used the following version:
ovmf-1:r21243.3858b4a1ff-1-any.pkg.tar.xz 04-Mar-2017 13:54 2M
ovmf-1:r21243.3858b4a1ff-1-any.pkg.tar.xz.sig 04-Mar-2017 13:54 588
from https://archive.archlinux.org/packages/o/ovmf/
The version from September didn't work. No clue why - the VM worked fine since Tuesday (1/16/2018) and im keeping my system up to date like a maniac.
I could easily install the package by removing the current version of ovmf (pacman -R ovmf) and installing the downloaded one with pacman -U [packagename].
Thanks again, and have a good time.
Simulacrum
Offline
Happy to hear I was able to help.
However, you definitely shouldn't consider this issue solved by downgrading to unsupported version. By not upgaring you're most likely missing important bug and security fixes, and it's not guaranteed that the older version will work with future updates.
You should figure out the actual issue with the newer package versions, and find a proper fix/workaround. At least keep this thread unsolved so someone with more knowledge of the matter could chime in.
Offline
Happy to hear I was able to help.
However, you definitely shouldn't consider this issue solved by downgrading to unsupported version. By not upgaring you're most likely missing important bug and security fixes, and it's not guaranteed that the older version will work with future updates.
You should figure out the actual issue with the newer package versions, and find a proper fix/workaround. At least keep this thread unsolved so someone with more knowledge of the matter could chime in.
Yes, thats true. I just marked it as "solved" because other people seeking a >quick< solution might click on it. But they will, probably, anyways I think about writing to the dev, maybe opening a ticket. But im really not sure about form and the "how to". I'm probably going to have some research about that.
Offline
The wiki has been updated, since the filenames have changed.
https://wiki.archlinux.org/index.php/PC … d_guest_VM
https://wiki.archlinux.org/index.php/PC … ut_libvirt
| alias CUTF='LANG=en_XX.UTF-8@POSIX ' |
Offline
2 changes were made to the package recently:
* Filenames in the Arch package got changed to match its upstream naming (/usr/share/ovmf/x64/OVMF_CODE.fd)
* 32bit build got disabled as it currently it fails to compile
Read it before posting http://www.catb.org/esr/faqs/smart-questions.html
Ruby gems repository done right https://bbs.archlinux.org/viewtopic.php?id=182729
Fast initramfs generator with security in mind https://wiki.archlinux.org/index.php/Booster
Offline
Edit: Thanks for the answers
The wiki has been updated, since the filenames have changed.
Ok, but when i change the nvram entry in the qemu.conf, I need to set up the VM from scratch, right? There is no way to change the Firmware (at least in virt-manager. Maybe directly in the XML?)
Edit: I found the following entry in the XML (/etc/libvirt/qemu/gaming.xml)
<os>
<type arch='x86_64' machine='pc-i440fx-2.9'>hvm</type>
<loader readonly='yes' type='pflash'>/usr/share/ovmf/ovmf_code_x64.bin</loader>
<nvram>/var/lib/libvirt/qemu/nvram/gaming_VARS.fd</nvram>
<boot dev='hd'/>
</os>
Applying changes here and in the nvram part of qemu.conf should do the thing?
2 changes were made to the package recently:
* Filenames in the Arch package got changed to match its upstream naming (/usr/share/ovmf/x64/OVMF_CODE.fd)
* 32bit build got disabled as it currently it fails to compile
So OVMF_CODE.fd is "the new" ovmf_code_x64.bin? If the upper assumption is correct (new VM), would it be a workaround to update ovmf and
dd if=/usr/share/ovmf/x64/OVMF_CODE.fd of=/usr/share/ovmf/ovmf_code_x64.bin
Sorry, for more experienced users this might appear like complete madness. But i want to keep the VM running until i got time to set up a new one, but also want to have all packages up to date.
Last edited by Simulacrum (2018-01-18 15:03:19)
Offline
So OVMF_CODE.fd is "the new" ovmf_code_x64.bin? If the upper assumption is correct (new VM), would it be a workaround to update ovmf and
dd if=/usr/share/ovmf/x64/OVMF_CODE.fd of=/usr/share/ovmf/ovmf_code_x64.bin
dd is overkill, and you'd have to remember to run the same command after every ovmf package update.
Symlink would be ok as a workaround, and shouldn't really break anything, as the link always points to the up-to-date firmware file from official package.
man ln
The "right" way to fix the issue, would be correcting the path in your VM settings to point to OVMF_CODE.fd.
Offline
OK, i created a symbolic link to the new file by using the following:
sudo ln -s /usr/share/ovmf/x64/OVMF_CODE.fd /usr/share/ovmf/ovmf_code_x64.bin
It works fine (so far). Im going to figur out how to adjust the VM settings and post it here.
Offline
So OVMF_CODE.fd is "the new" ovmf_code_x64.bin?
Yes. ovmf_code_x64.bin file got renamed to OVMF_CODE.fd to match filename used by upstream.
Symlinking like suggested above should do the trick for you.
Read it before posting http://www.catb.org/esr/faqs/smart-questions.html
Ruby gems repository done right https://bbs.archlinux.org/viewtopic.php?id=182729
Fast initramfs generator with security in mind https://wiki.archlinux.org/index.php/Booster
Offline
for some reson qemu doesn't like the ovmf bios
$ qemu-system-x86_64 -enable-kvm -m 4096 -cdrom Downloads/ubuntu-17.10-desktop-amd64.iso -bios /usr/share/ovmf/x64/OVMF_CODE.fd
qemu: could not load PC BIOS '/usr/share/ovmf/x64/OVMF_CODE.fd'
OTOH
-bios /usr/share/edk2/ovmf/OVMF_CODE.fd
from the edk2-ovmf package from AUR works
damjan ~ $ pacman -Qo /usr/bin/qemu-system-x86_64
/usr/bin/qemu-system-x86_64 is owned by qemu 2.11.0-3
damjan ~ $ pacman -Qo /usr/share/ovmf/x64/OVMF_CODE.fd
/usr/share/ovmf/x64/OVMF_CODE.fd is owned by ovmf 1:r23112.018432f0ce-1
damjan ~ $ pacman -Qo /usr/share/edk2/ovmf/OVMF_CODE.fd
/usr/share/edk2/ovmf/OVMF_CODE.fd is owned by edk2-ovmf 20170209-3
Offline
I was able to update OVMF without needing a symlink. I followed the steps on the wiki to update qemu.conf with the new path and filename for nvram:
/etc/libvirt/qemu.conf
-----
nvram = [
"/usr/share/ovmf/x64/OVMF_CODE.fd:/usr/share/ovmf/x64/OVMF_VARS.fd"
]
Then, I updated my existing VM (my VM name is "win7") using "virsh" since virt-manager doesn't seem to allow for changing the firmware on existing systems. (This opened a vi session with my VM config.) Look for the line with 'pflash' (near the top) and change to the new path. (Note that x64 is now part of the path.)
sudo virsh edit win7
-----
<loader readonly='yes' type='pflash'>/usr/share/ovmf/x64/OVMF_CODE.fd</loader>
I was then able to start my VM without any issue.
Offline