Tasks not being processed

[Wayne Workman]

@Drevonovic see how it has double forward slashes in the path below?

/opt/fog//log/multicast.log and /opt/fog//log/fogscheduler.log that can’t be right…

[Drevonovic]

@Wayne-Workman how can I change this? (I’m really new at this so sorry if this is a weird question)

[Wayne Workman]

@Drevonovic I’m not exactly sure, I haven’t seen that sort of issue before.

But, coming back to your registration issue, have you tried to delete the host from the DB and then re-register it?

When you select the host in the Web UI, towards the left at the bottom there should be a link for deleting.

[Drevonovic]

This is the only link I can find to delete my host in the host list. Don’t think it is this you meant?

[Drevonovic]

@Wayne-Workman Also, I cannot manage to find these 2 log files. /opt seems to have a map log in it, but don’t have any content :s

[Wayne Workman]

@Drevonovic I think that little remove link would work just fine. 1.2.0 looks worlds different than the current developmental version. So just delete that host and try to re-register it.

Here’s the delete link I was talking about:

[Drevonovic]

@Wayne-Workman In that case, yes I already tried that. It let me register the host again, it comes up in both the WEB UI as in the fog server, but the header of the menu isn’t changing

[Wayne Workman]

Is the host virtual or physical?

[Drevonovic]

@Wayne-Workman The host is physical, the server is virtual

[Sebastian Roth]

@Drevonovic The best I can offer now is to take a look at a packet dump. Capture packets while the client in question boots up so we can exactly see which request is send and which answer is generated.
For that please open two terminals on your server. Make sure that most of your browser windows and clients are closed/shutdown so that we don’t have too much other stuff interfering and filling the logs. In the install and run tcpdump:

sudo apt-get install tcpdump
sudo tcpdump -i eth0 -w bootmenu.pcap

Leave that and open the apache log in the second window:

sudo tail -f /var/log/apache2/error.log

Hit Enter twice or so that you see where it started last. Now boot up the client til you see the menu. Stop both commands with Ctrl+c and upload the PCAP file as well as the lines you see in the error.log (copy&paste).

[Drevonovic]

@Uncle-Frank I will do this the first thing tomorrow. I don’t have my environment available today which makes it hard to test this Let’s hope we can find something tomorrow

[Tom Elliott]

@Drevonovic does this system have multiple nics? Are both of these nics connected and getting ip addresses? It sounds, to me, like the nic that is pxe booting is not the nic that is registered to this host.

[Drevonovic]

@Tom-Elliott It shouldn’t. The network of my Virtual machine is set on bridged and the machine I’m running the VM on has only 1 NIC.

[Tom Elliott]

@Drevonovic What I mean,

When the system in question is network booting, it should show the MAC Address of the host that’s getting the IP Address. You can pause it when it’s obtaining the IP Address. If you look at the registered host’s mac address as displayed in the GUI and compare it to the one on the PXE screen, are they the same.

[Drevonovic]

Update: Before I tried @Uncle-Frank his packet dump, I did a wireshark capture while booting up the host. It gave me some information considering the TFTP packages.

The only file in /tftpboot/pxelinux.cfg/ is “default”

[Drevonovic]

@Uncle-Frank bootmenu.pcap
The error.log didn’t give any new lines when I was capturing.

[Sebastian Roth]

@Drevonovic Did you know that you have two DHCP server answering discoverys from your client? 192.168.1.102 and 192.168.1.1… Both offering an IP to the client. I think this is not causing your issue (because only one is offering pxe filename) but still this is not something you want I guess!

Please check your pxelinux.cfg/default! Do you see the ‘max/mac’ typo??

...
KERNEL ipxe.krn
APPEND dhcp && chain http://192.168.1.102/fog/service/ipxe/boot.php?max=${net0/mac}
...

This is why I love tcpdump/wireshark. You really see what’s being send over the wire…

[Tom Elliott]

@Drevonovic why are you loading pxelinux.0 as the boot file rather than one of the undionly files?

[Drevonovic]

@Tom-Elliott Before I had this error, my hosts weren’t able to find any PXE files with the error “default.ipxe… No such file or directory”. Following the instructions on https://wiki.fogproject.org/wiki/index.php/Chainloading_PXE_to_iPXE_using_pxelinux.0 solved this problem

@Uncle-Frank “chain http://192.168.1.102/fog/service/ipxe/boot.php?max=${net0/mac}”
I’m betting “max” should be mac?
However, using nano on this file on my server, it gives this as an output.

[Sebastian Roth]

@Drevonovic Right, give ‘mac’ a go and see if it works!

Please post a listing of your tftp directory ls -al /tftpboot. Sounds like default.ipxe might have wrong permissions?!

Or try tcpdump again to see if it really requests the correct file…