@theopenem_admin Sure, that sounds good. We are in no rush. I did have a similar problem a few years back and a new iPXE build did solve my problem back then. Thank you so much!
It means you have a duplicate computer name or install ID, or that computer needed to re-provision for some reason. Just apply that reset request and if it goes away you are good, if it then knocks off a different computer then those 2 computers are somehow duplicated.
Good morning, tested and works ok. We have found only one ‘anomaly’. When you boot the computer with a dock or NIC via USB, ipxe boots without problems but when it loads the kernel it only tries to assign IP via DHCP on eth0, which in case the computer has an internal NIC, causes it to retry several times without success. If the machine has only one NIC, it works without any problems. Thanks for the quick solution. I hope it will help to fix this problem in future kernel versions.
Same boat here(kernel 6.6.7), not looking forward to switching to the WIE since it's so much larger as far as the boot files etc.
from section 3.1 of this article it seems there is indeed an issue with arguments getting passed to the loader, but there was a commit to supposedly fix it, I'm just not familiar enough with the compilation processes to know what to do with this info.
Same here on new machines, we are looking at the WIE (tests work as expected) as well, but compared to the LIE it's huge as far as PXE booting. I figure this is a Linux kernal issue, but just a guess.
The sysprep module docs say you can replace parts with $customattributes
Is there a list of attributes we can use to dynamically update the sysprep for for example the computer name ?
Yea, Microsoft is making things difficult. The nature of the program which allows remote commands to execute causes the false positive. I've submitted a request to get it allowed, but I highly doubt they will approve it.