Posts made by rodluz

@Sebastian-Roth I just tested this change on my server and it is now working! Thank you

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

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

@DARUN974 Hi, I may be understanding this wrong but the output of the commands that you posted are from the FOG server or the host computer in debug mode?

If the output is on the host computer, then the Linux kernel is old (4.19.145) and you should update it to the newest one available (5.15.68).

@ericl Hi, are you able to give us a picture of the screen at the moment you get the error message?
There may be some more context in that image.

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

@Sebastian-Roth Thanks for the reply. I think you are right that it is an issue with PHP 8.

Yes please check the apache error log when this happens. See my signature on where to find the log.

I checked the apache error logs and there are no errors from trying to add the host to that group.

Is that one on PHP 8 as well? Please run dpkg -l | grep php-fpm on both servers and post the output here.

I ran the command on both systems and the server using FOG 1.5.94 is using PHP 7.2.24 while the new server with FOG 1.5.9.235 is using 8.1.

Hi all. I installed FOG 1.5.9.235 on an Ubuntu 22.04 server.
I activated the persistent groups plugin and created the host/group.
The issue is presented when trying to add a host to that group, the page just refreshes and goes back to show that the host isn’t a member of any group. It looks to me like FOG tried to add the host to the group, but the system just failed silently.
The same thing happens when I try to add the host through the group’s membership tab. I am able to add the hosts to a normal group without an issue.

I currently have the persistent groups plugin working on my 1.5.9 server (not the same host names or mac addresses).

I know that the plugin is really just a wrapper for the SQL trigger, so did anything change on the SQL side?
I also don’t know if there are any logs that I could look at, or produce through MySQL, to see what happened.

Thanks in advance!

Edit: Just tested it on another of our servers using FOG 1.5.9.94 and it DOES work on that version.

@h3krn & @Sebastian-Roth I may be completely wrong about this one (I haven’t really taken a deep dive into this file) but looking at the code, is the issue in the if statement in line 457? I only say this because the comment contradicts the statement. Should the ! be removed from the if statement?

456        # If fixed, add the partition size.
457        if (!match(fixedList, regex)) {
458            # Increment the variable value.
459            original_variable += p_size;
460            continue;
461        }

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

@chasteencs Do you see the SmartInstaller.exe & FOGService.msi files in /var/www/fog/client?

@fabiano-matos said in Cannot install a CA Certificate:

I did like you said. In the box fogserver I’ve tried my DNS and my IPV4 address. But still getting the same error.

Few questions:
Just making sure, when you say “my IPV4 address” you mean the FOG Server’s IP address right?

Was this a clean install of the FOG client on the computer or did you have an older version already installed?

Is your FOG server set up with HTTPS? If so, are you checking the Use HTTPS to connect to FOG server box?

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.

@Bristow-0 Doing some google-ing, seems like there is a package named virt-sysprep that does something very similar to what Windows Sysprep does. I will play around with it on a VM later today and let you know how it goes.

@bristow-0 I do all my images using Proxmox VMs and I haven’t had any issues. In my case, I only deploy Sysprep-ed Windows so I’m not sure how it would work with Linux. I know that Sysprep strips away any hardware-specific data from the Windows image, so you would need to do the same for Linux.

@thedark5776 Bueno en mi trabajo no usamos FOG con computadoras Mac. Puede ser que @george1421 te pueda dar sugerencias en cómo usar FOG para la captura y despliegue de imágenes para computadoras Mac.
Me imagino que también depende en que systema operativo. ¿Nos pudieras decir si estas queriendo usar FOG en Mac con MacOS o Windows?

Well at my job, we don’t use FOG to capture and deploy images to Mac computers. Maybe @george1421 has some suggestions for you on how to use FOG to capture and deploy images for Mac.
I imagine that this depends on the operating system you are trying to use. Could you let us know if you are trying to use MacOS or Windows on the Macs?

@thedark5776 solo reiterando y añadiendo a lo que @george1421 respondió. Todo depende en como quisieras usar el servidor FOG. Si quieres usar FOG solo para el despliegue de imágenes unas pocas veces al año, entonces si puedes apagar el servidor. Ahora si quisieras usar FOG para administrar las computadoras después del despliegue usando los servicios incluidos con FOG como snapins, administrador de impresoras, mantenimiento de Active Directory, etc., entonces necesitas mantener el servidor prendido.
Si apagas el servidor, necesitas chequear que el orden de inicio en el BIOS/UEFI tenga el disco duro or Windows Boot Manager como la primera opción.

Just to reiterate and add to what @george1421 answered. It all depends on how you want to use your FOG server. If you want to use it just to image some computers a few times a year, then you could just turn the server off. If you want to manage the computers after imaging them using the included FOG services like snapins, printer management, Active Directory support, etc., then the server needs to stay on.
If you do turn the server off, make sure that the computer’s boot order has the hard drive/Windows boot manager as the first option.

@yeet I can’t really speak for that model of the ProBook, only have a 650 G8 at hand and it works, but I had an issue like that on 5 EliteBook 850 G6 from a batch of 50.

I also tried all the same things that @Sebastian-Roth suggested with no luck. What I ended up doing for those few was to connect them using a USB-C to Ethernet adapter until right after the bzImage and init.xz then quickly switch the cable to the integrated Ethernet port when it’s connecting to the net0 interface.

As Sebastian said, you may have some luck using ipxe.efi.

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