TFTP Open Timeout
-
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).
-
[B]It takes me so long to type that this post is completely irrelevant now. Solved above :).[/B]
I think you’ve already checked this, but it sounds like permissions on /tftpboot, you need both read and execute set on the directory, e.g.
[CODE]
$ ls -ld /tftpbootdrwxr-xr-x. 2 fog root 4096 Jun 17 14:46 tftpboot
$ ls -l /tftpboot
total 2592
-rw-r–r–. 1 fog root 840 Jun 17 14:46 boot.txt
-rw-r–r–. 1 root root 296 Jun 17 14:46 default.ipxe
-rw-r–r–. 1 fog root 389702 Jun 17 14:46 ipxe.kkpxe
-rw-r–r–. 1 fog root 389750 Jun 17 14:46 ipxe.kpxe
-rw-r–r–. 1 fog root 391231 Jun 17 14:46 ipxe.krn
-rw-r–r–. 1 fog root 389766 Jun 17 14:46 ipxe.pxe
-rw-r–r–. 1 fog root 25340 Jun 17 14:46 memdisk
-rw-r–r–. 1 fog root 16794 Jun 17 14:46 pxelinux.0.old
-rw-r–r–. 1 fog root 165088 Jun 17 14:46 snponly.efi
-rw-r–r–. 1 fog root 102777 Jun 17 14:46 undionly.kkpxe
-rw-r–r–. 1 fog root 102825 Jun 17 14:46 undionly.kpxe
-rw-r–r–. 1 fog root 382650 Jun 17 14:46 undionly.kpxe.INTEL
-rw-r–r–. 1 fog root 102841 Jun 17 14:46 undionly.pxe-rw-r–r–. 1 fog root 147728 Jun 17 14:46 vesamenu.c32
[/CODE]Assuming that is all OK you should be able to run tftp in the foreground to check for errors,
[CODE]
$ service xinetd stop
$ /usr/sbin/in.tftpd -vvv -s /tftpboot -L
[/CODE]
Then from another shell on your fog server try the get (in a directory where you have write permissions!)
[CODE]
$ tftp fog.stat.ubc.ca
tftp> get pxelinux.0.oldtftp> quit
$ ls -l pxelinux.0.old
$ -rw-r–r–. 1 root root 16794 Jun 20 15:31 pxelinux.0.old
[/CODE]When you’re done, remember to restart xinetd
[CODE]
$ service xinetd stop
[/CODE] -
Hi Tom,
I left work immediately after it started working. However, I will be happy to perform the tests you’re requesting when I get back there Monday morning. I’ll let you know what happens.
-Bruce D.
[quote=“Tom Elliott, post: 31045, member: 7271”]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).[/quote]
