@Bhav Just for clarity, do you have an isolated imaging network or are you trying to image on your business network?

If you have an isolated imaging network then you should have configured FOG to setup a dhcp server. The configuration will work for both bios and uefi computers.

If you plan to image on an existing business network, then your primary dhcp server needs to be configured to support pxe booting.

So lets start with how do you plan on imaging?
Second if you are planning on imaging using your business network, what device is your current dhcp server?

@Tom-Elliott I had to reinstall my ubuntu server and installed the fogproject as you suggested. However, the installation still wasn’t able to run to the end. I have attached the error log. I do appreciate your assistance.fogserver error log.txt

@yannickF You really should state your issues.

If a feature isn’t available for whatever reason, we will tell you, but leaving us in “uh oh” isn’t really a good approach.

What issue are you having?

Finaly i have reinstalled my server again and just take exports from all sections (snapins, images etc…)

only gruops not working. nevermind ill setup again.

the problem was about the whole configuration with ISCSI disk attach, now i use an NFS and directly mount my image storage on /image.

works like a charm.

see yann

yann

@george1421
I resolved the issue by testing 1.5.10 on a laptop after trial and error I am able to have the same setup as our desktop environment. I will most likely upgrade our desktop server to 1.5.10 and recapture a new golden image.

@processor You set the replicator sleep time (and sleep time for all services.)

FOG Configuration -> FOG Settings -> FOG_IMAGEREPSLEEPTIME

It’s defaulted to 600 (10 minute cycles.)
If you set it to 86400, that should do the checks once per day.

@professorb24 said in How to use fog with two different VLANs:

Yes, I can ping the 192.168.54.X network.

This is positive. OK hopefully last question, what is device the dhcp server on the 54.x subnet? Is it the fog server on the 52.x subnet or something else?

@Tom-Elliott @george1421 I’ve done it, Winscp’d the files from my PC build lab FOG and added them to the directory on the SRV build lab FOG… PXE now working!!! woop

@JJ-Fullmer -y does indeed automate the schema updates.

@Nicolas-Bricet This really sounds like a spanning tree issue vs dot1x authentication (unless your authentication process is taking a really long time to authenticate the port). Make sure the port is configured for port-fast, fast-stp, rstp or whatever your switch manufacturer calls it.

Secondly if TIME is the resolution then this can probably be addressed too.

First of all we have the ability to update the iPXE boot loader from a fog install. This tutorial is intended to solve a different problem but you will need this in your solution: https://forums.fogproject.org/topic/15826/updating-compiling-the-latest-version-of-ipxe

So at this point you know that you can rebuild iPXE right from your fog server. Now we need to adjust iPXE to wait 30 seconds before requesting an IP address (FWIW, by default spanning tree it take 27 seconds to start forwarding data, so the timing is suspiciously similar).
When iPXE boots up it runs a FOG custom script file that tells iPXE how to configure itself. If you can remember back to the DOS days, this was the autoexec.bat files function. iPXE has a similar script. Within the iPXE source directory the file is call ipxescript (a look on github) https://github.com/FOGProject/fogproject/blob/a4bb1bf39ac53c3cbe623576915fbc3b5c80a00f/src/ipxe/src-efi/ipxescript#L1 This is the script that runs inside iPXE to configure the network.

To take this concept one step more, the FOG developers have already created a version of the iPXE that has a 10 second boot delay (remember you need a 30 second delay). An example of this 10 second delay startup is here: https://github.com/FOGProject/fogproject/blob/a4bb1bf39ac53c3cbe623576915fbc3b5c80a00f/src/ipxe/src-efi/ipxescript10sec#L3 All you need to do is either update that 10 to a 30 or copy that line over to the ipxescript main script and change it to 30. Once that is done recompile ipxe using the instructions above.

The FOG delivered 10second delay versions of iPXE are located in the /tftpboot/10seconds directory. So you have two paths to get this done, but I would surely look into spanning tree first to make sure port fast is enabled and make the above second way unnecessary.

