FOG Hangouts

@martial The fog-client mostly fails with Middleware::Response Invalid security token. From that I see in our code this can only happen if there is a security token set in the DB for this host (identified via MAC address but it’s always the same as you re-use the same adapter over and over).

Well let’s see if we can figure this out in the DB:

shell> mysql -u root -p
Password:
...
mysql> use fog;
...
mysql> SELECT h.hostID,h.hostName,h.hostSecToken,m.hmMAC,m.hmPrimary,m.hmPending FROM hosts h JOIN hostMAC m ON h.hostID=m.hmHostID AND m.hmMAC LIKE '%aa:bb:cc:dd:ee:ff%';
...

Use the USB nic adapter MAC address instead of aa:bb:cc:dd:ee:ff. See if you get any results.

@krejci Have you done a search in the forums on RAID yet? There is a ton of information. It all depends on what kind of RAID you have. Many different RAIDs exist, from plain software RAIDs to hardware RAID controllers. There is no general answer on how to make this work.

@george1421 As posted, using case insensitive grep should work fine: lspci -nn|grep -i net

@foguser I’ll answer your questions in different order as it makes more sense to me doing it this way.

Is it even possible to get this to work?

From what I have read so far it looks like a bit of a non-standard setup that needs a bit of knowledge and setting the right configurations. See my later answers.

Did i do anything wrong in the Installation of fog?

Looks fine for me. You don’t want the FOG server to handle DHCP in your network which is perfectly fine. All the other things are clear and correct.

Have i forgotten/overlooked a configuration to get this to work?

You probably have and I am fairly sure we can point you the right way. Maybe not spot on but close enough for you to figure it out.

so fog would recognize a dhcp-request for it, but without luck.

Just to get that right in the first place. In your setup FOG does not care about DHCP at all! You choose to use your own DHCP server and this one is in charge of serving the right information to the clients. BUT the FOG server is taking a share in the whole PXE process and I guess this is where things fail for you.

If you have Citrix Fat Client PXE stuff on by default your clients will boot into that and don’t reach out to the FOG server.

I can manually configure Option 66 and 67 for the Clients to use fog.
I replicated the scope to all other DCs and checked it, but the Client did not care at all.
He kept booting and finding the citrix server-ip and file.

So are you planning to manually switch between Citrix and FOG PXE booting the clients? There is only one route you can go or you need to use chainloading to PXE boot from the FOG server first and then hand over to the Citrix if there is no task scheduled for this client (just an idea how you can combine all you have there). But let’s go back to your issue. What did you set Option 66 and 67 to? 66 should be the FOG server IP address (make sure the DHCP hands out gateway information as well as your clients need to talk across the subnets) and 67 should be undionly.kpxe for legacy BIOS and ipxe.efi for UEFI machines (wiki article on this topic).

My guess is that DC replication wasn’t properly working and caused the clients to still boot to the Citrix server.

@jmason said in Dell 7730 precision laptop deploy GPT error message:

Could you make the functionality optional via some kind of check mark if multi-disk non-resizeable is selected?

Probably can but I don’t see why this would effect other users at all. “All Disk” option is non-resizable and therefore trying to allocate the image to the right disk by using a sector count shouldn’t hurt anyone really.

I can’t seem to recreate it, but I know it’s broken whenever I deploy a new computer. So next time I have to image a computer I’ll come on back

Ok so it appears to be working when I queued the tasks from the gui. I did grab the file while something was deploying and the hash was the same this time.
So maybe this only happens when the snapin is queued from the api, doesn’t make a ton of sense, but maybe.

Could also be related to when a host is new perhaps. I will try to be more vigilante in logging the next time it happens if I can’t recreated it by queuing the snapins from the api

ps this would be how I am queuing a all snapins task in powershell

