@Tom-Elliott woo not sure how i managed to miss that but its working as described. Thanks.

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

@shatchett0

Glad to hear it’s working for capture now. You should be able to mount /images on a separate disk without issue, but having it all in the same place is fine too.

I’m not 100% sure what that error is saying. At least not with enough detail to be helpful right off the bat.

First thing that comes to mind is a sector mismatch. If your image was captured from a disk with 512e sectors and you try to deploy to a 4kn disk (or vice versa) you’ll get errors when it tries to align the partition table because the sector sizes can’t align. It’s a limitation in disk alignment at a lower hardware level. I have some notes on when I was debugging such an issue in this post https://forums.fogproject.org/topic/17112/surface-go-4-incompatible

It could also be a simpler issue of the image doesn’t fit on the new disk. In most cases the resizable takes care of it, but if the image’s min size is bigger than the disk, not much can be done. But it looks like it’s an all disk or all partition image?

@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 Thanks for your reply.

I tried “Kernel 6.1.89 AMD/Intel 64 Bit (devel)” and it worked!

edit: FYI, I still got the “EFI stub: Measured initrd data into PCR 9” but it continued after that 🙂

Thanks !

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