14

virt-manager uses BIOS as the default option for firmware. There is an option to change this to UEFI just before installation, after the volume is set up.

before

However, after installation, the dropdown menu for changing the firmware disappears.

after

The installed system boots only with UEFI and not BIOS. The installation was a cumbersome procedure and I would like to avoid doing it all over again if possible.

Is there a way to convert the firmware to UEFI while keeping the contents of the system (disk) intact?

Improve this question

6 Answers 6

Reset to default
5

You must edit your vm xml using virsh and add in the <os /> section two items: <flash /> (ro efi ) and <nvram /> (rw environment).

You can read another preconfigured file for uefi in order to find more details about this two flags.

Improve this answer
1
  • 1
    That leaves us with: error: XML document failed to validate against schema: Unable to validate doc against /usr/share/libvirt/schemas/domain.rng
    – ckujau
    Feb 21 at 16:13
4

I just found out that you can move the disk (the file with the qcow2 extension) from one VM to another. So simply create another VM and add this disk. You can then do whatever you need to before the installation.

Improve this answer
1
  • Can confirm, this works. I agree with @nomad's comment it seems a silly hurdle in a already complex process (Linux partitions are fine, but Windows just has to have a whole drive to get the GPT table on the ESP). With Virt-mgr selecting 'OVMF_CODE_4M.ms.fd', the secureboot efi option wasnt required by Win 10.
    – alchemy
    Mar 21 at 20:39
4

It seems you figured out your problem, but to answer: you can't do this via the UI because for an existing installed VM you can't usually switch from BIOS to UEFI and have things 'just work'. If you installed Fedora for example, the way boot is first configured is dependent on whether it was installed on BIOS or UEFI, so changing that setting at the VM level will likely mean the VM is unbootable. If you want to change your firmware against the warning go ahead and change the starting <os> tag to <os firmware="efi">. It's that simple.

Improve this answer
5
  • That does make sense, but it just seems silly in this case.
    – nomad
    Oct 6, 2020 at 14:02
  • This must be added instead <loader readonly="yes" type="pflash">/usr/share/edk2/x64/OVMF_CODE.fd</loader> below <os>. See my comment on @Hamid's answer below.. the nvram line will be added automatically. ..given the triviality of this change, it could easily be done in the GUI of Virt-manager (maybe the nvram didnt automatically be added originally in VMgr, because it also copies a file from /usr/share/OVMF/ to /var/lib/libvirt/qemu/nvram/).
    – alchemy
    Mar 21 at 21:39
  • Also, this site (github.com/tianocore/edk2/discussions/3221#top) describes where to get the EFI file for Linux, at least for Debian: debian.pkgs.org/11/debian-main-arm64/…
    – alchemy
    Mar 21 at 21:42
  • I have to modify my comment about just adding the loader line.. It looks like the "create new" method actually sets some variables inside the /var/lib/libvirt/qemu/nvram/win10_VARS.fd file. I was successful at using a copy of that file from a working VM, but not able to use the file generated after just adding the "loader" line. I was able to get it to load an Aioboot partition (grub-based), and tried Win recovery from ISO, and also CMD shell bootrec /bcdrepair. I got a "Verification failed:.." error initially and then after using diskpart and "bcdboot C:\Windows /s V: /f ALL" got "Failure.."
    – alchemy
    Mar 23 at 0:26
  • This link mentions the Diskpart and Bcdboot commands as well as how to create a new EFI partition that might work: forums.tomshardware.com/threads/… ..oh, and on Ubuntu, the OVMF files are at: /usr/share/OVMF/OVMF_VARS_4M.ms.fd (the ms files are symlinked to secboot files anyway, just fyi).
    – alchemy
    Mar 23 at 0:49
3

I re-imported the qcow2 image to fix the problem in (following this tutorial):

In Archlinux, I firstly installed:

sudo pacman -S edk2-ovmf

Then:

Reconfigure Edit

Finally, the XML config file was changed from:

<os>
    <type arch="x86_64" machine="pc-q35-7.2">hvm</type>
    <boot dev="hd"/>
</os>

to:

<os>
    <type arch="x86_64" machine="q35">hvm</type>
    <loader readonly="yes" type="pflash">/usr/share/edk2/x64/OVMF_CODE.fd</loader>
    <boot dev="hd"/>
</os>
Improve this answer
1
  • 2
    Can confirm that adding the single line <loader readonly="yes" type="pflash">/usr/share/edk2/x64/OVMF_CODE.fd</loader> to the XML file works. Line nvram line that also is created will be added automatically.
    – alchemy
    Mar 21 at 21:33
1

If you want to change your firmware against the warning of Cole go ahead and change the starting <os> tag to <os firmware="efi">. It's that simple.

Improve this answer
1
  • This must be added instead <loader readonly="yes" type="pflash">/usr/share/edk2/x64/OVMF_CODE.fd</loader> below <os>. See my comment on @Hamid's answer below.. the nvram line will be added automatically.
    – alchemy
    Mar 21 at 21:35
1

Don't have enough reputation to comment, so I will just share my experience here.

I tried to do what @George Bungarzescu said, but the tags he presented are probably outdated. So instead I copied over the settings in a new machine that is initially configured to do UEFI. Result? Error during boot: Error I even copied over the new machine_VARS.fd for the old one. Did not work.

Just make a new VM as @nomad suggested, use the same qcow2 file and adjust your uefi settings accordingly.

Improve this answer
1
  • this could be something to try, @WoodenThuds thanks for posting this;
    – William Martens
    Jan 10 at 11:28

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .