InterGenOS

A Linux distribution built entirely from source with a custom package manager, a tiered local AI assistant, and integrated AI-driven security auditing.

Website · Updates · Documentation · InterGen Studios

📀 Download InterGenOS R001.4

x86_64 UEFI live ISO · 9.8 GiB · sha256 4608b40b9d8854a36489a435776e9bb08e20c7dd03cadf02929632b2cfe5b7d0 — checksum file and the signature over it Verify before you write it: check the signature on the checksum file, then check the image against the checksum — the steps are here. Signed on-hardware with the release key, fingerprint 5597 A3E0 587B 2530 06D0 DD7B 8C50 8261 8208 3050 — the same key signs the image checksum, the release tag and the package mirror index.

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. It runs on everything from a laptop with no discrete graphics to a GPU workstation, fully offline, choosing its model tier from the graphics hardware it finds. Every tier is multimodal. InterGen Sentinel — its security-scanner layer — checks every MCP tool call before it reaches a tool: a deterministic rules scanner that is always on, and a local model-backed classifier (Local-Qwen, your local Qwen model) that attaches when its configured model is present and verified.

"Fully offline" means the local model: web searches and page retrieval you request, and Phone-A-Friend requests you approve, are the only paths that touch the network, and each is your choice.

Screenshots

GNOME 49.4 on Wayland with the InterGenOS shell theme.

Desktop ships with the first-party InterGenOS icon theme as default (promoted at 1.4; it inherits Adwaita and hicolor for full application coverage). Papirus-Dark and the Cybernetic Blue icon theme by SethStormR ship as featured alternates, switchable in the first-boot Welcomer or later with GNOME Tweaks. Typography is Inter for the interface — shipped as the variable family Inter Variable, which is the family name the desktop defaults request — paired with JetBrains Mono on terminal and code surfaces, over a system-wide prefer-dark colour scheme.

Security-Only Alignment

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 available and strongly advised: every image ships a fully signed boot chain, and enabling Secure Boot with your machine's enrolled key makes the firmware enforce it. 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)"] --> E1["&nbsp;trusts MS UEFI CA&nbsp;"] --> SHIM["shim<br/>Microsoft-signed"]
    SHIM --> E2["&nbsp;verifies SBAT + signature&nbsp;"] --> GRUB["GRUB<br/>MOK-signed"]
    GRUB --> E3["&nbsp;verifies&nbsp;"] --> 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"]) -.-> S1["&nbsp;signs&nbsp;"] -.-> GRUB
    MOK -.-> S2["&nbsp;signs&nbsp;"] -.-> UKI
    classDef lab fill:#4b4b4b,color:#ffffff,stroke:none;
    class E1,E2,E3,S1,S2 lab;

The Prime Directive

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.

Features

• 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) — graphical and text 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,000+ packages with 3,900+ 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,400+ 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=y modules. The user's own MOK key is the trust anchor; the installer generates it per machine. See SECURITY.md.
• Test harness — over 600 tests in installer/tests/ covering installer backend, MOK validation, install-integrity, and Class 1 signing-chain verification; Phase A scaffold for GRUB check_signatures=enforce empirical validation. A further over 4,900 tests across the repo-level suites under tests/ (preflight, repo-publish, SBOM, upstream-check, download-sources, and more).
• Extra tier — 190+ packages spanning nine install-helpers for proprietary software (Brave, Chrome, Claude Code, Discord, Edge, Signal, Spotify, VS Code, Zoom) 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.

Meet InterGen

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 inspects the machine's graphics hardware and picks a model and quantization it can actually serve responsively. Tier selection is decided by discrete-GPU presence and VRAM alone — system RAM is never an input, because a large model held in system memory is slow enough to be the wrong answer no matter how much of it there is:

Detected hardware	Tier served
No discrete GPU	Tier 1 — a 2-billion-parameter model, the CPU-friendly floor
Discrete GPU, VRAM ≥ ~7 GB	Tier 2 — a 9-billion-parameter model
Discrete GPU, VRAM ≥ ~22 GB	Tier 3 — a 35-billion-parameter mixture-of-experts model
Discrete GPU, smaller or unreadable VRAM	Tier 1 — detection fails down, never up

The tier chooses the model; it does not decide whether the graphics card is used. With the shipped auto setting, InterGen separately compares the chosen model, its vision projector and serving headroom with the detected video memory. When those inputs are readable, it offloads every layer when the model fits, as many layers as fit when it does not, and reports a processor-only result when no layer fits. An explicit llama_server.gpu_layers setting remains the user's override.

The local model needs no cloud account or API key. Web searches and page retrieval you request, and Phone-A-Friend requests you approve, use the network only when you choose those features.

What separates InterGen from a generic local-LLM wrapper is the permission model. Every tool call is classified before dispatch: read-only operations may run automatically, state-changing operations require confirmation, and blocked operations are refused. Confirmed privileged operations cross PolicyKit through a short-lived runner rather than inheriting the assistant daemon's NoNewPrivileges setting. 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 before it executes: Local-Rules (rule-based, deterministic) is always on, and Local-Qwen (your local Qwen model reviewing the call) attaches when its configured model is present and verified; everything stays on the box.