function Start-FogSnapins {
    [CmdletBinding()]
    param (
        $hostid = ((Get-FogHost).id),
        $taskTypeid = 12
    )

    begin {
        Write-Verbose "Stopping any queued snapin tasks";
        $tasks = Invoke-FogApi -Method GET -uriPath "task/active";
        $taskID = (($tasks | Where-Object hostID -match $hostid).id);
        Write-Verbose "Found $($taskID.count) tasks deleting them now";
        $taskID | ForEach-Object{
            Invoke-FogApi -Method DELETE -uriPath "task/$_/cancel";
        }
        # $snapAssocs = Invoke-FogApi -uriPath snapinassociation -Method Get;
        # $snaps = $snapAssocs.snapinassociations | ? hostid -eq $hostid;
    }

    process {
        Write-Verbose "starting all snapin task for host";
        $json = (@{
            "taskTypeID"=$taskTypeid;
            "deploySnapins"=-1;
        } | ConvertTo-Json);
        Invoke-FogApi -Method POST -uriPath "host/$hostid/task" -jsonData $json;
    }

    end {
        Write-Verbose "Snapin tasks have been queued on the server";
        return;
    }
}

function Get-FogHost {
    [CmdletBinding()]
    param (
        [string]$uuid,
        [string]$hostName,
        [string]$macAddr
    )

    begin {
        [bool]$found = $false;
        Write-Verbose 'Checking for passed variables'
        if (!$uuid -and !$hostName -and !$macAddr) {
            Write-Verbose 'no params given, getting current computer variables';
            $uuid = (Get-WmiObject Win32_ComputerSystemProduct).UUID;
            $macAddr = ((Get-NetAdapter | Select-Object MacAddress)[0].MacAddress).Replace('-',':');
            $hostName = $(hostname);
        }
        Write-Verbose 'getting all hosts to search...';
        $hosts = (Invoke-FogApi).hosts;
        Write-Verbose "search terms: uuid is $uuid, macAddr is $macAddr, hostname is $hostName";
    }

    process {
        Write-Verbose 'finding host in hosts';
        [bool]$found = $false;
        $hostObj = $hosts | Where-Object {
            ($uuid -ne "" -AND $_.inventory.sysuuid -eq $uuid) -OR `
            ($hostName -ne "" -AND $_.name -eq $hostName) -OR `
            ($macAddr -ne "" -AND $_.macs -contains $macAddr);
            if  ($uuid -ne "" -AND $_.inventory.sysuuid -eq $uuid) {
                 Write-Verbose "$($_.inventory.sysuuid) matches the uuid $uuid`! host found";
                 $found = $true;
            }
            if ($macAddr -ne "" -AND $_.macs -contains $macAddr) {
                Write-Verbose "$($_.macs) matches the macaddress $macAddr`! host found";
                $found = $true;
            }
            if  ($hostName -ne "" -AND $_.name -eq $hostName) {
                Write-Verbose "$($_.name) matches the hostname $hostName`! host found";
                $found = $true;
            }
        }

    }

    end {
        if ($found){
            return $hostObj;
        }
        return $found; #return false if host not found
    }
}

@george1421 said in DHCP Lease Failing on 1.5.5 after upgrade - again:

lspci -nn|grep etwork

Please run lspci -nn|grep -i net…

To me it looks like the ethernet card is properly loaded and UP. Looks like the driver is not properly sending or receiving packets. We need to know the exact model of the card. Please run the above command and we’ll see.

@jmason @Tom-Elliott Although I kind of liked the idea you both came up with at first I can’t see this being a user-friendly and reliable solution the more I think about it. On top it would mean a huge change in FOG. Not that I wanna block those kind of changes, not at all. But I only would wanna go that way if it’s an appropriate solution.

Adding a simple sector count check is not much of a thing to implement and it would work in most situations (at least those I can think of so far). Even if the two disks are same size it wouldn’t hurt because deploying to the “wrong” one is not a problem.

@jmason so the same disk 0000:02:00.0 was Always the same sized NVME drive?