TFTP Server Working, but get PXE error
I had been trying for the past 2 days to get the PXE service to work, but I am having a difficult time. TFTP is working because I was able to connect to the FTP server and read files with a client, but for some reason, even though I define pxelinux.0 as a file name in the dhcpd.conf file, it still doesn't see it and the file is in the tftp directory. This is how the dhcpd.conf file looks like (Note that anything in Parenthesis is actually not in file and just information to clarify what is what like what ip address is used on what kind of server):
option domain-name "domain.local";
option domain-name-servers 192.168.1.1 (server running dhcp and tftp), 192.168.1.254 (router on network; is it even necessary?);
default-lease-time 600;
max-lease-time 7200;
authoritative;
basic subnet declaration
subnet 192.168.1.0 netmask 255.255.255.0 {
range 192.168.1.3 192.168.1.25;
filename "pxelinux.0";
next-server 192.168.1.1; #server that is hosting DHCP and TFTP
option subnet-mask 255.255.255.0
option broadcast-address 192.168.1.255;
option routers 192.168.1.254;
}
and then the xinetd.d file looks like this:
service tftp
{
disable = no
socket_type = dgram
protocol = udp
wait = yes
user = root
server = /usr/sbin/in.tftpd
server_args = -s /var/lib/tftpboot
per_source = 11
cps = 100 2
flags = IPv4
}
I never setup an TFTP server before (speaking of which, I am still a Red Hat newbie) so I utilized as much online sources as I could and I finally give up. The pxelinux.0 file is in /var/lib/tftpboot and i did create a pxelinux.cfg folder as well as creating the "default" file in pxelinux.cfg. I am really stuck. Any help is appreciated.
Responses
Hi Michael!
You might want to enable further logging in your dhcpd as well as in your tftpd, if you didn't do already.
Does DHCP itself work (without the tftp-part)?
Which (/etc/)redhat-release do you run and did you install all services from the official repositories or from any other sources (what might, in my experience, lead to issues with SELinux -> /var/log/audit/audit.log)?
Kind Regards,
Andreas
Community Member
70 points
Andreas:
You mean DHCP giving out addresses? That does work. I have two other machines on network and they are assigned an IP address automatically. It is 6.4 (Santiago) and Kernel version is 2.6.32-358.23.2.el6.x86_64. I understand I use cat or vi to look through a log, but how can I search by keyword so I only see the stuff contained in the log that relates to my issue?
In vi you can just type a slash ( / ) followed by the expression you are looking for to search from cursor towards end-of-file. By typing a question-mark ( ? ) followed by the expression you can do the same from bottom to top. As for cat it might be useful if you pipe your output into grep:
cat /var/log/somelogfile | grep -i somethingyouarelookingfor
Also, what log files do I need to look at for my case?
update:
I see something on the link that you provided me to log DHCP activity where it states:
"You may wish to enable logging of DNS updates on your DNS server. To do so, you might write a logging statement like the following:
logging {
channel update_debug {
file "/var/log/update-debug.log";
severity
debug 3;
print-category
yes;
print-severity
yes;
print-time
yes;
};
channel security_info
{
file
"/var/log/named-auth.info";
severity
info;
print-category
yes;
print-severity
yes;
print-time
yes;
};
category update { update_debug; };
category security { security_info; };
};
You must create the /var/log/named-auth.info and /var/log/update-debug.log files before starting the name server. For more information on configuring ISC BIND, consult the documentation that accompanies it. "
Is this what I want?
No, i don't think that part helps a lot. It seems to be about logging updates to your DNS by clients. The more interessting logging should be the one made by your tftp-service. tftpd-manpage gives a hint, that you might wanna add -v in server_args (in your xinetd-config), to get more information.
Community Member
70 points
I hate to keep doing multiple replies, but I was looking into logging xinetd and I found this
https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/3/html/Reference_Guide/s1-tcpwrappers-xinetd-config.html
I am trying to make it so it logs to authpriv but when I do a xinetd service reset, it fails to stop and when I check the status of service, I get "xinetd dead, but subsys locked"
Seems like there is no (working) xinetd-process, but a lock-file existing somewhere inside /var/lock, maybe /var/lock/subsys. You might have to kill the tftpd-process yourself. Try the following...
fuser 69/{tcp,udp}
to identify any process(es) listening on the tftp-port. Use kill followed by the PID to end them, in case there are any. Otherwise just find and remove the lock-file:
find /var/lock/subsys -name xinetd -type f -exec rm {} \;
service xinetd status should be fine by then.
Did you start tftpd by hand maybe, instead of invoking it via service xinetd start?
Active Contributor
148 points
make sure you have this file pxelinux.0 on /var/lib/tftpboot, if dont please install by command yum install syslinux
make sure on dhcpd.conf option next-server is point to your tftp server
Michael,
First question, is the DHCP server the same as the TFTP server? If so, eliminate the "next-server 192.168.1.1; #server that is hosting DHCP and TFTP" line. The PXE client will try the same server for TFTP services.
Have you checked firewall configuration on the TFTP server? TCP/UDP 69 needs to be available for TFTP.
Is the client getting a DHCP address from the new pool? I noticed a missing semi-colon on the following line:
option subnet-mask 255.255.255.0
That may just be a copy / paste error, but make sure you are getting an address on the console.
Watching the console of the booting client can tell you as much as editing logs. The three things to watch for: new DHCP address info in the right pool, PXE client requesting the file from the right server, PXE client successfully downloading the file. Once there, PXE is done and other issues may arise.
-Matt
Guru
6863 points
Depending on how you populated your /var/lib/tftpboot the file placement may have screwed up the SElinux contexts. Either way, to be safe you can do the following:
-- See if you are running SElinux
# getenforce
-- If it is encoforcing, run
# restorecon -RFvv /var/lib/tftpboot
Can you reply back to us with the output from:
ls -laZ /var/lib/tftpboot
getenforce
iptables -L
Also - you mention in your first post "FTP" and a client. Are you able to "tftp" to your host from another client?
Community Member
70 points
ls -laZ /var/lib/tftpboot
drwxr-xr-x. root root system_u:object_r:tftpdir_rw_t:s0 .
drwxr-xr-x. root root system_u:object_r:var_lib_t:s0 ..
-rw-r--r--. root root system_u:object_r:tftpdir_rw_t:s0 chain.c32
-rw-r--r--. root root system_u:object_r:tftpdir_rw_t:s0 e1000-0x100e.rom
drwxr-xr-x. root root system_u:object_r:cobbler_var_lib_t:s0 grub
-rw-r--r--. root root system_u:object_r:tftpdir_rw_t:s0 mboot.c32
-rw-r--r--. root root system_u:object_r:cobbler_var_lib_t:s0 memdisk
-rw-r--r--. root root system_u:object_r:cobbler_var_lib_t:s0 menu.c32
-rw-r--r--. root root system_u:object_r:tftpdir_rw_t:s0 ne.rom
-rw-r--r--. root root system_u:object_r:tftpdir_rw_t:s0 pcnet32.rom
-rw-r--r--. root root system_u:object_r:cobbler_var_lib_t:s0 pxelinux.0
drwxr-xr-x. root root system_u:object_r:cobbler_var_lib_t:s0 pxelinux.cfg
-rw-r--r--. root root system_u:object_r:tftpdir_rw_t:s0 rtl8029.rom
-rw-r--r--. root root system_u:object_r:tftpdir_rw_t:s0 rtl8139.rom
-rw-r--r--. root root system_u:object_r:tftpdir_rw_t:s0 system_u:object_r:cobbler_var_lib_t:s0
-rw-r--r--. root root system_u:object_r:tftpdir_rw_t:s0 system_u:object_r:tftpdir_rw_t:s0
-rw-r--r--. root root system_u:object_r:tftpdir_rw_t:s0 undionly.kpxe
-rw-r--r--. root root system_u:object_r:tftpdir_rw_t:s0 virtio-net.rom
getenforce:
Enforcing
iptables -L:
Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
ACCEPT icmp -- anywhere anywhere
ACCEPT all -- anywhere anywhere
ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:domain
ACCEPT udp -- anywhere anywhere state NEW udp dpt:domain
ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:ftp
ACCEPT udp -- anywhere anywhere state NEW udp dpt:netbios-ns
ACCEPT udp -- anywhere anywhere state NEW udp dpt:netbios-dgm
ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:netbios-ssn
ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:microsoft-ds
ACCEPT udp -- anywhere anywhere state NEW udp dpt:netbios-ns
ACCEPT udp -- anywhere anywhere state NEW udp dpt:netbios-dgm
ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:ssh
ACCEPT udp -- anywhere anywhere state NEW udp dpt:tftp
ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:ms-wbt-server
ACCEPT udp -- anywhere anywhere state NEW udp dpt:ms-wbt-server
ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:tftp
ACCEPT udp -- anywhere anywhere state NEW udp dpt:tftp
REJECT all -- anywhere anywhere reject-with icmp-host-prohibited
Chain FORWARD (policy ACCEPT)
target prot opt source destination
REJECT all -- anywhere anywhere reject-with icmp-host-prohibited
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
For your question about tftp to my host from another, yes
Community Member
70 points
---I had a reply that I couldn't get an TFTP client from another machine "get" file from TFTP server, but I was able to get it to work now. Ignore this reply.---
---The reply before this one is still applicable---
Guru
6863 points
I forgot the most important part of my response (and I have been in this exact spot where you are - followed directions perfectly yet things just-don't-work).
I would try turning off some of the protective services/measures, one-at-a-time, until everything works. Starting with SELinux
# setenforce 0
-- Try pxe-boot
# service iptables stop
-- again... Try pxe-boot
Your SELinux contexts look similar to my system.
However - I don't see DHCP open in your firewall rules (I don't know if you mentioned if you had a separate DHCP server - Sorry;-) Here is what I have for my pxe-with-kickstart system
-A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT
-A INPUT -p udp -m state --state NEW -m udp --dport 67 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 68 -j ACCEPT
-A INPUT -p udp -m state --state NEW -m udp --dport 67 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 67 -j ACCEPT
-A INPUT -p udp -m state --state NEW -m udp --dport 69 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 69 -j ACCEPT
-A INPUT -p udp -m state --state NEW -m udp --dport 53 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 53 -j ACCEPT
-A INPUT -p udp -m state --state NEW -m udp --dport 80 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 80 -j ACCEPT
Micheal - can you move the file name pxelinux.0 after next-server and see if that works .
like this-
next-server 192.168.1.1; #server that is hosting DHCP and TFTP
filename "pxelinux.0";
Guru
6863 points
I just looked at my DHCP.conf and noticed one slight difference..
next-server 192.168.0.11; # name of your TFTP server
#next-server 192.168.0.131; # name of your TFTP server
filename "/pxelinux.0";
Notice that I have a leading '/' before pxelinux.0
Here is my entry in /etc/xinetd.d/tftpd
server_args = -s /var/lib/tftpboot
Red Hat
Pro
694 points
Hi Michael,
Within /var/log/messages on your DHCP server, do you see DHCP requests when your client is attempting to boot? As mentioned before you may need to confirm that:
The dhcpd service is running:
# service dhcpd status
If you don't see logging there from DHCP ( in the form of REQUEST, OFFER, ACCEPTANCE) then you probably need to see if clients can reach dhcpd.
We usually recommend stopping and restarting iptables to see if there's a change in behavior with it off:
# service iptables save
# service iptables stop
Test from the client again, see if you see DHCP logging. If dhcp is working ok, then consider adding some more verbose logging to your tftp configuration as previously recommended:
In /etc/xinetd.d/tftpd:
server_args = -s /var/lib/tftpboot -vvv
And reload xinetd:
service xinetd reload
Then start checking to see if you have requests coming through. Tftp requests can also be tested from a standalone tool like lftp. Usually its a good idea to install that on the tftp server itself, and see if you can request files manually from first localhost, then your actual IP:
# yum install lftp
# lftp -c "get ftp://127.0.0.1/pxelinux.cfg"
If that works but:
# lftp -c "get ftp:// 192.168.1.1/pxelinux.cfg"
Doesn't, then you'll need to consider network access problems such as firewall, etc.
Hope that helps if you haven't already gotten this squared away.
Community Member
70 points
Sorry I haven't responded in a while. I gave up on setting up TFTP services. It was too much the effort to set it up. I might try again in the future, but I will just wait until I really need it. This discussion is valuable information that can help myself and others that have a hard time setting up TFTP services. I am going to save all this in a document. Thanks for the help anyway.
Guru
6863 points
No worries Michael - I (for one) completely understand. As I mentioned before, I had been in your shoes, numerous times, in fact. I can only assume other folks have been there too. There is simply a significant number of components in the equation. Please be sure to stop back and update this thread when you revisit the issue and discover what the solution is.
Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.