@Sebastian-Roth @george1421 Thank you both. I am most likely eventually going to move to using FOG dhcp so I am not going to go too crazy with this. Was just curious as to if this was a known issue with a workaround. Just using our hq dhcp for the time being for testing.

@Sebastian-Roth @george1421 Thank you both. I understand that FOG was not really created for this large of a project, however, I’m interested to see how to handles it and what, if anything, will break along the way. I will keep everyone updated with my experiences and issues so that hopefully somebody else can avoid my mistakes in the future! With the amount of stores we have, I think it may be better to use each FOG server independently to avoid overloading any single part of the system. This will make managing the project more difficult but in the end I think it will be better suited for this client. Each store has a maximum of 7 computers so that should be much more within the programs capabilities. For our corporate office and some of the larger daughter sites, (upwards of 300 computers per site) I will be performing local upgrades. If I had more time to play around with a central FOG node I might try to make it work, but with Windows 10 support ending at the close of this year, I need to have all 1200+ computer upgraded by then as to not give our compliance department a stroke. Again, thank you both for the prompt response and for supporting an opensource program.

@Polar-Bear said in Fog 1.5.7 can not capture second image (Debian 10 'Buster'): For me it is a mystery, on my part I have repeated same steps without any deviation and if earlier it produced described error now it works fine. We have seen this exact error reported by other users and I am still unable to reproduce the problem and find the real cause of this. Not really sure what to do about it. Seems to be something that does not occur for everyone (obviously) but it’s still around. I even don’t know if it’s something fixed by a reboot or not. And this time when I was creating new image in web interface I found that now instead of dashes ‘-’ replacing spaces ’ ’ it has removed them!!! Does anybody working on code right now? I suppose what you are referring to is in management/js/fog/fog.image.js and has not been changed since August 2017 as you see in the github commit history. Which version of FOG did you use before?

@blong10 The fog server really doesn’t do a lot in the imaging process. I would give it at least 4GB of ram to release some of the memory constraints though. The only thing the fog server does is move the image from the network to the disk. It doesn’t process the image at all. Depending on the number of FOG Clients you have a 2 vCPU VM with 4GB of RAM is sufficient.

@Rivybeast @Raymond-Bell Thanks for testing and letting me know! I will work on fixing the other reports and merge this into dev-branch in the next weeks.

@processor I will look into this when I get a bit more time. @Tom-Elliott Would you know what could be causing this just from the top of your head? You probably know how sizes are calculated for the pie charts without having to dig through the whole code.

@quinniedid Sad to hear that you had a lot of work and trouble with this but sometimes it’s just good to redo the whole lot to get rid of old issues. Hope you have moved forward from Ubuntu 16.04 as well! :-)

@doggiebone said in Isolated Network - Operation not supported: resolv.conf kept being over written but I found an article that sort it out. This almost sounds like your FOG server’s IP address is being set by dhcp? If that’s the case you need to set it static or you will have problems since the IP address is hard coded into the configuration when the FOG server is installed. Well done on the rest of getting it setup.

@george1421 thank you for the help.

@tbaumann Again: Also make sure SELinux and firewall on the FOG server are disabled and TFTP is running! https://wiki.fogproject.org/wiki/index.php?title=CentOS_7#CentOS_7_pre-config

Is the udp-sender command built from anything in the host inventory on the server? We also modify the DMI area of the motherboards, e.g. manufacturer, model, serial number, etc… I’m no programmer by any means, but I was thinking if we were putting a character in there that isn’t being parsed correctly (spaces, parenthesis, etc.), could that cause the built udp-sender command to fail? We also don’t name the machines, we just let FOG use the MAC address to name them.

