Hi all,

I believe I have figured out this issue, however it is unideal. I seems that between Kernel 5.15.68 and Kernel 5.15.93 there must have been some update to Realtek Driver R8169. As such, this driver now has degraded performance on my Dell G15 5510 machines.

I have also tested a machine with a intel NIC, which runs the e1000e driver in the FOG-OS environment. It works beautifully.

For other issues with similar issues out there, I would suggest for you to consider these 2 steps to resolve this issue:

• You can purchase PXE enabled USB to Ethernet adapters. Each brand of laptops will have their specified version that it allows use of (Dell’s is here: https://www.dell.com/en-au/shop/dell-adapter-usb-30-to-ethernet-pxe-boot/apd/492-11726/pc-accessories). I have tested this and it works beautifully, however would get costly above a certain amount.
• You can also roll you own Linux Kernel with your own selected drivers (ie. using R8168 instead of R8169). I also did this and it is fairly simple, but… in my case the time-cost benefit was not up to par.

Also just to put it out there, FOG debug mode is very very useful and can be found in the advanced tasks menu:

Let me know if there are any follow up questions out there.

Hi @rodluz

Just wanted to confirm that this update has worked. Now deploying my images in <5mins.

Thank you for your help.

@Tom-Elliott I figured it out.

I was getting confused by the similar language between the installation process and storage group setup.

A normal installation is just a fog storage node that has a web server and UI on it. A FOG network requires atleast one to work. However a Storage node can be set as the master of a storage group no matter the installation type.

My problem was that because the storage node in the “Bris” storage group did not have a master node setup, the default group could not replicate any images or snapins over. All storage groups must have a master for it to work effectively.

@Tom-Elliott feel free to clarify any of the above rant.

@george1421 Do you have any thoughts here either?

@Tom-Elliott Just wondering if I could have your input here.

I think I have found a bug.

I registered a new host. I then created a deploy task against this host. I then delete this host via the webUI.

My task list empties as it should, however if I look at my storage group activity on the dashboard there are still tasks queued:

There is no tasks scheduled, queued or checked-in.

Looking at the database I find the following:

There are tasks still queued for hosts that no longer exist in the host table.

2 fixes needed:

• When host is deleted, all currently queued or checked-in tasks should be set to a taskStateID 5 or cancelled
• If there are tasks that are not set as canecelled for hosts that do not exist, then these tasks should be cancelled

1 question:

• I have 24 queued tasks for hosts that do not exist. I see 4 on the webUI. I assume this is because there are 20 tasks with taskNFSGroupID and taskNFSMemberID set to 0. How do groups that do not exist get marked against a host / task?

@Tom-Elliott I have switched over but still having this issue:

@Tom-Elliott I figured it out.

I was getting confused by the similar language between the installation process and storage group setup.

A normal installation is just a fog storage node that has a web server and UI on it. A FOG network requires atleast one to work. However a Storage node can be set as the master of a storage group no matter the installation type.

My problem was that because the storage node in the “Bris” storage group did not have a master node setup, the default group could not replicate any images or snapins over. All storage groups must have a master for it to work effectively.

@Tom-Elliott feel free to clarify any of the above rant.

Hi there,

Unsure if this helps, but here is my setup for 7zip. I usually just go straight from the .exe or .msi files.

Another example of snapin arguments:

I would suggest adding in a loging function in the .bat or .ps1 file, this way you can see exactly what commands fail.

Hope this helps!!

@Tom-Elliott I don’t think its working then.

Storage Groups:

Storage Nodes:

Image Storage Group Association:

However as provided in my last post, according to my logs this image in not replication, nor any snapins.
Also the images on my nodes are different sizes, so I take it as my asumption of non replication is correct:
Melbourne Server:

BRIS_FOG server:

Any ideas?

Anyone have any thoughts or suggestions to help here?

@Tom-Elliott Yes this did work. Thank you for your quick action.

Hi all,

A little while ago I heard I could replicate snapins and images from one storage group to another. This would be very helpful as the location plugin load balances nodes within a single group rather than just using the single node selected in the location setup.

So I created a second Storage Group and within each snapin and image set the default storage group as the main group and the BRIS storage group as a secondary storage group.

However when I look at the replicator logs, It doesn’t seem to be replicating accross.

Can anyone help with this setup?