@wmw509 Disabling CSM makes sense. I’ve seen a lot of bioses that if CSM is enabled it only lets you use the legacy/bios pxe boot. I’ve had that disabled on all my hardware for so long I forgot it was a thing.

@FOG38640 said in DHCP option 67:

Is there an option for FOG to automatically choose between BIOS and UEFI?

For what? For the network boot file?

If so that is done by your dhcp server. What is your dhcp server? (its been a few days so I don’t remember, a quick scan of the thread didn’t answer that question either)

Edit: found it way at the bottom Windows 2019 server. So there is instructions for windows 2012 and later. Hopefully it translates to 2019 dhcp servers. https://wiki.fogproject.org/wiki/index.php/BIOS_and_UEFI_Co-Existence#Using_Windows_Server_2012_.28R1_and_later.29_DHCP_Policy

@Sebastian-Roth
Hello, Sebastian,
I believe the reason for why hostnames were not updating was due to the client not being up to date, however, after a name change, AD is still not updating, causing a trust relationship error when logging in and the domain does not change. Also, we a running 0.12.0 client version. Any other ideas on why AD is not communicating correctly? Thanks!

@Tacolover99 said in New to this:

Which I wanted but I notice that the internet was limited connected. So CMD, and found out the Thin Clint also inherited the IP Address from the other thin client. Check the original one and now that thin client is doing the same thing. Not to sure if it is DHCP problem when I cloned it.

I think you need to explain this part in more depth. Probably best if you can post some pictures so we know what you mean by “limited connected”, “inherited the IP Address”, “doing the same thing”.

@Sebastian-Roth Thank you very much for your help! After you pointed me to the right file, i found a very easy and good working solution.

/var/www/html/fog/lib/fog/fogbase.class.php:

Changed line 2305 from:

$size = filesize($file);

to:

$size = exec("stat -c %s ".$file);

I found this nice solution over here:

stackoverflow

Reverted my changes that i showed in the last post, restarted FOGImageReplicator service, and it works perfect!

We know that this can’t work for forever, and Updates are also nice and good, so we need to change a few internal things, and also reinstall this Server with x64 Debian.

Thanks for your great support. Keep up this very very nice project!

@george1421 Thank you lol, yeah the ips are still the same, we are working through it and will post the resolution.

@rodluz Sorry, somehow I lost track of this topic! Here you go…

@jtappen The picture you posted, is this in Hosts -> edit one host’s settings -> Active Directory or in Groups -> edit group settings -> Active Directory?

If it’s the host’s settings then we can start digging deeper by looking into the database:

shell> mysql -u fogmaster -p Password: ... mysql> use fog; ... mysql> UPDATE hosts SET hostPubKey='', hostSecToken='', hostSecTime='0000-00-00 00:00:00'; ... mysql> quit

The password for the fogmaster database user is found in /var/www/html/fog/lib/fog/config.class.php.

@plegrand Testing internet connection is now done mainly with curl.

Hi,

i am not sure if it can simply deleted, It’s used in recovery cases and there are 12,5MB of data in it. I need to find out if Windows 10 is using it for what ever case.

Best Regards X23

@Sebastian-Roth Thank you, I did forget about using Multicast. I’m running a job now using it and it’s immensely improved bandwidth utilisation!

@Kamiii said in Fog Update 1.4.4:

As for the images, how do I copy them over to a new fog node?

When you setup a new FOG server make sure you place the /images on its own partition. If you use Centos to install the default will be to place the root partition on 50GB and then give /home the remainder of the disk. For FOG I would select custom configuration and then select auto create partitions. Then rename /home to /images sections and then set that configuration. This will keep you from accidentally filling up the partition with imaging and killing your OS and database. The other option if creating in a VM pick the minimum size of disk required by your OS and then install the OS. Once the OS is installed create a second disk for your images and then mount that new disk over the /images mount point, THEN install FOG. This will then keep your disk images on a different disk and away from your OS disk.

thanks guys 🙂 that fixed my problem

and i have mounted a share from my host to the vm … and that was working fine until i rebooted as i know now 😄

i forget to automount this share on startup and than fogserver wasn´t writing to the share 🐶

@zzeuss1969 Thanks for the update. It’s interesting you get this error message when capturing in legacy BIOS mode and deploying to UEFI. While I know that you cannot boot a machine in UEFI mode that has a legacy BIOS image deployed to it I don’t think that you’d get this error when capturing/deploying. We do actually have users who capture UEFI installations in legacy BIOS mode because they do their master image in a VirtualBox environment which you still cannot PXE boot in UEFI mode and it works all fine deploying this image to an UEFI machine.

Anyhow, good you got it solved!

@Sebastian-Roth Thanks for the TIP. I did make the change on the storage nodes as well. The time on the reports is now correct.

Thanks for the reply.

@Bastian Looking into this, I can’t believe its still an issue after all of these years (> 5). The only solution I can find is to switch the disk controller to ahci mode from RST. If you have a live system that was installed with RST on windows will hate you. I’ve found instructions on how to fix windows.

The ideal solution would be for you to recreate you golden image and sysprep it on a system with the disk in ahci mode enabled. That way everything will work moving forward.

@Sebastian-Roth So it turns out most of my problems were in fact caused simply by old software. I installed Ubuntu 20.04 and FOG 1.5.9 and it solved all the database updating issues.

Now I just have to solve some DNS problems that I’m pretty sure are not FOG related.

Thanks mate.

@Sebastian-Roth I understand than I was racing my brain on this lol

Turns out the DNS server was not ser correctly and the server got it’s IP via DHCP. We got that fixed.

@jmvela2x Sorry, lost track of this.

Here you have a template for an advanced menu:

#!ipxe :ADVMENU menu colour --rgb 0x00567a 0 || cpair --foreground 1 1 || cpair --foreground 0 3 || cpair --foreground 4 4 || item item1 Do this item item2 Do that item item3 Go back to main menu choose --default item1 --timeout 6000 target && goto ${target} :item1 echo "Do this" || goto ADVMENU :item2 echo "Do that" || goto ADVMENU :item3 chain -ar http://${fog-ip}/fog/service/ipxe/boot.php || goto ADVMENU

@george1421 thank you for all the help yet again 🙂

seems to be all working as my router for the dhcp server and the fog server as the pxe server.

PS. i have to say it is a really nice project/community to flow in like this with people willing to help thnx appreciated.