lowell
OCI-native tools for building hermetic, host-agnostic boot artifacts (UKIs and initramfs).
Motivation
Bootable containers and Unified Kernel Images (UKIs) package the OS user space and the boot chain (kernel, initramfs, and command line), respectively, as portable artifacts. Image-based systems typically build the initramfs with dracut, which inspects the build host; that coupling can work against sealed, reproducible builds. lowell, a modern, cloud-native alternative to dracut, aims to produce hermetic, OCI-pinned boot artifacts that are easy to audit (SBOM-friendly), distribute via registries, and can optionally be signed/sealed.
Why “Lowell”?
Following the tradition of naming software after Massachusetts towns (e.g., Dracut, Wayland, Weston), the project is named after Lowell, Dracut’s younger, neighboring mill city, which continues to modernize and is home to a vibrant community of engineers and university students active in free and open-source software (FOSS).
Status
Still under early active development:
-
Works today
- CLI:
lowell inspect uki --file /path/to/vmlinuz.efi - Flags:
--format json|human,--verbose, global--log-level {error|warn|info|debug|trace} - Reports:
arch,pe32_plus- Signature presence and
cert_count - Kernel
cmdline os-releasefields.linuxand.initrdoffsets, sizes, SHA-256- initrd compression detection (gzip/xz/zstd/uncompressed) and cpio format (newc)
- CLI:
-
Planned next
lowell inject uki— modify initramfs and rebuild a UKIlowell build— hermetic initramfs + UKI, using OCI-pinned inputs where it helps
Documentation
Build and run
# build from source
# inspect a UKI
# useful flags
JSON example
Versioning
- Pre-1.0: rapid iteration; breaking changes may occur.
- 1.0 and later: Semantic Versioning.
Community discussion
GitHub issues/discussions will be the main source for now, but we’re open to any suggestions for better communication.
Contributing
Thanks for considering a contribution! Bug reports, docs, tests, and features are all welcome.
Before you start
- Search existing issues/discussions to avoid duplicates.
- For larger changes, open an issue first to align on scope.
Dev setup
- Rust: stable toolchain (
rustup default stable) - Recommended:
justfor common tasks
Common tasks
# build
# run the CLI
# format, lint, test (pre-PR checklist)
Style & guidelines
- Use
tracingfor logs and prefer structured logs overprintln!. - Favor
anyhow/thiserrorfor error handling; avoidunwrap()in library code. - Keep commits focused; Conventional Commits are appreciated but not required.
- Please remember to add the DCO
Signed-off-byline to the end of your commit messages.
Submitting a PR
- Make sure
fmt,clippy, and tests pass. - Add/adjust tests when changing behavior.
- Update docs/README flags or examples if needed.
- Fill in a short rationale in the PR description and link any related issues.
Security
If you believe you’ve found a vulnerability, please open a private GitHub security advisory (preferred) or contact the maintainers directly. Please do not open a public issue for security reports.
License
Licensed under either of the following options at your choice:
- Apache License, Version 2.0 (
LICENSE-APACHEor http://www.apache.org/licenses/LICENSE-2.0) - MIT license (
LICENSE-MITor http://opensource.org/licenses/MIT)
Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in this project by you, as defined in the Apache-2.0 license, shall be dual-licensed as above, without any additional terms or conditions.
Add SPDX headers to new source files (recommended):
// SPDX-License-Identifier: Apache-2.0 OR MIT