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

@Eliza Cual version de FOG y de Kernel esta usando? Puede poner una foto de la pantalla con el error de Kernel?

What version of FOG and Kernel are you using? Can you post a photo os the screen with the Kernel error?

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

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

@sami-blackkite What filesystem are you using on your device?

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

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

@stokehall @george1421 I have the 6.11 kernel booting, however I am unable to get the keyboard and networking working. It seems like this keyboard issue is also affecting Linux distributions trying to build for the X1 SOCs like Ubuntu.
I have not been able to test anything on the init (imaging, registering, etc) because of the networking and keyboard issue. Also, Buildroot has not updated their linux headers to include 6.11 so I can build the new init needed.

@stokehall Thank you for the update. I didn’t think Ubuntu was going to start using kernel 6.11 for their 24.10 release, but it seems like they are, so I’ll take a look over the weekend.

@george1421 I’m getting an X Plus, X1P-64-100 (10 cores up to 3.4GHz, NPU integrated). I’ll be getting an X Elite probably a few weeks later but from my understanding, they are the same generation.

I will be getting a snapdragon laptop on Monday for FOG/FOS testing.
It looks like kernel 6.11 will most likely be released Sunday but there already is a release candidate that I could build to test with.

@Tom-Elliott Implemented some changes to support ARM by default on the 1.6-alpha branch of FOG.
I am currently porting it over to the 1.5 dev-branch

@george1421 Let me know how that goes. I remember that I had to patch something on buildroot for partclone and ncurses. A new patch may be needed if they made changes for 2024.05.1.
I can give it a try as well.

Are you trying to build the newest version of partclone?

@Cire3 FOG 100% works in Proxmox. My FOG install runs on my Proxmox server without any issues.
How is your storage pool for your images setup?

@Kureebow Kernel version 6.1.63 is the one with changes for UFS. You can try updating the kernel on its own first.

@VegaFlash I just published the new inits that include a newer version of e2fsck.
If you have the newest version of FOG installed from the dev-branch 1.5.10.18, you should be able to update it easily through the settings page.

If your FOG server isn’t on the newest dev-branch release, either update it or follow the next steps.

1. SSH into your FOG server
2. cd /var/www/fog/service/ipxe
3. mv init.xz init_original.xz #Not necessary but recommended so you can revert if there are any issues
4. wget https://github.com/FOGProject/fos/releases/download/EXP_20240430/init.xz
5. chmod 644 init.xz
6. chown fogproject:www-data init.xz

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