Skip to content
Librux Runtime Kernel for Robotics development
Librux Runtime Kernel for Robotics development

    Installation

    This page describes the published Librux install flow. It focuses on getting the runtime and SDK onto a host. After installation, use Operate for service management, time sync, resource control, security, and validation.

    Supported Platforms

    Librux runtime installation is Linux-only.

    Published runtime bundles currently target.

    • Linux x86_64
    • Linux aarch64

    The installed runtime uses Linux facilities such as systemd services, cgroup resource placement, Unix-domain local control channels, SocketCAN, device-node policy, and Linux time-sync tooling. macOS and Windows are useful for reading docs, preparing source trees, or editing SDK/tutorial code, but they are not runtime deployment targets.

    The documented commands assume Ubuntu / Debian. Other Linux distributions can work when equivalent packages and service facilities are available, but the published install path is validated first on Ubuntu / Debian.

    License Model

    The runtime binary payload is not Apache-2.0. Runtime installation requires manual acceptance of the Librux runtime license/EULA during the installer review step. Automatic license acceptance is intentionally not supported.

    Public SDK source, tutorials, docs, and public spec payloads are distributed under the Librux SDK open-source license group. Bundled third-party dependencies and declared SDK environment dependencies are disclosed under Open Source Notices.

    After installation, license and notice documents are stored under <prefix>/licenses (plural). This directory contains the files listed by the release manifest, typically including.

    • the Librux download and installation data notice
    • the Librux runtime license/EULA for runtime binaries and services
    • the Apache-2.0 license for public SDK/source payloads
    • Open Source Notices covering bundled third-party dependencies and declared SDK environment dependencies
    • third-party full license files, such as the yaml-cpp MIT license when the bundled Linux C++ SDK artifact is installed

    The presence of multiple files in <prefix>/licenses does not mean that the entire installed tree uses one license. It records the license and notice groups for the runtime, distribution logging notice, installed SDK artifacts, and open-source notices.

    Prerequisites

    On a minimal Ubuntu / Debian host.

    sudo apt update
sudo apt install -y ca-certificates curl wget

    Install python3-vcstool only when you plan to fetch the full matching source workspace through the entry repo's librux.repos manifest.

    sudo apt install -y python3-vcstool

    The install snippets use curl by default. Equivalent wget -qO- ... | sh forms are also supported. The bootstrap script can request sudo when the selected prefix or service registration needs elevated privileges, so the recommended default command runs the script as the current user.

    Current Release Install Command

    Use the install command from the published entry repository release page. For the current release candidate, use this command.

    curl -fsSL http://git.librerobotics.org/justin.kang/librux/releases/download/v1.0.0rc11/install.sh | sh

    Published release docs and entry-repository READMEs are stamped with the exact release asset URL during the release process. If you are preparing a different release channel, use that channel's entry-repository release page instead of copying this RC URL.

    For repeated commands, set.

    INSTALL_URL=http://git.librerobotics.org/justin.kang/librux/releases/download/v1.0.0rc11/install.sh

    Download Endpoint

    The public install script is small. It downloads the platform-matching installer binary and the installer then resolves the runtime manifest through the Librux distribution endpoint.

    In production, runtime artifacts are served through the distribution API rather than a public object bucket. The API keeps the artifact bucket private, issues short-lived download URLs for the files referenced by the release manifest, and records download metadata such as install session ID, client IP, CDN request metadata, user agent, release version, channel, platform, architecture, artifact name, response status, byte count, and failure reason.

    This data is used for artifact delivery, private artifact access, installation diagnostics, release adoption analysis, abuse investigation, and distribution reliability/security. The distribution endpoint does not collect application source code, subsystem payloads, runtime messages, robot data, host config files, shell history, or local files from the installing host. The complete notice is installed as DOWNLOAD-NOTICE-Librux.txt under <prefix>/licenses and is included in the public source tree as DOWNLOAD_NOTICE.md.

    The current public install flow does not require a user install token. The installer still sends a generated LIBRUX_INSTALL_ID so one installation attempt can be correlated across bootstrap, manifest resolve, and artifact download events.

    Official release scripts use the embedded distribution endpoint by default. LIBRUX_RELEASE_BASE_URL is only for development scripts generated in direct asset mode. For production installs, use the published install.sh without overriding distribution variables.

    Interactive Install

    Default install.

    curl -fsSL "$INSTALL_URL" | sh

    Default prefix.

    /opt/librux

    Choose a development user prefix.

    curl -fsSL "$INSTALL_URL" | sh -s -- --prefix ~/.local/librux

    When a TTY is available, the installer opens a terminal UI for license review, prefix selection, PATH integration, and Linux system-service setup. On Linux hosts with systemd, the interactive default is to install and enable the Librux system services unless you choose to skip them.

    Line-based prompt mode.

    curl -fsSL "$INSTALL_URL" | sh -s -- --no-tui

    Manual License Review

    Runtime license acceptance is manual only. Official runtime manifests require the installer to show the required license document and record consent through the TUI or line-based prompt. The installer intentionally rejects automatic license acceptance flags.

    Default manual flow.

    curl -fsSL "$INSTALL_URL" | sh

    Line-based manual prompt instead of the full-screen TUI.

    curl -fsSL "$INSTALL_URL" | sh -s -- --no-tui

    Product prefix and system services.

    curl -fsSL "$INSTALL_URL" | sh -s -- \
  --prefix /opt/librux \
  --system-services install

    Useful flags.

    --prefix <path>
