FOG will not recognise valid image

[pederskz]

Yes. The two disks (sda and sdb) are an Ubuntu and Windows 10 image. All 26 machines have the exact same hardware configuration.

[george1421]

@pederskz OK just doing a sanity check on your data. With multidisk non resizable if just one system has a smaller disk deployment will fail.

[Tom Elliott]

Are you still having issues with multicast, or worried about the fact the main page doesn’t “see” the “On client” or Capture dates?

The ON Client, and Capture dates, information have no bearing on the imaging capabilities. They’re both there as informative elements, not elements telling you whether or not an image can be used.

[george1421]

@george1421 these settings look good except for the file ownership. They should be owned by fog.root

[george1421]

@Tom-Elliott There should be a multicast deployment log some place like /opt/fog/logs??

[Tom Elliott]

@george1421 correct.

[pederskz]

@Tom-Elliott In short, yes to the multicast; And sorry about the delay in responding.

Multicast is working now (issues on the old server where quite likely related to an…interesting hack, as well as a switch misconfiguration), but it’s on a machine with a “bad” hardware configuration (both ports plugged into the same network).

All of the PCs are HP Elitedesks 800 G1 TWRs with an extra pci intel gigabit NIC installed. The built in NIC is connected to a switch that is (practically speaking) never powered on, which shows up as eth0. Eth1 is the pci NIC, which is connected to a always-on network that can reach the fog server. When the client boots eth1 predictably fails to get a DHCP address, but when client says “no link detected on eth0 for 35 seconds, skipping it!” It attempts to start eth0 again.

I tried using the kernel update feature to update to kernel “Kernel - 4.10.10 TomElliott” and trying the new inits you suggested here but i’m still having the same issue (both as previously described and as @kleanthis in the previously mentioned thread)

[george1421]

@pederskz said in FOG will not recognise valid image:

All of the PCs are HP Elitedesks 800 G1 TWRs with an extra pci intel gigabit NIC installed. The built in NIC is connected to a switch that is (practically speaking) never powered on, which shows up as eth0. Eth1 is the pci NIC, which is connected to a always-on network that can reach the fog server. When the client boots eth1 predictably fails to get a DHCP address, but when client says “no link detected on eth0 for 35 seconds, skipping it!” It attempts to start eth0 again.

Its not clear where this error is being thrown. Is this in the iPXE kernel or the FOS Engine kernel? Can you snap a clear picture of the error with a mobile phone and post it here. It will allow us to see the context of the error. Make sure you grab other messages around the error.

[pederskz]

@george1421 The fog engine kernel. I can photograph the error in about an hour.

[pederskz]

@george1421

[Tom Elliott]

@pederskz WOudl you mind installing FOG 1.4.0-RC-8? There was a fix put in place to ensure we don’t only look on a single interface as what seems to be the case here.

[pederskz]

@Tom-Elliott Not at all, i’ll get started on that now

[george1421]

@pederskz What you are seeing was an issue with 1.3.5 stable that issue was fixed in 1.4.0RC2 or 3.

[Tom Elliott]

@george1421 https://news.fogproject.org/fog-1-4-0-rc-2/ just for reference

[pederskz]

@Tom-Elliott How exactly do I update to a release candidate version? Is it done similarly to the instructions at wiki.fogproject.org/wiki/index.php/Upgrade_to_trunk

[Tom Elliott]

@pederskz That’s exactly how you do it.

Dev-branch will contain the latest RC or “stable” depending on release cycle.

[pederskz]

@Tom-Elliott Looks like the update solved the issue. Thanks for the help! I’m not entirely sure how to mark this thread as solved.

[george1421]

@pederskz I marked it for you. Glad you have it going now.