@george1421 I might just try that, just for troubleshooting purposes. Re: firmware - There is a BIOS update for the machines, and a firmware update for the NVM Samsung drive. Sadly, trying these was my first troubleshooting step (not listed here, because it was before I suspected components of FOG). I sure was holding my breath that it was the drive firmware though!

@aspiringtow that is correct.

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

@fogmania said in Can't do Quick Image After creating Users: I’m using a storage node that is working well but it has not been updated to the last version. Should I do this too? Absolutely - it’s required in most cases. But the image history still shows that the user that is logged in is the one that made all imagings. Any idea? Others have complained about this too, see this thread: https://forums.fogproject.org/topic/11596/host-imaging-history-lists-the-current-image-name-on-every-line

@george1421 Ok, sorry about not getting back to this sooner, but work has been a bit busy. So anyway, I made the changes to the config file. (basically I created the ltsp.conf because it did not exist in the dnsmasq.d directory) there was only a README file. I was able to do a TCP dump and cap the information. But I have a feeling it will not be much help, I did see that I am running 2.75 version of dnsmasq, but I can reload the VM to just before I installed DNSMASQ and make sure the 2.76 version is installed. *will update if there are any changes from that versioning. Thanks for the help!

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

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

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

@howtogravity Just manually set it via SQL.

@jemerson93 Have you already tried using kernel version 4.15.2 as opposed to 4.16.6 and 4.17.0?

Hi Tom, thanks for the answer, this works fine during the host creation. I’ve tryed to activate the modules after the host creation by creating a moduleassociation for the newly created host object. For example: #Hostname Changer $TaskdataSet = @{ "hostID" = $HostID "moduleID" = "9" "state" = "1" } Try{ $taskdataToSend = ConvertTo-JSON($TaskdataSet) New-FogObject -type object -coreObject moduleassociation -jsonData $TaskdataSet }Catch{Write-Host "Failed to create Module association for Module 4 in Fog" -ForegroundColor Red $error[0] | Format-List -Force Exit 1 } But i think this was the wrong way. Could you tell me the right way to activate the modules after the host creation step? And one further question: If i try to define a ‘AllSnapin task’ for the new created host it doesn’t work. So my last step should be the deployment of the already, successfully assigned snapins after the hostname was changed (which is now working if i activate the hostchanger module during the host creation step). That’s why i try to create a “AllSnapin” task for the newly created host object like this: #Create Snapin Tasks for new Host $HostID = $createHostResult.id $TaskURL = $baseUri + "/host/" + $HostID + "/task" $TaskdataSet = @{ "hostname" = $createHostResult.name "taskTypeID" = $AllSnapinID } Try{ $taskdataToSend = ConvertTo-JSON($TaskdataSet) $TaskResult = Invoke-RestMethod -Method Post -Uri $TaskURL -Headers $headers -Body $taskdataToSend -ContentType "application/json" }Catch{Write-Host "Failed to create All Snapin Task in Fog" -ForegroundColor Red $error[0] | Format-List -Force Exit 1 } But this dosen’t work, i guess because the deployment task is in the queue for the new host? Would it be the right way to create the “AllSnapin Task” after the deployment task has finished? Is that the clue? Thank you for your support!

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.

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

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

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

@davido38 I can tell you that we have 7010s and they will not pxe boot past the ipxe kernel. I haven’t found any kernel that will work. Its something specific with the firmware on the 7030 model. Bios mode works correctly for that model.

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?)

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

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