@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!

@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.

@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.

@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.

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.

@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.

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.

@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.

@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.

@jhumpf When the task comes to the end you might pay attention to the output on screen on the hosts’ display. I am fairly sure you see an error when it does the step “Updating Database…”. Please take a picture of the error message and post that here.

@juels said in Zyxel USG40 DHCP Pool: Actually I don’t need dual NICs since the server is located in my department, so I can just access it when I need it. I actually just want a FOG server and a 24port switch connected so I can connect my workstations for deployment, but what about dhcp then? Well you do and you don’t. To install FOG the fog server needs to have internet access. BUT FOG gets cranky when you change its IP address after FOG is installed. So its best to have 2 network interfaces. One for management and internet access to install/upgrade FOG and one for imaging (if you want an isolated imaging network, not specifically required). If you have an isolated imaging network then you will need to configure the FOG server to be the dhcp server for the imaging network. Just understand the system’s imaged on the imaging network won’t have access to the rest of your network including the AD server if the target servers will connect to AD. If you are concerned about network traffic AND as part of the imaging process your computers need to reach out of the isolated network you are better off not to use an isolated imaging network. You can modify your design a bit to plug the fog server and computers to be imaged on that 24 port switch, then plug that 24 port switch into your business network. All imaging will stay local to that 24 port switch but the clients that are imaged will be able to reach your business network servers and the internet if needed.

@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?

@msi I am wondering why you have two IP addresses within the same subnet assigned to your FOG server? Any good reason to do this? I also noticed that it is using enp0s31f6 IP address instead of p2p3 IP (192.168.1.230). is it normal since both IP’s are working when accessing the web console? FOS uses the IP set as FOG_WEB_HOST (FOG Configuration) to call out to the FOG webserver. I suppose you have set 192.168.1.230 in that field, right? That shouldn’t matter from my point of view. If you have checked all the passwords and resynced as described by George I may ask you to do a simple FTP test: https://wiki.fogproject.org/wiki/index.php?title=Troubleshoot_FTP

@danieln So if you key in http://10.50.0.218/fog does it display any page or error message? Displaying the default apache page is great. That tells you the web server is installed and operational.

@Sebastian-Roth said in Stuck at bzImage after selecting image to deploy: Please check BIOS/UEFI firmware version. Are those exactly the same as well? I will check once we’re back in the office. As you may have guessed, we’re all WFH now and our fog server is back in the office so might be some time before I have a chance to test again. I will try updating to latest BIOS and try again. Do you really mean init.xz here? Above you say stuck on bzImage. Not sure if that makes a difference but I just want to make sure we talk about the same things here. So is it all stuck at the same spot that we see in the picture with bzImage ........ but not showing init.xz .....? Wopos, I do mean init.xz. I didn’t take a screenshot of it but after booting into PXE, when I try to do the “quick register” option, then it gets stuck at init.xz But for now, I guess we’re sort of stuck until I find a chance to visit the office to test.

@eliaspereira Dell uefi firmware and iPXE, not specifically FOG. The x010 series was the first to support uefi network booting (kind of). They got it right with the x020 series.

@fogusnew said in Snapin creation fails: System suggests a snapin name, but it's already there: My 1.5.4 Fog is running on CentOS I am fairly sure this issue is fixed in the current version of FOG (1.5.8 as of now). Though you might want to wait a few more days before you upgrade because 1.5.9 is not too long down the road and has even more things fixed, some which might cause you trouble when trying to update to 1.5.8. So please stick around and I will let you know when it’s out.

@binglingyu Anything more we can do to help you on this? Please provide more information as requested by George.

@Chris-Whiteley @george1421 Just wanna keep this topic up on the screen…

@alansopro Somehow lost track of this and forgot about it, sorry! Now that I am starting to tackle this I see that it’s not as simple as I’d hoped. In a basic setup (single FOG server, no storage node, clean install, no plugins, unicast deploy) I don’t see the issue as described. So we need some more details of your setup: What does your storage setup look like, what nodes do you have? Any plugins you have enabled? When this happened, did you do a unicast or multicast deploy? As well I may ask you to do DB maintenance and try forcing a deploy task again. Just to make sure we are not hunting down a dead rabbit. I’ve already looked at the “force task” code and I have to say that I can imagine something can go wrong here if a plugin goes astray.