I’ve just tried an Insider build from the Dev channel, Secure Boot was not required - though is supported by this hardware (Intel NUC). MS are saying that the requirement is actually a TPM - they’re saying ‘Secure Boot Capable’ because that’s more consumer-friendly than talking about TPMs.

The image type in FOG can be set to Windows 10, and I was able to capture and deploy

@greg-plamondon Yes, I never enable that nonsense

@george1421 Thank you, that’s a very helpful explanation. I think I will start experimenting with using snp.efi as my default and create specific rules for machines where it does not work.

@sebastian-roth Thanks. In the end I found that even realtek.efi didn’t entirely work. The PC is connected to a KVM and using realtek.efi it will only boot if the active KVM port is the one the PC is connected to. Otherwise it gets stuck in and endless loop of retrieving the file, crashing, and rebooting. ‘snp.efi’ does seem to work but I’d really like to know what the difference is. Do you know if it’s documented anywhere or shall I have to rely on the mailing list? I haven’t found anything on the iPXE website.

This is what I came up with in dhcpd.conf

class "Realtek-64Bit-UEFI" {
    match if binary-to-ascii(16,8,":",substring(hardware, 1, 3)) = "1c:69:7a";
    filename "snp.efi";
}

I found another possible solution though I’ve no idea why it works. I switched every instance of ‘ipxe.efi’ in my dhcpd.conf to ‘realtek.efi’. This was a complete guess, but now the USB-C ports work.

How can I work our what to use as the string match so that I can ensure that only this Lenovo PC uses realtek.efi?

Also can anybody explain why this made a difference? The main USB controller is an AMD controller. There is a Realtek USB SD Card Reader and a Realtek NIC but I was never having any issues with those.

Running FOG 1.5.9. I have a specific problem with an AMD-based Lenovo. When booting normally it’s fine but when booting via iPXE all the USB-C ports are disabled. This happens the moment that it downloads the NBP file from FOG.

From searching forums it seems this is a known iPXE problem and the only solution I’ve found is that you need to completely disable usb support in iPXE by rebuilding iPXE with some special options, but I don’t know how to do this using FOG’s buildipxe.sh. I’ve tried just running that to get the latest version of iPXE but that hasn’t helped.

@Sebastian-Roth thanks! I did not know about the postinit scripts. I’ve no problem with them all having the same password so that was really easy.

I’ve noticed that there is an SSH server running on the client machine while it is imaging. I’m wondering what the login details are, or how they can be set?

To explain why, I’ve been running a lot of unattended installs remotely (covid etc) and just occasionally a machine will get stuck, where it sits at the Partclone screen waiting to start but never does. It’s related to using Multicast, but not being able to get to the machines easily it’s been very hard to figure out what’s causing it. If I could SSH in I could at least reboot the machine, instead of having to badger somebody to go and do it for me (or driving for an hour to push a button). It’s only a workaround but it would be a big help.

I’ve just tried an Insider build from the Dev channel, Secure Boot was not required - though is supported by this hardware (Intel NUC). MS are saying that the requirement is actually a TPM - they’re saying ‘Secure Boot Capable’ because that’s more consumer-friendly than talking about TPMs.

The image type in FOG can be set to Windows 10, and I was able to capture and deploy

@pep said in Using a separate NIC for multicast:

web = http: //192.168.1.100/fog/ ftp = 192.168.1.100 storage = 192.168.1.100: / images / dev / storageip = 192.168.1.100

Thanks! That works. I can leave my storage settings as default and Multticast will use eno2, then for anything not multicast I can set the correct parameters for eno3.

Just a note that for deployment the storage variable needs to be ip.address:/images/ (without the dev/)

@Sebastian-Roth OK thanks for the reply. It’s no biggie but I’ve got all these NICs and nothing to use them for

As an idea, could I create another storage group for the images I might want to multicast, where all the settings except the interface and IP address are the same as the default group? If I set that to use eno3, and multicast to use eno3, that might achieve what I want?