A Linux distribution built entirely from source with a custom package manager, a tiered local AI assistant, and integrated AI-driven security auditing.
Website · Documentation · InterGen Studios
InterGenOS puts the user in control of their own machine. Every package is compiled from source with deliberate choices. Every design decision serves one purpose: giving people a system they understand, can modify, and can trust.
InterGen, the local AI assistant, doesn't just help you use your system — it helps you understand and secure it. Hardware-detected tiers run it on everything from a 4 GB laptop to a GPU workstation, fully offline. InterGen Sentinel — its pluggable security-scanner architecture — routes MCP traffic through your choice of scanner before it reaches a tool. A local-only default (Local-Rules rule-based + Local-Qwen InterGen-LLM-backed via your local Qwen model) ships ready to go. Six cloud providers are opt-in: Claude-Anthropic, Gemini-Google, CoPilot-Microsoft, ChatGPT-OpenAI, Grok-xAI, and DeepSeek. Frontier AI models in 2026 routinely surface security-relevant findings at scale — pluggable cloud routing lets users opt into that capability through whichever vendor they trust. The user picks which (if any) reaches across the network.
GNOME 49.4 on Wayland with the InterGenOS shell theme.
![]() |
![]() |
![]() |
![]() |
Desktop ships with the Papirus-Dark icon theme as default; the Cybernetic Blue icon theme by SethStormR is included as a featured alternate, switchable via Settings → Appearance or the first-boot welcomer.
InterGenOS is built for a world where AI-assisted vulnerability discovery is a foregone conclusion, not a theoretical threat. Recent frontier-AI evaluations have demonstrated working-exploit yields two orders of magnitude above the previous generation, with broad benchmark coverage across major operating systems and browsers — and that capability will proliferate. We build this distribution assuming adversaries have superhuman vulnerability discovery and make every design decision with that in mind. Secure Boot is mandatory. Every package choice is a security choice. Nothing that hides how the system works gets shipped.
Security is not first. It is only.
The Forge Secure Boot chain — each link verifies the next, anchored to a Machine Owner Key the installer generates per machine:
flowchart TD
FW[" UEFI firmware<br/>(Secure Boot on) "] -->| trusts MS UEFI CA | SHIM[" shim<br/>Microsoft-signed "]
SHIM -->| verifies SBAT + signature | GRUB[" GRUB<br/>MOK-signed "]
GRUB -->| verifies | UKI[" Unified Kernel Image<br/>MOK-signed "]
UKI --> KRN[" kernel<br/>lockdown=integrity<br/>module sig_enforce "]
MOK([" Your Machine Owner Key<br/>enrolled once — the trust anchor "]) -. signs .-> GRUB
MOK -. signs .-> UKI
InterGenOS exists to put the user in control of their own machine. Every design decision, every default, every included component must serve this purpose: giving people a system they understand, can modify, and can trust. Any complexity that doesn't serve the user — or that hides how the system works — is not welcome, regardless of how conventional it may be.
The Prime Directive and the security-only alignment above are complementary: a machine the user cannot trust is a machine they do not control.
- Built from source — Based on LFS 13.0 / BLFS 13.0, every component chosen deliberately
- Custom package manager (
pkm) — Natural-language CLI with SQLite + text manifest hybrid storage - System installer (
forge) — TUI-based installer powered by pkm, from partition to bootable desktop - Custom build system (
igos-build) — Python orchestrator with YAML templates, dependency resolution, and full build logging - BLFS package database — 1,030 packages with 3,948 dependencies queryable via SQL, plus a meson feature database for auditing build options across packages
- 5-distro kernel convergence — kernel config derived from Ubuntu, Fedora, Arch, Debian, and openSUSE consensus (3,434 universal options)
- GNOME desktop — Wayland-native with dark theme and InterGenOS branding
- Transparent boot — no Plymouth splash. You watch the kernel hand off to systemd and every service start with
[OK]/[FAILED]; if a mount breaks or a module misbehaves you see it the moment it happens. Spotting odd boot output is a real practice for catching compromise or hardware change — we give you that surface rather than hide it behind a logo. See docs/users/desktop-experience.md. - Forge Secure Boot chain — signed shim → MOK-signed GRUB → MOK-signed kernel →
MODULE_SIG_FORCE=ymodules. The user's own MOK key is the trust anchor; the installer generates it per machine. See SECURITY.md. - Test harness — 375 tests in
installer/tests/covering installer backend, MOK validation, and Class 1 signing-chain verification; Phase A scaffold for GRUBcheck_signatures=enforceempirical validation. Additional preflight, repo-publish, SBOM, upstream-check, and download-sources test suites live undertests/. - Extra tier — 112 packages spanning seven install-helpers for proprietary software (Brave, Chrome, Claude Code, Discord, Edge, Spotify, VS Code) plus open-source applications (Firefox, LibreOffice, Audacity, GIMP, Inkscape, Thunderbird, MPV, Rhythmbox, Transmission), the Rust CLI suite (ripgrep, bat, eza, fd, hyperfine, just, starship, zoxide, and more), and container runtimes (podman, crun, conmon, netavark). Proprietary packages are fetched transparently via pkm.
- InterGen — tiered local AI assistant with permission-gated tool calling, D-Bus activation, and a local LLM stack (llama.cpp). Hardware-detected, fully offline. Text-only by design.
- InterGen Sentinel — Pluggable security-scanner architecture.
Local-Rules(rule-based, deterministic) +Local-Qwen(InterGen-LLM-backed via your local Qwen model) ship by default, fully offline. Six cloud providers are opt-in: Claude-Anthropic, Gemini-Google, CoPilot-Microsoft, ChatGPT-OpenAI, Grok-xAI, DeepSeek. Schema-pinning, audit logging, and sandbox enforcement are vendor-neutral local plumbing — they apply regardless of which scanner is active.
Meet InterGen — your onboard AI assistant. Fully offline, hardware-aware, and built to understand the specific machine it's running on. At intergen setup time, InterGen detects your CPU, RAM, and GPU, then picks an LLM and quantization appropriate to the machine — from a 4 GB laptop on up to a GPU workstation. No cloud, no accounts, no round-trip latency.
What separates InterGen from a generic local-LLM wrapper is the permission model. Every tool call is treated as privileged: the default escalation mode is ask, requiring user confirmation before any action that modifies system state. Tool signatures are pinned against drift between upgrades. A separate audit log captures every tool invocation for after-the-fact review. The AI is a system component, not a hole in it.
InterGen Sentinel routes every MCP tool call through a security scanner of your choice before it executes. The default is local-only: Local-Rules (rule-based, deterministic) and Local-Qwen (your local Qwen model reviewing the call). For richer review, opt into any of six cloud providers: Claude-Anthropic, Gemini-Google, CoPilot-Microsoft, ChatGPT-OpenAI, Grok-xAI, and DeepSeek. The user picks which (if any) reaches across the network; everything else stays on the box.
flowchart TD
U[" You "] --> IG[" InterGen<br/>local LLM assistant "]
IG -->| every tool call | SEN{" InterGen Sentinel<br/>scan + permission gate "}
SEN --> LR[" Local-Rules<br/>(deterministic) "]
SEN --> LQ[" Local-Qwen<br/>(local model review) "]
SEN -. opt-in .-> CL[" Cloud scanner<br/>Claude · Gemini · CoPilot ·<br/>ChatGPT · Grok · DeepSeek "]
LR --> RUN[" approved → tool runs<br/>(logged to the dispatch audit) "]
LQ --> RUN
CL -.-> RUN
See intergen(1) for the full command surface and /etc/intergen/config.yml for the default configuration.
| Tool | Purpose |
|---|---|
pkm |
Package manager — install, remove, search, verify, depends |
forge |
System installer — partition, deploy archives, configure, boot |
intergen |
Natural-language CLI to the InterGen AI assistant daemon |
igos-build |
Build system — source to archives with dependency resolution |
blfs-query |
BLFS database query tool — deps, gaps, chain-cost, versions, meson-flags, meson-audit |
populate-meson-db |
Meson feature database populator — parses options from source tarballs |
| Tier | Purpose |
|---|---|
| toolchain | Cross-compilation (LFS Ch. 5-7) |
| core | Full system: kernel, shell, coreutils, systemd, GCC, SSH |
| base | CLI tools: htop, rsync, strace, screen |
| desktop | GNOME on Wayland: GTK, Mesa, GStreamer, GNOME Shell |
| ai | Local AI assistant: llama.cpp, InterGen, InterGen Sentinel |
| extra | User applications: Node.js, Google Chrome, VS Code, Claude Code |
Single command builds the entire system:
sudo bash scripts/build-intergenos.sh --user <username> --checkpointPhases: validate → verify-sources → setup → toolchain → chroot-prep → chroot-tools → core → config → core-extra → base → kernel → desktop → ai → extra → bootloader → image → manifest → squashfs → ukis-verity → iso
flowchart TD
V[" validate "] --> VS[" verify-sources<br/>(SHA-256 source gate) "]
VS --> TC[" toolchain "] --> CO[" core "] --> BA[" base "] --> KE[" kernel "]
KE --> DE[" desktop "] --> AI[" ai "] --> EX[" extra "]
EX --> BL[" bootloader<br/>(MOK-sign shim → GRUB → UKI) "]
BL --> IM[" image → manifest<br/>(signed package index) "]
IM --> SQ[" squashfs "] --> UV[" ukis-verity<br/>(dm-verity roothash → signed UKI) "]
UV --> ISO[" signed ISO "]
Resume from any phase with --start-at, stop with --stop-after. Checkpoints saved after toolchain, core, kernel, and desktop phases.
# Build the OS (on Ubuntu 24.04 build VM)
sudo bash scripts/build-intergenos.sh --user <username> --checkpoint
# Query the BLFS package database
python3 scripts/blfs-query.py info samba
python3 scripts/blfs-query.py deps mesa --recursive
python3 scripts/blfs-query.py chain-cost openldap
# Meson feature database — what flags does a package need?
python3 scripts/blfs-query.py meson-flags gtk4
python3 scripts/blfs-query.py meson-audit --tier desktop
python3 scripts/blfs-query.py meson-impact shaderc
# Package management (on a running InterGenOS system)
pkm install alsa-utils
pkm install chrome # Proprietary: fetched from Google, installed via pkm
pkm install vscode # Proprietary: fetched from Microsoft, installed via pkm
pkm install claude-code # Proprietary: fetched from Anthropic, installed via pkm
pkm remove htop
pkm list installed
pkm search audio
pkm info openssh
pkm provides /usr/bin/bash
pkm verify --allA virtual machine is the fastest way to evaluate InterGenOS without dedicated hardware. Full Forge installations are verified on VirtualBox 7.x and VMware Workstation Pro. InterGenOS is UEFI-only — enable EFI firmware in the VM settings; there is no legacy BIOS fallback.
| Setting | VirtualBox | VMware Workstation Pro |
|---|---|---|
| Firmware | EFI enabled | EFI enabled |
| Memory | 8 GB | 8 GB |
| Processors | 4 cores | 4 cores |
| Disk | 30 GB or larger | 30 GB or larger |
| Graphics | VMSVGA, 256 MB VRAM, 3D acceleration on | VMware SVGA |
| Network | NAT | NAT |
| Guest integration | none — do not install Guest Additions | open-vm-tools (not bundled VMware Tools) |
These resources give a responsive GNOME desktop and usable InterGen latency. InterGenOS will boot with as little as 4 GB and 2 cores, but at that floor the desktop and the local assistant feel noticeably slow and it is not a representative evaluation — allocate the recommended 8 GB and 4 cores. In a virtual machine InterGen runs its CPU-friendly 2-billion-parameter assistant model; the larger 9B and 35B tiers require a discrete GPU (passthrough), which most VM setups do not provide, so a VM exercises the entry tier regardless of additional RAM.
- VirtualBox: set the resolution in Settings → Displays after first boot (e.g. 1920×1080) on high-DPI hosts. Do not install Guest Additions — the locked-down kernel rejects unsigned out-of-tree modules by design.
- VMware: scales correctly out of the box using the in-tree
vmwgfxdriver with EDID support. - Both hypervisors may log a cosmetic
failed to create vmw_framebuffer: -22message in the live session; the display works normally. - Both boot with Secure Boot disabled initially. The signed boot chain (shim → GRUB → UKI) is provisioned regardless; enabling Secure Boot is a one-time MOK enrollment at first boot.
Install: boot the ISO, choose Install InterGenOS (Graphical) from the GRUB menu, and follow Forge screen by screen. Nothing is written to disk until you confirm on the review screen.
Full walkthrough: Virtual Machine guide.
intergenos/
├── igos-build/ # Build system (Python — parser, graph, builder, tracker)
├── pkm/ # Package manager (Python — install, remove, query, verify)
├── installer/ # Forge installer (Python — TUI + backend)
├── packages/ # 860 package templates (YAML + build.sh)
│ ├── toolchain/ # LFS Ch. 5-7 (28 packages)
│ ├── core/ # LFS Ch. 8 + TLS/PAM/SSH + Forge SB primitives (272 packages)
│ ├── base/ # End-user CLI tools (23 packages)
│ ├── desktop/ # GNOME desktop stack (423 packages)
│ ├── ai/ # Local AI assistant stack (2 packages)
│ └── extra/ # User-facing applications (112 packages)
├── scripts/ # Build orchestrator, chroot scripts, BLFS tools
├── data/ # Curated metadata (meson option-to-dep mappings)
├── config/ # Kernel config, systemd units, gsettings overrides
├── build/ # Sources, patches, logs, archives (not committed)
└── docs/ # Project documentation, governance, security policy, and research
Active development, pre-1.0. Originally built 2015-2016 (build_001 through build_003 on GitHub). Revived March 2026.
Now: 860 package templates across six tiers. First successful GNOME 49.4 desktop boot on Wayland achieved April 7, 2026 — kernel 6.18.10 with config converged from 5-distro analysis. First themed qcow2 image built May 3, 2026 with full GNOME theming applied. The v1.0 archive set is being finalized. Installer (forge) handles partition → signed boot chain → image deploy → post-install hooks. The signed boot chain (shim → MOK-signed GRUB → MOK-signed UKI → forced module signatures) has been validated end-to-end under enforced Secure Boot with per-machine MOK enrollment in a virtual machine — the first end-to-end Secure Boot validation; native Secure-Boot-from-ISO follows in the build that embeds GRUB's SBAT record. Test harness covers 375 tests across installer backend, MOK validation, and Class 1 signing-chain verification, plus additional suites under tests/ (preflight, repo-publish, SBOM, upstream-check, download-sources). The public binary mirror is live at repo.intergenos.org, serving signed per-package archives and a signed InterGenOS.db index; the signing-key ceremony is complete (RSA-4096 master with hardware-token signing subs).
External reviews: Full codebase reviewed by four external LLMs (ChatGPT, DeepSeek, Gemini, Grok) across build system, installer, orchestration, and package management. Initial audit findings have all been remediated, and hardening continues as new edge cases surface.
Bare-metal installs validated across widely varying hardware — from current laptops back to a ~2012 2nd/3rd-generation Intel Core i5 — each deploying the full signed boot chain through the end-to-end ISO-installer path.
Items actively in flight or planned before v1.0:
- Forge Secure Boot bare-metal validation — enforced Secure Boot is validated end-to-end in a virtual machine (per-machine MOK enrollment, full signed chain); first-hardware MOK enrollment on bare metal is the remaining step.
- Microsoft shim-review submission — obtaining an InterGenOS-owned MS-signed shim via the
rhboot/shim-reviewsponsor track. - Public binary mirror — v1.0 archive completion —
repo.intergenos.orgis live, serving signed per-package archives and a signedInterGenOS.dbindex; remaining work is completing full v1.0 package coverage on the mirror. pkminstalled as a system tool — packaging pkm itself sopkm install <pkg>works out of the box on a freshly installed target.- VPS source mirror completion — download-sources tooling refresh plus an upstream-version auto-poller (Components 2 and 3 of the mirror design).
- 35B AI tier scoping — evaluating the 35-billion-parameter local-assistant tier for high-end hardware.
- NVIDIA driver-open packaging — fetch-helper approach for the GPL-compliant NVIDIA open modules.
- Dual-boot Zephyrus playbook — tested alongside-Windows install flow on shared hardware.
- Switchable desktop environments — v1 ships GNOME on Wayland; KDE Plasma, XFCE, and other Wayland-capable desktops planned post-v1, with the per-tier architecture already supporting the split.
- Security Hall of Fame — researcher acknowledgment page maintained alongside the project's responsible-disclosure track.
- 2015: build_001 — First LFS attempt
- 2016: build_002, build_003 — 83 packages, fully automated
- 2016-2025: Life happened. Project shelved.
- 2026: Revival. New build system, package manager (pkm), installer (forge), BLFS database, GNOME desktop, a Secure Boot chain the user owns end-to-end, and the conviction that a from-source distribution can be both deeply educational and genuinely accessible — and that security-only alignment is not a luxury for the next decade of computing.
Every major decision is documented. See docs/research/ — 188 markdown documents (plus supporting diagrams and data files) across 27 subdirectories covering:
- Why LFS over Gentoo, Buildroot, NixOS
- Build system design (9 systems evaluated)
- Package management history and design
- Kernel config convergence analysis (5 distros)
- GNOME desktop dependency chain (~370 packages)
- Application roadmap (Flathub/Snap/Arch data-driven)
- Forge Secure Boot design, signing-key custody, MS shim sponsorship research
- FLUX.2 branding pipeline
InterGenOS is built on the foundation of Linux From Scratch (LFS 13.0) and Beyond Linux From Scratch (BLFS 13.0). The LFS project and its contributors have made from-source Linux building accessible and educational for over two decades. This project would not exist without their work.
All included packages carry their own licenses as tracked in their package templates. See CREDITS for full attribution.
InterGenOS ships under a layered licensing posture. The summary table below points you to the operative document for each layer; nothing here is a substitute for those documents.
| Layer | License | Reference |
|---|---|---|
| Build system, tools, package templates, pkm, Forge, InterGen wrapper, scripts (InterGenOS-authored code) | GPL-3.0-or-later | LICENSE |
| Individual upstream packages (over 800 build targets and counting) | Upstream's own license (SPDX in each package.yml) |
CREDITS, docs/governance/license-policy.md |
| GPL source availability | §6d network access + §6b 3-year written offer | SOURCES.md |
| Brand assets (name, logo, color palette, shell-theme name) | Common-law trademark; carved out of GPL-3 | TRADEMARK.md |
| AGPL-licensed packages shipped (ghostscript, mupdf) | AGPL-3.0-or-later, with project posture not exposing as network service | docs/governance/license-policy.md § 3 |
| Patent-encumbered codecs (FDK-AAC, H.264/H.265 — opt-in) | Various; default ISO ships without FDK-AAC linkage | docs/legal/PATENTS.md |
| Proprietary-fetched helpers (Chrome, Edge, VS Code, Spotify, Discord, Brave, Claude Code) | Each vendor's EULA, accepted at install time | docs/legal/payload-licenses.md |
| Fetched-at-runtime LLM weights (Qwen via InterGen) | Tongyi Qianwen License, accepted at first launch | docs/legal/payload-licenses.md |
| Privacy posture | Local-first, no telemetry; GDPR / CCPA disclosures | PRIVACY.md |
| Export-control posture | ECCN 5D002 self-classified, TSU + ENC license exceptions | EXPORT-NOTICE.md |
| Contributor sign-off | Developer Certificate of Origin 1.1; Signed-off-by: trailer required |
DCO.md |
| Vulnerability disclosure | Responsible-disclosure flow | SECURITY.md |
| Contributing | Issue + PR workflow | CONTRIBUTING.md |
| Project contributor record | Real-person identity list | AUTHORS |
For redistributors: you inherit the project's source-availability, trademark, and export-control obligations in your own distribution channel. The respective documents explain what that means for you.
InterGenJLU — InterGen Studios







