I believe I have a viable migration process to get FOG services moved from set of servers to another set. This process takes into account Locations, Storage Groups, existing Hosts, etc. The system I’m migrating has 7 remote sites so that’s 8 locations and 8 servers - one FOG server and 7 FOG Storage Nodes, each at the end of a Static VPN WAN. The initial FOG server is an alias ‘fogserver’ in DNS and DHCP is served out by MS Domain Controllers at each site. Each Storage node serves out all that is needed for each remote location (PXE, initrd, snapins, and images). Each storage node is the master of its own storage group. We do replication manually, so there may be some snapin and image replication issues in this process that I can’t account for.

The process requires being able to harvest the digital identity of the initial FOG server for use on the replacement FOG server, so the replacement server needs the same name and IP address. This is necessary to allow existing hosts to be easily ‘acquired’ by the new system since the Hosts. I pursued a side-by-side migration that worked fine PXE booting->host registration->imaging, but failed for existing Hosts and, for unknown reasons, even new Hosts failed all software distribution steps. The idea of placing FOG required scripts in group policies wasn’t appealing for my purposes since we need the FOGService to work without the machine joining a domain.

I’m currently testing and will have a process “doc” soon. I’m interested in posting this process for FOG Project’s use if the powers that be find it useful.

I’ll post it here when it’s completed.

It seems to me that the need to change Linux distros is an age-old requirement as various Linux OSs have been dropped or usurped. Migration of FOG from CEntOS to any other Debian Linux should be well documented.

More soon.

Jim Graczyk

@Tom-Elliott Thank you! This helps a lot! Funny enough, it was tftp-server that I installed. I suspect we may have had a different issue (maybe during a patch management cycle) and these things just got tied together.

@george1421 I appreciate your response. I went ahead and tried to install ubuntu 24 via a USB drive and got the same issue. I’m going to reach out to the manufacturer.

@JJ-Fullmer @Tom-Elliott

I’ve found a work around. I now have /images on USB HDD passed through the to VM. When I run a standard back up of the VM via the VM software (Virtualization Station), it only back-ups the OS VM drive.

For the /images drive - I use a sync program to back-up the files, not the disk .

@Tom-Elliott

Hi Tom,

We have added a column to the ‘location’ table in the fog database and we have given this column an ENUM ‘http’, ‘https’. The error message disappeared.
Should anyone run into the same problem, you can at least remove the error message from your logs.

We still have image-task problems but we’ll deal with those now.

Thanks.

Regards, sassonie

hello, i’m the original author of the Subnet Groups plugin: I wrote and committed the first version of its code back in 2019 (https://github.com/FOGProject/fogproject/pull/289).

i just wanted to inform you that in our environment (currently equipped with the last stable version of FOG) everything is working alright, we never had issues with the plugin even though we are used to update our systems on a regular basis.

as @Tom-Elliott mentioned, problems might arise due to incorrect IP addresses mapping: on our system, we had to set up a dynamic DNS server which has the job to automatically keep track of the actual host IPs based on their hostname; without this (or some alternative solution to correcly associate IPs with hosts) the plugin is not going to work properly.

best regards.

Side note, it appears that the KEA DHCP server in pfSense 2.7.2 does not properly support serving the correct boot file to BIOS vs EFI systems. It all works fine with Windows DHCP. This had nothing to do with my original issue.

The purpose of me using Capone for me is because we use all hps so I already have Capone configured to serve the golden image based off of the system-manufacturer matching HP

@george1421 said in Multicast stuck:

[09-18-24 9:36:35 am] Interface not ready, waiting for it to come up: 10.54.68.101
[09-18-24 9:36:45 am] Interface not ready, waiting for it to come up: 10.54.68.101
[09-18-24 9:36:55 am] Interface not ready, waiting for it to come up: 10.54.68.101

If you disable the storage node then you will get this message inside the log.

I found out that it wasn’t a FOG problem but i mixed up some vlans together.
Multicast works now. Problem solved.

@george1421 Thanks its working

Not sure why setting the LDAP plugin manually I couldn’t get it working … but I exported the plugin config from an old FOG instance and imported it in the new one and it worked, so I think you can mark this as solved 😉

@Tom-Elliott thank you very much!
I didn’t consider it to be a MAC address where I absolutely should have 🤦🏻.

So the copying process doesn’t happen but the image is fully useable, I will sort this out manually and consider re-installing the server so it will start doing this automatically…

Thanks again!

@Tom-Elliott said in fog 1.5.10 post pxe boot problem:

d in almost a decade, so I think you’re FOG version is MUCH newer than that considering the bzImage version is 6.6.44 and the one you " updated " to is 4.1.2

please attempt updating your latest fog version?

i have rolled back to the 6.6.44 bzImage files. im not sure where to get current init.xz files however

ok when you say to update the latest fog version, can you please give me a link or something here?

am i updating a specific part or am i updating the whole fog installation?

the fog wiki says to use these links:

https://wiki.fogproject.org/wiki/index.php?title=Download_Current_Init's_and_Kernels_Command_Line

Sorry everyone I haven’t updated on this post, my organization wanted our fog server migrated to our data center on to a vm so my time was reverted to doing that and building an additional one at one of our new hospitals we recently finished construction on. But I plan to get back to working on it this week on my test server I have set up. Once I have it set up I am going to implement it on our production servers, I think I’m very close to implementing this concept and once I have it cracked I will make sure to share this with everyone because I think the option of being able to do this will be valuable to many others. @george1421 @Wayne-Workman

@Sab First I would have to say both fog server and fog storage node have to be on the same version. The fog storage node doesn’t have its own database, it uses the fog server’s database. There could be schema changes in the database between 1.5.10 and 1.5.9.

Unless you change the storage group around, its not possible to capture to a storage node (in the default configuration). Only the master node in a storage group captures the image, then it replicates the captured image to all storage nodes. Both the master node and storage node can deploy images.

If I had to guess, I would think that in the storage group the nas fog server is not defined as the master node. If I think I understand what you did to configure this setup.

On the fog error screen it should print out the kernel parameters sent to the FOS imaging engine. There should be a filed marked storage or storage_ip, that will point to the fog server it will try to get the image from. Make sure that is correct for your configuration.