Trying to push a custom os to torizon cloud

Hi guys,

I am currently working on a github action to push an update to the torizon cloud environment, I think all the commands are setup correctly to do so, however when I run the command

torizoncore-builder platform push --credentials *** --package-version test --package-name FM2-OS base

It results in an OS error 36 filename too long as seen below

Traceback (most recent call last):
  File "/builder/torizoncore-builder", line 222, in <module>
    mainargs.func(mainargs)
  File "/builder/tcbuilder/cli/platform.py", line 537, in do_platform_push
    package_info, compatible_with = _check_compatible_with_param(args.compatible_with, credentials)
  File "/builder/tcbuilder/cli/platform.py", line 471, in _check_compatible_with_param
    return translate_compatible_packages(credentials, criteria)
  File "/builder/tcbuilder/backend/platform.py", line 1148, in translate_compatible_packages
    server_creds = sotaops.ServerCredentials(credentials)
  File "/builder/tcbuilder/backend/sotaops.py", line 36, in __init__
    self._load()
  File "/builder/tcbuilder/backend/sotaops.py", line 40, in _load
    with ZipFile(fname, "r") as archive:
  File "/usr/lib/python3.9/zipfile.py", line 1239, in __init__
    self.fp = io.open(file, filemode)
OSError: [Errno 36] File name too long: '/__w/FM23/FM23/UEsDBBQACAAIAAAAAAAAAAAAAAAAAAAAAAAIAAAAcm9vdC5jcnSEkk1zokwQgO/8iveeeksUTeCQQ89MMxniIKMDAjfFOEL8iJKtAX79lmZve9g+9fNUV1d3df9/D4JcxP9RXGoRCgoaH9aRQpANoxTUkwErCBiR5qNT1dYueGkn1NRrDnG0if1hRVVrqSnE+6UUQ+MiWGEdznAtieIwThGsjbfe8jDP42N1Lo9VPWZKgwmt20uGvWywlxr7WC83HPx7PnPuYsFEJ7UYx+HF/rshKSWRnPRXvpLTwAGDnNIfAItv4AogSZbhibHvLzYJ3j5Id+Z+Xa6b6w4Kr+2Ll8Nnf/Ce81UVpU7JTFT6aRLxJJxki3zce1+rfJ403GyFe+2O5VTfMvJ+3jw3sYZBgr1Pt0OrQgmSOLD3LbUFy5ZuQkAxMAIlKR5FkUIyskpKuHBKWw4qDYmV5If/rEBAUnArkKioYLfP77KOBn942dO2wfHQh2jjRRAuXH+/3trTPqjmHyurfahhZKpT4mwChcMvMttP7a1IcBIM+bBru0ruiol+0jU/ZzNjXl+dx9UxZn9/wu8AAAD/1BLBwhSQXdalAEAACYCAABQSwMEFAAIAAgAAAAAAAAAAAAAAAAAAAAAAAsAAAB0YXJnZXRzLnB1YhTIsQ7CQAgA0H9hdgCucOFm/RAoR2Ls0EFNmqb/blzfCa95vI99woDHnUXI4Pa3r28wTtg/sT1XGBCe3DMtvVVfCiU8ogQ7tQilIFbqmlbZfGVDXEoZzXSKmUyH6/oFAAD/1BLBwi1UST4YwAAAGwAAABQSwMEFAAIAAgAAAAAAAAAAAAAAAAAAAAAAAsAAAB0YXJnZXRzLnNlYxTJPWrFMAwA4Lt47qAfy7Le3B5EepKhtEMoIRBC7l6yft/Vfurcz63aq319kgha+3js8N/2utr29334/mz5nGMiUQUu6WozWB

What it looks like is that it has base64 encoded a zip file and is trying to do something with it however I am not sure why this is happening. any ideas how I could prevent it from being base64 encoded?

Kind regards,

Simplymehmet

Hi, I’m the Toradex AI Assistant. The Toradex Support team will follow up with you shortly!

Did you like my answer?

:+1: :-1:


The error you’re encountering, OSError: [Errno 36] File name too long, suggests that the filename or path being used is exceeding the maximum length allowed by the filesystem. This is likely related to the credentials.zip file you’re using.