flowchart TD
    U["You"] --> IG["InterGen<br/>local LLM assistant"]
    IG --> T1["&nbsp;every tool call&nbsp;"] --> SEN{"InterGen Sentinel<br/>scan + permission gate"}
    SEN --> LR["Local-Rules<br/>(deterministic)"]
    SEN --> LQ["Local-Qwen<br/>(local model review)"]
    LR --> RUN["approved → tool dispatches<br/>(outcome logged to the dispatch audit)"]
    LQ --> RUN
    classDef lab fill:#4b4b4b,color:#ffffff,stroke:none;
    class T1 lab;

See intergen(1) for the full command surface and /etc/intergen/config.yml for the default configuration.

Tools

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

Package Tiers

Tier	Purpose
toolchain	Cross-compilation (LFS Ch. 5-7) — 25+ packages
core	Full system: kernel, shell, coreutils, systemd, GCC, SSH — 300+ packages
base	CLI tools: htop, rsync, strace, screen — 30+ packages
desktop	GNOME on Wayland: GTK, Mesa, GStreamer, GNOME Shell — 450+ packages
extra	User applications: Node.js, Google Chrome, VS Code, Claude Code — 190+ packages
compute	GPU compute platform: the ROCm stack and its SDKs — 50+ packages
ai	Local AI assistant: llama.cpp, InterGen, InterGen Sentinel, and the model-tooling stack — 55+ packages

Tiers build in that order. A tier's default decides whether its packages ship on the installation image or are available from the mirror only, and individual packages override that default either way — so the tier is the rule, not the shipped reality. Of the 1,100+ package definitions, roughly three quarters ship on the image and the rest are mirror-only, with a couple of hundred packages overriding their tier default in one direction or the other. compute is mirror-only in full; the ai tier ships intergen and llama-cpp on the image and keeps the rest of the model-tooling stack on the mirror.

Build System

Launch a full build as a transient systemd unit so it survives a disconnected shell and retains a named control and logging surface:

UNIT="igos-build-$(/usr/bin/date +%Y%m%d-%H%M%S)"
/usr/bin/sudo /usr/bin/systemd-run \
    --unit="$UNIT" --working-directory=/mnt/intergenos \
    /usr/bin/bash /mnt/intergenos/scripts/build-intergenos.sh \
    --user <username> --checkpoint --debug-verbose

See Running the builder for prerequisites, monitoring, signing pauses, and resume commands.

Phases: validate → verify-sources → setup → toolchain → chroot-prep → chroot-tools → core → config → core-extra → base → kernel → desktop → extra → compute → ai → bootloader → image → manifest → squashfs → ukis-verity → iso

flowchart TD
    V["&nbsp;validate&nbsp;"] --> VS["&nbsp;verify-sources<br/>(SHA-256 source gate)&nbsp;"]
    VS --> TC["&nbsp;toolchain&nbsp;"] --> CO["&nbsp;core&nbsp;"] --> BA["&nbsp;base&nbsp;"] --> KE["&nbsp;kernel&nbsp;"]
    KE --> DE["&nbsp;desktop&nbsp;"] --> EX["&nbsp;extra&nbsp;"] --> CM["&nbsp;compute&nbsp;"] --> AI["&nbsp;ai&nbsp;"]
    AI --> BL["&nbsp;bootloader<br/>(MOK-sign shim → GRUB → UKI)&nbsp;"]
    BL --> IM["&nbsp;image → manifest<br/>(signed package index)&nbsp;"]
    IM --> SQ["&nbsp;squashfs&nbsp;"] --> UV["&nbsp;ukis-verity<br/>(dm-verity roothash → signed UKI)&nbsp;"]
    UV --> ISO["&nbsp;signed ISO&nbsp;"]

Resume from any phase with --start-at, stop with --stop-after. With --checkpoint, a restore tarball is saved after the toolchain, core, and desktop phases.

Quick Start

# Build the OS on the Ubuntu 24.04 build VM using the canonical
# transient-unit invocation in “Build System” above.

# 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)
sudo pkm install alsa-utils
sudo pkm install chrome              # Proprietary: fetched from Google, installed via pkm
sudo pkm install vscode              # Proprietary: fetched from Microsoft, installed via pkm
sudo pkm install claude-code         # Proprietary: fetched from Anthropic, installed via pkm
sudo pkm install codex               # OpenAI Codex CLI + extension: fetched from OpenAI, installed via pkm
sudo pkm install chatgpt             # Proprietary: ChatGPT desktop app with Codex, fetched from OpenAI
sudo pkm remove htop
pkm list installed
pkm search audio
pkm info openssh
pkm provides /usr/bin/bash
sudo pkm verify --all

Try InterGenOS in a Virtual Machine

A 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 vmwgfx driver with EDID support.
• Both hypervisors may log a cosmetic failed to create vmw_framebuffer: -22 message 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.

Project Structure

