@george1421 said in issue with netcard of dock gen2 of lenovo l390:

@JJ-Fullmer The r8152.c from the torvalds github site failed to compile on 4.19.65, I’m suspecting its for a later release of linux. The version from the torvalds site was 1.10.10. The version in 4.19.65 was 1.9.9 of the realtek driver.

I was able to compile the realtek driver from the wget github site. This version is 2.12. Here is a link to that kernel with the 2.12 driver built in. I also enabled the usb-c code in the kernel that appears to have not been set. I don’t know if its relevant, but it should be on for other applications. https://drive.google.com/open?id=1wZwwOwbEr0nR3mnPLKg7AsulwJaGhO0A

Download this as bzImageRT (watch your case) and copy it to the ipxe directory with the other kernel images. Manually register the host and then in the host definition add in bzImageRT as the kernel for that host. Then pxe boot into FOS Linux debug mode to see if the network adapter inits correctly with this updated driver.

@jps Please give @george1421’s kernel a try, see if that fixes your problems.

@george1421 That done did it!
It imaged correctly as expected, huzzah! No problems at all.

@george1421 I’m on it! Thanks for doing all that!

@george1421
This is what I see when I tried to boot to fog on the second one. Same usb-c adapter, same model, same just updated bios version. It isn’t the same ethernet cable but it’s connected to the network through the same switch. I did reboot my fogserver (adding more space for an unrelated issue), so there’s an outside chance something changed at the fogserver dhcp level, but unlikely.

However I was able to register it in the gui and then it gave similar output when booting to a debug task, said it didn’t get an ip via dhcp and then the fog debug stuff came up…Don’t I require a network connection to get the network hosted FOS system on the machine via pxe? ifconfig in the debug session makes it look like it indeed doesn’t have an ip, however the usb-c ethernet adapter is blinking. The ifconfig devices don’t show one with the macaddr of the usb-c. All of that is really just to say, this is why I’m not copy pasting text output and just putting a screenshot.

I can do much more debugging on this tomorrow. We ordered the alternate ethernet adapters to see if they work better natively on these devices, they use an intel chipset. But I’m happy to do all I can to make the usb-c ethernet on these work for everyone, as that’s a better answer than go spend more money on a different proprietary adapter

@george1421 I will when I image the next one, which might be today might be tomorrow.

@george1421
Hardware ID - USB\VID_17EF&PID_720C&REV_3000
I’m not seeing the Vendor ID, but the driver Provider is realtek

The offical lenovo doc page can be found here https://support.lenovo.com/us/en/accessories/acc100324

I believe this is the page for the dock that this post and another is using that uses the same chipset/usb-c connection https://support.lenovo.com/us/en/accessories/acc500106

It looks like there are firmware updates for the dock option available here https://download.lenovo.com/cdrt/wp/usb-docks.html and there may be other helpful information, but it looks mostly centered around windows

It is also possible that the usb-c port is what needs a new linux driver. There are also 2 usb-c ports on the device I believe, one that has power delivery and one that does not, I did not try both ports.

@Daniel-Miller I’m pretty sure also that this is the same issue, which is the same issue I’m having with the usb-c to ethernet adapter for the same model. My experience was slightly different than here and in the other post cause my l390 got into the image process but then it hangs at a different spot. I’m able to image with a different method utilizing a different adapter. I think that this lenovo usb-c ethernet is missing a kernel driver in FOS. It’s based on realtek, the other post has the windows hardware id of the device.

I am now successfully imaging with my work around method that involves using a usb 2.0 “gigabit” ethernet adapter following the method I outlined here many moons ago.

Since the device is able to be imaged with a different ethernet adapter, I’m thinking that maybe there’s just a new driver that needs to be added to FOS. I have tried to find a .efi driver for this device but haven’t been able to find it available for download and there isn’t a way I have yet found to extract it from the built-in lenovo efi drivers. Maybe there’s a kernel option we can add in building that will help. I am very sure though that it’s tied around FOS and this lenovo usb-c ethernet adapter chipset. It will pxe boot just fine but then there are issues after that. It gets further along in the latest version of FOG than @jps is running but it isn’t quite working yet. Just need to find a way to add full support for this adapter and then this will be fixed.

I was figuring that although the situation is a bit different the solution will probably be close to the same since it’s the same computer model and same ethernet adapter chipset. I believe @jps’s problem and my problem get down to FOS. I got pxe errors in trying different network configurations figured that it was network related

For me I don’t actually get an error message it just hangs like above. This is with the newest kernel available in the kernelupdate fog configuration screen, 5.1.16

I can go throw this in a new thread if you think that’s better.

Doing the mac passthru still fails to do pxe boot. It tries a net0 adapter twice, each one failing and then gives a pxe dhcp error and then restarts.
Going to try the newest kernel, downloaded it as bzImage2 and will just use it on this device

