Topics created by TBCS

@TBCS OK Just so I understand. Now the error printed on the screen no longer appears. It was fixed by the kernel update to 5.15.x.

Now when you capture the image capture just freezes at 30% and no visible error is displayed.

Do you have another one of this model you can try to capture? So the question is, is the problem related to this specific computer or this computer model. I’m suspecting there is something strange with the source computer’s storage media. As of now there is no difference in disk structure between windows 10 and 11. So selecting win 11 in the fog ui should work well.

@TBCS ok good to know thanks.

@TBCS You are right, can’t do debug in multicast mode. I should have stated more clear. The debug was only meant to figure out the sgdisk .... issue. Not the multicast one. This happens when we talk about different issues in the same topic…

Logs are always welcome. More information is always better than none.

@TBCS Are all the Yogas in a specific part of your network (one switch/room/subnet)? It’s kind of unlikely this is caused by the Yogas being UEFI systems. What could be the case is that the network driver for the NIC used (probably an external adapter, right?) is kind of buggy and not allowing for a proper NFS connection. But as we check network connection on bootup it’s also very unlikely.

I guess George is on the right track here. Your network seems to not handle the default 0.7 second timeout well and therefore you see random failures. Try manual mounting as George suggested a couple of times in a row to see how often it fails.

mkdir /testfs mount -o nolock,proto=tcp,rsize=32768,intr,noatime 10.10.1.93:/images /testfs umount /testfs mount -o nolock,proto=tcp,rsize=32768,intr,noatime 10.10.1.93:/images /testfs umount /testfs ...

Then add the timeout option as well and see if it’s doing any better.

mount -o timeo=10,nolock,proto=tcp,rsize=32768,intr,noatime 10.10.1.93:/images /testfs umount /testfs mount -o timeo=20,nolock,proto=tcp,rsize=32768,intr,noatime 10.10.1.93:/images /testfs umount /testfs ...

Well this will get a little complicated to explain, but lets try.

Traditional pxe booting requires dhcp options 66 and 67 to be set with the proper information namely the next-server and boot-file settings. In a normal environment that is all that is needed to pxe boot a device.

Now enter a network function called ProxyDHCP. A proxy dhcp server can be configured to override what is set in dhcp options 66 and 67. FOG can use a ProxyDHCP server in cases where the main dhcp server can’t be modified such as in a managed service. For the FOG/linux world you would install DNSMASQ which can be configured as a proxy dhcp server. ProxyDHCP servers work over broadcast messages. So if you have a ProxyDHCP server on one subnet it will not hear or respond to pxe boot requests on a different subnet unless you have the ProxyDHCP server configured in the dhcp-helper/dhcp-relay service on your subnet router.

SCCM / WDS has a built in ProxyDHCP server. So that is why your dhcp options are being over written with the SCCM boot loader. If you want to block / stop this there is a netboot service on your SCCM server that you need to stop.

If you want proof this is happening you can use wireshark on a computer on the same subnet as the pxe booting computer that connects to sccm instead of fog. If you use the capture string of port 67 or port 68 or port 4011 then capture the pxe booting process.

When you look in wireshark you will see

Discover sent by the client. (2) Offers one from your dhcp server and one from sccm Request from the client ACK from the dhcp server You probably won’t see this unless you run wireshark on your sccm server, but he client will talk to the proxydhcp server over udp port 4011 to get the pxe boot information.

@TBCS Mmmmmm cookies…

I’m glad you have it worked out and it was simple enough to just update your firmware (which you probably should have done anyways).

@george1421 That was a really helpful guide. Easy to follow and now we’re ready for whatever type of boot we need.