@Joe-Gill
I work in particular environment : a school.

All we install is use for a very short period (not more than 2 weeks) , So I don’t need to SysPrep for instance.
Nearly the same for our software that are pre-installed in our images as they usually are free and for those which are under trial license it depends from a software to another.

So I’m not using FOG in a “REAL” production environment.

I quickly read about your issue, could this be related with your problem ? :

https://forums.fogproject.org/topic/10006/ubuntu-is-fog-s-enemy?page=1

@RogerBrownTDL I believe the 24.04.3 LTS is supported by FOG in the Dev-branch.

If wanting to stick strictly to the 1.5.10 “latest official” release, I believe Ubuntu 22.04 is the latest supported.

UPDATE –

@astrugatch

I just wanted to follow up on this. I realize this thread is ancient but I feel this is still very much relevant. We ended up going with Mosyle (PAID) for our MAC / Apple MDM. We are unhappy with it. It does not meet either myself or the instructors expectations.

You are 100% correct, Mosyle does not meet the expectations of a true MDM. It’s clunky and the support is not great. I have not looked at munki yet but am going to pursue that to try and make the most of what we have. I am also looking at another product called FileWave, which is supposed to work very well with pretty much every platform (minus Linux). FileWave is a paid service / subscription.

Thanks again!

@george1421 Perfect, thank you very much for all of your explanations!

Paolo

@Tom-Elliott I think this post helps fix the issues:
https://forums.fogproject.org/post/154920

@Tom-Elliott Thank you so much for your verification. I was a little panicked haha. Have a good day!

@plegrand said in upgrade Debian 11 to 12:

127.0.0.1:9000

This is the communication port that apache talks to php-fpm (PHP Execution Engine). For some reason during the update php-fpm was not updated or failed to restart correctly.

Well done getting this resolved on your end.

@Tom-Elliott

@Tom-Elliott said in Multicast timeout:

You created a table in FOG called hostsIP?

Yes, in our environment hosts, have ip reservations and I did not found in FOG tables last used ip by hosts (may be I missed something) so I created a table associating ip to hosts names.

@Tom-Elliott said in Multicast timeout:

Note: This isn’t a bad thing, I’m just trying to reference the information.

No worries.

@Tom-Elliott said in Multicast timeout:

The way I understand this, you’re looking at the mutlicastSessions table, getting a group, and getting the name of the hosts.

First I get all running mutlicast sessions. foreach sessoin I guess the group associated. I get max number of machine in the group I get the current current associated machines to the session As if a machine is finished, it is removed from the sesssion machine list, I compare the group machine number and the current machine running for this session. If the two differ it means that at least one went to the end but not the others. Now you make me talk on it I understand the specificity of our setup, all of our machines names start with group name (ex : all machines in rooms 1 will have such a name pattern : R1-P1, R1-P2…R1-P10), So as I have group name and I know that hosts which belong to it have it in their name, I get all machines with name starting with the group name we are working on. The same way I get machines IDs If not already done I get image ID Same for task ID (one client is enough as in mulitcast if I kill on client it kills all multicast) For each remaining hosts, I store ID, and Name in an array. I kill the task and do a 1 sec sleep loop till the mutlicast session disappear. (It can take few seconds for the multicast to be removed and without this loop some clients can’t be reinstalled because they are still part of another process. and finally for each hosts in created array, I create a unicast session (using host id) and reboot the pc using host ip.

@Tom-Elliott said in Multicast timeout:

You’re at least aware of the IPs which most others will not be, but just trying to think this through.

I searched for a more elegant way to get hosts ip and which could be universal, but the lack of time lead me to this rude behaviour 😉

But if someone has an idea on how to do it I would be very please to update this.
To be honest I thought to modify more the init.xz to populate automatically the hostsIP table when it loads but I have a working solution and it’s not even a priority for us but something more comfortable, if I had spent more time on this, someone would have come to break my fingers 😉

Sorry for the long post.