Bug 632716 - PXE Booting fails to fetch the kernel from the correct IP address
Summary: PXE Booting fails to fetch the kernel from the correct IP address
Keywords:
Status: CLOSED DUPLICATE of bug 632712
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: gpxe
Version: 6.0
Hardware: All
OS: Linux
low
medium
Target Milestone: beta
: 6.1
Assignee: Glauber Costa
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks: 580954
TreeView+ depends on / blocked
 
Reported: 2010-09-10 19:56 UTC by Gordan Bobic
Modified: 2013-01-09 23:06 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-03-02 14:26:01 UTC
Target Upstream Version:


Attachments (Terms of Use)

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 ***


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