@NateUH Yes it is supposed to auto-start on bootup of your FOG server.

Please run

systemctl is-enabled FOGMulticastManager.service

to see if it’s enabled on bootup. If you get disabled there must have been an issue when running the installer. You might run

systemctl enable FOGMulticastManager.service

or re-run the installer to do this for you.

But if it’s enabled already then you might be running into a startup dependency issue in FOG 1.5.7 which we have fixed lately. Ask here if you need more details on this.

@Tom-Elliott

Nice, it is working now.

There was a slight blip where it got stuck at

Downloading kernel, init and fog-client binaries…

So I ‘quit’ the install removed user fogproject and ran the install again.

I was able to update the database schema, continue the install and login.

New interface looks slick!

@justeverything Do you have the working version of this?

@zuf76 Yes, take a look at the so called “Service Settings” tab within the host’s view. As well there is a global service setting in FOG Configuration -> FOG Settings -> FOG Client - … sections.

@xfz said in Endless reboots:

The snapin does not even require reboot.

While I am not exactly sure I would think that this is not caused by a snapin task.

Yeah, unfortunately i deleted the task already. It was the group deploy thing.

And does machineB still reboot in an endless loop? Probably not or do I get this the wrong way?

@fry_p said in About image acquisition error.:

Sunucudaki “fogproject” kullanıcı hesabının parolasını değiştirdiniz mi? Bu hesap yalnızca FOG için bir hizmet hesabı olarak kullanılır ve sis yönetiminde kullanılmaz. Bunu yaptıysanız, aşağıdaki yerlerde şifreleri eşleştirmeniz gerekir:
Web Interface -> Storage Management -> [Your storage node] -> Management Username & Management Password

Web Interface -> FOG Configuration -> FOG Settings -> TFTP Server -> FOG_TFTP_FTP_USERNAME & FOG_TFTP_FTP_PASSWORD

The local ‘fogproject’ user’s password on the Linux FOG server

Server file: /opt/fog/.fogsettings -> password

Sunucudaki hizmet hesabı parolasını (fogproject) değiştirdiyseniz bunu düzeltmenin en kolay yolu, bunu yaparak Ubuntu’daki bu parolayı diğer konumlarla eşleştirmektir.
sudo -i
passwd fogproject

Yeni bir şifre girmeniz istenir. Lütfen başka bir yerde şifreyle eşleştiğinden emin olun.

@fry_p

Finally happened 🙂 . Thank you very much for the quick answer.

Latest inits should have all the fixes included. Marking as solved.

Marking as fixed as we have this added to dev-branch and it will be in the next release.

@Demache Nice we found this and you were able to fix it so quickly. When looking through the code I thought about HTTP/HTTPS possibly being an issue but dropped that idea. Now looking at it again I think you have found a bug in the code! Just pushed a fix.

Though I still really wonder why the backup logic of checking size via FTP didn’t work in your case either.

I appreciate the quick reply Tom. I was just curious if there was already a quick check box to turn this off or not. I think I will hold off on it and just let my team know they need to be sure to approve hosts after installing the client. I appreciate your insight and look forward to a possible feature addition in the future!

Marking as solved as we haven’t heard back since one week.

Oh yes, that is most likely what it is. It is when you click the wrench at the top right in the web interface.

FOG Version Information
404 Not Found

@george1421
I try it to install several times but i have same issue with missing files(i try github version too).I also try re run install on existing FOG server but same results .Can you please advise most stable or more less problematic linux distribution ?Fog-install.txt

Thanks all. It makes sense why it was happening now.

@Quazz

Yes, it was a legacy 10 install that was converted to EFI.

@jhumpf All I can say is that based on the two to three years of using that configuration for different fog admins, we haven’t needed to deviate from that configuration since dnsmasq is not giving out dhcp addresses the mask “should be” irrelevant. The remote subnets should just work as long as dnsmasq is being informed of them requesting a dhcp address.