I am also having issue with a similar device. I have the L390 yoga and the lenovo usb-c ethernet adapter that lenovo says is supported for pxe boot. I have the latest version of fog and get into bzimage but I was not able to complete imaging. I think it is in part because it first tries the “internal” ethernet adapter and then the pxe device. There is a ethernet port but it requires a special adapter, and that special adapter differs between the L390 and the X390 lenovo thinkpad models, but both of those (we have some of both) can use the usb-c ethernet adapter, so we went with the universal choice.

I also could not register the device in the fog pxe boot. Everytime I put in a hostname it just asked for it again. I just registered it in the gui with the usb-c adapter’s mac and queued it to upload.

I keep getting stuck at one of 2 different spots during the imaging process, either

Restoring Partition Tables (GPT) ..............DONE
_

Then it just sits with a flashing cursor,
or it get through imaging the first partition and sits flashing.

I did just update to the newest version of the bios and am getting the same behavior.

I have also tried doing a debug image session, but then it gives an error of something along the lines of ‘check your network connections’ and the task gets cleared.
I think that maybe something is getting hung up on the device having 2 ethernet adapters in a weird way, what’s fun is you can’t disable the internal one when using the usb-c one, just have to wait for the first one to fail during pxe boot and fog’s processes

There is a bios option to do mac-address passthru. I’m going to try setting it to use the internal mac for the usb-c adapter (adding the internal mac to the fog host first of course) and see if it makes a difference. When I did this and tried to then boot to fog to register, it didn’t get passed the pxe boot.

Also, I am using the uefi pxe booting and @jps appears to be using the legacy version of pxe boot. Just to note another difference in situations.

I was able to image a lenovo x390 yoga, but I used my old hackish method of booting to a usb with refind, going to the efi shell, loading the efi driver of a usb 2.0 ethernet adapter and then loading the ipxe.efi from the usb and that worked, but I didn’t have the usb-c adapter at the time. I haven’t tried doing that on the L390 because well I want the “supported” adapter we bought to work as intended for some weird reason.

New Module Version Published

Just wanted to let people know that there’s a new version of the API yay!
It’s been published to the psgallery here https://www.powershellgallery.com/packages/FogApi/1903.0.0.22 and it is awaiting a pull request to show up in the fog community scripts git.
It has new functions to help do some common tasks, particularly with snapins. Here’s a list of the current functions.

Add-FogSnapins
Set-FogObject
Get-FogAssociatedSnapins
Get-FogGroup
Get-FogHost
Get-FogHosts
Get-FogInventory
Get-FogLog
Get-FogObject
Get-FogServerSettings
Get-FogSnapins
Install-FogService
Invoke-FogApi
New-FogObject
Remove-FogObject
Remove-UsbMac
Set-FogInventory
Set-FogServerSettings
Set-FogSnapins
Start-FogSnapins
Update-FogObject

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
    }
}

First let’s try to gather some more information. Leave the snapin as is for now and only schedule snapin tasks for clients and let those run.

1. Does it randomly fail on the same host? So if you schedule the same task on one host ten times in a row, does it run through all the time if it is fine on the first run?

I don’t typically try it more than once maybe twice, if it fails I just run the command manually. But I will give that a try. See if I can’t recreate it on my computer.

2. When it magically fails on a host can you please grab that host and take a look at C:\Program Files (x86)\FOG\tmp. I have not checked the code yet but I would hope the fog-client leaves a copy of that file there on failure. Now check if that file is zero size or truncated or anything like that.

It does not leave a copy, it does put a copy there and if you’re watching it you can copy it real quick or you can stop the fogservice before the hash check if you’re lucky. I think I did that once when I first discovered the issue but don’t recall the result, I remember it being confusing, I guess I’ll have to try this again too.

3. On snapin failure as well pay attention to the apache and PHP-FPM log files to see if there is an HTTP/PHP error on snapin download (see my signature).

Good thought will give those a post.

4. Please post the full fog-client log here in case of a failure so we can have a look. Sometimes there is something we see that leads us to the real problem.

Standby

If that doesn’t help we can go ahead an try monitor the database for changes of the hash. FOG has a deamon running that updates the snapin hashes from time to time. Unlikely but maybe this is causing an issue. You can take a look in that log file (webUI -> logs -> snapin log) and even disable that in another step just to see if it interferes.

I was hoping there is a way to disable it on the server, maybe something in the database or something, because I didn’t want to go through the trouble of recompiling the fog client. The other trick is that I really only use snapins during provisioning right after I image a computer. But I guess if I want it fixed I oughta suck it up.

The only other thing that may be a factor is I also add the snapins to the host and initiate the task from the api during provisioning. So It’s possible that it being queued from api causes this too, we’ll see if that’s the case though since I’ll be testing by deploying through the gui.

@Sebastian-Roth

