Topics created by quinniedid

@JJ-Fullmer I am sure you are incredibly busy. I was just wondering if you had a few minutes to help me out with the FOG API and changing inventory values?

@quinniedid I updated this article with the testing from today: https://forums.fogproject.org/topic/14791/feature-request-for-fog-1-6-x-configure-image-capture-to-use-nfsv4-instead-of-nfsv3

@sebastian-roth Because we are using VMs that are thin provisioned, Windows only optimizes, which we tried and the same result and behavior happened. Increasing the value of how much space to use https://forums.fogproject.org/topic/15416/out-of-disk-space-fog-capture-error/7#, did fix our issue and we only had to increase the value from 5 to 8 for a successful capture.

Thank you for your help!

@quinniedid Ok, looks like this is not due to the picture you used but a general issue with displaying the image on the HP ProBook 445 G2. So far I have not found any hint on other people reporting this issue to iPXE and I would suspect this to be kind of an endeavor to figure out even with the help of iPXE developers. Though you can still report it on github or the forums.

The easier way is just using the workaround that George came up with. Not fancy but way less effort than figuring this one out I suppose.

@Sebastian-Roth

Thank you for your help!

@Quazz

You are absolutely right. I always struggle to keep the copying behavior between Linux and robocopy. Sure enough there was a snapin folder inside of the snapin folder. I thought that I had checked that but probably just saw that files were there and did not pay attention to the path. The hashes now exist and I saw that in the logs that it was generated and deploying of those snapins now work as expected.

I appreciate everyone’s help and willingness 🙂

@quinniedid Sad to hear that you had a lot of work and trouble with this but sometimes it’s just good to redo the whole lot to get rid of old issues. Hope you have moved forward from Ubuntu 16.04 as well! 🙂

@george1421 I forgot to mention that in my notes. I will fix that. Changing fetch=tftp://${fog-ip}/gparted/filesystem.squashfs to fetch=tftp://<fog_server_ip>/gparted/filesystem.squashfs worked just fine and booted properly.

The persistent groups plugin is most likely still working.

First, understand how it works.

It’s a simple trigger that’s generated but the trigger gets it’s template from a default host assigned to that group.
The template host name must be the same of the group’s name. In that host, you define your wanted group settings. Then, when you add a “real” host to the group, it will obtain the information in that group.

Hi @quinniedid ,

In this post you can find info about how works and how create rules in this plugin.

https://forums.fogproject.org/topic/9624/control-access-plugin/14

With this plugin you can restrict the access to the menus and submenus but not to specific host and groups. To do this maybe you can use the Site plugin but, unfortunately, this plugin doesn’t work with the 1.5.5 version. I am working to fix the bugs.

I would admit you are absolutely correct. I should not have put the local admin into the group…

I was finally able to get back in. I appreciate all of your help!

@george1421 @Sebastian-Roth I just discovered the solution to this issue.

Back a while ago we had HP Z400 workstations that required us to put a global kernel argument of “ahci = off” as they would fail to deploy an image without it. The reason we made this global as it did not have an impact on any other devices and I would not have to specify it specifically on every workstation. The oddness of this all, when the VM was running in BIOS this was not an issue with capturing the image with the SCSI controller. When the VM was UEFI it would fail and would require us using the SATA controller which slowed capturing to be almost a 2 hour process. Removing this kernel argument now allows us to capture an image at full speed again using teh SCSI controller and it fixed a hang issue that occurred in the beginning that was also previously reported with the “can’t find IRQ”.

All in all this is now fixed removing that kernel argument. I am just shocked that it would be affected differently between BIOS and UEFI specifically on a VM.

Thanks for all your help.

@quinniedid said in FOG Storage Relication:

Also, what port/protocol is used for storage replication or needed in this scenario?

Depends on how you choose to set it up. Using the multi-master configuration that George explained, you just need FTP for replication and port 80 for the PHP scripts on the remote nodes to listen for requests from the master server on.

But, with a 20 to 40Mbps link between your sites, that’s enough to just use fog in the standard way - with one master server and other storage nodes at your remote sites - and you can accomplish sending specific images to specific locations. You’d setup the location plugin - and you’d use FOG’s group-to-group image sharing. There’s no need to export/import anything in this setup and it’s officially supported.

@george1421 When I renamed refind.efi to refind_x64.efi, it worked as intended. Thank you for your help, I really appreciate it.

@Sebastian-Roth Yes it does return. I even see a ton of data being downloaded. I have cut off the data towards the end due to the length of the capture.

