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

Hello!

I recommend following these guides.
https://forums.fogproject.org/topic/8889/fog-post-install-script-for-win-driver-injection?page=1

https://forums.fogproject.org/topic/11012/resolution-to-inject-drivers-in-windows-10-sysprep/5
Have worked for all of my models so far.
And all i need to do is keep my driver model repo in check.

Here is another approach.
https://forums.fogproject.org/topic/9859/post-deployment-driver-installation-using-powershell-scripts

Hope this guides you in the right direction.

Oracle Virtualbox only supports legacy PXE booting, which is why ipxe.efi didn’t (and couldn’t) work.

@wayne-workman Hey Wayne, you can forget this. I tinkered with it a bit (reentered in the credentials, changed the path a few times, etc) and for some reason, it started working on the SYSTEM user using psexec. After that, I tested as a snapin, and with the powershell template (powershell.exe -ExecutionPolicy Bypass -NoProfile -File xxxxx.ps1) it worked correctly.

thanks for your help, i was able to ssh into it and get it to turn off. I appreciate it.

@klkwarrior Can’t see where this -S is coming from. Can you please capture the HTTP traffic when this is happening?

Get your client ready but don’t start yet. Make sure you know the IP address it receives on DHCP later on. install tcpdump on your FOG server (e.g. sudo apt-get install tcpdump) run tcpdump: sudo tcpdump -w item_issue.pcap host x.x.x.x (put in the client’s IP address instead of x.x.x.x and leave the command running) boot up the client till you see the error message on screen - then stop tcpdump (ctrl+c), upload the item_issue.pcap file to some server/cloud and post a link here.

@zer0cool I should add fog now has the ability to take raw clonezilla images directly, well you change the filenames a little but otherwise it’s a 1:1 swap. Just set manager to partclone uncompressed. The mbr from cz would change to name d1.mbr, sda1 would change to d1p1.img and up as needed.

@george1421 sorry, i was still researching what might be happening.

For a little bit more background, i can’t get my vm to boot to the win10 1803 iso using efi but I didnt have an issue with the ltsb version last year.

I setup a second esxi server for testing, running 6.5 to see if it was issue with 5.5 and i am able to boot win10 1803 using efi on that test server but not able to pxe boot.

efi network comes up then says downloading nbp file then continues booting. I dont see any other messages but i will do a slow mo video see if i can see if anything flashes up briefly.

On the production server that I can’t get the iso to boot, I was able to get it to pxe boot after i deleted the nic and re-added it using vmxnet3.

recap:
prod esxi server 5.5u3 – cant boot 1803 iso using EFI
Test server esxi 6.5, able to boot iso to EFI but cant PXE boot EFI.

I just did quick google search that brought me to this thread and was just making a general commenting that i was having issues. i can make a new thread if that would be better.