RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1031518 - iPXE does not honor specified boot device
Summary: iPXE does not honor specified boot device
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: ipxe
Version: 7.0
Hardware: x86_64
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: Alex Williamson
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-11-18 07:50 UTC by Xu Han
Modified: 2014-06-18 08:30 UTC (History)
8 users (show)

Fixed In Version: ipxe-20130517-5.gitc4bce43.el7
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-06-13 09:22:53 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
e1000 (11.02 KB, image/png)
2013-11-18 07:56 UTC, Xu Han
no flags Details
virtio-net (10.86 KB, image/png)
2013-11-18 08:01 UTC, Xu Han
no flags Details
82576 PF rom (67.50 KB, application/octet-stream)
2013-11-18 08:02 UTC, Xu Han
no flags Details
82576 VF rom (68.00 KB, application/octet-stream)
2013-11-18 08:03 UTC, Xu Han
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1057249 1 None None None 2021-01-20 06:05:38 UTC

Internal Links: 1057249

Description Xu Han 2013-11-18 07:50:25 UTC
Description of problem:
PXE boot fail from 82576 PF/VF while attach e1000 at the same time. If use virtio-net instead it then won't hit this issue.
Both PF and VF rom were burned by use source code which is download from http://ipxe.org/. Not sure whether it is cause by the problems of roms, so, currently file this bug on seabios.

Version-Release number of selected component (if applicable):
seabios-bin-1.7.2.2-4.el7.noarch
ipxe-roms-qemu-20130517-1.gitc4bce43.el7.noarch

How reproducible:
always

Steps to Reproduce:
1. boot guest with 82576 PF/VF and e1000 NIC.
# /usr/libexec/qemu-kvm -nodefaults -M q35 -m 4G -cpu Opteron_G3 -smp 4,cores=2,threads=2,sockets=1 -boot menu=on -monitor stdio -rtc base=localtime,clock=host,driftfix=slew -qmp tcp:0:5555,server,nowait -vga qxl -drive file=/home/pxe-install.qcow2_v3,format=qcow2,id=guest-img,if=none,werror=stop,rerror=stop -device virtio-blk-pci,scsi=off,drive=guest-img,id=os-disk -spice disable-ticketing,port=5931 -device virtio-balloon,id=balloon -global PIIX4_PM.disable_s3=0 -global PIIX4_PM.disable_s4=0 
-monitor unix:/tmp/guest-sock,server,nowait \
-netdev tap,id=hostnet0,script=/etc/ovs-ifup,downscript=/etc/ovs-ifdown \
-device e1000,netdev=hostnet0,id=net0,mac=00:1a:4a:42:0a:00 \
-device vfio-pci,host=01:00.0,id=pf0,romfile=/home/82576PF.rom,bootindex=1 -S

2. choose PXE boot from 82576 PF/VF in seabios.

Actual results:
after step2, fail to boot from 82576 PF/VF, and would boot from e1000.
will attach the screen shot later.

Expected results:
could boot from 82576 PF/VF.

Additional info:

Comment 1 Xu Han 2013-11-18 07:56:16 UTC
Created attachment 825418 [details]
e1000

Seabios screen shot of boot from 82576 PF/VF with attached e1000.

Comment 2 Xu Han 2013-11-18 08:01:03 UTC
Created attachment 825419 [details]
virtio-net

Seabios screen shot of boot from 82576 PF/VF with attached virtio-net.
From this screen shot could see that can be able to boot from 82576 PF/VF(00:05.0).

Comment 3 Xu Han 2013-11-18 08:02:58 UTC
Created attachment 825420 [details]
82576 PF rom

Comment 4 Xu Han 2013-11-18 08:03:31 UTC
Created attachment 825422 [details]
82576 VF rom

Comment 6 Alex Williamson 2013-11-27 05:23:53 UTC
Moving to iPXE

After reproducing this bug, I believe the description is not actually correct.  The problem does not occur between emulated e1000 and 82576 VF.  It only happens between emulated e1000 and 82576 PF.  The reason for this is that e1000 and 82576 PF use the same driver in iPXE.  When iPXE is selected it appears to boot from the first device supported by the driver in PCI scan order.  In the described scenario the e1000 is a lower numbered PCI device and thus iPXE attempts to boot it first, regardless of bootindex.  Using addr= to re-order the PCI order of the devices results in the opposite problem.

