@sudburr that’s where i was confused. I was thinking it would boot uefi no problem, but for whatever reason you needed it to legacy boot for imaging.

@Quazz
I thinks that I fixed the issue somewhere along the way and kept on having a different issue on my debug VM, then when I went to check out that issue, I recognized the fact that I already solved it somewhere… The Physical devices also deploy without issue now;

I’ll still need to confirm that the exact issue is solved, so i’ll be creating a few images and see if they restore out of the box.

Thanks again for the quick support, I’ll mark this thread as solved

edit;
(…if I knew how… )

good job! you are the best.

it seems to work with my VM. I will try with the Opliplex 5260 very soon. I’m not on the same working place today.

thanks
Pierre

@jahilton2002 Partclone is the default for FOG 1.2.0 and later. Partimage is left in the configuration for legacy images so they will deploy correctly with newer releases of FOG.

The next question you might ask is zstd or gzip compression. By default gzip is selected since it has been part of fog imaging for many years. The new compression technology is zstd. zstd is known for having a fast decompression speed as compared to gzip. zstd also creates smaller image files on the fog server. The only down side(s) to fog using zstd:

zstd is a newer compression format than traditional gzip compression. It takes longer to compress the image with zstd than with gzip, but decompression times more than make up for the slower compression times (consider you typically capture once and deploy many times).

So what should you pick? partclone with zstd with compression ratio 11.

Also there are 2 bugs in FOG 1.5.4 that have been patched in the 1.5.5 beta release that have not been back ported to 1.5.4.

Roll the FOS kernels back to 4.15.2 (done in fog setup->kernels). Download both the 64 bit (bzImage) and 32 bit (bzImage32) x86 images. This will fix the 3-5 delay (in some cases) creating the partition table (this issue is being actively worked on by the developers) If you run into an imaging issue with out of memory condition (under rare circumstances) there is another fix that I can tell you about if you run into it.

@Sebastian-Roth
ok I’ll try this as soon as I have a moment.
Don’t remember if i have use –force-https , but sure manually configured https in my virtualhost

@george1421 Thank you!
As a precaution I have created all my images outside A.D

SOLVED

A little more information

Below is a view of the C:\fog.log

Not sure if I know what I’m looking for here, but I don’t think I’m seeing any errors

------------------------------------------------------------------------------ ---------------------------------SnapinClient--------------------------------- ------------------------------------------------------------------------------ 9/20/2018 4:51 PM Client-Info Client Version: 0.11.16 9/20/2018 4:51 PM Client-Info Client OS: Windows 9/20/2018 4:51 PM Client-Info Server Version: 1.5.4 9/20/2018 4:51 PM Middleware::Response Success 9/20/2018 4:51 PM SnapinClient Running snapin Office16 9/20/2018 4:51 PM Middleware::Communication Download: http://10.0.0.1/fog/service/snapins.file.php?mac=00:50:56:85:26:8F||00:00:00:00:00:00:00:E0&taskid=49 9/20/2018 4:51 PM SnapinClient C:\Program Files (x86)\FOG\tmp\Setup.zip 9/20/2018 4:51 PM SnapinClient Processing SnapinPack Setup.zip 9/20/2018 4:51 PM SnapinClient Extracting SnapinPack 9/20/2018 4:51 PM Bus Emmiting message on channel: Notification 9/20/2018 4:51 PM SnapinClient Starting snapin 9/20/2018 4:51 PM SnapinClient Snapin finished 9/20/2018 4:51 PM SnapinClient Return Code: 1 9/20/2018 4:51 PM Bus Emmiting message on channel: Notification 9/20/2018 4:51 PM Middleware::Communication URL: http://10.0.0.1/fog/service/snapins.checkin.php?taskid=49&exitcode=1&mac=00:50:56:85:26:8F||00:00:00:00:00:00:00:E0&newService&json 9/20/2018 4:51 PM Power Creating shutdown command in 60 seconds 9/20/2018 4:51 PM Bus Emmiting message on channel: Power ------------------------------------------------------------------------------

I also have been modifying my bat file and have added a output which works perfectly when I run it on my machine. I see the output file pop up and it has all the command responses.

