Bug 498230 - virtio PXE Roms "No IP address"
virtio PXE Roms "No IP address"
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: etherboot (Show other bugs)
rawhide
All Linux
low Severity medium
: ---
: ---
Assigned To: Eduardo Habkost
Fedora Extras Quality Assurance
:
: 499586 (view as bug list)
Depends On:
Blocks: F11VirtTarget
  Show dependency treegraph
 
Reported: 2009-04-29 10:36 EDT by Daire Byrne
Modified: 2009-05-21 16:30 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-05-21 16:30:25 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Daire Byrne 2009-04-29 10:36:25 EDT
Description of problem:
Since Fedora10 we have been unable to get the QEMU/KVM PXE roms to get an IP address. The bridged network is setup correctly and the DHCP server OFFERs an IP but the PXE rom just keeps retrying and reporting "No IP address".

If I install an OS from CD it will get a DHCP IP within the OS just fine. It is just the PXE roms that fail. This is the same for all included PXE roms (e1000, virtio etc.).

I suspect there is a problem with the PXE roms not liking the DHCP response from our server.

Version-Release number of selected component (if applicable):
qemu-system-x86-0.10-12.fc11.x86_64
libvirt-0.6.2-2.fc11.x86_64
virt-manager-0.7.0-4.fc11.x86_64

[~] - uname -r
2.6.29.1-111.fc11.x86_64

How reproducible:

Always when trying to PXE boot on our network. Was the same in Fedora 10.

Steps to Reproduce:
1. Create new virtual machine with virt-manager
2. Assign to bridged network interface
3. PXE boot
  
Actual results:
"No IP address"

Expected results:
Recieve DHCP server's OFFER and use it.

Additional info:
Comment 1 Mark McLoughlin 2009-05-04 12:18:31 EDT
Sounds the same as bug #494541, except you mention that it also affects virtio. Let's make this bug track the virtio issue and #494541 track the e1000 issue

You might want to try rtl8139 and pcnet; the report of bug #494541 found that they work fine
Comment 2 Daire Byrne 2009-05-05 05:35:28 EDT
Mark,

(In reply to comment #1)
> Sounds the same as bug #494541, except you mention that it also affects virtio.
> Let's make this bug track the virtio issue and #494541 track the e1000 issue

I do not think it is related to #494541 as ALL of the PXE roms fail for us. I can only assume that there is something setup wrong in our Fedora image stopping PXE roms from receiving the DHCP offer (iptables is disabled) or our DHCP server sends OFFERs that the PXE roms don't want to accept.

Saying that we don't know of any other devices on our network that don't work with our DHCP server and I can't think of anything else other than iptables that could interfere with DHCP requests. The virtual host OS receives the DHCP offer just fine.
Comment 3 Mark McLoughlin 2009-05-05 06:11:50 EDT
(In reply to comment #2)

> I do not think it is related to #494541 as ALL of the PXE roms fail for us.

So, you've tried rtl8139 and pcnet?

> I
> can only assume that there is something setup wrong in our Fedora image
> stopping PXE roms from receiving the DHCP offer (iptables is disabled)

When you say "Fedora image", you mean the host machine?

You could try and configure dhcpd on the host machine to test whether you can get it to work with a different dhcp server

> or our
> DHCP server sends OFFERs that the PXE roms don't want to accept.
> 
> Saying that we don't know of any other devices on our network that don't work
> with our DHCP server and I can't think of anything else other than iptables
> that could interfere with DHCP requests. The virtual host OS receives the DHCP
> offer just fine.

Yes, it could well be specific to your DHCP server.
Comment 4 Daire Byrne 2009-05-05 06:28:36 EDT
(In reply to comment #3)
> (In reply to comment #2)
> 
> > I do not think it is related to #494541 as ALL of the PXE roms fail for us.
> 
> So, you've tried rtl8139 and pcnet?

Yes - same (non) result.

> When you say "Fedora image", you mean the host machine?

Yes.
 
> You could try and configure dhcpd on the host machine to test whether you can
> get it to work with a different dhcp server

I'll try setup a vanilla DHCP server and config on a test vlan and see if I get any further. 

> Yes, it could well be specific to your DHCP server.  

Or our DHCPD config (which is pretty long and convoluted at this point). FYI we are using DHCP-3.0.5-13 which I believe is the standard RHEL5 version.
Comment 5 Mark McLoughlin 2009-05-11 07:21:23 EDT
*** Bug 499586 has been marked as a duplicate of this bug. ***
Comment 6 Mark McLoughlin 2009-05-11 07:25:06 EDT
Could you try and rebuild etherboot with this change:

--- etherboot-5.4.4/src/Config.old	2009-05-11 12:23:47.000000000 +0100
+++ etherboot-5.4.4/src/Config	2009-05-11 12:23:59.000000000 +0100
@@ -469,7 +469,7 @@
 # (Requires TFTP protocol support)
 CFLAGS+=	-DPXE_IMAGE -DPXE_EXPORT
 # Etherboot stricter as a PXE network protocol ROM
-# CFLAGS+=	-DPXE_DHCP_STRICT
+CFLAGS+=	-DPXE_DHCP_STRICT
 
 # Support for PXE emulation. Works only with FreeBSD to load the kernel
 # via pxeboot, use only with DOWNLOAD_PROTO_NFS



Eduardo suggests it may help
Comment 7 Daire Byrne 2009-05-11 10:35:54 EDT
(In reply to comment #6)
> Could you try and rebuild etherboot with this change:
>
> Eduardo suggests it may help  
It doesn't seem to make much difference. I have just noticed that our Myrinet 10GigE cards have also recently lost their ability to PXE boot using our DHCP server config. They use Etherboot roms too.
Comment 8 Daire Byrne 2009-05-12 10:42:01 EDT
(In reply to comment #7)
> (In reply to comment #6)
> > Could you try and rebuild etherboot with this change:
> >
> > Eduardo suggests it may help  
> It doesn't seem to make much difference. I have just noticed that our Myrinet
> 10GigE cards have also recently lost their ability to PXE boot using our DHCP
> server config. They use Etherboot roms too.  

Figure it out. It seems that in a recent upgrade of our dhcpd version they changed the way "next-server" works. You must specify it explicitly for Etherboot to work. If you left it unset before the server just used it's own address for it and sent that.

So by adding a "next-server" directive we can now boot Etherboot roms again. We still can't etherboot on e1000 as already reported in #494541. You can close this now. Thanks for your time and effort.
Comment 9 Mark McLoughlin 2009-05-21 16:30:25 EDT
Thanks for the update Daire

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