I sent a query upstream describing the problem and looking for advice on a solution.  I suspect this problem has always existed in iPXE/gPXE.

Comment 8 Miroslav Rezanina 2014-03-05 09:32:41 UTC
Fix included in ipxe-20130517-5.gitc4bce43.el7

Comment 10 Xu Han 2014-03-17 03:30:31 UTC
Verify this bug with component:
ipxe-roms-qemu-20130517-5.gitc4bce43.el7.noarch

Scenario 1: Bootindex disorder by PCI address.
# /usr/libexec/qemu-kvm ... \
     -device e1000,netdev=hostnet0,id=net0,mac=00:1a:4a:42:0a:00,addr=0x03,bootindex=2 \
     -device vfio-pci,host=03:00.1,id=pf0,romfile=82576PF.rom,addr=0x05,bootindex=1 \
     ...

Results:
ipxe boot from the specified boot device(82576 PF).
---
SeaBIOS (version seabios-1.7.2.2-11.el7)


iPXE (http://ipxe.org) 00:03.0 C100 PCI2.10 PnP PMM+BFFC92B0+BFF292B0 C100
                                                                               




iPXE (http://ipxe.org) 00:05.0 C200 PCI2.10 PnP PMM+BFF172B0 BFF292B0 C200
                                                                               


Booting from ROM...
iPXE (PCI 00:05.0) starting execution...ok
iPXE initialising devices...ok



iPXE 1.0.0+ (f473) -- Open Source Network Boot Firmware -- http://ipxe.org
Features: iSCSI HTTP DNS TFTP AoE ELF MBOOT PXE bzImage Menu PXEXT

net1: 00:1b:21:39:8b:18 using 82576 on PCI00:05.0 (open)
  [Link:down, TX:0 TXE:0 RX:0 RXE:0]
  [Link status: Down (http://ipxe.org/38086101)]
Waiting for link-up on net1................. Down (http://ipxe.org/38086101)
No more network devices

Booting from ROM...                      
iPXE (PCI 00:03.0) starting execution...ok
iPXE initialising devices...ok

Comment 11 Xu Han 2014-03-17 03:34:01 UTC
Scenario 2: Bootindex order by PCI address.
# /usr/libexec/qemu-kvm ... \
     -device e1000,netdev=hostnet0,id=net0,mac=00:1a:4a:42:0a:00,addr=0x03,bootindex=1 \
     -device vfio-pci,host=03:00.1,id=pf0,romfile=82576PF.rom,addr=0x05,bootindex=2 \
     ...

Results:
ipxe boot from the specified boot device(e1000).
---
SeaBIOS (version seabios-1.7.2.2-11.el7)


iPXE (http://ipxe.org) 00:03.0 C100 PCI2.10 PnP PMM+BFFC92B0+BFF292B0 C100
                                                                               




iPXE (http://ipxe.org) 00:05.0 C200 PCI2.10 PnP PMM+BFF172B0 BFF292B0 C200
                                                                               


Booting from ROM...
iPXE (PCI 00:03.0) starting execution...ok
iPXE initialising devices...ok



iPXE 1.0.0+ (c4bce43) -- Open Source Network Boot Firmware -- http://ipxe.org
Features: iSCSI HTTP DNS TFTP AoE bzImage ELF MBOOT PXE Menu PXEXT

net0: 00:1a:4a:42:0a:00 using 82540em on PCI00:03.0 (open)
  [Link:up, TX:0 TXE:0 RX:0 RXE:0]
DHCP (net0 00:1a:4a:42:0a:00)...... ok
net0: 192.168.122.209/255.255.255.0 gw 192.168.122.1
Nothing to boot: No such file or directory (http://ipxe.org/2d03e13b)
No more network devices

Booting from ROM...                      
iPXE (PCI 00:05.0) starting execution...ok
iPXE initialising devices...ok


Base on these test results above, this bug has been fixed.

Comment 13 Ludek Smid 2014-06-13 09:22:53 UTC
This request was resolved in Red Hat Enterprise Linux 7.0.

Contact your manager or support representative in case you have further questions about the request.


Note You need to log in before you can comment on or make changes to this bug.