@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.
@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.
Hello, it has been a while since I have tried anything for this.
I now have more time and more equipment to actually work on this.
I have taken some time to learn a bit more about the Linux kernel and adding a module to it (still so much more to learn).
@george1421 I used the reference link, excluding the arm specific parts of the Kconfig, and compiled the kernel. I can see that the driver was added during the compiling process because I see this output CC drivers/hpuefi/hpuefi.o, but I can’t figure out if I did it correctly.
When I pxe boot to Debug Mode I can’t run lsmod or modprobe to find if it was installed.
These are the steps I did to compile the kernel. Please let me know if this is correct.
1 . Clone FOS repo from GitHub
2. Run ./build.sh --kernel-only --arch x64
3. When the output “We are ready to build. Would you like to edit the config file [y|n]?” comes up, I opened another terminal and then did this:
a. Made directory hpuefi in /path/to/fos/kernelsourcex64/drivers/
b. Copied the hpuefi module files hpuefi.c & hpuefi.h to that directory.
c. Made Makefile in /path/to/fos/kernelsourcex64/drivers/hpuefi with content:
obj-$(CONFIG_HPUEFI) += hpuefi.o
d. Made Kconfig in /path/to/fos/kernelsourcex64/drivers/hpuefi with content:
config HPUEFI
tristate "HP UEFI Kernel Module"
e. Modified /path/to/fos/kernelsourcex64/drivers/Makefile adding:
obj-$(CONFIG_HPUEFI) += hpuefi/
f. Modified /path/to/fos/kernelsourcex64/drivers/Kconfig adding before endmenu:
source "drivers/hpuefi/Kconfig"
g. Modified /path/to/fos/kernelsourcex64/arch/x86/configs/x86_64_defconfig adding:
CONFIG_HPUEFI=y
4 . Returned to the original terminal with the prompt still open and entered n.
5. Entered y for the prompt: HP UEFI Kernel Module (HPUEFI) [N/y/?] (NEW)
6. Pressed Enter for everything else.
After it finished, I copied the bzImage to my testing FOG server.
I can boot into Debug Mode but don’t know if the module was added successfully.
Sorry for the long read but hope this is enough information to figure out if/what I did wrong.
@george1421 Thank you for the explanation. I am trying to do this not as a fix for the passthrough to work, instead as a patch/workaround. @Sebastian-Roth I don’t think this should be added to FOS for everyone since it doesn’t really fix anything, again it’s just a workaround for me. I have read many threads of people bringing up this issue and maybe this can be a sort of solution for now but it would only work on HP machines.
In my case, iPXE is getting the correct MAC (passthrough from BIOS) but FOS is not. My thought was to run this utility when registering the computer to FOG so that the MAC address attached to it is the passthrough one instead of the adapter.
I tried this utility on a laptop running Ubuntu and I know that I can retrieve the system MAC address for sure, and that it is correct. I am limited in my Linux knowledge to know how to add the module to FOS and then compile it. I honestly got lost with the reference that @george1421 provided.
Hello I need some guidance in modifying FOS to include a new package/software.
I have some new HP laptops that don’t have an ethernet port, this means that I have to use a USB-C to Ethernet adapter. When I register those laptops to FOG, the MAC address it adds is from the adapter instead of the passthrough system MAC address. It seems to me like the issue is with HP’s UEFI/BIOS programming, because it also doesn’t passthrough when in Windows/Linux.
HP has a software called “HP Flash and Replicated Setup Utilities for Linux” which I can use to retrieve the system’s MAC address from Linux.
My idea is to modify FOS and add that software to it, then modify the FOG registration script to check if the UEFI/BIOS has a system MAC address that differs to the one FOS can see. (Side note: I know that this would only work with HP computers and it is fine because we only use HP)
I know that I can modify the registration script using this https://wiki.fogproject.org/wiki/index.php/Modifying_the_Init_Image, but I am limited in my Linux knowledge in modifying FOS with the software.
Here are the install commands from “user guide”:
To install the kernel module:
• tar xzf hpuefi-mod-x.x.x.tgz
• cd hpuefi-mod-x.x.x/
• make
• sudo make install
To install the utility applications:
• tar xzf hp-flash-<version><architecture>.tgz
• cd hp-flash-<version><architecture>
• sudo ./install.sh
Since FOS is stripped down a lot, it doesn’t have the make command or the Linux headers to be able to run the make command, also it would be horrible to have to install the software every time FOS loads.
I would greatly appreciate any help possible.
Thank you in advanced!