@echo off >C:\Temp\Office16.txt 2>&1 ( PushD "C:\Program Files (x86)\FOG\tmp\Office16" setup.exe /configure configuration.xml PopD )

However when I run this on my target machine nothing happens at all. I don’t see the output text at all.

@Crok Ok, now I got you. Unfortunately I won’t have enough time to come up with a solution to that. So you need to try it yourself. To get back to the initial request, a quick search on the web revealed many projects/libs/… that do wake on lan in python:
https://pypi.org/project/wakeonlan/
https://github.com/bentasker/Wake-On-Lan-Python
https://gist.github.com/rschuetzler/8854764

So it’s just a matter of getting into coding and get it done. This has nothing much to do with what we can do for you as a FOG team.

There should be no functional differences between capturing and deploying to raid-1 vs raid-0. FOS should deploy properly to both. If you think, you are able to deploy raid-1 and its OK you might want to ensure that your array is intact.

I could understand how it might deploy in a raid-1 situation and fail in a raid-0 because of the way the intel raid works, in that it presents the disks as individual regular disks (/dev/sda & /dev/sdb) AND the array disk (/dev/md126).

I wrote a tutorial on how to configure FOS to deploy to systems using the intel raid array disks here: https://forums.fogproject.org/topic/7882/capture-deploy-to-target-computers-using-intel-rapid-storage-onboard-raid

Did you use this method to deploy to the raid-1 systems?

@Sebastian-Roth
Thank you
Its working now, I’ve updated the post with my steps.

For some reason Microsof thought it would be a great idea to constantly fake your Wifi MAC. Despite the MAC being a common identifier for various purposes.

And of course they enable it by default so that it’s the maximum amount of pain for everyone.

@Zer0Cool From what you describe you went a far step already. DHCP relay is definitely what you need to male PXE booting across subnets possible. Would you mind taking pictures or maybe even a video of a client booting that ends in the timeout? Possibly this could shed a light on what is missing.

@newlined I would suggest shorter lease times. Something like below. These values are in seconds, so you can play with them yourself.

default-lease-time 1800; max-lease-time 3600;

After each of these changes, you need to restart dhcp with this command: systemctl restart dhcpd

@sebastian-roth

I found a setting deep in the configuration options to increase the default value from what is was to 99.

This is where computer imaging isn’t exactly a smooth process. Unfortunately, machines implement displaying a drive however they see fit, even across the same model of different machines. Typically the channels that an HDD is connected to (SATA 0, SATA 1, etc…) are followed to some level, but sometimes this isn’t the case (as I imagine you’re seeing now).

It is possible to tell FOG which drive to use, though it doesn’t know if the drive is ssd or hybrid or spinner. This is completely dependent on the machine, and if you can’t rely on which will be populated as what letter (my guess is your machines were setup in RAID mode of sorts?) that isn’t really going to help you much.

One way you could do this though, is to swap out the /usr/share/fog/lib/funcs.sh file and change the getHardDisk function to detect your drive sizes. (You can do the swap out using postinit scripts.) But then it’s implicit that all machines will follow the same method.

The steps I would take, albeit more time consuming initially:

Install the SSD to the 1st SATA Channel (if that’s how your machines are setup – I can’t help much in the case of NVMe/MMC builtin controllers as I have nothing to base them on yet).

Move the 1TB to the second SATA Channel.

Ensure the machine’s firmware is updated to the latest and greatest.

Ensure the machine’s SATA operation mode is AHCI.

If these don’t make your SSD display as /dev/sda then I don’t know else to tell you to try.

@geekjosh Then for safety in the future:

Please run:

mv /var/www/fog{,_backupold} ln -s /var/www/html/fog /var/www/fog

@andrewg78 At this time don’t enable memcached, The developers have decided to not add this feature at the moment.

Actually you should not need to follow any of this post since most of it has already been included in FOG 1.5.2 base configuration and later.

It’s easier to update /opt/fog/.fogsettings and set bldhcp to 1 and dodhcp to Y, and then re-run the installer. The installer will build the correct config file for you and setup the service. More information about the settings file is here: https://wiki.fogproject.org/wiki/index.php?title=.fogsettings

I think the op is using fog as a kind of invetory system 😉

thank you