Tasks not being processed
-
-
@Wayne-Workman
-rw-r----- 1 root adm 6935 okt 26 11;57 /var/log/apache2/error.log -
@Drevonovic see how it has double forward slashes in the path below?
/opt/fog//log/multicast.logand/opt/fog//log/fogscheduler.logthat can’t be right… -
@Wayne-Workman how can I change this? (I’m really new at this so sorry if this is a weird question)
-
@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.
-
This is the only link I can find to delete my host in the host list. Don’t think it is this you meant? -
@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
-
@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:
-
@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
-
Is the host virtual or physical?
-
@Wayne-Workman The host is physical, the server is virtual
-
@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.pcapLeave that and open the apache log in the second window:
sudo tail -f /var/log/apache2/error.logHit 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).
-
@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 -
@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.
-
@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.
-
@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.
-
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”
-
@Uncle-Frank bootmenu.pcap
The error.log didn’t give any new lines when I was capturing.
-
@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…
-
@Drevonovic why are you loading pxelinux.0 as the boot file rather than one of the undionly files?
