I’m trying to install leaf packages in a docker container. Where can I copy an existing accepted license to in order that leaf detects it so I don’t get the following error:
Can't accept license in non-interactive mode
Please accept license on this system before running in non-interactive mode
@timelapsepaul, I don’t know how leaf work with a docker container … but did you tried Leaf with command line on lInux?
Hi @timelapsepaul,
Did you ever end up solving this? I’d be interested to know if and how you did.
I’m trying to setup a CI pipeline using Leaf to build a Legato system and I’ve hit this wall too.
Can’t accept license in non-interactive mode
Cheers,
Raf
@raf unfortunately not. Haven’t got round to trying some more things yet, still in dev so it hasn’t been a priority to get this working yet. Would be nice if someone from the Legato team could help.
My temporary solution has been to script it out, but have a human execute it because of the interactive portion.
My script launches a container with the image being half-built, the user is prompted to accept the licence and accept installing the last few packages which can’t be auto-answered with a switch option.
Then the script takes over again, commit an extra layer to the image and pushes to a remote repository for publication.
Very ugly.
One would hope Sierra can understand the need to support a CI pipeline in the 2020s.
Hi @jfaucher
For my use case, there is no human interaction. I have a WP module on a board (similar to mangOH Red) that is connected to a Raspberry Pi (in fact there are many distributed globally in remote locations). The code is actually stored on the Pi (in a docker container which is updated automatically OTA) which builds and deploys to the WP module automatically whenever the source code changes. I need the license to be accepted in the container on the Pi. I therefore need an accepted license to be stored in the source code which is copied to the container image which is built in a CI/CD pipeline before being deployed to all of our remote systems, which in turn update the connected WP modules if the Legato source code is changed. I don’t want to have to SSH into containers on hundreds of Rasperry Pis to manually accept the license.
@timelapsepaul,
I’m confused… Myself it’s the toolchain image, used to build/generate the WP code that needs a licence to be accepted. Isn’t it the same for you?
Why can’t this be a pre-built container downloaded by your Raspberry Pi from a private repository? Can’t it be the same image for each Raspberry Pi? Does it really need to regenerate the toolchain docker image each time? That pre-built image I’m describing could mount via a volume the source code and generate the image for the WP, no?
Sorry if I make it sound simple or erroneous, but since we’re early in our own project I’m concerned about facing similar issues.
I guess this is a possibility and something I’ll have to look into, but ideally, I just want to be able to write the source code and commit it and have everything else automated. I also want as little data as possible to be sent over the network since our Pis are connected via cellular networks, and the solution we use does incremental updates based on changes to the images deployed to the Pis which are built automatically with no human interaction on a third party service.
My gut tells me that if I prebuild an image, rather than this third party service doing it, any time the image changes the whole image will need to be downloaded to the Pi. I may be wrong about this (at least partially) and be able to find a solution, but as I said, ideally, I just deploy source code to the cloud builder which builds (including building the legato toolchain) the image to be deployed to the Pis and only transfers the image differences.
Surely, if there was just somewhere a pre accepted license could be stored this would eliminate any developer headaches and would be much easier to implement than anything you or I might have to do to make our use case work. There must be something that the legato installer checks to see if the license has been accepted, why can’t someone just tell us where and what this is so we can pre-populate it before installation?
FYI, it is the same image for all of the Pis, it gets built in the cloud and then only the image differences from the previous build get distributed over the air to all of the devices associated with the same application. Anything that is device specific is managed with another process using environment variables that don’t need to be included in the application image at build time.
In case anyone is interested, I’m using Balena OS and Balena Cloud for this fleet management and software/firmware distribution process.
Hi All,
I’ve made some progress on this and can now at least get as far as installing Leaf and setting up a profile without errors* in a CI pipeline.
Let me preface this by stating that it’s a complete hack and I can’t recommend it. It’s purely a proof-of-concept.
Essentially, the license-checker script is modified to not check if Leaf is running in non-interactive mode. This allows the license to be accepted automatically, without user input. Ideally this would be something which Sierra Wireless might provide to assist with CI pipelines.
You can find the relevant Leaf install tools in the ~/.leaf directory as per the docs:
I won’t go into specifics because I’m not sure what Sierra Wireless’ stance is on this. Perhaps someone from the Legato/Leaf team can comment?
Since this proof-of-concept CI pipeline (currently) regenerates the toolchains each time, the process is as follows:
non-interactive mode. This will fail but also install all the necessary tools.non-interactive mode. License is accepted. Device images are generated. No more errors.Hi all, the path would have to be modified to match to your configuration, you need to pass an argument to docker like this:
“-v /home/dfrey/.cache/swi-accepted-licenses:/home/dfrey/.cache/swi-accepted-licenses”
to map the appropriate file into the container