SystemLink Forum

Showing results for 
Search instead for 
Did you mean: 

Apply State via Systemlink

I have not used states too much as I have been mostly creating our own feeds and have the clients point to it.   But it is a little unwieldy to maintain as you can add to a package repo via the interface from   Select a LV 2019 SP1 (thought the search box does not return anything when you type LabVIEW, anyone else notice that?) and download from and it adds the packages....  


Anyway so I decided to try and use Apply state...  Install all the tools needed and then create a state.   This way all the packages/feeds are nicely bundled.


But I have noticed that when I install the SL Client...  Connect it to the server... And say apply state...  The first thing it does is to disable the SL client service so the client is disconnected.  The client says it is applying the state but it just sits there.  And the client never connects again.  If the applied state has a client that is older than the current installed version.  Does this cause a bootstrap type of issue?  Since the State has SL 20.1 and installed is SL smart enough to handle this?

0 Kudos
Message 1 of 9

What is the SL version of the systems you are applying the state?

Is the state containing the "ni-systemlink-client" package? If yes, what exactly version?

0 Kudos
Message 2 of 9

Sure.  The state contains:

The client local had the 2020 R4.  Let me get that package number from the installer.



So what I noticed is that the local PC after applied state did not ever reconnect to Systemlinker server.  But the SL client 2020 R4 was uninstalled and the R3 version was available to be installed.


After I installed the R3 version of the client and applied the state it worked as expected.   So it does seem that when downgrading systemlink via a state that at least in this case failed and required a local manipulation to get the state applied.


So are people removing the SL client from their states to avoid this?   I will try on another system and report.

0 Kudos
Message 3 of 9

On a fresh system same the applied state does not automatically apply.  Will try a third system starting with a the same version of Systemlink client 2020 R3 as the applied state to see if it automatically applies the state with intervention.  I suspect it will.  So seems like to be safe it is best to pull the ni-systemlink-client package out of a state to make sure that whatever version of SL client is installed that the state will be applied.

0 Kudos
Message 4 of 9

Actually no.  I installed client R3 and was the same.  I stripped out all systemlink client and salt minion services...basically every package that is installed by the client installer.  And the client still disconnected when applying the state.  I have to remove and re-approve the client to the server to get connection back after state being applied.

0 Kudos
Message 5 of 9

I was expecting that you were actually downgrading SystemLink Client through the state.


Here is how things work right now:

1. We don't support downgrades on the SystemLink Client. If you downgrade the SL Client package then its configuration will be lost. This includes the server on which to connect too and the keys of the client. By removing these, the server will not know anymore who this client is when it tries to reconnect. 

2. These SL Client related packages have also dependencies and when these dependencies are downgraded, then SL Client will get downgraded as well. I am pretty sure that you were in this use case on the last try when you expected to work. An example of these packages would be the "ni-sysapi" (NI SystemAPI Framework) which is getting pulled by many other NI products, so this package could be the one that triggers the downgrade of the SL Client.


At this point, if you cannot build your golden state from scratch then you have to create it from a golden system and polish it until it doesn't trigger a SystemLink Client downgrade.


If you are still encountering weird behaviors, please send us the state and the client snapshots to take a look over them. 

Message 6 of 9

I am starting to understand your pov but this implies that older states have little utility without being scrubbed for these dependencies that cause a disconnection.   Seems like something the tool should handle as this will be a known use case.  Namely, applying a labview 2017 SP1 state and test an old test case for example.  The expectation is that I should be able to apply a state successfully of any vintage.


You are right that I can create a new state that is current every time we upgrade...  But this really only applies to the current latest image not legacy states.

So if I get a list of all the recursive dependent packages from the ni-systemlink-client and remove these from the states then the state should be client agnostic?


Seems like the SL client is needs to be decoupled from the state by the tool when making the state.  I do not see the utility of saving those packages if by saving them it causes the client to disconnect permanently from the server when the state is applied.

0 Kudos
Message 7 of 9

You are right. At this point, these states are pretty limited when you want an old state to be applied to a newer Windows system. They work only when upgrading the SL Client. We've had a discussion and we decided that we have to improve that so a new item has been added to our backlog. 


Until we do the changes in the product you can modify the state content by using the Raw Editor. Take a look and you will find the ni-package-manager package definition in the state. You will probably notice that the version is different than the other definitions. It should start with > or >=. You can do it on any package by hand. So by using that you could be less restrictive about the SL Client package and its dependencies. Probably this would be our implementation in the product as well, do the same thing on the SL Client related packages as we do with package manager related packages.


"So if I get a list of all the recursive dependent packages from the ni-systemlink-client and remove these from the states then the state should be client agnostic?"

Yes! The alternative to the above solution is to remove them from the state.


If you are having a hard time determining the dependencies of SL Client, feel free to send us the state and I will highlight them for you. They've changed over time so there is no golden set of dependencies that I could share with you. 


0 Kudos
Message 8 of 9

I did try and add the systemlink package R4 to the state.   But it did disconnect when being applied.   Worth a shot.  


The Raw view has more packages than the exported SLS so I just copied the packages in the state to txt files and removed the URLs.


The only items in the list that have upgrade items at least:

C:\Users\***\Downloads\LabVIEW 2019 SP1 image.txt (5 hits)
Line 251: - ni-package-manager: '>='
Line 252: - ni-package-manager-deployment-support: '>='
Line 253: - ni-package-manager-released-feed: '>='
Line 254: - ni-package-manager-upgrader: '>='
Line 375: - system-windows-x64: '>='


I was expecting to see a >= for systemlink client or some salt packages, so yes if you could scrub the list to allow a clean application of the state that would be great.




0 Kudos
Message 9 of 9