that worked, thanks everyone for the troubleshooting.

@msaglioc99 Has it worked in the past? What changed? Network, router, …?

Another thing that shows up in the log:

Several of the modules (for example: TaskReboot or the HostnameChanger) list:

Middleware::Response Module is disabled on the host

Where would I even do that? On the server - as far as I can see from the web-gui - the modules are activated. I also deactivated and reactivated them to see if that would kickstart anything - no success.

EDIT:
Okay … I just saw that one of the two hosts I deployed the image to had the modules deactivated in the Service Settings. I have no idea why, it is enabled globally and the other machine does not have them deactivated.
Now in the fog.log the Modules are shown with a response success on the one machine (the one that had the services disabled) but the “Unable to get subsection” message still appears on the other machine.

EDIT2:
The computer that had the services disabled just restarted - so in that case it seems everything works.

EDIT3: After reading some more I tried resetting the Encryption Data and aw and behold - everything seems fine now. Thanks for reading along if you have 🙂

Sorry if I’m being complicated - just trying to figure this out 😕

Thanks George !
Sorry for thanking you too late but i didn’t think that i will get the answer that fast haha !
Anyway Thanks again !

#Resolved

@sebastian-roth I worked around the issue using an iPXE boot ISO.

@dirtyhandz lets start with how did you create this dvd to begin with? Did you have instructions?

-Or- My intuition just said; break that dvd into smaller bits. A win32 iso, a win64 iso and then utilities iso.

@JLE Looks quite interesting that packet dump. Something I have not come across in a long time. I am trying to write down what I see in the PCAP to hopefully make any sense as I don’t see what’s wrong yet. Maybe George can add to that as well.

First the PXE ROM of the NIC sends a DHCP Discover and does not get an answer. So 8 seconds later it sends another Discover (same information but just a new DHCP transaction ID). The second DHCP Discover is answered with a DHCP Offer very promptly (delay only ms). Transaction IDs of the second Discover and the following Offer match so the answer is definitely not a delayed one to the first Discover. Question: Why is the first DHCP Discover not answered? (this is happening again later on) As far as I can see the DHCP Offer looks good (next-server and filename set properly). Now the client is quiet for 16 seconds before sending a DHCP Request packet to complete the DHCP communication. This Request packet is promptly answered by a proper looking DHCP ACK. So client is finally happy I suppose. Then I suspect the TFTP transfer to happen which was not captured. See the next bullet point. Another 12 seconds after the first DHCP DORA (Discover, Offer, Request, ACK) finished I see a new DHCP Discover from that client. This time option 175 is set which is a clear sign for iPXE sending the packet. And the same thing is happening again. No answer from the DHCP server for 8 seconds and the client (now iPXE instead of the PXE ROM) sends another DHCP Discover which is promptly answered with a fine DHCP Offer. After the Offer the client sends a third DHCP Discover and then a DHCP Request just a second later. I think this is where things start to go really wrong. I suppose iPXE is very confused about the DHCP server only answering the second DHCP Discover (matching transaction ID). I haven’t checked the iPXE code yet but I guess this is something unexpected now causing an issue in your case. Following are a row of DHCP Request packets from the client which are all answered by DHCP NAK (non ACK!) packets. So the DHCP server declines to give that offered IP information to the client. Result is the “No configuration methods succeeded” message in iPXE. In the packet dump I see the same thing happening again a minute later. But one thing is different this time. The very first DHCP Discover sent by the client’s PXE ROM is answered within one second this time. But for the DHCP Discover sent by iPXE I see again the exact same behavior as described above.

I guess this can be fixed in iPXE but I doubt this is the right place to do so. There is something wrong within your network. Do those first DHCP Discover packet get lost somewhere along the way? Why is the second one answered so promptly then?

Ok, I’ll leave this ti you for now. We all need to think about it and I am sure someone will come up with a proper explanation on what’s going wrong here.

@Krassus Please run ls -al in that desktop/fog_1.4.4/bin directory and post the full output here. I suppose there is something wrong with the files. Are you still using the “transfered” files or did you use git pull to get a fresh copy after connecting to the internet?

@krassus said in Going to Management page and get blank screen, any help would be great. Thanks:

@krassus said in Going to Management page and get blank screen, any help would be great. Thanks:

@george1421 said in Going to Management page and get blank screen, any help would be great. Thanks:

@krassus Did you answer yes to install isc-dhcp server? If not you would issue this command prompt
sudo systemctl disable isc-dhcp-server
sudo systemctl stop isc-dhcp-server

