Posts made by rtarr

@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.

Hello,

I am attempting to create a Golden Reference Image that I am capturing to FOG and then deploying to multiple models of devices. I have the Storage and NIC drivers for all the models I support preloaded into the Windows Driver Store using the following PowerShell command:

Get-ChildItem -Path $PSScriptRoot -Recurse | Where-Object -Property Extension -EQ “.inf” | ForEach { PnPUtil.exe -a $PSItem.FullName }

I have verified they are in the Driver Store located in C:\Windows\INF. I am sysprepping using the attached skipoobe.xml file.

skipoobe.txt

The issue I had before was that I could load my Golden Image onto older model devices, but the HP 650 G8 wasn’t working. I updated my FOG Server to the latest dev-branch and I could correctly deploy images to all models now after sysprepping.

Now when I sysprep my VirtualBox VM, I get a boot loop where Windows spins for one and a half loop and then the screen cuts back to the manufacturer logo, it boots to Windows but BSoD’s with an INACCESSIBLE_BOOT_DRIVE error, or Windows Recovery pops up with an 0xc01 error. This is not model specific, and happens for various models, leading me to believe I am missing something in the answer file I’m using. The goal is to use the tthom account that was setup prior to sysprep, and to skip OOBE completely and just go to the login screen.

Any guides, advice, and/or tips would be much appreciated.

Thank you!
Ryan