Repository navigation
FAQ
This FAQ addresses what nx-bootstrap builds, how it compares with package build services, and where its YAML-driven workflow can be reused.
It builds three related artifacts or inputs:
- A package snapshot downloads selected binary
.debfiles from an APT repository and verifies each file's SHA-256 value. - A rootfs build creates a Debian-based filesystem from the fixed minbase baseline, the package roots in YAML, and their required dependencies.
- An ISO build takes a rootfs archive, applies an ordered set of packaged Nitrux stages, and creates a bootable image.
The snapshot is an input to repository publication; the rootfs archive is an input to the ISO build.
The YAML declares the APT repositories, a fixed minbase is installed first, and the top-level base list (or its packages alias) is added in a second transaction. APT installs the required dependency closure. Recommendations and suggestions are disabled, and the exclude list prohibits packages from both the baseline and dependency closure.
Repository priority and package Essential flags do not add unrelated packages to the fixed baseline. That keeps the package selection tied to the minbase definition and the YAML package roots.
No. The rootfs YAML supplies every repository URL, suite, component, architecture, and signing-key source. nx-bootstrap does not infer or hardcode a distribution mirror. The snapshot target also reads its repository location from its own YAML document.
It is a separate rootfs bootstrap implementation. It uses Python-APT to read repository metadata, resolve package dependencies, and carry out APT package transactions in the target root. It seeds the package runtime from the configured repositories, configures the fixed minbase, then installs the YAML package roots. It does not wrap either debootstrap or mmdebstrap.
The Open Build Service (OBS) is a build and distribution service for building binary packages and images from source across supported distributions and architectures. Its workflow includes source package recipes, build workers, repository publication, and project collaboration. See the OBS User Guide for its supported formats and workflows.
nx-bootstrap is a local or CI-run rootfs and ISO assembly tool. It consumes binary packages already available through APT; it does not compile those packages from source, host a general package repository, or provide OBS's project and worker services. The included GitHub Actions workflow is project automation around nx-bootstrap, not an nx-bootstrap build farm.
| Question | nx-bootstrap | OBS | Launchpad PPA |
|---|---|---|---|
| Main input | APT repositories and YAML package/stage selections | Source packages and build recipes | Ubuntu source package uploads |
| Main work | Assemble rootfs archives and Nitrux ISOs | Build and publish packages and supported image formats | Build Ubuntu binary packages and publish them in an APT archive |
| Build infrastructure | Local host or a CI runner configured by the project | Hosted or self-managed build service with workers | Launchpad's hosted build farm |
| Repository hosting | Uses external APT repositories | Can publish build results through OBS projects | Hosts the resulting PPA packages |
A Launchpad PPA accepts source packages, builds binaries on Launchpad's build farm, and hosts them in an APT repository. nx-bootstrap consumes binary packages from APT repositories and assembles rootfs and ISO outputs. It does not accept Debian source uploads or operate a PPA build farm.
A compatible APT repository can be used as a rootfs source regardless of which service hosts it. Launchpad PPAs target Ubuntu packaging and suites; their package availability and dependencies must match the rootfs architecture and repository suite you configure.
The rootfs target is based on Debian APT and can assemble a root filesystem from compatible APT repositories when the fixed minbase packages and requested packages exist for the selected architecture. You provide the repositories, keys, package names, exclusions, and output settings.
The ISO target is more specific: its shipped stages, boot files, and current flavors are for Nitrux. YAML can choose and order packaged stages but cannot add arbitrary shell stages. Reusing the rootfs target for another Debian-based system is possible; producing another distribution's ISO requires extending or adapting the packaged ISO stages.
No. APT selects and installs binary packages from the configured repositories. Use a package build service or a source-package tool to produce .deb files, then publish them to an APT repository that nx-bootstrap can read.
No. nx-bootstrap snapshot downloads and verifies selected .deb files. The included GitHub Actions workflow separately yanks matching old packages and uploads the new snapshot to Nitrux Packagecloud before it builds the rootfs. The publishing credentials belong to that workflow, not to the snapshot command.
The CLI requires effective UID 0 for rootfs and ISO builds. UID 0 inside a rootless container can satisfy that check, but the container may not grant the capabilities needed by chroot, device creation, or mounts. The rootfs builder has device setup fallbacks, but it does not mount /proc or /sys for package installation. A package script that needs those facilities can still fail.
The ISO target consumes a rootfs archive, not a package repository. Build the rootfs archive first, then reference that archive locally or by a checksum-verified download in the ISO definition.
No. The stages list selects scripts shipped in the nx-bootstrap package. YAML controls their order and which packaged stages run; it is not an inline shell-script interface. A custom distribution workflow needs a change to the packaged stages or a maintained fork.
The included Actions workflow publishes the rootfs archive and its SHA-256 sidecar to a GitHub Release after checking that the archive is below GitHub's 2 GiB per-asset limit. ISO files are produced locally by the ISO target. A larger ISO needs a host that accepts files of that size; repository and release hosting are separate from the build itself.
©2026 Nitrux Latinoamericana S.C.