Bug 1214033 - When installing with virt-install and using ovmf-x86_64.bin PXE boot fails initially
Summary: When installing with virt-install and using ovmf-x86_64.bin PXE boot fails in...
Status: NEW
Alias: None
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: Virtualization:Tools (show other bugs)
Version: Current
Hardware: x86-64 Other
: P5 - None : Normal (vote)
Target Milestone: ---
Assignee: Joey Lee
QA Contact: E-mail List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2023-08-07 14:26 UTC by Roger Whittaker
Modified: 2023-10-12 19:55 UTC (History)
2 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Roger Whittaker 2023-08-07 14:26:32 UTC
I have a setup using ipxe to install various operating systems: we do
a PXE boot and get ipxe.efi over tftp for a menu.

I'm using ovmf-x86_64.bin as the UEFI for the guests.

Until fairly recently (sorry, not sure when this started) on Tumbleweed as soon as I kicked off the install, I would see

>>StartPXE over IPv4

and the guest would get an address and the menu.

Now it waits for a long time, fails and then tries the other network
boot methods.

But if I do a virsh reset on it, I can go into the Boot Manager menu
and select UEFI PXEv4 and everything works as expected.

This looks as if it could be a bug in the qemu-ovmf-x86_64 package.

This is the type of command I am using for the install:

export VIRTINSTALL_OSINFO_DISABLE_REQUIRE=1; virt-install --name test \
             --pxe --boot loader=/home/roger/kvm-machines/test/ovmf-x86_64.bin \
	     --network bridge=br0 \
	     --ram 4096 \
	     --channel unix,mode=bind,name=org.qemu.guest_agent.0 \
	     --disk size=16,path=/home/roger/kvm-machines/test/test.qcow2

Note: the ovmf-x86_64.bin referred to above is directly copied from 
/usr/share/qemu/ovmf-x86_64.bin to the location specified.
Comment 1 Roger Whittaker 2023-08-07 14:49:04 UTC
Looking back in the Tumbleweed history I have found the following packages:

ovmf-202302-3.1.x86_64.rpm

qemu-ovmf-x86_64-202302-3.1.noarch.rpm

Using these, I do not see this behaviour.  It takes a while for the PXE boot to succeed, but it does.
Comment 2 Roger Whittaker 2023-08-07 14:51:31 UTC
So it looks like a problem was introduced in qemu-ovmf-x86_64-202305-1.1.noarch, while qemu-ovmf-x86_64-202302-3.1.noarch.rpm works as expected.
Comment 3 James Fehlig 2023-08-07 14:55:22 UTC
(In reply to Roger Whittaker from comment #2)
> So it looks like a problem was introduced in
> qemu-ovmf-x86_64-202305-1.1.noarch, while
> qemu-ovmf-x86_64-202302-3.1.noarch.rpm works as expected.

Thanks for confirming. Assigning to Joey to take a look...
Comment 4 Roger Whittaker 2023-08-07 15:03:40 UTC
I spoke too soon I think.  Even with the downgraded packages it is not consistently succeeding.
Comment 5 Roger Whittaker 2023-08-07 15:15:25 UTC
One failure but otherwise success with the older packages, but even so a *long* wait before the PXE boot succeeds.  Consistent failure with the newer packages, but always works after a reset and choosing UEFI PXEv4 from the Boot Manager menu.
Comment 6 Roger Whittaker 2023-08-08 11:40:16 UTC
There is a long gap after "StartPXE over IPv4" before the DHCP server sees the DHCPDISCOVER and a half minute gap between the DHCPOFFER and the DHCPREQUEST.
Comment 7 Roger Whittaker 2023-10-12 19:55:33 UTC
Upgraded:

 $ cat /etc/os-release ; echo "---"; rpm -qa | grep ovmf 
NAME="openSUSE Tumbleweed"
# VERSION="20231008"
ID="opensuse-tumbleweed"
ID_LIKE="opensuse suse"
VERSION_ID="20231008"
PRETTY_NAME="openSUSE Tumbleweed"
ANSI_COLOR="0;32"
CPE_NAME="cpe:/o:opensuse:tumbleweed:20231008"
BUG_REPORT_URL="https://bugzilla.opensuse.org"
SUPPORT_URL="https://bugs.opensuse.org"
HOME_URL="https://www.opensuse.org"
DOCUMENTATION_URL="https://en.opensuse.org/Portal:Tumbleweed"
LOGO="distributor-logo-Tumbleweed"
---
ovmf-tools-202308-1.2.x86_64
ovmf-202308-1.2.x86_64
qemu-ovmf-x86_64-202308-1.2.noarch

The first PXE over IPv4 fails.  

The following PXE over IPv6 and HTTP boot over IPv4 and IPv6 fail because these are not set up.

We drop to a screen where I can choose a boot method and this time PXE over IPv4 succeeds.

I think something is seriously wrong here, unless there's an issue with my DHCP and TFTP server (?)