function Invoke-FogApiChocoSnapin {
<#
    .SYNOPSIS
        a cmdlet function for making fogAPI calls via powershell

    .DESCRIPTION
        takes a few parameters with a default that will get all hosts
        Makes a call to the api of a fog server and returns the results of the call
        The returned value is an object that can then be easily filtered, processed, and otherwise manipulated in poweshell.
        i.e. you could take the return value of the default all hosts and run
            $(invoke-fogapiChocoSnapin).hosts | where name -match "$(hostname)"
        to get the host information for the current computer

    .PARAMETER fogApiToken
        a string of your fogApiToken gotten from the fog web ui. Can be set in the function as a default or passed to the function

    .PARAMETER fogUserToken
        a string of your fog user token gotten from the fog web ui in the user section. Can be set in the function as a default or passed to the function

    .PARAMETER fogServer
        The hostname or ip address of your fogserver, defaults to the default fog-server

    .PARAMETER uriPath
        Put in the path of the apicall that would follow http://fog-server/fog/
        i.e. 'host/1234' would access the host with an id of 1234

    .PARAMETER Method
        Defaults to 'Get' can also be

    .PARAMETER jsonData
        The jsondata string for including data in the body of a request

    .EXAMPLE
        #if you had the api tokens set as default values and wanted to get all hosts and info you could run this, assuming your fogserver is accessible on http://fog-server
        Invoke-FogApiChocoSnapin;

    .Example
        #if your fogserver was named rawr and you wanted to put rename host 123 to meow
        Invoke-FogApiChocoSnapin -fogServer "rawr" -uriPath "host/123" -Method "Put" -jsonData "{ `"name`": meow }";

    .Link
        https://news.fogproject.org/simplified-api-documentation/

    .NOTES
        The online version of this help takes you to the fog project api help page

#>

    [CmdletBinding()]
    param (
        [string]$fogApiToken = '',
        [string]$fogUserToken = '',
        [string]$fogServer = "fog-server",
        [string]$uriPath = "host", #default to get all hosts
        [string]$Method = "Get",
        [string]$jsonData #default to empty
    )

    begin {
        # Create headers
        Write-Verbose "Building Headers...";
        $headers = @{};
        $headers.Add('fog-api-token', $fogApiToken);
        $headers.Add('fog-user-token', $fogUserToken);

        # Set the baseUri
        Write-Verbose "Building api call URI...";
        $baseUri = "http://$fogServer/fog";
        $uri = "$baseUri/$uriPath";

    }

    process {

        Write-Verbose "$Method`ing $jsonData to/from $uri";
        if ($Method -eq "Get") {
            $result = Invoke-RestMethod -Uri $uri -Method $Method -Headers $headers -ContentType "application/json";
        }
        else {
            $result = Invoke-RestMethod -Uri $uri -Method $Method -Headers $headers -Body $jsonData -ContentType "application/json";
        }
    }

    end {
        Write-Verbose "finished api call";
        return $result;
    }
}

@Sebastian-Roth That is the general idea of what happens in the fog log yes. I get a hash doesn’t match error.
I took out the paths when I copied pasted the script, I think that duplicate get-item is just a typo.
I beleive I am trying to not update the file on the server here, instead of trying to re-upload the file everytime I am just getting the correct information about the file (name, size, hash) and trying to force every snapin database entry to match the file’s details correctly. Somehow though I end up with different hash’s during deployment. If I export the snapins, they all look the same in the exported csv as they should. It’s like something happens when the snapin is deployed where it changes.

@Sebastian-Roth That is a internal function in that script. I’m pretty sure that it is the same as the Invoke-FogApi function I have in the published powershell module, so you could find it here https://github.com/FOGProject/fog-community-scripts/blob/master/PowershellModules/FogApi/FogApi.psm1
It’s renamed here to avoid clobberring I think as I may have written the code I pasted as an example here before I made the uninversal module.

See also https://forums.fogproject.org/topic/12915/windows-boot-manager-boot-option-disappears-after-image

My workaround for this happening was to use refind as my default bootloader, which I configure before capturing the image and then again after I deploy the image in scripts to ensure it sticks. That way I have a boot menu that I can pick between windows, fog (required copying latest ipxe.efi file to each machine’s uefi partition), and even options for uefi shell and uefi firmware settings without any special keystrokes. I find it gives a nice balance between faster boot time for users and flexibility in support.

I am fairly sure this is a ‘feature’ of windows 10 with the intent of helping users that had changed their boot order to boot to install media and then don’t have to worry about going back into the bios settings and changing it to the new boot manager.
When I get a moment (like that will ever happen) I’ll try to universalize my bootmgr configuration powershell functions a bit and share them. Probably will put them in the fog community scripts git or add them to my fogAPI module, the former might make more sense, so they’re findable outside of a single blog post. If I remember I’ll try to make some time to do that tomorrow.