Bug 632716

Summary: PXE Booting fails to fetch the kernel from the correct IP address
Product: Red Hat Enterprise Linux 6 Reporter: Gordan Bobic <gordan>
Component: gpxeAssignee: Glauber Costa <gcosta>
Status: CLOSED DUPLICATE QA Contact: Virtualization Bugs <virt-bugs>
Severity: medium Docs Contact:
Priority: low    
Version: 6.0CC: amit.shah, mkenneth, tburke, virt-maint
Target Milestone: beta   
Target Release: 6.1   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-03-02 14:26:01 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 580954    

Description Gordan Bobic 2010-09-10 19:56:41 UTC 
Description of problem:
When PXE booting, the firmware tries to fetch the kernel from tftp://0.0.0.0 rather than the IP address of the DHCP server.

Version-Release number of selected component (if applicable):
qemu-kvm-0.12.1.2-2.90.el6.x86_64

How reproducible:
Every time.

Steps to Reproduce:
Boot a VM via PXE through a bridged interface:

  
Actual results:
DHCP (net0 52:54:00:56:4e:1f)................ ok
net0: 10.20.250.99/255.255.0.0 gw 10.2.0.1
Booting from filename "linux-install/pxelinux.0"
tftp://0.0.0.0/linux-install/pxelinux.0........ Connection timed out (0x4c106035)
Could not load tftp://0.0.0.0/linux-install/pxelinux.0: Connection timed out (0x4c106035)


Expected results:
Manually taking over the boot process:
gPXE> dhcp net0
DHCP (net0 52:54:00:56:4e:1f).... ok
gPXE> kernel tftp://10.20.10.1/linux-install/pxelinux.0
tftp://10.20.10.1/linux-install/pxelinux.0.. ok
gPXE>

Additional info:
PXE booting bare metal machines on the same network works fine.
Comment 2 Gordan Bobic 2010-11-20 11:35:07 UTC 
I believe this is a duplicate of bug:
https://bugzilla.redhat.com/show_bug.cgi?id=586324

Setting DELAY=0 in the ifcfg config file solves the problem.
Comment 3 Dor Laor 2011-01-03 09:57:47 UTC 
Can we close the bug?
Comment 4 Gordan Bobic 2011-01-03 12:52:13 UTC 
I don't think this can be closed until either DELAY=0 is the default (possibly dangerous for non-VM related bridging) or it is well documented that DELAY=0 should be set in the bridge ifcfg file.
Comment 5 Dor Laor 2011-01-03 13:13:23 UTC 
(In reply to comment #4)
> I don't think this can be closed until either DELAY=0 is the default (possibly
> dangerous for non-VM related bridging) or it is well documented that DELAY=0
> should be set in the bridge ifcfg file.

It is documented in the documentation guide on 10.2
Comment 6 Glauber Costa 2011-03-02 14:26:01 UTC 
At the very least this is a dupe of 632712

*** This bug has been marked as a duplicate of bug 632712 ***