@george1421 said in Issues with inventory and uploading image:

That isn’t the response from the file command I expected.

Some older Linux systems do not provide the great output using file that we see with up to date systems.

As the OP reported the issue is solved, we don’t need to worry.

@DylanG I provided a database query and requested you to post a picture of the error you see on screen. If you don’t provide that information I won’t be able to help you.

@VlanFlex said in FOG won't deploy properly.:

https://ibb.co/D1wd4cs
Any idea why it would show up as an SATA device?

Can’t see enough information on the picture as it’s not clear enough. M.2 does not mean the disk is NVMe in general! So I can imagine this to be a M.2 SSD drive showing up as sdX in Linux. You can run hdparm -i /dev/sdX (put in a and b instead of the X) to get some more information about the disk drives.

@Pere-Pozo-Miro You are probably using a dock for network connection, right? Some of the docks do a pass through of the device’s MAC address or hand out the dock’s MAC address either.

Which exact model of dock do you use?

How do you register the device? Through the PXE menu or manually in the web UI? What MAC do you see in the web UI for it after registration? Please post the full MAC address or at least the first three blocks here in the forums so we know which vendor it belongs to.

@george1421 Thank you so much! It works now!

These laptops are coming with M2 Nvme disks, i used diskpart in windows 10 with “clean all” option to fix the problem.

Yes all laptops are UEFI only

I am building fresh windows 10 using one of the new Microsoft ISO files.
I will try to capture an image from one of the laptops and try to deploy it to other.

If this will not work we will raise a ticket with dell

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