This appears to be caused by a recent update to the iPXE repo on Github. Here is a link to someone else encountering the same error:

https://github.com/ipxe/ipxe/discussions/1126

According to the thread above, build 6ca597e will not cause this error, which is the build before the one that gives this error. Therefore I added the line “git checkout 6ca597e” in the buildipxe.sh script after the git pull lines for the iPXE and iPXE-efi repositories. This allowed me to compile the binaries via the script without errors. I hope this helps if you come across this error!

Update, rebuilding the VM from scratch helped it at least boot to windows a little before a sysprep error appeared during the specialize step.

I generated a new answer file using this link: https://schneegans.de/windows/unattend-generator/

I then modified it to have our local admin account info. I have tested my Image on 4 separate models, and the sysprep skipped OOBE as desired and only prompts for a network connection before booting, which is perfect. It then boots to the login page for the local admin where install packages are located on the desktop.

Thank you again George for your help!

I tried reinstalling the Capone plugin, but that didn’t work.

I checked my other machines that show the fog.capone option and I manually added it in using the New iPXE Menu Entry option with the same values as my other machines. I haven’t tested if this is the solution yet. Here’s a screenshot of my values:

Hello!

I have several FOG Servers that I am adding Capone to. On one of them, I have Capone installed and FOG up to date to the latest stable version. However, the fog.capone PXE Menu Item is not showing in the Fog Configuration settings. What can I do to have this show up? I have Capone on another server and it is showing on that one.

Thank you!

@TaTa Glad that worked for you! There hasn’t been any update to the github thread since 1/31, but I was able to compile binaries today using the original buildipxe.sh script without the additional line without error.

This appears to be caused by a recent update to the iPXE repo on Github. Here is a link to someone else encountering the same error:

https://github.com/ipxe/ipxe/discussions/1126

According to the thread above, build 6ca597e will not cause this error, which is the build before the one that gives this error. Therefore I added the line “git checkout 6ca597e” in the buildipxe.sh script after the git pull lines for the iPXE and iPXE-efi repositories. This allowed me to compile the binaries via the script without errors. I hope this helps if you come across this error!

Here’s a screenshot of the error if that’s easier to read:

Hi,

I’m trying to compile the latest iPXE binaries using the buildipxe.sh script but I am getting an error when it tries to build bin/aes.o:

[BUILD] bin/aes.o
In file included from <command-line>:
crypto/aes.c: In function ‘aes_gcm_setkey’:
include/assert.h:82:10: error: call to ‘build_assert_805’ declared with attribute error: build_assert(( ( void * ) &context->raw ) == ( ( void * ) context->gcm.raw_ctx )) failed
82 | C2 ( build_assert, LINE ) ();
| ^
./include/compiler.h:46:21: note: in definition of macro ‘_C1’
46 | #define _C1( x, y ) x ## y
| ^
include/assert.h:82:4: note: in expansion of macro ‘_C2’
82 | C2 ( build_assert, LINE ) ();
| ^~~
include/ipxe/gcm.h:92:2: note: in expansion of macro ‘build_assert’
92 | build_assert ( ( ( void * ) &context->gcm ) == ctx );
| ^~~~~~~~~~~~
crypto/aes.c:805:1: note: in expansion of macro ‘GCM_CIPHER’
805 | GCM_CIPHER ( aes_gcm, aes_gcm_algorithm,
| ^~~~~~~~~~
crypto/aes.c: At top level:
cc1: error: unrecognized command line option ‘-Wno-dangling-pointer’ [-Werror]
cc1: all warnings being treated as errors
make: *** [Makefile.housekeeping:964: bin/aes.o] Error 1

I’m on Ubuntu 20.04, I did apt update and apt upgrade, and FOG is 1.5.10. I’ve tried downloading the script again, downloading the fogproject package again, and cloning the iPXE package and trying to manually do it, but it always gives this error.

I’m not really sure what the error means or what I need to do for this to work. I have other FOG servers on Ubuntu 20.04 and same make package version that have latest Ubuntu updates and they can compile using the buildipxe.sh script no problem.

Any insight would be much appreciated.
Thank you!

@george1421 I am using two NICs because I want all the imaging to happen on a segregated network and any repo updates or image replication to happen over the LAN NIC. This prevents imaging from happening over our firewall tunnels.

With that said, I have the Location plugin enabled and setup so that inits/kernels are pulled from the local storage node. However, you are saying the remote storage node needs connected to the master for the duration of the image because it is using the Master’s database. So if I still want imaging to not go over our firewall tunnels (ie pushing a 30-60GB image to a device between the master and remote storage node) I need Location enabled and then the image replicated. Instead of having dhcp and tftp happen on the imaging NIC, I could just use 1 NIC on our LAN and the location plugin will ensure the image comes locally from the storage node? That way the device being imaged can pull from the master for instructions and then the bulk data transfer stays local. Do I have that right?

Hello,

I have a Master and a Storage Node both configured with 2 NICs (eno1 and enp2s0). I want eno1 to be connected to my internal network for remote management as well as image replication. I want enp2s0 for imaging (DHCP, TFTP, PXE).

In the FOG console under Storage, if I set the interface and IP to what is staticed on eno1, replication works, but imaging doesn’t. If I set the IP and interface to what is staticed on enp2s0, imaging works, but replication doesn’t. What file do I need to edit to set it so that replication works on eno1 but imaging only on enp2s0?

Any help would be appreciated!
Thank you!
Ryan

Update, rebuilding the VM from scratch helped it at least boot to windows a little before a sysprep error appeared during the specialize step.

I generated a new answer file using this link: https://schneegans.de/windows/unattend-generator/

I then modified it to have our local admin account info. I have tested my Image on 4 separate models, and the sysprep skipped OOBE as desired and only prompts for a network connection before booting, which is perfect. It then boots to the login page for the local admin where install packages are located on the desktop.

Thank you again George for your help!

@george1421 Thanks for the info George, I’ll take a look at this for the answer file. I noticed my VM has 6 partitions instead of the regular 4, so I’m rebuilding my VM from scratch with the standard 4 Windows partitions. Wonder if that was causing an issue.

I’ll post an update once I’ve rebuilt the reference image and test a push to a few different models.