@george1421 thanks for the reply! After following your instructions I noticed that there is no “Installing Patch” text on the new server that is not behaving. Also, /bin/fog.man.reg exists on both servers. So I decided to follow the rest of your instructions on the old server that behaves as it should just to see what kind of results I should be getting. The results from following your post on the OLD server were as follows: After getting to the command prompt I keyed in fog and hit Ctrl+C once i saw “* Running post init scripts … Installing Patch”. However, when I was returned to the command prompt and keyed in set |grep postinitpath nothing was returned and I was returned to the command prompt. I did grep for other words/variables that appear after keying in set by itself, just to make sure everything was functional, and set |grep type returned type=down as expected. As for the NEW server, “Installing Patch” did not appear at all, just “* Running post init scripts … Done” . I did press Ctrl+C after this to see what set |grep postinitpath would return and it too output nothing and returned me to the command prompt. Keying in set |grep type for testing purposes returned type=down. I also executed the fog command multiple times so that i could stopping the procedure at different debug steps to check set |grep postinitpath on both the OLD and NEW server and it never returned the location of the fog.man.reg.cust file. Please let me know what you think.

@RyanBair We have way too little information to be sure but from what I read between the lines I expect this to be an issue with an Ubuntu installation that is being upgraded to FOG 1.5.7 where the database moved from MySQL to MariaDB. Please try the following and see if that fixes it for you: sudo -i apt-get remove mariadb-client mariadb-server mv /var/lib/mysql /var/lib/mysql-mariadb cp -a /var/lib/mysql-5.7 /var/lib/mysql apt-get install mysql-client mysql-server systemctl start mysql See if your images show up again.

@weidongyan said in Cannot log into the fog server management: I changed the fogproject 's password. After changing it, I cannot log into the Web UI any more. Again you are mixing up two different things here. Please read my last message very carefully.

Thank you. yes, you are right the problem is NOT the “//” but SPT on the switch that caused “udhcpc failed”. the solution is posted here: https://forums.fogproject.org/topic/12248/udhcpc-failed/4 Tested imaging with a dumb switch, and everything worked.

So, I kinda had to give up on that device, had to ship it. No idea what excactly was the problem with that. I’ve set up a new devive today (basically same computer), did the same routine of setting it up, installing winodws and so on… With that one, capturing went perfectly fine. So basically my problem is somewhat solved by that… In the way that my company can continue their workflow as usual. I still would like to understand what was going on with that pc… But I can’t do any more test on that one… So I guess we’ll never know… Thank you guys for helping me :)

While I can’t speak for the FOG Project developers, I would say that managing MS Windows updates is not something that the FOG Project wants to enter. FOG’s focus is cross platform image deployment. I feel that moving into the MS Windows (only) space would be moving in a direction away from The FOG Project’s original charter. Also there are currently free MS Windows patch management solutions like Microsoft’s WSUS. There are other like free solutions like WSUS Offline Updater already in this space. In the linux space there is puppet, chef, and ansible.

@Cheetah2003 Have you tried to “Reset Encryption Data” after you update the MAC? List “all hosts”, click on the one MAC is changes, the select “Reset Encryption Data”.

@bogle No model specific drivers are copied to the target computer during image push and then inserted into the windows environment using pnputil utility. https://forums.fogproject.org/topic/11126/using-fog-postinstall-scripts-for-windows-driver-injection-2017-ed I probably should update it for 2019 / Win10 specifically, but everything is in there. I do have MDT add in the WinPE10 standard drivers so the golden image has at least the core network and disk drivers, but most of the windows 10 built in drivers are good enough to get to at least the point where the pnputil program is used.

Same results (black screen, no text) with the 4136 kernel. I looked through the BIOS and there’s not a ton of options to change, but I did try flipping a few of them on/off with no luck. 32 bit kernel looped back around to a dark version of the main FOG menu when I tried to choose compatibility mode, which was strange, but then trying to deploy an image I got a “Could not boot: Error 0x71048283” message three times before sending me to the iPXE command line. I’m not sure if it matters but poking around in the BIOS reminded me that these things do support Android. There’s three options in the bios for “Droid Mode” “Android Mode” and “Windows Mode”, all of which are set to be disabled on the stock tablet except the Windows option which says “Windows 8.x”. I don’t know if that means the drives are partitioned in such a way that it would cause issues like this but that was about the only thing I found looking around in the BIOS for settings to change.