# InterGenOS R001.3 — Release Notes **Released:** 2026-10-18 **Designation:** R001.3 — the third 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.3 is a point release. Where R001 was produced by a complete from-source bootstrap from an empty build root, R001.3 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. This cycle reached the release policy's drift limit, which calls for a major release; R001.3 ships as a point release by a one-time exception, and the complete from-source rebuild follows as the next major release. What triggers a complete rebuild, and why point releases exist at all, is in `docs/release-policy.md` in the source repository. If you are already running R001, R001.1 or R001.2, 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.3.iso`](https://repo.intergenos.org/iso/intergenos-r001.3.iso) | | **Size** | 10,487,570,432 bytes (9.77 GiB) | | **SHA-256** | `098c8747deedc14c7d844b8047cfa239c655381b1614c950e3a676dcae53f256` | | **Checksum file** | [`intergenos-r001.3.iso.sha256`](https://repo.intergenos.org/iso/intergenos-r001.3.iso.sha256) — signed, see [`.sha256.asc`](https://repo.intergenos.org/iso/intergenos-r001.3.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.3 is signed by the same key as R001, R001.1 and R001.2. 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, package index and source tag 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.3.iso curl -O https://repo.intergenos.org/iso/intergenos-r001.3.iso.sha256 curl -O https://repo.intergenos.org/iso/intergenos-r001.3.iso.sha256.asc # 2a. Is the checksum file the project's? gpg --export 5597A3E0587B253006D0DD7B8C50826182083050 > release-key.gpg gpgv --keyring ./release-key.gpg \ intergenos-r001.3.iso.sha256.asc intergenos-r001.3.iso.sha256 # 2b. Is the image the one that checksum names? sha256sum -c intergenos-r001.3.iso.sha256 ``` Expect `Good signature from "InterGenOS Project Signing Key (primary)"` from the first command, and `intergenos-r001.3.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. New in this release: an entry whose package declares an upstream source also carries `source_sha256`, the digest of the corresponding source archive published beside the binaries — so the same signature now attests the source archive of every such package (1,104 of the 1,146 entries; the other 42 declare no upstream source). ### 4. Verify the signed release tag The source tree for this release is tagged `R001.3`, and the tag is signed: ```sh git clone https://github.com/InterGenJLU/intergenos.git cd intergenos git tag -v R001.3 ``` 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-10-18T22:27:31Z: | | Count | |---|---| | Package definitions in the source tree | 1,194 | | Packages that ship on the installation image | 873 | | Package definitions that resolve to mirror-only | 321 | | — of those, published in the signed mirror index | 292 | | — of those, build-stage intermediates that are never published | 29 | | Packages published in the signed mirror index | 1,146 | 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: 873 shipping packages + 321 mirror-only definitions = 1,194, every definition counted once under its own name. The 1,146 published packages are the 854 shipping packages that are published plus the 292 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`, `desktop`, `extra`, `compute`, `ai`; the kernel is built in `core`. 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.2 The full record is the `[R001.3]` section of `CHANGELOG.md` on `master` in the source repository, dated 2026-10-18; its summary runs by subsystem and is written from the release note each changed package's recipe carries. The shape of the release: **The three issues published on 14 September are closed.** The browser chat answers questions that need the language model again; the release identity files agree, held to one declared release by a build gate; and `pkm restart-services --all` restarts only the running services of packages changed since this boot, never the units that carry your login session, and names a package that needs a reboot instead. **The kernel moves to Linux 6.18.51**, the current 6.18 long-term release, which carries upstream the fixes the kernel recipes had carried as local patches, among them the known-exploited local flaw CVE-2026-53362. gzip, GNU inetutils, Go, Linux-PAM, GNU sed, ncurses and WebKitGTK are updated, and a shipped sysctl drop-in sets the kernel's hardening floor. **Signing is in the machine owner's hands.** New installations encrypt the owner's kernel-signing key; a kernel or driver update asks its passphrase once and refuses to sign unattended, keeping the previous signed kernel bootable. A driver install holds the one passphrase for its module signings and the boot image; a refused signing leaves the package marked unfinished and names the exact `pkm reinstall` that finishes it. Every EFI install builds and signs its boot image after the package phase and refuses to finish unless the image verifies. **The installer, after the real-hardware evaluations.** An encrypted install offers a recovery key and shows it once at the end; every install ends with a restore point; root is no longer left locked after installation; the install record never keeps a password hash or any credential-shaped value; and the live medium's init links every command its first boot runs. **The package manager** upgrades from a local archive under the same trust gate as a named install, keeps a rollback copy that is the release it claims to be, repairs an older recorded version that carried its own release so a newer build of the same version is no longer refused as a downgrade, names archive members by the path they land at, and exits non-zero where it used to report success it could not prove. **The assistant** asks before anything is sent to a frontier model and cannot send until you confirm you have read the content; turns end cleanly in the web chat; a message that forbids tools gets none; it serves from exactly one graphics card and measures that card when deciding whether a model fits; its panel is served on the loopback address only; and privileged actions are refused where a path passes through a link root does not own. **Desktop and hardware.** Current scanners and IPP-over-USB printers work without a vendor driver; a Bluetooth headset can use aptX, LDAC or LC3; an attached iPhone or iPad can be mounted and paired; mpv and Celluloid decode on the graphics card's video engine where the driver supports it; a kernel panic leaves a record the next boot can read; and the daemons that would offer this machine to the network ship off and follow the Welcomer's switches. **GPU compute.** The ROCm stack builds for six architectures (gfx1030, gfx1100, gfx1101, gfx1102, gfx1200, gfx1201), its tools work by name, and both inference engines record the architectures they were built for and check the libraries they link. **Supply chain.** The signed repository index records each package's corresponding source archive by name and SHA-256; a resumed build produces the packages a from-scratch build does, because optional features a populated build root would detect on its own are stated explicitly in the recipes concerned; and the project's own text spells "license" one way throughout. **The known limits of this release**, including the five the real-hardware evaluations added, are listed under *Known limits in R001.3* in `CHANGELOG.md`. --- ## 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. The assistant's own known limits for this release, and the five limits the real-hardware evaluations added, are listed under *Known limits in R001.3* in `CHANGELOG.md`. - **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. - **Twenty packages on the mirror keep their R001.2 version and release with different bytes.** They were rebuilt in this cycle with their recipe version and release unchanged: for fourteen the installed files are identical to the R001.2 archive and only the build date in the archive's metadata differs; for five (`caddy`, `etcd`, `ibus`, `mingw-w64-winpthreads`, `wxwidgets`) binaries were rebuilt from the same pinned sources; and `unsloth` moves from 2026.7.4 to 2026.6.2, the newest release its upstream publishes as a source tarball, so that the package can be rebuilt from its declared source. A signed corrective record names every one of the twenty with the served and the replacement digests and travels with the mirror's transparency log. An R001.2 system keeps its installed copies — `pkm upgrade` moves a package only to a newer version or release, and there is nothing in these twenty that it needs — and `pkm reinstall ` fetches the current bytes if you want them; an installed `unsloth` 2026.7.4 stays, reported as newer than the index. - **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 are attested through the index, one level removed.** The signed index records the digest of each published package's source archive, so verifying a source archive is a checksum comparison against the signed index row rather than a signature check on the archive itself; the 48 source archives that belong to build intermediates and toolchain staging definitions have no index row and are not covered. - **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.3 supersedes R001.2 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,152 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,104 of the 1,146 published binaries have a source archive matching them by name, version and release, and the index carries each one's digest. The remaining 42 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 publisher prints every one of them by name. The corpus also contains 48 source archives with no corresponding published binary: the build-stage intermediates described under *Known limitations* and the toolchain's staging definitions, 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.3.iso` | | Image checksum | `repo.intergenos.org/iso/intergenos-r001.3.iso.sha256` | | Signature over the image checksum | `repo.intergenos.org/iso/intergenos-r001.3.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.3` in the source repository | | Software bill of materials | `intergenos-r001.3.sbom.spdx.json` — SPDX 2.3, 873 shipped packages plus one entry for the image; all 873 carry a SHA-256; of the 854 that the signed index lists, 854 match it | | Published advisories at shipped versions | `advisories-r001-3.html` — the per-package list from this release's pre-build scan, with each advisory's severity — served beside this image and published at https://intergenos.org/advisories/r001-3.html | | Provenance index | `PROVENANCE-R001.3.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.