--path-mode none|print|shell-rc
--shell-rc <path>
--system-services install|skip
--system-service-config <path>
--no-tui

    If the installer cannot prompt for sudo in a headless session, complete the manual license review first and register services from an interactive terminal.

    curl -fsSL "$INSTALL_URL" | sh -s -- \
  --prefix /opt/librux \
  --system-services skip

sudo /opt/librux/bin/librux system install --prefix /opt/librux

    Use a service-readable prefix such as /opt/librux for product deployments. User-home prefixes remain useful for development.

    Installed Layout

    The installer writes.

    • runtime payload under <prefix>/runtime
    • executables under <prefix>/runtime/bin
    • runtime libraries under <prefix>/runtime/lib
    • Web Console assets under <prefix>/runtime/frontend
    • public spec files under <prefix>/runtime/spec
    • runtime support tools under <prefix>/runtime/tools
    • C++ SDK under <prefix>/sdk/cpp
    • Python SDK wheel under <prefix>/sdk/python
    • guided tutorial source under <prefix>/tutorials
    • benchmark runner source under <prefix>/benchmarks
    • license and notice documents under <prefix>/licenses
    • service unit sources under <prefix>/systemd
    • runtime state, logs, and control service home under <prefix>/var
    • shell environment helper under <prefix>/env.sh
    • uninstaller under <prefix>/bin/librux-uninstall

    Top-level entry points.

    • <prefix>/bin -> <prefix>/runtime/bin
    • <prefix>/spec -> <prefix>/runtime/spec
    • <prefix>/config.yaml -> <prefix>/runtime/config.yaml

    Source the environment helper before using installed SDK/runtime commands, tutorials, or benchmarks.

    . <prefix>/env.sh

    This sets LIBRUX_PREFIX, updates PATH, and configures spec/runtime library paths for the installed SDK.

    Linux Services

    On Linux, the installer can register.

    • librux-control.service
    • librux-resourced.service
    • librux-timesyncd.service

    The control service runs without root privileges. Resource and time-sync companions keep the narrow root authority needed for resource brokering and host-level clock management.

    The system service installer creates a librux resource group by default. The control service and managed SDK package processes use that group for runtime IPC such as timed-exchange Unix sockets. Managed package launches preserve the runtime IPC group as a supplementary group, so application code does not need to patch socket ownership or permissions.

    Service unit files live under <prefix>/systemd. The installer links them from /etc/systemd/system so uninstall can remove the links and then remove the single install prefix. Runtime sockets use /run/librux, owned by root:librux with mode 2770, and are recreated when services start. The SDK control plane uses /run/librux/control.sock by default; managed launch paths pass the resolved path to application processes as LIBRUX_CONTROL_SOCKET.

    If service setup was skipped.

    sudo <prefix>/bin/librux system install --prefix <prefix>

    For a dedicated config.

    sudo <prefix>/bin/librux system install \
  --prefix <prefix> \
  --config /path/to/config.yaml

    For details, see Time Sync Operations and Resource Control.

    Uninstall

    To remove a product install.

    sudo <prefix>/bin/librux-uninstall --prefix <prefix>

    The uninstaller stops and disables Librux services, removes Librux systemd unit links, clears /run/librux, and removes the selected install prefix. It keeps the librux system user and group by default; pass --remove-users only when those accounts are no longer used by any Librux install.

    Verification

    . <prefix>/env.sh
librux --help
lbx --help
librux status
librux config --help
librux package --help
librux launch --help
librux resource inventory
librux timesync doctor --json

    If services were installed.

    sudo systemctl status librux-control.service --no-pager
sudo systemctl status librux-resourced.service --no-pager
sudo systemctl status librux-timesyncd.service --no-pager

    Interactive Linux installs default to system-service setup when systemd is available. Noninteractive plans default to skipping services unless --system-services install is passed.

    Installed SDK Payload

    The installer places SDK payloads under <prefix>/sdk, but it does not install the Python wheel into your active virtual environment. It also installs the guided tutorial source under <prefix>/tutorials and benchmark runners under <prefix>/benchmarks, so normal tutorial and performance paths do not require a separate SDK source checkout.

    Linux C++ SDK release payloads bundle yaml-cpp internally, so installed-user C++ tutorial builds do not depend on a distro-specific libyaml-cpp.so.* at runtime.

    License Files

    The installer keeps release-manifest license and notice documents under <prefix>/licenses. Use this directory as the installed license record for the runtime EULA, public SDK/source notices, bundled third-party licenses, and the download/install data notice.

    Next Step

    Continue with Quickstart. Use Operate for host operation and Develop for SDK/tutorial workflows.