@3mu Will you show us a screen shot of the fog configuration->multicast settings page. I’m confused where its getting the dev name from. You don’t have the network interface setup as /dev/ens3 for some reason?

@JJ-Fullmer Just a short update on this issue: The NUC’s BIOS was outdated, and updating it failed for unknown reasons. We now replaced the NUC with a brand new one and hope to see the issue gone.

@george1421 So here is a capture with 2 request, on pxe at time 0 and at time 196 a usb boot ubuntu. When ubuntu loaded, ip a give good IP adress, good router and good netwask capturedhcp.pcap

@c70m83 Just to try and see why exactly those three (PC24, PC08 and PC12) seem problematic you might try to connect those to other ports on the switch where you know that other PCs work. As George said, PXE boot does not depend on Windows or any operating system. No matter what you have installed on disk PXE does work!! So if it used to work then something within your network / DHCP setup changed!

@robo Could you possibly provide the SQL dump so I can test? Please upload to a file share and send me a private message with the link.

@anon01013 Possibly the VirtualBox VM is set to UEFI but pfSense might not provide PXE boot information for UEFI clients? Note for everyone: As far as I see in the picture this output we see here from iPXE is NOT the one delivered from the FOG server but the one build into VirtualBox.

@mckay said in Repurpose the restart notification to work for running/delaying Snapins: Is this documented anywhere? Sorry no. Not because we want to keep this secret but because we don’t have enough time to document it all. I will try to give some answers on the options but as I haven’t been the author of that code I might not know all the details either. The parameters are given as JSON string. So action is the name of one parameter and request it’s value. As far as I understand the code this parameter is not used in this case. I just used it in the example because it’s used in the fog-client code like this as well. Testing a bit more I found that you can run it without that parameter: {"period": 60, "options": 2, "aggregatedDelayTime": 0, "message": "This is a test message."} (encoded: eyJwZXJpb2QiOiA2MCwgIm9wdGlvbnMiOiAyLCAiYWdncmVnYXRlZERlbGF5VGltZSI6IDAsICJtZXNzYWdlIjogIlRoaXMgaXMgYSB0ZXN0IG1lc3NhZ2UuIn0=) Now with the options parameter you can switch the button label (see code here). It will show “Hide” when you set options to the value of 2 or 0 but “Cancel” when set to 1. Please don’t ask me why. It’s just the way it was coded and I can’t tell you why. As mentioned before I have that feeling that might not get what you want to achieve using FOGShutdownGUI. I am not even sure if it’s worth investigating any further. Probably better to look forward to working-1.6 instead.

@JYost said in Fog 1.5.5 to 1.5.8 - Creating SSL Certificate - FAILED: Creating SSL Certificate …FAILED Please check the installer error log (/root/fogproject/bin/error_logs/) and post it here. Probably the last 15 lines will do. Don’t need the whole lot.

@jc35 So shutdown is not hanging anymore and fog-client functions as expected? Did you also test scheduling a power task to shutdown or reboot the machines?

This one is a bit hard to diagnose since you’ve provided so little information. Assuming all other systems pxe boot like you say, the fog server can probably be ruled out, as well as dnsmasq. The PXE rom lives on the network card/LOM so the PXE rom driver knows how to reach the network. So I would say network cable or you have 2 network adapters in that computer and you are trying to pxe boot from the wrong network adapter compared to where the pxe rom is running from.

Just to chime in here, 1.6 is now setup with innodb as default. So while we discuss things for 1.5.x, just know that this has been corrected.

@Arrowtron In addition to increasing your fog client checking time as was suggested by @Sebastian-Roth, and in addition to moving the database to InnoDB as suggested by @george1421 I’d recommend you go to 4 CPU cores.

Answering some of these in reverse I am pretty sure that the default group apply settings do overwrite fields with the empty fields but I’m not 100% on that which is by design. i.e. maybe you want to remove the ad settings on all computers in a group, you’d want it to overwrite with blank fields. I don’t use that plugin, so I’m not sure if that was one of the things it does different or not, it may be. It would probably be moderately difficult to change that in the plugin, but that’s just a guess. The domain trust issues could be fog related or rather a mix of things. I would suggest double checking your user/password on the group2 domain settings. Sometimes if there is already a computer with the same name a problem occurs, not always as that is something that should be allowed. I would check the c:\fog.log on any of the machines that are getting the errors. See if there are any error messages when fog joins them to the domain. The first thing I would suggest trying is disabling the plugin and trying normal groups or just individual hosts for a couple hosts to isolate if the problem is in FOG or in the plugin. I would also double check the quick registration settings in the fog server and double check the default ad settings in the fog server, maybe they are set to group1 and its overwriting things at some point.

What OS are you using to connect to the api? Shameless plug here for the api powershell module. I have a function called Set-FogServerSettings that helps with just inputting the api keys and it will handle the authentication from there with any function call. See the links in my signature. I originally made it cross-platform but it’s currently more windows oriented. Due to COVID-19 I am not working, which means I might have some free time (I say might because I also have a new baby). If you’re not running on windows I can dedicate some time to adding more linux support to the module since powershell core 6 and 7 are both cross platform on linux, mac, and windows. The module takes that simplified documentation and creates tab completable functions from the structure outlined in the documentation.

Thanks. It’s helped.

@tigervince30 Well as I see it you have 2 problems. The first one is the files are not being copied over to the target computer the second is that the pnputil is not setup to run. I would use the . ${postdownpath}/fog.custominstall over the /images/postdownloadscripts/fog.custominstall Just to keep the postdownload script portable between fog installs. Not all imaging directories are /images path. There is nothing wrong with calling out the full path, but the standard is to use the . ${postdownpath} (Oh!!) I just saw something, you enter /images/postdownloadscripts/fog.custominstall you missed the leading dot-space (. ) . /images/postdownloadscripts/fog.custominstall That would impact the execution of the install. So to debug the first problem, FOG has a specific debug mode that can be used to debug post install scripts. When you schedule a deployment you would tick the debug checkbox before you hit the Schedule Task button. Then pxe boot the target computer. That will place the target computer into debug mode. After a few screens of text that you need to clear with the enter key you will be dropped to a FOS Linux command prompt. At the command prompt key in fog and press enter to start the imaging. In debug mode the FOG install will stop at each breakpoint (debugPause) in the deployment process. This way you can watch and read error message that might happen during image deployment. Now you might want to add an echo statement at the beginning of the fog.custominstall script and modify it such as this. #!/bin/bash . /usr/share/fog/lib/funcs.sh echo "Starting post install scirpt" [[ -z $postdownpath ]] && postdownpath="/images/postdownloadscripts/" Also looking at the code, if the $postdownpath path variable is not set the entire postinstall script will abort. Its possible that the missing dot calling the script would do this (not populate that variable). That is some magic missing dot ( . ). During debugging you can exit out of the imaging script by pressing Ctrl-C. You can restart the imaging process without having to reboot by just keying in fog again. Your post install script should execute right after the last partition is imaged with PartClone.

@abulhol FOG doesn’t check the free disk space before capturing an image. We consider this something the admin needs to take care of. As well we can’t be really sure how much space a new image would actually take.

@tricyphona Have you tried disabling fast boot in Win 10 and do a full chkdsk before capturing? Is the partition on the client nearly full?

@plegrand Ops, I forgot to post here. This should be fixed in dev-branch now…

@Wayne-Workman Thanks heaps for mentioning this here! We should really update that wiki page to help people fix this. Newer versions of MySQL/MariaDB behave very different and we have changed the old way of using an empty DB password.