FAQ

Common questions about InterGenOS. Answers here describe what ships today, not what is planned. Where the answer differs for planned work, it says so explicitly.

What is InterGenOS?

InterGenOS is a Linux distribution built entirely from source, based on Linux From Scratch 13.0 and Beyond Linux From Scratch 13.0. Every package is compiled from source with deliberate choices. It ships a custom package manager (pkm), a from-source build system (igos-build), a native installer (Forge), a signed Secure Boot chain, and a tiered local AI assistant. The goal behind every default is a machine you understand, can modify, and can trust.

What does “security-only alignment” mean?

It is the project’s governing doctrine. Where a security control conflicts with convenience, security wins. The phrasing the project uses is direct: security is not first, it is only. In practice that means a fully signed boot chain (with optional Secure Boot enforcement), AppArmor profiles in enforce mode for system daemons, aggressive systemd sandboxing, localhost-only network binds by default, and zero telemetry. See Hardening Baseline and Threat Model & Security Philosophy for the full picture.

What version is this?

The current development line is 1.0-dev (build id v1.0-dev1). InterGenOS is in active development, pre-1.0. The package set, build tooling, and installer are functional; the public binary mirror’s first publish lands once the v1.0 archive set is complete.

What desktop does it use?

InterGenOS ships GNOME 49 on Wayland with a dark theme and InterGenOS branding. There is no Plymouth splash: you watch the kernel hand off to systemd and every service report [OK] or [FAILED] at boot. That visibility is deliberate. Spotting unusual boot output is a real practice for catching a compromise or a hardware change.

Switchable desktop environments such as KDE Plasma and others are on the roadmap. They are not shipped today.

How do I install software?

With pkm, the InterGenOS package manager. The common commands:

sudo pkm sync          # refresh the local index, verify its signature
pkm search audio       # search the local index (no network needed)
sudo pkm install htop  # download, verify, and install a package
sudo pkm upgrade       # install newer versions of installed packages
sudo pkm remove htop   # uninstall, and clean orphaned dependencies
pkm list installed     # list everything installed
pkm info openssh       # show metadata for a package
pkm verify openssl     # check installed files against recorded hashes

pkm also accepts familiar aliases from other distributions: update accepts sync/refresh, remove accepts uninstall, search accepts find, and so on. See The Transparent Package Manager for the full reference.

Does pkm phone home or auto-update?

pkm does not phone home, and it never installs or upgrades software on its own — your system changes only when you explicitly run pkm install, pkm upgrade, or pkm remove. There is no telemetry of any kind. It does ship one opt-out convenience: a daily timer that checks whether upgrades are available and shows a count (a GNOME tray indicator and a login message), installing nothing and reaching no further than the index you last synced. Turn it off with sudo systemctl disable --now pkm-check-updates.timer if you would rather it not run. The project’s phrasing is that silence is golden.

How is software trust verified?

pkm fetches the InterGenOS.db index from the official mirror and verifies its signature against a release-signing subkey — held on a hardware token and certified by the offline InterGenOS master key — whose fingerprints are pinned locally. When you install a package, its SHA-256 hash is checked against the verified index before extraction. A signature failure or hash mismatch is a hard rejection. The v1.0 release uses an index-only signature trust model.

What about proprietary software?

InterGenOS does not ship proprietary binaries in its archive set. Instead, you install them with the ordinary pkm install <name> command (e.g. pkm install vscode); pkm recognizes these as proprietary and routes to a small download-helper that fetches the payload from the vendor. The install stops for an explicit, interactive vendor-EULA acceptance the first time — you confirm a Continue? [y/N] prompt and then type I ACCEPT to proceed, and the acceptance is recorded so a later reinstall does not re-prompt. Helpers cover software such as Brave, Chrome, Edge, Spotify, Discord, VS Code, and Claude Code. The core operating system itself relies on open-source drivers and firmware; proprietary firmware blobs are available only when your hardware strictly requires them.

How many packages are there?

The package set is organized into six tiers and drifts as the system grows. As of June 2026 it is roughly 857 templates: toolchain (28), core (272), base (23), desktop (420), ai (2), and extra (112). Treat these as a live count rather than a fixed number; query your synced index for the current state.

What is InterGen?

InterGen is the onboard AI assistant: a tiered, hardware-detected, offline-first local assistant built on Qwen models with zero telemetry. At setup time it detects your CPU, RAM, and GPU, then selects a model and quantization appropriate to the machine, from a 4 GB laptop up to a GPU workstation. No cloud, no accounts, no round-trip latency. It is text-only by design.

Every tool call InterGen makes is treated as privileged. The default escalation mode requires user confirmation before any action that changes system state, tool signatures are pinned against drift across upgrades, and a separate audit log records every invocation. The assistant is a system component, not a hole in it.

What is InterGen Sentinel?

InterGen Sentinel is a pluggable security-scanner architecture. It routes MCP tool calls through a scanner of your choice before they execute. The default is local-only: Local-Rules (rule-based, deterministic) and Local-Qwen (your local Qwen model reviewing the call), both fully offline.

For richer review you can opt into any of six cloud providers: Claude (Anthropic), Gemini (Google), Copilot (Microsoft), ChatGPT (OpenAI), Grok (xAI), and DeepSeek. This escalation path is called Phone-A-Friend (Frontier/Cloud Escalation). It is entirely opt-in. You pick which scanner (if any) reaches across the network; everything else stays on the machine. Schema-pinning, audit logging, and sandbox enforcement are vendor-neutral local plumbing that apply regardless of which scanner is active.

How does Secure Boot work here?

The boot chain is fully signed: a Microsoft-signed shim to a signed GRUB to a signed kernel and Unified Kernel Image. Secure Boot enforcement is optional and off by default on the current fleet — the signatures are present and verifiable, ready to enforce on hardware where you enable Secure Boot and enroll your Machine Owner Key (MOK). The Forge installer generates that MOK per machine. Installed systems sign each kernel’s UKI with your machine’s local MOK at every kernel install or upgrade. The InterGenOS release-signing key never leaves a hardware token under project control; only your machine-local MOK signs the kernels you install. See Verified Boot & Secure Boot.

What integrity protections ship by default?

A signed Secure Boot chain, dm-verity integrity, and UKI signing. System daemons run under AppArmor in enforce mode and under extensive systemd isolation directives (NoNewPrivileges, ProtectSystem=strict, PrivateTmp, syscall filtering, and more). Server packages bind to localhost by default. No service ships with a blank or default password.

What hardware does it run on?

Bare-metal installs have been validated across widely varying hardware, from current laptops back to a roughly 2012 2nd/3rd-generation Intel Core i5, each through the full signed boot chain and the end-to-end ISO-installer path.

How is the OS built?

A single build runs 20 phases:

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

Publishing to the mirror is an optional follow-on step. The build can resume from any phase with --start-at and stop with --stop-after; checkpoints are saved after the toolchain, core, and desktop phases.

What is on the roadmap but not yet shipped?

Several items are in flight and not present in the current build: switchable desktop environments (KDE Plasma and others), the public binary mirror’s first publish, packaging pkm itself so it works out of the box on a fresh target, a higher AI tier for high-end hardware, and NVIDIA open-module packaging. Curated application campaigns (for example Kdenlive, OBS, Krita, Blender, FreeCAD, GnuCash, Boxes) are planned and not current. None of these are guaranteed in the current build.

Where can I learn more?

• The Transparent Package Manager
• Hardening Baseline
• FORGE Installation Guide
• Threat Model & Security Philosophy