TFTP Open Timeout
-
Have you triple checked that SELinux is disabled?
I know that sounds like it’s a joke, but for some 6.5 installs, the selinux config is actually in two locations. Something with the way it installs forces the link that’s supposed to be created become its own file. So, editing /etc/sysconfig/selinux (this is supposed to be a symlink) doesn’t do JACK! Sorry. So in this case, I’d recommend checking the actual config located in /etc/selinux/config.
-
Thanks for the info, Tom. You are correct that the file in /etc/selinux/config was enforcing (I had no clue that file was even there!). I changed that to disabled, reset, and tried the client again. This time, I’m getting a different error message: PXE-T00: Permission denied.
/var/log/messages reads:
Jun 20 16:51:51 localhost xinetd[1777]: START: tftp pid=2987 from=192.168.0.107
Jun 20 16:51:51 localhost in.tftpd[2988]: RRQ from 192.168.0.107 filename undionly.kpxe
Jun 20 16:51:51 localhost in.tftpd[2988]: sending NAK (0, Permission denied) to 192.168.0.107Same results for local TFTP.
-
Can you try this:
[code]chown -R fog:root /tftpboot
chmod -R 644 /tftpboot[/code]Then try again with bootup?
-
Done, but no change.
-
Are you running iptables by chance?
-
[code]service iptables status[/code]
If they’re running you’ll get lot of output.
We recommend disabling with:
[code]chkconfig iptables off
service iptables stop[/code] -
“service iptables status” gives
iptables: Firewall is not running -
What returns with:
[code]setstatus[/code] -
bash: setstatus: command not found
-
Sorry syntax:
[code]sestatus[/code] -
Ah! That command worked:
SELinux status: disabled
-
Grrrrr
From the same system can you use the tftp command to download the default.ipxe file?
-
Negative. Permission denied. (That is, using the command prompt tftp utility on the FOG VM itself.)
-
Grrrr, indeed!
-
Can you try:
[code]restorecon -r /tftpboot[/code] -
tried it withOUT reboot, no change. rebooting now.
-
no change after reboot. still permission denied.
-
[code]restorecon -Rv /tftpboot[/code]???
I’m trying anything/everything I can think of now. If that doesn’t work, try:
[code]chmod -R 777 /tftpboot[/code] -
Winner!
I didn’t think to re-change the ownership and permissions after the first restorecon. After your last post reminded me, I changed them back to fog:root and 777, and now the client is booting! Woo-hoo!
So, it looks like the restorecon (and then re-changing the permissions) did it. Any idea what the problem was?
(Oh, and a BIG thanks! I’d never have figured that out on my own.)
-
Well,
Can you do one more test?
We know 777 perms works, but that leaves it open for anyuser logged in to the system to delete it.
Can you reset the mod to
[code]chmod -R 644 /tftpboot
chmod -R fog:root /tftpboot[/code]My guess is the selinux wasn’t actually allowing the changing of the permissions when you were trying before.
Chances are most likely the restorecon released the locking rights which had been established upon your initial reboot after the /etc/sysconfig/selinux change (which didn’t work).
