@svalding What would be interesting to know is what is different between the two docks.

Please do the following

Schedule a debug deploy/capture (tick the check box for debug before you submit the task) for the nic of the working dock. It doesn’t matter if its a capture or deploy because we are not going to do either. PXE boot the target computer, after FOS boots you should see several screens of text press enter a few times until you get to the linux command prompt. Key in
lspci -nn | grep etwork Record what you see there for the network adapter. The hex codes are important. Repeat the same process with the non-working dock. You may get warning messages about not able to access the network, but it still should allow you to get to the linux command prompt. Collect the output of the lspci command from above. Please post the output of those two systems in this thread.

0_1530763109245_33e20c39-f273-4851-b3f1-fedd0e4bbeed-image.png

Got this working over the weekend with QNAP. The NFS shares are slightly different in v4.3.3 of the QNAP software on the TS-231. You don’t have to specify the full local path. Only the shared path location.

@p4cm4n Glad you figured out what the issue was and a way to resolve the problem. Glad to help program this for you, among others. I know how useful it is and how it has impacted jobs.

Now if only I could find a job that requires FOG as a part of it, I think I’d be a shoe in lol.

@plegrand UEFI implementations can be a real pain. It’s meant to be Kind of universal but everyone is just doing his/her own thing. So some UEFI clients work great while others just don’t want to play nicely. There is not much we can do about it. Well, you can try using rEFInd and start playing with the config file. If you are lucky it’s justa matter of finding the right options.

echo Installiere Acrobat Reader DC + Font Pack
“%source%\AcroRdrDC1801120035_de_DE.exe” /sAll /rs
msiexec /qn /i “%source%\FontPack1500720033_XtdAlf_Lang_DC.msi” REBOOT=ReallySuppress

i’ll write a quick tutorial as soon as i have everything working. I guess i can’t use -no–describe in uefi, but i can allways use wimbot to boot to an envoirment and then mount iscsi devices and go from there.
memdisk is a nice kernel but loading the ENTIRE iso into the ram is network consuming and big isos will eat up my ram at best.
running from iscsi is the way to go! it’s like a physical device , but mounted virtually, via a network, it’s like using a pen, but -no-describe ruins some of the feautres i want to use, well… if i want to use it in uefi mode anyway.

@george1421 Thank you for the help. Capture seems to be working properly now.
Tom

@tom-elliott @george1421 So it is taking forever to replicate just 1 Node drivers. We rsynced before but its almost copying every file again. What do we need to do to make the copies be the same and speed up replication? What does FOG use to check the file to see if it matches?

@howtogravity Just manually set it via SQL.

@vince-villarreal If your image contains the FOG Client, which is sounds like it does, simply disable the service, disjoin the domain, capture the image. In terms of SYSPREP, you would have your setupcomplete.cmd set to enable the fog service as the last thing it does. Then you can start the service or restart the machine.

So basic steps:

Create your layout of software/OS, etc… If machine is to be constant master image maker machine, don’t allow it to join the domain (can be setup in the GUI under Hosts->Edit->Active directory->Join Domain) Install FOG Client.
# If sysprepping Disable fog client service. Sysprep Machine. Fully shutdown machine.
# End sysprep steps Capture image.

Thanks and fixed.

Was this meant to be deleted/purged, or is this an issue?

@mattf You could separate the fog servers and the database - so that both servers use the same database on a dedicated VM for this purpose. In this scenario, the fog server would not be able to process queries as quickly because each query would need to traverse the network. Another option is you could use MariaDB 10.x Galera to create a database cluster between the two fog servers. Based on my own experiences with both of these things and considering how heavy FOG is on the database, I’d opt for a Galera database cluster to keep the database local to each server. Here is information on that: https://mariadb.com/kb/en/library/getting-started-with-mariadb-galera-cluster/

@Wayne-Workman @Quazz Fixed, it was that fixparts was missing from 1.5.4 as discussed from this post https://forums.fogproject.org/topic/12059/fixparts-missing-1-5-4-win-10.

To be on the safe side I manually downloaded bzImage, bzImage32, init.xz, and init_32.xz and put them in /var/www/html/fog/service/ipxe/. I followed the directions “Manual update to latest kernel” on this wiki page https://wiki.fogproject.org/wiki/index.php?title=Kernel_Update.

Nevermind, i went to ipxe and saw how sanboot works.
So here’s what i found out:

101 tutorials later, the simpliest way to get Fog to work as a IT Tools and OS’s deployment system is indeed with an iscsi device.

So here’s what i did:

Step1: Get a Synology or an Xpenology
Step2: Create iScsi drive
Step3: Mount the iScsi drive in your favourite OS and Clone / Install whatever you want it there, treat it as you were installing stuff on a drive you would like to have it bootable, in my case, i had a physical hard drive full of tools , windows installs, and even a partition with an instalation of windows so i can test everything out.
Step4: After creating your Hard Drive just use Fog Project menu to say : Hey IPXE boot into this San device please.
In my case i just added: sanboot iscsi:192.168.0.6::::iqn.2000-01.com.synology:SrSynology.Target-1.43ae68fcff , i’ll leave this one here but this one is leading into my xpenology, you will need to modify yours.
Step3.5: i forgot you should enable multiple clients to access your drives, you can also make them read only if they are windows instalations or hiren’s boot or something, it works with everything and you don’t need to use the dreadful memdisk kernel that only works half o the time and it uses a bunch of unecessary ram.

Anyway, many thanks to this comunity you guys were great , for now, i’m setup.

A special thanks to George who was extremely helpful , it’s guys like you who make the internet awsome

Just for notice,
I’m using Fog 1.5.4 normally with ubuntu 16.04 and this function is working fine. Both this option you mentioned and the option to go in the option “power management” work the same.

Best regards, Igor.

@mparlette said in Date off in dashboard #253 - Github:

CentOS 7 w/ FOG 1.5.4
/etc/php.ini date.timezone entry was commented out.
corrected with:
date.timezone =“America/Vancouver”

Technically that may not help you. In a normal world it would. But in FOG’s case its using php-fpm which has its own opinion of things and if you have php 7.x installed then the /etc/php.ini file is typically not referenced since php 7 has this file in a different path.

But having the OS and fog menus in agreement should get you to where you want to be. So good job!!

Something you might consider.

login kernel nfs://10.100.0.55/winimgs/iso/Winpe/wimboot gui iseq ${platform} pcbios && goto mem_bios || goto no_mem :mem_bios initrd -n bootmgr.exe nfs://10.100.0.55/winimgs/iso/Winpe/bootmgr.exe bootmgr.exe goto mem_cont :no_mem initrd -n bootx64.efi nfs://10.100.0.55/winimgs/iso/Winpe/bootx64.efi bootx64.efi :mem_cont initrd -n bcd nfs://10.100.0.55/winimgs/iso/Winpe/BCD bcd ...

Also realize that ${fog-ip} is a variable that expands out to the IP address of your fog server. If you use the variable it makes your pxe menus portable between FOG servers.

Lets collect a bit more information here.

What version of FOG are you using? You captured an image from a reference computer, what hardware was that reference image created on? Is the hardware you are deploying that image to the same as the source computer? Did you capture the image as single disk resizable? Is the target hardware running in the same mode as the source computer (i.e. bios and bios, or uefi and uefi?)