Best posts made by rodluz

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

@Warsonix I really needed to get those laptops imaged asap, so I just used a USB-C to Ethernet adapter on those and it worked. I haven’t touched those laptops since then.
Funnily enough, I have to re-image them next week, so I’ll let you know what happens.
I have done a lot of changes to my FOG server since then, so it’s really going to depend on your setup too.

@sebastian-roth I figured out how to simplify it using patch yesterday. I will look into the link that you posted.

As you said, probably not something to be merged into the official FOS kernel. I’m guessing that I would not be the only one using FOG that would find this helpful so (unless there is a better way) I’m going to fork the FOS repo and make my changes there. Like I said before, I will write up what I did and try to streamline it as much as possible for anyone to reproduce.

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

@bballmcoe I haven’t used CentOS 7 in a while so unless this is a CentOS quirk that I don’t remember, you are running the install script using shell not bash.
Try running the installer like this: ./installfog.sh or bash installfog.sh

@yannickF I may be wrong, but the Persistent Group plugin runs the SQL trigger only when a host gets added to the group. That means that the behavior you are seeing is normal.

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

@pauleb I use this powershell script for my M365 snappin. Hope it helps you.

$username = "DOMAIN\USERNAME"
$password = ConvertTo-SecureString "PASSWORD" -AsPlainText -Force
$creds = New-Object System.Management.Automation.PSCredential $username, $password

New-PSDrive -Persist -Name "Z" -PSProvider FileSystem -Root "\\SHARE\AppRepo" -Credential $creds

Start-Process -Wait -FilePath "Z:\Microsoft\Microsoft365_x64\setup.exe" -ArgumentList '/configure "Z:\Microsoft\Microsoft365_x64\configuration.xml"' -NoNewWindow

Remove-PSDrive -Name "Z"

@ingemedia I will be working on a 6.12.x kernel soon and I will make sure to include the r8126 config.

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

@iljared98 There is a way. The CSV will contain more information than just the Motherboard Product Name, but that is easy to clean.
On FOG, go to the Reports tab and select Inventory Report from the left side menu. Don’t change anything there, just click on Search. Download the CSV from the page using the excel sheet icon. When you open the CSV, column R should be mbproductname which is what you are looking for.