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 594682 - tftp: No filename or root path specified
Summary: tftp: No filename or root path specified
Keywords:
Status: CLOSED WONTFIX
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
: ---
Assignee: Eduardo Habkost
QA Contact: Virtualization Bugs
URL:
Whiteboard:
: 614307 (view as bug list)
Depends On:
Blocks: 575298 580953 655062
TreeView+ depends on / blocked
 
Reported: 2010-05-21 10:33 UTC by Qian Cai
Modified: 2014-03-17 13:35 UTC (History)
16 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 623951 655062 (view as bug list)
Environment:
Last Closed: 2011-05-30 14:49:00 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
virtio-net rom from gpxe.git compile (55.00 KB, application/octet-stream)
2010-07-29 08:15 UTC, Amit Shah 		no flags Details
View All


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 655062 0 high CLOSED use --dhcp-no-override option when using tftp 2021-02-22 00:41:40 UTC

Internal Links: 655062

Description Qian Cai 2010-05-21 10:33:51 UTC 
Description of problem:
When booting from PXE via a TFTP server in a virtual network.

<network>
  <name>newpxe2</name>
  <forward mode='nat'/>
  <ip address="192.168.123.1" netmask="255.255.255.0">
    <tftp root="/" />
    <dhcp>
      <range start="192.168.123.2" end="192.168.123.254" />
      <bootp file="pxelinux.0" />
    </dhcp>
  </ip>
</network>

# ls -l /var/lib/tftpboot/
total 28848
-rw-r--r--. 1 root root 29515304 May 21 23:47 initrd.img
-rw-r--r--. 1 root root    16794 May 22 04:20 pxelinux.0
drwxr-xr-x. 2 root root     4096 May 22 06:50 pxelinux.cfg
-rw-r--r--. 1 root root        0 May 22 06:57 vmlinuz

# cat /var/lib/tftpboot/pxelinux.cfg/default 
default linux
kernel vmlinuz
append initrd=initrd.img

The guest could get an IP address, and it said,

No filename or root path specified
No more network devices

Version-Release number of selected component (if applicable):
libvirt-0.8.1-5.el6
dnsmasq-2.48-4.el6
syslinux-3.86-1.1.el6

How reproducible:
always

Steps to Reproduce:
1. setup a TFTP server
2. define a virtual network
3. start a guest to boot from PXE there.
  
Actual results:
Unable to boot from PXE.

Expected results:
Successfully boot from PXE.
Comment 1 Qian Cai 2010-05-21 10:39:52 UTC 
Correction -- the following has also been tested,

<network>
  <name>newpxe2</name>
  <forward mode='nat'/>
  <ip address="192.168.123.1" netmask="255.255.255.0">
    <tftp root="/var/lib/tftpboot" />
    <dhcp>
      <range start="192.168.123.2" end="192.168.123.254" />
      <bootp file="pxelinux.0" />
    </dhcp>
  </ip>
</network>
Comment 3 Jiri Denemark 2010-06-10 15:30:20 UTC 
This is a qemu-kvm bug. When a guest obtains DHCP ACK from dnsmasq, instead of trying to get pxelinux.0 from dnsmasq (running as tftp server) it sends out more DHCP Requests to port 4011, which fails as nothing is listening there. After replacing /usr/share/qemu-kvm/pxe-rtl8139.bin with similar file from upstream qemu, PXE boot works as expacted.
Comment 4 Jiri Denemark 2010-06-10 16:10:09 UTC 
Actually, looks like gpxe is the right component since /usr/share/qemu-kvm/pxe-rtl8139.bin was just a link to /usr/share/gpxe/rtl8139.rom which is provided by gpxe-roms-qemu package.
Comment 5 Dor Laor 2010-07-21 13:20:11 UTC 
Is it related to the latest net filter rule by Michael?
Does different nic emulation work (like virtio?)
Comment 6 Juan Quintela 2010-07-27 14:11:26 UTC 
I hit this bug here.  I have to call dnsmasq with --dhcp-no-override to get RHEL6 KVM to use PXE.  Without this option, RHEL5 and F13 hosts worked, but RHEL6 don't.

