# InterGenOS R001 — Release Notes **Released:** 2026-08-16 **Designation:** R001 — the first public release, and the first major release of the InterGenOS release line. InterGenOS is a from-source Linux distribution built on the Linux From Scratch and Beyond Linux From Scratch method. Every package in the system is compiled from upstream source by the project's own build pipeline; nothing is repackaged from another distribution's binaries. R001 was produced by a complete from-source bootstrap — every package rebuilt from an empty build root with the full validation gate set enforced — and installed and evaluated on real hardware before publication. --- ## Download | | | |---|---| | **Image** | [`intergenos-r001.iso`](https://repo.intergenos.org/iso/intergenos-r001.iso) | | **Size** | 10,411,311,104 bytes (9.70 GiB) | | **SHA-256** | `1beeb90539bc1031ad135148f379e97a1830b835350f9c7924fd7b9fc3db07c7` | | **Checksum file** | [`intergenos-r001.iso.sha256`](https://repo.intergenos.org/iso/intergenos-r001.iso.sha256) — signed, see [`.sha256.asc`](https://repo.intergenos.org/iso/intergenos-r001.iso.sha256.asc) | | **Architecture** | x86_64 | | **Boot mode** | UEFI only — there is no legacy BIOS fallback | | **Image type** | Live ISO with a graphical installer | The package mirror for this release is `https://repo.intergenos.org/x86_64/current/`. Its index is signed; see *Verifying this release* below. --- ## Verifying this release Four things can be verified independently, and none of them requires trusting this document. Do them in this order: the key first, then everything the key attests. ### 1. Get the release public key The same key is served from three places. Fetching from more than one and comparing the fingerprint is stronger than fetching from any single one: ```sh # From the project mirror curl -O https://repo.intergenos.org/keys/intergenos-release-key.asc gpg --import intergenos-release-key.asc # Or from keys.openpgp.org gpg --keyserver keys.openpgp.org \ --recv-keys 5597A3E0587B253006D0DD7B8C50826182083050 # Or from keyserver.ubuntu.com gpg --keyserver keyserver.ubuntu.com \ --recv-keys 5597A3E0587B253006D0DD7B8C50826182083050 ``` **The fingerprint to check is the primary key's:** ``` 5597 A3E0 587B 2530 06D0 DD7B 8C50 8261 8208 3050 ``` That primary key carries several signing subkeys. The subkey that signed the R001 tag and the package index is: ``` D7AA 641D 81AC D690 C5AD 865E 7276 E14D D888 6BFE ``` Both fingerprints are correct, and they are not interchangeable. Certify and compare the **primary** fingerprint — a subkey fingerprint is what your tools report as "using RSA key …" when they check a signature, and it changes when a subkey is rotated. Confirm what you imported with: ```sh gpg --list-keys --with-subkey-fingerprint 5597A3E0587B253006D0DD7B8C50826182083050 ``` ### 2. Verify the ISO checksum The checksum file is signed, so check the signature before you trust the checksum. Verify in that order — signature first, then the image against the checksum it attests: ```sh curl -O https://repo.intergenos.org/iso/intergenos-r001.iso curl -O https://repo.intergenos.org/iso/intergenos-r001.iso.sha256 curl -O https://repo.intergenos.org/iso/intergenos-r001.iso.sha256.asc # 2a. Is the checksum file the project's? gpg --export 5597A3E0587B253006D0DD7B8C50826182083050 > release-key.gpg gpgv --keyring ./release-key.gpg \ intergenos-r001.iso.sha256.asc intergenos-r001.iso.sha256 # 2b. Is the image the one that checksum names? sha256sum -c intergenos-r001.iso.sha256 ``` Expect `Good signature from "InterGenOS Project Signing Key (primary)"` from the first command, and `intergenos-r001.iso: OK` from the second. The signature is a detached armored signature made by the signing subkey `D7AA641D…`, the same subkey that signs the release tag and the package index; the key you compared in step 1 is what verifies it. Signing the image checksum is the project's standing practice for every release, not a one-time measure for this one. Doing both halves matters, and each answers a different question. The signature proves the checksum file is the project's and has not been altered in transit or on the mirror. It does not, by itself, say anything about the file sitting on your disk — hashing the image against that checksum is your step, and it is the one that catches a truncated download or a substituted image. If you write the image to a USB stick, verify the stick after writing rather than trusting that the write command exited successfully: read back exactly the image's byte count from the device and hash that. ### 3. Verify the signed release tag The source tree for this release is tagged `R001`, and the tag is signed: ```sh git clone https://github.com/InterGenJLU/intergenos.git cd intergenos git tag -v R001 ``` Expect `Good signature from "InterGenOS Project Signing Key (primary)"`. Git reports the signing subkey `D7AA641D…`; the primary key it belongs to is `5597A3E0…`, which is the one you compared in step 1. **A note on what the tag covers.** The `R001` tag names the initial public source import commit. Two additional commits on `master` — the README download block and the release-policy document — sit outside the tag. That is expected: the tag marks the source state the release was built from, and this document is the canonical pointer to the image, its checksum, and the key. If you fetch the tag alone and find no download information in the tree at that commit, nothing is wrong; the download information is here and in the repository README on `master`. Until GnuPG is told you trust this key, it also prints: ``` WARNING: This key is not certified with a trusted signature! ``` That warning is about *your* trust decision, not about the signature. It means the signature is cryptographically good and you have not yet certified that the key belongs to whom you believe it does. Comparing the primary fingerprint against more than one independent source, as in step 1, is how you settle that. ### 4. Verify the signed package index The mirror's package index is a signed manifest of the whole repository. The signature covers the entire index, so one verification covers every package listed in it: ```sh curl -O https://repo.intergenos.org/x86_64/current/InterGenOS.db curl -O https://repo.intergenos.org/x86_64/current/InterGenOS.db.sig gpg --export 5597A3E0587B253006D0DD7B8C50826182083050 > release-key.gpg gpgv --keyring ./release-key.gpg InterGenOS.db.sig InterGenOS.db ``` Expect `Good signature`. Use `gpgv` rather than `gpg --verify` here: `gpgv` checks the signature against exactly the keyring you name and nothing else, which is what you want when the question is "was this file signed by that key." The index is gzip-compressed JSON. Every package entry in it carries a `sha256` of that package's archive, so the one index signature transitively attests every published package's bytes: ```sh gzip -dc InterGenOS.db | python3 -m json.tool | head -40 ``` --- ## What is in this release Measured from the tagged source tree (`packages/` tree object `137deb9f42fbb9951b9848ae22598aee08dc5f92`) and from the signed mirror index generated 2026-08-17: | | Count | |---|---| | Package definitions in the source tree | 1,153 | | Packages that ship on the installation image | 856 | | Package definitions that resolve to mirror-only | 294 | | — of those, published in the signed mirror index | 268 | | — of those, build-stage intermediates that are never published | 26 | | Packages published in the signed mirror index | 1,105 | Those figures are counts of different things, so they do not subtract into each other, and it is worth saying why rather than leaving a reader to find the discrepancy. The 1,153 source-tree definitions divide into 840 that ship, 294 that are mirror-only, and 19 early-bootstrap variants that build a package a second time under a `-core` name and ship no archive of their own. The shipped total is 856 rather than 840 because sixteen packages built during the earliest bootstrap stage — `binutils`, `gcc`, `coreutils`, `util-linux` and similar — ship under a name that has no separate definition directory of its own. The 1,105 published packages are the 837 shipped packages that are published plus the 268 mirror-only ones. The build proceeds in tiers, in this order: `toolchain`, `core`, `base`, `kernel`, `desktop`, `extra`, `compute`, `ai`. A tier's default decides whether its packages ship on the image or are mirror-only, and individual packages override that default in either direction — so the tier is the rule, not the shipped reality. The `compute` tier, which holds the GPU compute stack, is mirror-only in full. **The desktop** is GNOME 49.4 on Wayland with the InterGenOS shell theme. **The boot chain** is signed end to end: shim → GRUB → unified kernel image, with a dm-verity root hash sealed into the signed UKI on the live image. Secure Boot is supported through a one-time machine-owner-key enrollment at first boot; the ISO boots with Secure Boot disabled as well. **The package manager** is `pkm`, which installs from the signed mirror index and verifies package checksums against it. It can also fetch a small set of proprietary applications directly from their vendors, transparently and on request. **The local AI assistant** is InterGen. It runs entirely offline and selects a model tier from the graphics hardware it finds: | Detected hardware | Tier served | |---|---| | No discrete GPU | A 2-billion-parameter model — the CPU-friendly floor | | Discrete GPU, VRAM at or above roughly 7 GB | A 9-billion-parameter model | | Discrete GPU, VRAM at or above roughly 22 GB | A 35-billion-parameter mixture-of-experts model | | Discrete GPU with smaller or unreadable VRAM | The 2-billion-parameter tier — detection fails down, never up | Tier selection reads discrete-GPU presence and VRAM only; 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. Every tier is multimodal, and a tier whose vision projector is not pinned in the signed model manifest is refused rather than served without vision. --- ## Installing Boot the image and choose **Install InterGenOS (Graphical)** from the boot menu. The installer writes nothing to disk until you confirm on its review screen. **On real hardware:** write the ISO to a USB stick of at least 16 GB. Confirm you have the right device before writing, and verify the stick by reading it back afterwards. **In a virtual machine:** enable EFI firmware — InterGenOS is UEFI-only. Allocate 8 GB of memory, 4 processor cores, and a disk of 35 GB or larger for a representative evaluation — the installer refuses a target disk smaller than 32 GiB. The system boots with as little as 4 GB and 2 cores, but the desktop and the assistant are noticeably slow at that floor. Full installations are verified on VirtualBox 7.x and VMware Workstation Pro. Do not install VirtualBox Guest Additions: the kernel is locked down and rejects unsigned out-of-tree modules by design. On VMware, use the distribution's `open-vm-tools` package rather than the bundled VMware Tools. In a virtual machine the assistant runs its 2-billion-parameter tier. The 9B and 35B tiers need a discrete GPU passed through to the guest, which most virtual-machine setups do not provide, so a VM exercises the entry tier regardless of how much memory it is given. --- ## Known limitations These are stated so you meet them here rather than in the middle of an install. - **Nineteen components on the image have no published binary archive.** They are build-stage intermediates — names ending in `-pass1`, `-pass2`, or `-bootstrap`, such as `systemd-pass2` and `linux-kernel-pass2` — that exist because the from-source bootstrap builds certain packages more than once, at different stages, with different capabilities available. Their files are on the image and they are listed in the software bill of materials for this release, but the mirror deliberately does not publish build intermediates, so those nineteen entries carry no downloadable binary archive and no index checksum. Every other shipped package is published and covered by the index signature. **Their source is published.** Eighteen of the nineteen have their own source archive on the mirror under `sources/`. The nineteenth, `glib2-bootstrap`, builds from exactly the same upstream tarball as `glib2` — both recipes pin `glib-2.88.1.tar.xz` at sha256 `51ab804c56f6eab3e5045c774d1290ac5e4c923d4f9a3d8e33123bee45c1840e` — and that tarball is published inside `glib2-2.88.1-1.igos.src.tar.gz`. So the source for every shipped component is obtainable, even where the built binary is not separately published. - **The `compute` tier is mirror-only in full.** The GPU compute stack is not on the installation image; install it from the mirror after installation. - **Source archives on the mirror are not covered by the index signature.** The signed index attests binary package archives. The corresponding source archives are published alongside them and are byte-reproducible, but verifying them is a checksum comparison against the source archive's own bundled per-file hashes rather than a signature check. - **Virtual machines may log a cosmetic display message.** Both VirtualBox and VMware can log `failed to create vmw_framebuffer: -22` in the live session. The display works normally. - **On high-DPI hosts under VirtualBox**, set the display resolution manually after first boot. - **There is no changelog for R001.** It is the first public release, so there is no previous release to describe changes against. Releases after this one carry one. --- ## Support model InterGenOS is a curated rolling distribution with a single supported line. The latest release is the supported release; installed systems move forward with `pkm upgrade` from the mirror, and installation images are refreshed at each point release. There are no maintenance branches and no backports — fixes reach users by advancing the supported line, so every user runs the package set the project actually evaluates. Nothing reaches the mirror or the installation image without a rebuild, an installation, and an evaluation on real hardware. The full policy, including what triggers a complete from-source rebuild, is in `docs/release-policy.md` in the source repository. --- ## Sources The mirror publishes 1,126 source archives under `https://repo.intergenos.org/x86_64/current/sources/`, and the publish pipeline refuses to publish a binary whose source archive is not staged alongside it — unless that package declares no upstream source at all. Counted against the signed index: 1,066 of the 1,105 published binaries have a source archive matching them by name and version. The remaining 39 are packages with no upstream source to publish — the project's own configuration, branding, font and theme packages, and the helper recipes that fetch a proprietary application from its vendor at install time rather than building it. The corpus also contains 60 source archives with no corresponding published binary: those are the build-stage intermediates described under *Known limitations*, whose source is published even though their built binary is not. Source archives are byte-reproducible: regenerating one from the same inputs produces an identical file. The build system that produced this release is in the source repository, along with the recipe for every package. Reproduction instructions are in `SOURCES.md`. --- ## Verification artifacts published with this release | Artifact | Location | |---|---| | Installation image | `repo.intergenos.org/iso/intergenos-r001.iso` | | Image checksum | `repo.intergenos.org/iso/intergenos-r001.iso.sha256` | | Signature over the image checksum | `repo.intergenos.org/iso/intergenos-r001.iso.sha256.asc` | | Release public key | `repo.intergenos.org/keys/intergenos-release-key.asc` | | Signed package index | `repo.intergenos.org/x86_64/current/InterGenOS.db` + `.sig` | | Signed source tag | `R001` in the source repository | | Software bill of materials | `intergenos-r001.sbom.spdx.json` — SPDX 2.3, 856 shipped packages, 837 carrying a SHA-256 that matches the signed index | | Provenance index | `PROVENANCE-R001.md` | --- ## Legal InterGenOS is assembled from software under many licenses. The bill of materials lists the license declared by each shipped package. The project's own code is licensed as stated in the source repository. Proprietary applications that `pkm` can fetch are downloaded from their vendors under those vendors' terms and are not redistributed by this project.