# InterGenOS R001.1 — Release Notes **Released:** 2026-08-20 **Designation:** R001.1 — the first point 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.1 is a point release. Where R001 was produced by a complete from-source bootstrap from an empty build root, R001.1 was produced as a targeted rebuild against R001's proven substrate: every changed package recompiled with the full validation gate set enforced, then assembled, installed and evaluated on real hardware before publication. What triggers a complete from-source rebuild instead, and why point releases exist at all, is in `docs/release-policy.md` in the source repository. If you are already running R001, you do not need this image. `pkm upgrade` moves an installed system onto the same package set from the signed mirror. The image exists for new installations and for verifying what the release contains. --- ## Download | | | |---|---| | **Image** | [`intergenos-r001.1.iso`](https://repo.intergenos.org/iso/intergenos-r001.1.iso) | | **Size** | 10,414,972,928 bytes (9.70 GiB) | | **SHA-256** | `31b6e0a38ff74170a927413037e8b03b441e7178385d12ed8074c5041e0cd527` | | **Checksum file** | [`intergenos-r001.1.iso.sha256`](https://repo.intergenos.org/iso/intergenos-r001.1.iso.sha256) — signed, see [`.sha256.asc`](https://repo.intergenos.org/iso/intergenos-r001.1.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 R001.1 is signed by the same key as R001. The key is served from three places, and 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 this release's image checksum and 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.1.iso curl -O https://repo.intergenos.org/iso/intergenos-r001.1.iso.sha256 curl -O https://repo.intergenos.org/iso/intergenos-r001.1.iso.sha256.asc # 2a. Is the checksum file the project's? gpg --export 5597A3E0587B253006D0DD7B8C50826182083050 > release-key.gpg gpgv --keyring ./release-key.gpg \ intergenos-r001.1.iso.sha256.asc intergenos-r001.1.iso.sha256 # 2b. Is the image the one that checksum names? sha256sum -c intergenos-r001.1.iso.sha256 ``` Expect `Good signature from "InterGenOS Project Signing Key (primary)"` from the first command, and `intergenos-r001.1.iso: OK` from the second. 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 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. ### 4. Verify the signed release tag The source tree for this release is tagged `R001.1`, and the tag is signed: ```sh git clone https://github.com/InterGenJLU/intergenos.git cd intergenos git tag -v R001.1 ``` 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. 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. --- ## What is in this release Measured from the source tree this release was built from and from the signed mirror index generated 2026-08-20: | | Count | |---|---| | Package definitions in the source tree | 1,173 | | Packages that ship on the installation image | 861 | | Package definitions that resolve to mirror-only | 309 | | — of those, published in the signed mirror index | 283 | | — of those, build-stage intermediates that are never published | 26 | | Packages published in the signed mirror index | 1,125 | These figures count 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. Counted as sets: 861 shipping ship-names + 309 mirror-only ship-names + 3 toolchain definitions whose ship-name is claimed by another definition = 1,173. The 1,125 published packages are the 842 shipping packages that are published plus the 283 mirror-only ones. The 19 shipping packages that are not published are build intermediates, described under *Known limitations*. 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. --- ## What changed since R001 The full record is the `[R001.1]` section of `CHANGELOG.md` on `master` in the source repository, dated 2026-08-20. The shape of the release: **Nineteen new package recipes — the first package additions since R001.** Five ship on the installation image: automatic log rotation on every install (`logrotate`, ending unbounded log growth), USB device tooling (`usbutils`), NVMe drive management (`nvme-cli`), ethernet diagnostics (`ethtool`), and hybrid-graphics switching (`switcheroo-control`). Fourteen are published to the signed mirror and install on demand: the VPN client set — OpenVPN, OpenConnect and WireGuard tooling with their NetworkManager plugins — the container-tooling completion (`buildah`, `skopeo`, `docker-buildx`), and a network-diagnostics suite (`nmap`, `tcpdump`, `iperf3`, `mtr`, `socat`) with a meta-package that installs the set in one command. **Package lifecycle hooks.** The package manager runs a package's declared pre-remove hook before removal and its post-remove hook after removal completes, and lifecycle hooks now report what they actually did rather than only that they ran. **Discovered-name resolution.** When the first-boot welcomer's Network Discovery option is enabled, discovered `.local` hostnames also become resolvable, so a discovered machine can be reached by name and not only seen. **New fail-closed build-integrity gates.** An aspirational-reference check spanning services, autostart entries, documentation and package lifecycle hooks refuses a build where a referenced path is produced by nothing in the tree; a service-preset check refuses an artifact that contradicts the declared enablement policy; and a changelog-accumulation gate requires that a change to the shipped package set move this release record's source with it. **Service enablement has a single owner.** Recipes no longer enable their own units; the preset policy states the default for every service, and the preset engine resolves it — so what a service does on a fresh install is stated in one place, and an upgrade no longer re-applies that decision over a choice the user has since made. --- ## 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. 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 larger 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. - **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. --- ## 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. R001.1 supersedes R001 as the supported release. Nothing reaches the mirror or the installation image without a rebuild, an installation, and an evaluation on real hardware. --- ## Sources The mirror publishes 1,131 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,085 of the 1,125 published binaries have a source archive matching them by name and version. The remaining 40 are packages with no upstream source to publish — the project's own configuration, branding, font and theme packages, the meta-packages that install a set of other packages, and the helper recipes that fetch a proprietary application from its vendor at install time rather than building it. The corpus also contains 46 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.1.iso` | | Image checksum | `repo.intergenos.org/iso/intergenos-r001.1.iso.sha256` | | Signature over the image checksum | `repo.intergenos.org/iso/intergenos-r001.1.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.1` in the source repository | | Software bill of materials | `intergenos-r001.1.sbom.spdx.json` — SPDX 2.3, 861 shipped packages plus one entry for the image; 842 carry a SHA-256 and all 842 match the signed index | | Provenance index | `PROVENANCE-R001.1.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.