@kalafina Hi, DISM’s error code 87 is often because of an incorrectly formatted command.
The issues could be because you are trying to run this command with a relative path of the xml file instead of the absolute path.

You can try changing the Snapin Run With Argument to “/c dism.exe /online /import-defaultappassociations:C:\Program Files(x86)\FOG\tmp\”
I’m not sure how the command will react to the space in the file path.

This is what I do for my default app associations snapins. I create a snapin pack with the xml file and a batch file that moves the xml file to the C drive then runs the dism command with the absolute path (dism.exe /online /import-defaultappassociations:c:\appassoc.xml)

Hope this helps!

@westcustom I had this issue with some of my HP workstations. I had to change the DHCP bootfile setting from ipxe.efi to snp.efi and that fixed it.

I know this thread is old, but I am adding onto it with my research and findings.

My experience with this issue is only with HP computers, so no idea how other manufacturers do this.
HP’s firmware is written in a way that MAC address passthrough only works using HP thunderbolt docks, on Windows, using the correct dock drivers. MAC address passthrough also does not work with USB-C to Ethernet adapters because the adapters are not thunderbolt. Given this information, FOS out of the box would not be able to access the MAC address passthrough.
Judging by the Linux kernel patches I have seen online, adding this support to FOS would be pretty difficult since it seems like it depends on the network controller of each dock. This means that each dock needs to be programmed into the kernel and changes to that network controller driver need to be made as well.

The other part of the issue is that iPXE gets the MAC address of the device in a different way than FOS. In my experience, iPXE gets the system MAC address (the same address that should get passthrough), while FOS gets the address that Linux gives through the ip addr command.
I have read other threads where iPXE gives a different MAC address, but it wasn’t HP so I can’t check on that.

I have a workaround that I did for HP computers which I have been testing for a couple weeks. The workaround is working for me, but I would rather do some more testing before putting out a tutorial.

@dvorak Just as @george1421 said, e2fsck needs to be updated on the FOG Operating System (FOS), specifically the inits. The FOS inits haven’t been updated in a bit over a year but I can build new ones for you so you could test it out, just let me know.

@Tom-Elliott I am working on newer inits with the updated e2fsck package to resolve this issue.

@VegaFlash I will update you when the new inits are available, for you to try it out.

@george1421 Thanks so much! So what fixed it for me was just removing all the other iPXE commands. So now my parameters are:

login
kernel bzImage loglevel=4 initrd=init.xz root=/dev/ram0 rw ramdisk_size=275000 web=http://10..../fog/ consoleblank=0 nvme_core.default_ps_max_latency_us=0 rootfstype=ext4 mac=${net0/mac} ftp=10.... storage=10....:/images/ storageip=10.... irqpoll chkdsk=0 capone=1 type=down img=1909GoldenImage imgType=n imgPartitionType=all imgid=43 osid=9 imgFormat=0 auditMode=1
imgfetch init.xz
boot || menu

This works perfectly for what I need.

@DARUN974 I’m not sure what you are referring to by “reconfigure”.

How did you update the kernel?
I would recommend you update the kernel using this guide.

@chasteencs That’s strange, not sure why they wouldn’t be there. You could get them from https://github.com/FOGProject/fog-client/releases/tag/0.12.2 and place the files in the /var/www/fog/client directory.

@george1421 Okay so I found it in /proc/devices and I was able to get the HP program working!!
I had to add the program files to the init.xz filesystem and modify parts of the program to not use the modprobe & rmmod commands.
I also had to create the directories needed for dynamically loaded modules and add the compiled module into it so that the program can look for it there.

I now have to do the third part which is custom postinit scripts to use the system MAC address instead of the dongle address. This should be pretty easy.

Once I have that working, I am going to do a full write-up of it for reference for myself in the future and anyone else that comes across this.

@JJ-Fullmer I’m currently working on new kernels and inits. Having issues with building partclone for the inits, but I’ll hopefully have some time this weekend to get it done.
I will include the ufs changes for the kernels.

@Clebboii I just checked through the commits between kernels 5.15.34 and 5.15.98. I didn’t see any changes that would cause this issue.

I have a theory of what it could be, so can you try this kernel I added to my forked repo. Let us know if the networking issue still persists.

@John-L-Clark Can you try updating to the latest dev-branch of FOG? This is mainly to update iPXE to the latest version.
After updating, please try the experimental releases of the kernel 6.12.25 and initrd 2025.02.0

@Itay1787 I just pushed a change to the dev-branch. Please try installing it again from there and let me know how it goes.

@jflash Great! Did you use the default kernel from FOG after the update, or did you use the kernel from my repo?

@Tycho Okay so I see two things that could be the problem.

1. Is your Hyper-V network adapter on the same subnet as the FOG server? I’m guessing yes as I only see one scope in your DHCP.
2. In the FOG document that you uploaded, is see this line: All router, DNS, and DHCP setting: No, n in the installation steps.

I recommend that some of those settings are actually set to yes. Like this:

Make sure that the IP for your DHCP and DNS servers are set correctly in those first two prompts.

If it still doesn’t work, then please include an image/video of the failure.

@pilipp_edv I had a very similar issue to this a while back but it was with an HP laptop. It turned out to be a hardware defect. I was able to get the motherboard replaced under warranty, so maybe you can too for this laptop.

@jflash I was just rereading through the full post and noticed a couple things.

I’m using FOG version 1.5.9. TFTP Server settings:

This is a really old version of FOG. I would recommend upgrading to the latest stable release.

From the last picture, your iPXE version should be updated too. @Tom-Elliott Can correct me if I’m wrong, but the iPXE version will update when you update FOG.

@jflash Thank you for the video. I don’t see anything that jumps out at me that is wrong.
I created another kernel on my repo to try. https://github.com/rluzuriaga/fos/releases/tag/EXP_20250430

If that doesn’t work, maybe you could try disabling Securlty -> Memory Protection -> Execution Prevention.

If the memory protection setting doesn’t fix it, could you post the output of lspci -nn by booting into a linux environment on that computer? (Sorry I forgot the flags last time I asked)

@ingemedia We just released new experimental kernel/initrd. I included the r8126 drivers. I don’t have any devices to test with so would you be willing to test it and let me know?

@jflash We just released a new experimental kernel/init. Can you update both the kernel and initrd, they are versions 6.12.25 & 2025.02.0. Try those and let me know if it still kernel panics.