Posts made by zpoling

@george1421 Don’t spend too much time on it if at all since it’s working now. I’d love to know why it wasn’t working, but I assume those packet captures aren’t going to show jack since they weren’t captured during the issue’s occurrence.

@george1421 Here you go. Taken from my computer on VLAN 3, attempting a pxe boot on the computer that was having an issue. Though like I said, it seems to be working fine now.

0_1541174066153_vlan3computer.pcap

The computer in question is 10.32.10.118, DHCP server is 10.32.0.224, and the fog server is 10.32.0.31.

@george1421 No, it was a TCPdump from the fog server.

@george1421 I would love to send you a pcap of the issue, but it’s no longer happening. I’ve tested several work stations a couple dozen times. They’ve all been fine.

So the VLAN 3 pcap was not enough to see what was going wrong?

@george1421 I don’t know how it couldn’t be sending the option out properly. If I have them set globally and every subnet works besides one of them, I don’t know what it could be. Unless someone happened to plug in a DHCP server enabled device to that subnet, but there doesn’t appear to be any evidence of that anywhere.

I’m sure this isn’t fog, but I’m still at a loss.

@george1421 Notice in my picture that PXE boot stalls at “Please enter tftp server:” where I must enter the fog IP manually. On all the computers on vlan 3 that haven’t been booted up yet, they will stall at this section of the PXE boot. I don’t feel like getting more calls about this.

Around noon, every computer that will be turned on for the day should be turned on, so I’ll turn the options back on and begin testing.

@Sebastian-Roth I’ve opened another thread about it. I ran a program that scans for DHCP traffic because I’m not too familiar with wireshark, but it does the same thing I imagine. After three hours, the only traffic showing up was our one and only DHCP server.

https://forums.fogproject.org/topic/12615/tftp-only-working-with-certain-vlans/2

@george1421 The vlan 3 pcap is the one that doesn’t work. I’ll make another pcap later today. I can’t turn the option 66 and 67 back on right now, as it’ll prevent computers on the network from booting.

@drewklein22 Windows Server 2012 R2. Option 66 and 67 are global, but having them specific to the scopes doesn’t change the result unfortunately.

Fog 1.5.4
Ubuntu 16.04 LTS

We began having issues this morning that prevented computers on a different VLAN than the fog server from finding the TFTP server; it would request us to enter the TFTP server address. Going through a few threads, it seems that this is caused by multiple DHCP servers, but we only have one. Throughout the day, I tested a few more VLANs. It appears that there’s only one VLAN having issues.

I ran sudo tcpdump -w output.pcap port 67 or port 68 or port 69 or port 4011 while PXE booting over both VLANs. VLAN 2 (and others) works, VLAN 3 doesn’t. I don’t really know what to be looking for, so I’ll attach the pcaps.

1_1541098906654_vlan3.pcap
0_1541098906651_vlan2.pcap

@george1421 Yes, it is Ubuntu. That article fixed it. Time to tackle the other issue.

Edit: That actually took care of my other issue too!!

EditEdit: Or not. Now it’s just intermittent.

We began having issues this morning that prevented computers on a different VLAN than the fog server from finding the TFTP server; it would request us to enter the TFTP server address. Going through a few threads, it seems that this is caused by multiple DHCP servers, but we only have one. I have a pcap file showing this.

Something I always do when we have odd fog issues is reboot the server. If that doesn’t work, I rerun the installer. I did this specifically because I thought /maybe/ the fog DHCP may have turned on somehow. Once the installer finished, it said that the fog password change was failed. No biggie, I know where to change it myself; I verified it’s correct in all the server locations. However, now I’m unable to reach the web GUI at all. All I see on the GUI is “Database connection unavailable.”

@george1421 Fog has been working, but I haven’t had any machines to test a multicast on since we last spoke. I am going to attempt to image a classroom today and will report back.

@george1421 Okay I think I found what you were requesting. I installed 4.15.2 x64 and x32, but I’m not sure what to do now. I assume I have to tell Fog to use one of those specifically rather than the most current?

@george1421 Yes, there was only one www.conf file.

I also have to apologize. I have no idea where to begin to downgrade the kernel. I’ve cringed every time I ever see kernels mentioned because I have no clue what it even is.

I now can’t reach http://fogserver/fog. I get a 503 error. I am able to reach http://fogserver and /html/

Should I change the settings back?

Edit: I changed pm.min_spare_servers to 5.

pm.max_spare_servers was set to 3. I changed it to 5 and it began working again.

@george1421 Done. The memory_limit line already existed, but was set to 32M. The other lines existed as well, but were set to lower numbers. pm.max_requests was the only correct one.

However, this was happening before I updated to 1.5.4. Or did the issue exist before then as well?

@george1421

Quick thing about the VLANS. We added a voice VLAN recently, but the port was not set to that, nor was it trunked with it. I think it was just a goof because non of the other machines did it. Unless there’s some odd multicast issue due to adding a voice VLAN.

The server is Ubuntu Server 16.04 LTS

I originally said that only one machine was stuck here, but there were actually two of six stuck here. The others made it past this point then got stuck at PXE boot. The second image is what was happening back on Friday when I made this post.

After a few reboots of the server, I was able to login again. I never shut the machines off, so the machines that were stuck at “updating database” just retried over and over. Once the server came back up, they all were able to make it past this step and completed successfully.

One machine is stuck after imaging at “Updating Database” and the original issue is occurring once again.

More oddities. I tried imaging one of the machines that I tried on Friday. Pxe boot pulled the correct IP, but then once Fog booted, it was trying to pull an IP from a different VLAN. I changed the switch port to the VLAN that it was trying to pull from, Pxe boot pulled the address that fog was attempting to pull before, and everything worked fine. Never had to have my machines on a specific VLAN before.