<div dir="ltr"><div dir="ltr"><div dir="ltr"><div>Hi,<br><br></div><div>Thank you very much for the quick response!<br></div><div>Actually setting the explicit boot order for the '--disk'-s worked like a charm! Just needed to correct the 'bootorder' to 'boot_order' (got: "ERROR    Unknown options ['bootorder']"), see also virt-install '--disk=?'. Just I was not aware to search for the options of the --disk.<br><br></div><div>Thanks for the general improvement comments as well, I will apply them! I based my command on an existing script, and did not check all the options.<br><br></div><div>As for libvirt, I can live with these options, I will try to find some downloadable package which contains these files (also, ultimately I will run the virt-install command in an ubuntu 18.04 VM and there in the ovmf package the ovmf files are somehow not separated like this, I also found a debian bug report about it).<br><br></div><div>Regards,<br></div><div>Attila<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jan 22, 2019 at 4:26 PM Cole Robinson <<a href="mailto:crobinso@redhat.com">crobinso@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 01/22/2019 07:40 AM, Attila Vangel wrote:<br>
> Hi,<br>
> <br>
> I am new to virt-install and just a regular user of UEFI, so forgive me<br>
> if I ask something stupid.<br>
> <br>
> I am trying to create and start a VM with virt-install so that<br>
> - it needs to boot with UEFI,<br>
> - if the first disk is "empty" (just created, not partitioned), then the<br>
> system should boot from the second HDD, which contains an installer image,<br>
> - otherwise if an UEFI bootable system is found in the first HDD, then<br>
> it should boot from that.<br>
> (it is also OK if I could change the boot order after the VM is booted<br>
> (during installation it gets rebooted)<br>
> - it should happen without manual intervention (e.g. interactive boot<br>
> menu), fully scripted.<br>
> <br>
> So far I put together a command line something like this:<br>
> <br>
> INSTALLER_IMAGE_PATH=/path/to/installer-image.qcow2<br>
> <br>
> virt-install --name my-vm --network default --connect qemu:///system<br>
> --memory=4096 --cpu=host --vcpus=2 --os-type=linux --os-variant=generic<br>
> --noautoconsole --events on_poweroff=preserve --disk<br>
> pool=default,size=30 --disk $INSTALLER_IMAGE_PATH --boot<br>
> loader=/usr/share/ovmf/x64/OVMF_CODE.fd,loader_ro=yes,loader_type=pflash,nvram_template=/usr/share/ovmf/x64/OVMF_VARS.fd,loader_secure=no<br>
> <br>
<br>
A couple small things for starters: --network default and<br>
--os-type=linux are redundant here, they are the default settings<br>
(unless you have a bridge device manually configured on your host, then<br>
virt-install will use that). Similarly --os-variant=generic is the<br>
default too, if you want a better performing guest using virtio specify<br>
a modern linux version in there like --os-variant=fedora28<br>
<br>
> The "--boot<br>
> loader=/usr/share/ovmf/x64/OVMF_CODE.fd,loader_ro=yes,loader_type=pflash,nvram_template=/usr/share/ovmf/x64/OVMF_VARS.fd,loader_secure=no"<br>
> magic I googled from somewhere, as the "--boot uefi" option did not work<br>
> (gave "ERROR    Error: --boot uefi: Did not find any UEFI binary path<br>
> for arch 'x86_64'").<br>
> The OVMF file paths are based on the Arch linux ovmf package.<br>
> <br>
<br>
That --boot string looks correct although loader_secure=no is redundant<br>
I think. '--boot uefi' requires getting those paths from libvirt<br>
domcapabilities output, which only knows where to look if libvirt is<br>
built with an appropriate --with-loader-nvram option pointing to the<br>
distros nvram paths. You should file a bug with arch libvirt maintainers<br>
to investigate using that build option, then --boot uefi will work fine.<br>
<br>
Anyways I'm surprised this doesn't work. The default boot=hd setting I<br>
thought would try each hd in sequence and boot the first bootable one.<br>
You can try adding explicit --disk ...,bootorder=1 --disk<br>
...,bootorder=2 attributes, maybe it will make a difference. You can use<br>
that to make usb booting too with --hostdev ...,bootorder=X<br>
<br>
That said, I just tried that bootorder= with seabios booting, and it<br>
didn't work either for your use case. Seems like for hd booting, seabios<br>
will just bail out on the first hd failure, like it isn't smart enough<br>
to continue on if there's no boot entry in the first hd it hits. That<br>
surprises me. Maybe UEFI doesn't have the same issue though<br>
<br>
- Cole<br>
</blockquote></div></div></div></div>