Just if it helps.
Comment 7 Amit Shah 2010-07-27 14:20:29 UTC 
I just installed an OS via PXE on a RHEL6 host. The PXE, TFTP, DHCP servers were not on the host itself. Perhaps the network topology matters for this to show itself.
Comment 8 Dor Laor 2010-07-27 14:26:03 UTC 
Michael, isn't that the netfilter bug that should be solved?
Comment 9 Michael S. Tsirkin 2010-07-27 14:56:01 UTC 
Talked to Juan, apparently he doesn't use nat so at least his
issue does not appear to be related.
Comment 10 Amit Shah 2010-07-29 04:09:17 UTC 
*** Bug 614307 has been marked as a duplicate of this bug. ***
Comment 11 Amit Shah 2010-07-29 04:19:13 UTC 
Upstream gpxe commit 1958974d0a59e0e374751d9d5c1405de0ffc8066 should be the one fixing this?

    [tftp] Process OACKs even if malformed
    
    IBM Tivoli PXE Server 5.1.0.3 is reported to send trailing garbage
    bytes at the end of the OACK packet, which causes gPXE to reject the
    packet and abort the TFTP transfer.
    
    Work around the problem by processing as much as possible of the OACK,
    and treating name/value parsing errors as non-fatal.
    
    Reported-by: Shao Miller <Shao.Miller.on.ca>

We're on gpxe-0.9.7, we should consider rebasing to newest upstream 1.0.1 for 6.1.
Comment 12 Amit Shah 2010-07-29 08:15:10 UTC 
Created attachment 435217 [details]
virtio-net rom from gpxe.git compile
Comment 13 Amit Shah 2010-07-29 08:16:52 UTC 
Can you try putting the attached rom file in /usr/share/gpxe/virtio-net.rom (replacing the older one after a backup) and trying again?

The attached file is from upstream gpxe 1.0.1 release, if that works, I can compile one with the commit mentioned above to confirm if that fixes this issue.
Comment 14 Amit Shah 2010-07-29 09:06:38 UTC 
This behaviour is documented on the gpxe page:

http://etherboot.org/wiki/dnsmasq

They suggest using the --dhcp-no-override parameter to work around as Juan has also confirmed as working.

Maybe this can be added to the release notes and the bug could be closed.
Comment 15 Michael S. Tsirkin 2010-07-29 09:33:25 UTC 
Let's reconsider for 6.1 then?
Comment 17 Jiri Denemark 2010-07-29 10:06:10 UTC 
Hmm, --dhcp-no-override parameter is not a viable release-notable work around when using dnsmasq launched by libvirt. We probably need to change libvirt to add this option everytime it launches dnsmasq.
Comment 18 Amit Shah 2010-07-30 07:23:50 UTC 
(In reply to comment #17)
> Hmm, --dhcp-no-override parameter is not a viable release-notable work around
> when using dnsmasq launched by libvirt. We probably need to change libvirt to
> add this option everytime it launches dnsmasq.    

libvirt launches dnsmasq only for dhcp, right? If you're not doing any tftp transfers, there's no need to change anything.
Comment 19 Jiri Denemark 2010-07-30 08:56:47 UTC 
(In reply to comment #18)
> libvirt launches dnsmasq only for dhcp, right? If you're not doing any tftp
> transfers, there's no need to change anything.    

No, not only dhcp. libvirt can be configured to start dnsmasq as a tftp server for PXE boot. (the configuration can be seen in comment 1).
Comment 20 Chao Yang 2010-08-06 07:17:20 UTC 
(In reply to comment #4)
> Actually, looks like gpxe is the right component since
> /usr/share/qemu-kvm/pxe-rtl8139.bin was just a link to
> /usr/share/gpxe/rtl8139.rom which is provided by gpxe-roms-qemu package.    

Hi Jiri,

I have already updated my gpxe-roms-qemu package, but still can't get pxe boot up.

Downloading Packages:
gpxe-roms-qemu-1.0.0-1.fc13.noarch.rpm                                                                                                                                                  | 229 kB     00:02     
Running rpm_check_debug
Running Transaction Test
Transaction Test Succeeded
Running Transaction
  Updating       : gpxe-roms-qemu-1.0.0-1.fc13.noarch                                                                                                                                                      1/2 
  Cleanup        : gpxe-roms-qemu-0.9.7-6.3.el6.noarch                                                                                                                                                     2/2 

Updated:
  gpxe-roms-qemu.noarch 0:1.0.0-1.fc13                                                                                                                                                                         

Complete!
[root@ts1 ~]#

Any suggestions? Thanks.

Best,
Chao
Comment 22 Eduardo Habkost 2010-11-19 14:31:08 UTC 
I have opened Bug 655062 to change libvirt to use --dhcp-no-override.

I am keeping this bug open for cases where the DHCP server is not under our control. But this would be lower priority as the most usual case is when using libvirt; and if not using libvirt, the admin can configure dnsmasq to use the dhcp-no-override option.
Comment 27 Anand Kumar B 2014-03-17 13:35:22 UTC 
I know it's not a permanent fix. But when I restarted the "network" service of the host the pxeboot worked. I was testing on CentOS6.3(host) and VM also Centos6.3.

However, installation failed while picking the KS.CFG due to VM-network shutdown.
Note You need to log in before you can comment on or make changes to this bug.