563 13.682607 10.86.96.177 10.85.195.199 TCP 74 50514 > 8080 [SYN] Seq=0 Win=29200 Len=0 MSS=1460 SACK_PERM=1 TSval=1729539897 TSecr=0 WS=128 569 13.742557 10.85.195.199 10.86.96.177 TCP 78 8080 > 50514 [SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0 MSS=1460 SACK_PERM=1 TSval=400875488 TSecr=1729539897 WS=64 570 13.742594 10.86.96.177 10.85.195.199 TCP 66 50514 > 8080 [ACK] Seq=1 Ack=1 Win=29312 Len=0 TSval=1729539912 TSecr=400875488 571 13.742693 10.86.96.177 10.85.195.199 HTTP 161 CONNECT fogproject.org:443 HTTP/1.1 575 13.801898 10.85.195.199 10.86.96.177 TCP 66 [TCP Window Update] 8080 > 50514 [ACK] Seq=1 Ack=1 Win=771008 Len=0 TSval=400875548 TSecr=1729539912 576 13.864407 10.85.195.199 10.86.96.177 HTTP 105 HTTP/1.1 200 Connection established 577 13.864424 10.86.96.177 10.85.195.199 TCP 66 50514 > 8080 [ACK] Seq=96 Ack=40 Win=29312 Len=0 TSval=1729539942 TSecr=400875608 579 13.87112 10.86.96.177 10.85.195.199 TLSv1.2 583 Client Hello 582 13.992592 10.85.195.199 10.86.96.177 TLSv1.2 1414 Server Hello 583 13.992609 10.85.195.199 10.86.96.177 TCP 166 8080 > 50514 [PSH, ACK] Seq=1388 Ack=613 Win=771008 Len=100 TSval=400875738 TSecr=1729539944 [TCP segment of a reassembled PDU] 584 13.992616 10.86.96.177 10.85.195.199 TCP 66 50514 > 8080 [ACK] Seq=613 Ack=1488 Win=32128 Len=0 TSval=1729539974 TSecr=400875738 585 13.992893 10.85.195.199 10.86.96.177 TCP 1414 8080 > 50514 [ACK] Seq=1488 Ack=613 Win=771008 Len=1348 TSval=400875738 TSecr=1729539944 [TCP segment of a reassembled PDU] 586 13.992908 10.85.195.199 10.86.96.177 TCP 166 8080 > 50514 [PSH, ACK] Seq=2836 Ack=613 Win=771008 Len=100 TSval=400875738 TSecr=1729539944 [TCP segment of a reassembled PDU] 587 13.992916 10.86.96.177 10.85.195.199 TCP 66 50514 > 8080 [ACK] Seq=613 Ack=2936 Win=35072 Len=0 TSval=1729539974 TSecr=400875738 588 13.992928 10.85.195.199 10.86.96.177 TLSv1.2 640 Certificate, Server Key Exchange, Server Hello Done 589 13.995298 10.86.96.177 10.85.195.199 TLSv1.2 192 Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message 593 14.114585 10.85.195.199 10.86.96.177 TLSv1.2 117 Change Cipher Spec, Encrypted Handshake Message 594 14.114752 10.86.96.177 10.85.195.199 TLSv1.2 182 Application Data 598 14.237584 10.85.195.199 10.86.96.177 TCP 1414 8080 > 50514 [ACK] Seq=3561 Ack=855 Win=771008 Len=1348 TSval=400875988 TSecr=1729540005 [TCP segment of a reassembled PDU] 599 14.237599 10.85.195.199 10.86.96.177 TCP 166 8080 > 50514 [PSH, ACK] Seq=4909 Ack=855 Win=771008 Len=100 TSval=400875988 TSecr=1729540005 [TCP segment of a reassembled PDU] 600 14.237607 10.86.96.177 10.85.195.199 TCP 66 50514 > 8080 [ACK] Seq=855 Ack=5009 Win=40704 Len=0 TSval=1729540036 TSecr=400875988 ...... ..... .... ...

@quinniedid OK in my test lab I’m running the build listed in my post. That is with 6.5u1 and the Oct 2017 patch. Point being if I can get a few minutes of time I want to see if I can duplicate what you are seeing to see if VMWare addressed/changed/fixed the issue with a vSphere update. I don’t know one way or the other, but this sounds like a uefi firmware issue to me.

@Tom-Elliott @george1421 Moving those folders and running the installer again has resolved the issues. Thank you again!

@george1421 I have removed the the global parameters and still exhibiting the same behavior. It is weird that this happened right after I made that change. I think something might have gotten corrupted, but I am not sure what to do at this point.

@quinniedid There is a .msi version of the client that you could use to install the newer client with the correct address. Unsure if old client would need uninstalled first.

If you have a way to push out a PowerShell script, something like this might help.

$FOG = Get-WmiObject -Class Win32_Product | Where-Object -Property Name -EQ 'FOG Service' $FOG.Uninstall() $url = "http://<ip address>/fog/client/download.php?newclient" $outfile = "FOGService.msi" (New-Object System.Net.WebClient).DownloadFile($url, $outfile) $ArgumentList = "/i $outfile /quiet USETRAY=""0"" WEBADDRESS=""<ip address>"" WEBROOT=""/fog"" /norestart" Start-Process -FilePath MSIEXEC.exe -ArgumentList $ArgumentList -Wait Start-Service -Name FOGService Start-Sleep -Seconds 2 Restart-Computer -Force