I got no prompt in the installer to install DHCP services but I did see it say it was doing so.
I will run the below commands. Thank you again.

Right now I am doing a test capture. You guys are on it, this forum is great with how quick on responses are given and the notification system.

Capture Look liked it work just fine. Pushing the image back was unsuccesful and never threw an error. Booting back into PXE to retry and this is what loads. Ideas?

0_1501795579202_FOGError.JPG

I am going to make a new thread for this since it looks to be dead.

@zingaro Here are some resources:

https://wiki.fogproject.org/wiki/index.php?title=NAS_Storage_Node
https://forums.fogproject.org/topic/9430/synology-nas-as-fog-storage-node/1

There are others you can find too if you just search for the key words.

The issue looks to be fixed since I changed the boot file name. This thread can be marked as closed/solved. Thanks again for everyone’s help.

@george1421 I’ll try to get this fixed, I thought I already did, but I might have missed it already sorry.

@Tom-Elliott Yes it is safe to solve now, sorry for the delay. Thanks again!

@george1421 I’m sorry, it really seemed (to me) that was the same issue (exactly same errors deploying an old image with a >1.3.x)

Now I can confirm that it was an issue copying the /images folder.

Thank you for your suggestion on zstd, I’ll change the compression method at the the next capture.

@chris178 There is a right way to do this and an easy way.

Easy route.

Download both .sh files to your FOG server. Then make both executable. by running this command chmod 755 *.sh Install the script by running ./install.sh Done.

@Tywyn Probably there was the multicast interface setting (FOG web GUI -> FOG Settings) still wrong.

Not sure about the performance issue now. Please check layer one (hardware, switch) first.

@sebastian-roth said in Changed IP of Fog, dhcpd is not starting anymore...:

/etc/default/isc-dhcp-server

That was it.
I changed it, because indeed there was the old interface in there. Now the dhcpd works fine.
I also found, that in /tftpboot/default.ipxe was the old IP-Address.

Maybe these two places are worth to be mentioned in https://wiki.fogproject.org/wiki/index.php?title=Change_FOG_Server_IP_Address

Now I have another problem, but I will open a new thread for this 🙂

Thanx everybody for your help!
Rainer

To create a menu in the advanced one, you must fill it in under iPXE General Configuration -> Advanced Menu Settings > Advanced Menu Commands

example:

:urls set msdart-url http://192.168.1.155/2-MSDART :MENU menu colour --rgb 0xff0000 0 || cpair --foreground 1 1 || cpair --foreground 0 3 || cpair --foreground 4 4 || item --gap -- ------------------------------------- item fog.local Boot from hard disk item msdart6x86 Microsoft DaRT for Windows Vista 32bit item msdart6x64 Microsoft DaRT for Windows Vista 64bit item msdart7x86 Microsoft DaRT for Windows 7 32bit item msdart7x64 Microsoft DaRT for Windows 7 64bit item msdart81x86 Microsoft DaRT for Windows 8.1 32bit item msdart81x64 Microsoft DaRT for Windows 8.1 64bit item fog.return Return to previous menu choose --default fog.local --timeout 5000000 target && goto ${target} :fog.local sanboot --no-describe --drive 0x80 || goto MENU :msdart6x86 initrd ${msdart-url}/MSDaRT60x86.iso chain memdisk iso raw :msdart6x64 initrd ${msdart-url}/MSDaRT60x64.iso chain memdisk iso raw :msdart7x86 initrd ${msdart-url}/MSDaRT70x86.iso chain memdisk iso raw :msdart7x64 initrd ${msdart-url}/MSDaRT70x64.iso chain memdisk iso raw :msdart81x86 initrd ${msdart-url}/MSDaRT8.1x86.iso chain memdisk iso raw :msdart81x64 initrd ${msdart-url}/MSDaRT8.1x64.iso chain memdisk iso raw :fog.return chain http://${fog-ip}/${fog-webroot}/service/ipxe/boot.php?mac=${net0/mac} || prompt goto MENU

@sebastian-roth Thanks for the suggestion, those commands are handy. I ran --recreate-CA alone & with --recreate-keys and just got a newer version of that same strange cert. I’m looking into it now but I believe someone may have customized the openssl.cnf file on our template, and something with that may be causing this behavior.

Ok I don’t know why, but creating a new user on the GUI made the disk usage come back !

Maybe it has updated the db ? Really don’t know but IT WORKS ! You can mark it as “Solved”.

Thanks for your help 😉