@Kureebow Which kernel version and FOG version do you use? Does the same happen on different computer models?

@chambie said in Fog Configuration Kernel Update not working:

I have this file in two directories, one that is updated and one that is not.

You seem to have a duplicated FOG docroot, one in /var/www/html/fog/ and another one in /var/www/fog/. In certain cases this happens - I think I have only seen this when the FOG installer runs for the first time but does not finish properly. Though I never had the time to look into this properly.

Now that you know the correct docroot path on your system I suggest you rename or move the wrong one. But instead create a symbolic link pointing to the correct one named just like the old wrong docroot directory.

@lostitguy Do you have any USB devices connected. If yes, then I suggest you disconnect all if possible or use different USB ports and try again.

I missed the step to run the installer again. That seems to have resolved my issue. Thank you very much!

@jfenner said in Changing Server IP in VirtualBox?:

I’ll check with our admins, but our environment is fairly rigid.

If you can’t run a second network, then there should be only two places outside of the web ui that you need to update.

a hidden file /opt/fog/.fogsettings and /tftpboot/default.ipxe Inside the web ui FOG Configuration->FOG Settings and hit the expand all button. Search for the old IP address and replace it with the new. Press the save button in each section where you find the replaced IP address Then in Storage Nodes -> Default storage node there is an ip address in there.

Once those three have been changed and then rebooted it should work on an isolated network. Its best to rerun the fog installer script but it should work without it as long as if you change the IP address in those locations.

@hammerc807 Hello.

We checked a bit more on some logs on the client, and turned out we enabled the FOG_LEGACY_FLAG_IN_GUI on the server, and we passed the image from “partimage” to “partclone Zstd” and problem solved.

Apparently with partimage the client wasn’t able to write on the disk (where it was perfectly fine on the other one)

Thanks a lot for you help.

@Sebastian-Roth
Thank you for the quick response, I was able to put the images back in place, only the hosts will remain.

Thank you so much

@Ax_Hades Please open a new topic in the forums and give us some more information on your own setup (FOG version, DHCP server, make and model of client machine, picture of errors on screen, …).

@jisd Please post the full logs for fog and see if there is also a log for the Apache web service.

@alexamore90 said in Specification pc before deploy:

in which folder should it be replaced

The answer is difficult to explain in just a few words.

The fog.download file is actually in the FOS Linux image that gets transferred to the target computer before imaging begins.

The fog developers provided two call out functions where the fog admin can do things before imaging starts and just after imaging stops but before the target computer reboots. You will use the first call out that the developers give you called a post init script. This call out script is called just after FOS Linux (the OS that runs on the target computer boots). My idea is to use this first call out to copy the patched fog.download script from the fog server to FOS linux, then when imaging starts it will use your patched file with the data you need to see. I would place the file to copy in the same directory as where the post init scripts are called from.

NOW Sebastian mentioned an easier way to go about this without patching the fog.download file. In that you will again use the post init script call out script to simply print the info you need then pause waiting for a key press before continuing. There is nothing to patch, you will simply create a bash script in the post init directory and then call it from the post init callout script.

Thinking outside the box, actually you have the power of php engine on the fog server. If one stretches their imagination a bit, this same script that displays your information on the screen, you should use php mail and send the contents of the fields in an email to you. This is a little harder to setup, but its not that hard to do.

@Sebastian-Roth May i know which part of the PHP will passing these argument into kernel ?

@george1421 said in Issue booting PXE on clients:

https://forums.fogproject.org/topic/12796/installing-dnsmasq-on-your-fog-server?_=1681250221198

Ok, let me check with my boss and give me a few days to see if I can fix it. Because we have some work to do. Thank you very much for the help and I hope it works because I’ve been trying to get this implementation out for about a month.

Practically, they let me do it all and no device information or anything hahaha.

@zbe So from your picture it appears the wait time is coming from iPXE getting an IP address?

Yes.

What version of FOG are you using?

1.5.10

Could you grab a new pcap of the failing pxe boot sequence

Well, technically it’s not failing, it just takes 180 seconds for yet unknown reason.

–

I PM-ed you 6 captures. 3 are done booting UEFI and other 3 BIOS.

I used 3 different network devices:

VirtIO paravirtualized Intel E1000 Realtek RTL8139

As you’ll see almost every configuration behaves somewhat unique. It makes no sense to me. 😛

I can do captures of physical PCs sometime next week, hopefully.

@alexamore90 said in Post download install script:

it start ms-settings:activation

I don’t know that command. I have not used it before.

I;ve used the command line scripts

cscript //nologo c:\windows\system32\slmgr.vbs /ipk <activation_key> cscript //nologo c:\windows\system32\slmgr.vbs /ato

The setupcomplete.cmd will only run if you use sysprep. Do you sysprep your images before you capture with FOG?

@Sebastian-Roth
I think to know what is blocking.
I have to change vlan and fog IP adress to make updates but it use IP parameter in the updateDB() function :

wget --no-check-certificate -qO - --post-data="confirm&fogverified" --no-proxy ${httpproto}://${ipaddress}${webroot}management/index.php?node=schema >>$error_log 2>&1

I think -X with help to finish install.

@jblomquist said in Is there a way to restrict FOG menu access to specific users?:

I’d like to allow a particular user to be able to deploy an image, but not quick delete a host through the PXE menu.

Which version of FOG do you use?

The quick delete option is secured in the iPXE menu in FOG 1.5.10 (github commit).

@AlexPDX said:

i see u did not find the time to fix the M.2 NVMe problem 😐 …and the Storage Nodes being Unauthorized 😐

No, we haven’t yet. You are very welcome to get involved and help fix this stuff.

@Sebastian-Roth Challenge accepted!😁

As a side note:
The image type description in the wiki (I got there from the balloon help: https://wiki.fogproject.org/wiki/index.php?title=Managing_FOG#Images) points to a non-existing page (404): https://docs.fogproject.org/en/latest/management/image-management.html

Thanks! @JJ-Fullmer would you find the time to fix that quickly?

Fixed!
@medchemii thanks for letting us know. We changed the structure of the new docs page a bit and it affected the links. We’re working on getting redirection working for old links still