Here are a few steps you can take to troubleshoot and potentially resolve this issue:

  1. Check the Path Length: Ensure that the path to your credentials.zip file is not excessively long. Try placing the credentials.zip file in a directory with a shorter path and update your command accordingly.

  2. Verify the credentials.zip File: Make sure that the credentials.zip file is correctly formatted and not corrupted. You can try unzipping it manually to verify its contents.

  3. Environment Variables: If you’re using environment variables to pass the path to the credentials.zip file, ensure that these variables are correctly set and not causing any issues with path length.

  4. GitHub Actions Specifics: Since you’re running this in a GitHub Action, ensure that the working directory and paths used in the action are not contributing to the path length issue. You might want to use relative paths or set the working directory to a shorter path.

  5. Base64 Encoding: The error message suggests that the file might be base64 encoded. Ensure that the credentials.zip file is not being altered or encoded in any way before being used in the command.

Here is an example of how you might adjust your GitHub Action to use a shorter path:

name: Push Custom OS to Torizon Cloud

on: [push]

jobs:
  push-os:
    runs-on: ubuntu-latest
    steps:
    - name: Checkout repository
      uses: actions/checkout@v2

    - name: Set up TorizonCore Builder
      run: |
        mkdir -p ~/tcb
        cd ~/tcb
        wget https://files.toradex.com/torizoncore-builder/latest/torizoncore-builder
        chmod +x torizoncore-builder

    - name: Download credentials
      run: |
        mkdir -p ~/tcb/credentials
        echo "${{ secrets.CREDENTIALS_ZIP }}" | base64 -d > ~/tcb/credentials/credentials.zip

    - name: Push OS to Torizon Cloud
      run: |
        cd ~/tcb
        ./torizoncore-builder platform push --credentials ~/tcb/credentials/credentials.zip --package-version test --package-name FM2-OS base

In this example, the credentials.zip file is placed in a directory with a shorter path (~/tcb/credentials/credentials.zip), which should help avoid the filename too long error.

If the issue persists, please provide more details about how the credentials.zip file is being handled in your GitHub Action, and any additional context that might be relevant.

Please, also check if these links can help you solve your problem:

CI/CD - Integrate With GitHub Actions | Toradex Developer Center.

Hi @simplymehmet

As mentioned by @ToradexAI , that looks like a problem when passing the credentials.zip file, what is those *** you mentioned? How are you passing this file into the github pipeline?

Also, another problem.
The argument to torizoncore-builder platform push is the commit ref you want to push.
In you command you are pushing the base branch, which is the one used by the base input image.
You can define the output branch name in the tcbuild.yaml configuration file.

output:
  # >> OSTree deployment configuration (relevant also for raw/Easy Installer output).
  # ostree:
    # branch: my-dev-branch
    # commit-subject: "OSTree commit subject"
    # commit-body: "OSTree commit body"

You can have a better understanding of the workflow with torizoncore-builder by reading this article.

Hi Allan,

This is just the info I needed thank you man. Regarding the ‘***’ it are indeed the credentials. By zipping the base64 encoded credentials the error has been resolved. I will look into branching and change the yaml file accordingly.

Kind regards,

Simplymehmet

Hi Allen,

I hope you are doing well, I was trying to push my OS to the torizon cloud environment using the REST API. In doing so I got the following result,

{
	"code": "500",
	"description": "Internal server error",
	"cause": null,
	"errorId": "90d7cab2-ebfb-49ff-87ec-42133173a99a"
}

Which explains close to nothing to me :blush:.

So what I did is run the

torizoncore-builder build --force

which results in a folder, I zip that folder and try to send it to the REST API using the following curl

curl --request POST \
  --url 'https://app.torizon.io/api/v2beta/packages?name=FM2-OS&version=v0.0.23&hardwareId=verdin-imx8mp&targetFormat=BINARY' \
  --header 'Authorization: Bearer token' \
  --header 'Content-Type: application/zip' \
  --header 'accept: application/json'

And this request results in the 500. Now when doing this using a docker-compose this works fine. Any idea what step I am missing?

Kind regards,

Simplymehmet

If you’re trying to push the OS itself as a package then you don’t push the folder/zip-file from the build command. You need to provide an OSTree reference that refers to the OS you want to push. Please see this section here on how to push the OS using TorizonCore Builder: Signing and Pushing Torizon OS Packages to Torizon Cloud | Toradex Developer Center

Best Regards,
Jeremias

Hi Jeremias,

What I try to achieve is to actually use this endpoint Swagger UI

However I do not know how the file should be added to this request, my curl is findable in the above comment.

Kind regards,
Simplymehmet

It’s strongly recommended to use TorizonCore Builder to push OS type packages. Uploading an OS package is quite complex and involved. This is because we’re talking about an OSTree that is composed of hundreds of objects/metadata files.

The API is mainly meant for simpler packages like docker-compose packages where only a single file is being uploaded.

Best Regards,
Jeremias