intergenos/
├── igos-build/          # Build system (Python — parser, graph, builder, tracker)
├── pkm/                 # Package manager (Python — install, remove, query, verify)
├── installer/           # Forge installer (Python — GUI + TUI + backend)
├── packages/            # 1,100+ package templates (YAML + build.sh)
│   ├── toolchain/       # LFS Ch. 5-7 cross-toolchain
│   ├── core/            # LFS Ch. 8 + TLS/PAM/SSH + Forge SB primitives
│   ├── base/            # End-user CLI tools
│   ├── desktop/         # GNOME desktop stack
│   ├── extra/           # User-facing applications
│   ├── compute/         # GPU compute platform (ROCm stack + SDKs)
│   └── ai/              # Local AI assistant stack
├── 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

Status

R001.x is the first public release line; the project is in active development. The current release is always stated at https://intergenos.org/news.html. Originally built 2015-2016 (build_001 through build_003 on GitHub). Revived March 2026.

Now: 1,100+ package templates across seven tiers (toolchain, core, base, desktop, extra, compute, ai). First successful GNOME 49.4 desktop boot on Wayland achieved April 7, 2026 — kernel 6.18.10 with config converged from 5-distro analysis. The installer (forge) handles partition → signed boot chain → image deploy → post-install hooks, and pkm ships as a system tool (/usr/bin/pkm) so package management works out of the box on an installed target.

Secure Boot validated on bare metal (first hardware, July 2026). The full signed chain — Microsoft-signed shim → MOK-signed GRUB → MOK-signed Unified Kernel Image → MODULE_SIG_FORCE=y modules — runs end-to-end under enforced Secure Boot, with per-machine Machine Owner Key enrollment through MokManager, after earlier end-to-end validation in a virtual machine. From R001.3, new installs encrypt the owner's kernel-signing key; kernel updates ask the owner's passphrase and refuse unattended signing, leaving the previous signed kernel bootable. Enforcement follows the firmware setting: with Secure Boot on and the per-machine key enrolled, the chain is enforced; with Secure Boot off, the same signed chain boots unenforced. A fresh install does not turn Secure Boot on for you.

NVIDIA proprietary driver packaged from the SHA-256-pinned upstream .run (open kernel modules rebuilt per machine, closed userspace repackaged). A hybrid Intel + NVIDIA laptop runs a discrete-GPU-accelerated GNOME Wayland desktop with multi-monitor output and the full EGL external-platform set; the kernel post-install hook chain — rebuild modules → MOK-sign → rebuild UKI → re-sign — is proven on hardware.

Install-integrity verification. A GPG-signed archive manifest is sealed into the squashfs at build time and verified offline by the installer before anything is written to disk.

Clean installs at scale. Multiple bare-metal installs validated with every package deploying, zero build failures, and zero failed systemd units — across current and legacy hardware, from recent 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.

Local assistant. InterGen ships with hardware-tiered local models — selected from discrete-GPU presence and VRAM, failing down to the entry tier when a card is absent or its VRAM cannot be read — and code-owned, permission-gated tool dispatch as the default posture: every tool call is gated, tool signatures are pinned against drift, and every invocation is logged.

Mirror and signing. The public binary mirror is live at repo.intergenos.org, serving package archives whose SHA-256 values are covered by a signed InterGenOS.db index; the archives are not individually signed. That is by design: the index signature covers every archive's SHA-256, pkm refuses any archive whose hash is not in the signed index, and the installation image carries its own signed archive manifest, so every archive is authenticated through one signature. The signing-key ceremony is complete (RSA-4096 master with hardware-token signing subkeys).

Test harness. over 600 tests in installer/tests/ covering installer backend, MOK validation, install-integrity, and Class 1 signing-chain verification, plus over 4,900 tests across the repo-level suites under tests/ (preflight, repo-publish, SBOM, upstream-check, download-sources, and more).

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.

Upcoming

Items actively in flight or planned post R001.4:

• Microsoft shim-review submission — obtaining an InterGenOS-owned MS-signed shim via the rhboot/shim-review sponsor track, so Secure Boot works out of the box without the first-boot MOK-enrollment step.
• OneDrive and Google Drive integration — built-in cloud-file access for users coming from Windows: connect a Microsoft or Google account through a guided graphical sign-in that is as easy as logging in on a phone, with files syncing to the local desktop — no command line, no config files.
• Switchable desktop environments — v1 ships GNOME on Wayland; KDE Plasma, XFCE, and other Wayland-capable desktops are planned as additional options, with the per-tier architecture already supporting the split.
• Automated CVE advisories — a pre-build scan now matches NVD, OSV, Debian security tracker and CISA KEV data against every shipped package at its pinned version before each build, and the per-package result is published with each release on the Updates page; a continuous advisory pipeline and prioritized package updates remain upcoming.
• Package-set expansion — new from-source packages planned for upcoming releases, including Qt6 and the KDE frameworks that underpin the switchable-desktop work above.

History

• 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.

Research

Every major decision is documented. See docs/research/ — over 180 markdown documents (plus supporting diagrams and data files) across more than 25 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

Acknowledgments

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.

Legal

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 1,100 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 (via InterGen)

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.

Author

InterGenJLU — InterGen Studios