If you want to debug deeper into the matter, I would suggest that you reset the configuration back to what I have in the article then follow this procedure to see if we can capture a bad remote proxydhcp request and then capture a good remote proxydhcp request so we can compare. There also may be some value in taking a computer on the remote “bad” subnet and loading wireshark on it. Start the capture filter of port “67 or port 68”. That would capture what the dhcp and dnsmasq are sending to the target computer, from the target computer’s point of view. https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue

Upload those 3 captures to a share file site and share them as public. Either DM me directly or post the links here and I will review them.

My gut feeling is that you have something not configured right in your infrastructure not related to FOG or dnsmasq.

@hj104 said in Scheduled Tasks (Delayed / Cron-style) not working, but instant tasks are.:

My only question now is whether restarting the server has the same effect on the FOGScheduler service as running systemctl restart FOGScheduler?

I am pretty much sure this can be answered with yes. Sorry but I have no idea why this was wrong in the first place but working now. Seems like you have not changed anything.

@alesser said in PXE-Booting a Modern Ubuntu live CD via UEFI mode:

I simply want to boot a linux live CD in EFI mode when the option is selected, run a script, and then stop.

Reading between the lines here, I wonder if another approach would be better/faster/greener?

Let me tell you a bit how fog images computers. The iPXE menu in conjunction with the boot.php program send 2 files to the target computer with some kernel parameters that tell the target computer what to do. Those two files are bzImage (the kernel) and init.xz (virtual hard drive a.k.a initrd). Those two files make up the os known as FOS (Fog Operating System). FOG uses buildroot to construct the initrd as well as compiles bzImage.

So one might wonder, do you need a full commercial OS run your script or just a linux OS? Do you need a persistent disk storage or once the script runs can the virtual machine just disappear?

So the grey beard hacker in me wonders if you could take FOS Linux delivered by the FOG server to do your bidding? Unless you are doing something crazy (like vlans, wireless, packet filtering) FOG’s bzImage should do what you need. It supports both uefi and bios modes, as well as init.xz. FOG supplies both a 64 bit and 32 bit version of FOS Linux.

So how do you hack init.xz to not image your target computer? Simply unpack the inits https://wiki.fogproject.org/wiki/index.php/Modifying_the_Init_Image Once you unpack the inits then look in the /etc/init.d directory for S99fog and delete it. Repack the inits and then pxe boot the computer again. Now you have a command line linux OS to play with that boots in under 15 seconds and disappears when powered off. The entire OS fits into 512MB of RAM, so its very VM friendly. If you need persistence memory just map an NFS share and grab your persistent data from there.

You might want to look into the /etc/init.d/S99fog file a bit deeper since you want to run a script the S99fog to do your task. https://github.com/FOGProject/fos/blob/master/Buildroot/board/FOG/FOS/rootfs_overlay/etc/init.d/S99fog

Now what do you do if FOS Linux doesn’t contain the linux programs you need. Welp, then you need to turn to build root and build your own init.xz (initrd) file. No worries since the FOG Project also provides the buildroot config file and fs overlay you need in the github site. https://github.com/FOGProject/fos/tree/master/Buildroot

@UWPVIOLATOR If you can’t get the application to behave with respect to the restarts, you could always create a snapin pack bundling the executable with a script. In the script, you could check to see if the application was already installed and of the correct version, then if it wasn’t perform the install. if you wanted to kick off the application and then do something like loop while the executable was running, you might want to play with the start command, something like start "" installer.exe -args. https://ss64.com/nt/start.html

@george1421 the /k flag runs the specified command then leaves the command window open. https://ss64.com/nt/cmd.html

@explosivo98 Strange that kernel should boot because the only thing added was some apple hardware IDs and an apple disk patch. Nothing for non-apples should be impacted.

Solved. OMG it’s so good to have another set of eyes on. Talk about not seeing the tree for the forest! I am watching first clone progress. This is far further than I was ever able to get with Symantec ghost - never could build their PXE client. Thank you so much Sebastian.