@Gael et al. I’m post a more descriptive post to summarize what the issue is. I don’t know how to fix (so I’ll start there.) TL;DR; Linux Kernel is putting a volatile Firmware on the NIC. This happens when FOS loads and the kernel begins associating the drivers. On restart, the firmware is still existing on the NIC from the Kernel. When Windows Boots, it re-flashes the volatile firmware so subsequent elements will work. Or a full power pull will do too (completely cold boot.) Basis: This particular issue, is due to Linux Kernel having a firmware defined for the NIC. This is volatile. This means when power is pulled, the firmware will no longer be present and normal actions will work properly. While the machine is in FOS, the linux kernel hands it a temporary Firmware File and this is what’s causing the strangeness with the NIC. Pulling the power cord causes the firmware to wipe. Similarly, if booting to Windows immediately after, and then powering off the machine, it should WOL. This is because Windows has a FW being applied when it loads, overwriting whatever the Linux Kernel pushed.

@Quazz said in Can't deploy latest win10x64uefi with 1.5.5: Wow, you’re so fast with answers! I really appreciate that! As I’ve said in the firs post, I’m using Hyper-v second generation VM based on UEFI. AAAAND! It seems that I’ve got some progress(really hope so). What i’ve done: Downloaded latest binary zip of rEFInd: https://sourceforge.net/projects/refind/files/0.11.4/refind-bin-0.11.4.zip/download extracted /refind/refind_x64.efi ; drivers_x64 from this folder Renamed refind_x64.efi to refind.efi, renamed drivers_x64/ntfs_x64.efi to drivers/ntfs.efi, renamed /drivers_x64 to /drivers. Chmod 644 chown fog:www-data to this files|folders, moved them to /var/www/fog/service/ipxe, removed comment symbol from this line: #scan_driver_dirs EFI/tools/drivers,drivers in /var/www/fog/service/ipxe/refind.conf. And I’ve just deployed my image with only one error at the end: “failed initialization of the interactive login process” or something like this, it’s translated from Russian.

@Tom-Elliott Just here to thank you for this!

What this thread is asking, I think, is a plugin for Key Management. I understand the desire - but here’s how I dealt with your problem. I made sure during registration that I entered the correct host-name and assigned the correct image and told the system to join the domain, and made sure I picked to image it right then. Then after I did a lab or a hallway or whatever a good stopping point is, I used the fog web interface and used Group Management to assign the right key to the systems I just imaged, along with snapins too.

This issue only appears to happen on windows 10 installations. It would seem the legacy client uninstaller is not fully compatible (of sorts) with windows 10.

@Sebastian-Roth @Tom-Elliott After an update to the current subverion it’s working again. Thanks.

@Tom-Elliott to further iterate and give some more specific information. Unicast worked because while the order was not “proper” it pulled the partition number from the iterated item. Example /dev/sda1 would look for file d1p1.img. /dev/sda10 would actually look for and use d1p10.img. In multicast this iteration happens but the data is sent by the server. It did not scan for a particular file. So in your case the commands were sent in expected order. udp-sender would send in order d1p1.img, d1p2, d1p10 It sent the commands in that specific order. The partition receiving the file was not matching the file it was receiving. /dev/sda1 would get d1p1.img properly but /dev/sda10 was getting d1p2.img. Hopefully that helps make sense of the problem.

Hello guys. Finally, with wimboot systems work fine in all computer. This was the code: #!ipxe cpuid --ext 29 && set arch amd64 || set arch x86 kernel http://${fog-ip}/iso/asus/133/wimboot initrd http://${fog-ip}/iso/asus/133/BOOT/BCD BCD initrd http://${fog-ip}/iso/asus/133/BOOT/BOOT.SDI boot.sdi initrd -n boot.wim http://${fog-ip}/iso/asus/133/SOURCES/BOOT.WIM boot.wim boot Thank all, a lot.