# InterGenOS R001.2 — Release Notes **Released:** 2026-09-03 **Designation:** R001.2 — the second 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.2 is a point release. Where R001 was produced by a complete from-source bootstrap from an empty build root, R001.2 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 or R001.1, 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.2.iso`](https://repo.intergenos.org/iso/intergenos-r001.2.iso) | | **Size** | 10,431,324,160 bytes (9.71 GiB) | | **SHA-256** | `37b0d8fe4a48e56a6c6a4182d1f9a812cb123ed03ae5dfe934f3676f2d6fa6ff` | | **Checksum file** | [`intergenos-r001.2.iso.sha256`](https://repo.intergenos.org/iso/intergenos-r001.2.iso.sha256) — signed, see [`.sha256.asc`](https://repo.intergenos.org/iso/intergenos-r001.2.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.2 is signed by the same key as R001 and R001.1. 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.2.iso curl -O https://repo.intergenos.org/iso/intergenos-r001.2.iso.sha256 curl -O https://repo.intergenos.org/iso/intergenos-r001.2.iso.sha256.asc # 2a. Is the checksum file the project's? gpg --export 5597A3E0587B253006D0DD7B8C50826182083050 > release-key.gpg gpgv --keyring ./release-key.gpg \ intergenos-r001.2.iso.sha256.asc intergenos-r001.2.iso.sha256 # 2b. Is the image the one that checksum names? sha256sum -c intergenos-r001.2.iso.sha256 ``` Expect `Good signature from "InterGenOS Project Signing Key (primary)"` from the first command, and `intergenos-r001.2.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.2`, and the tag is signed: ```sh git clone https://github.com/InterGenJLU/intergenos.git cd intergenos git tag -v R001.2 ``` 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-09-03: | | Count | |---|---| | Package definitions in the source tree | 1,174 | | Packages that ship on the installation image | 862 | | Package definitions that resolve to mirror-only | 312 | | — of those, published in the signed mirror index | 283 | | — of those, build-stage intermediates that are never published | 29 | | Packages published in the signed mirror index | 1,126 | 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: 862 shipping packages + 312 mirror-only definitions = 1,174; since R001.1 the three toolchain definitions that shared a ship-name with another definition carry their own names, so every definition now counts once. The 1,126 published packages are the 843 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`, `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.1 The full record is the `[R001.2]` section of `CHANGELOG.md` on `master` in the source repository, dated 2026-09-03. The shape of the release: **The first-boot path on NVIDIA machines works end to end.** The first-boot greeter installs the vendor driver, asks for a reboot, and now comes back after that reboot so the assistant can be set up; before, it crashed before it had a window and recorded the crash as the person having finished. The CUDA toolkit — fetched from NVIDIA by its own installer package after the license is accepted — is now downloaded when the CUDA engine is installed, its 32-bit objects are tracked, and a failed download makes the command fail. Upgrading that installer package no longer deletes the toolkit it installed: an upgrade keeps the application and its record in place and replaces only the script. **A fresh installation passes `pkm verify`.** The package manager no longer deletes the compiled Python files a package ships on upgrade, three systemd slice units whose file names contain a backslash are recorded and read cleanly, upgrade rollback copies are actually kept, an abandoned upgrade is reported with a non-zero exit, a second package-manager operation waits for the first instead of failing, and `pkm --root DIR install` puts a package into a directory instead of into this system. **The assistant does what it was asked.** An explicit web-search request runs the search and looks up the subject of the sentence; a request that asks for two things is handled as two things; a refused action is reported in the tool's own words; a remembered fact is answered from the stored fact; `don't forget X` keeps X; an invented command never reaches the person; credentials typed into a command are redacted from the assistant's records; the wiki index finishes building; and `intergen --version` prints the version and, where a Qwen-family model is installed, the model attribution. **A graphics card waking up no longer rebuilds the desktop.** On a machine whose second card serves compute work and drives no display, each wake was announced as a display hotplug and the desktop was rebuilt. The kernel now reports only a real connector change, the compositor retries a refused reopen, and the assistant daemon holds its serving card awake while a model is loaded on it. An ASUS laptop keyboard also keeps its driver, through a backported upstream fix. **One new package recipe — `gst-plugin-gtk4`,** the GTK4 video sink the camera application's live preview requires; the camera application now declares the dependency. MariaDB gains NUMA memory placement and PostgreSQL gains PL/Tcl and io_uring asynchronous I/O in their next builds; the plain-named `iptables` commands use the nftables backend the shipped kernel supports. **Release tooling requires a sealed, green installed-system gate record.** An opt-in tier of installed-system checks is now part of the tree, and the image builder, mirror publisher and promotion path refuse to run without a record of that tier passing on a real installation, signed by the release key. This release is the first produced under that requirement. **The shipped release identity states R001.2** in `/etc/os-release` and the related files. Systems installed from the R001.2 images minted on 2026-09-02, before the identity fix, report R001.1 until they upgrade the base system files package. --- ## 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 are listed under *Known limits in R001.2* 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. - **Two shipped packages are already newer on the mirror than on the image.** The package manager (`pkm`) and the installer (`forge`) were republished after the image was assembled, to carry the fix that keeps a download-helper's application through an upgrade. A fresh installation picks the newer releases up with its first `pkm upgrade`; run that before installing the CUDA toolkit. - **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.2 supersedes R001.1 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,134 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,086 of the 1,126 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 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.2.iso` | | Image checksum | `repo.intergenos.org/iso/intergenos-r001.2.iso.sha256` | | Signature over the image checksum | `repo.intergenos.org/iso/intergenos-r001.2.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.2` in the source repository | | Software bill of materials | `intergenos-r001.2.sbom.spdx.json` — SPDX 2.3, 862 shipped packages plus one entry for the image; all 862 carry a SHA-256; of the 843 that the signed index lists, 841 match it and 2 (`pkm`, `forge`) are the pre-republish releases described under *Known limitations* | | Provenance index | `PROVENANCE-R001.2.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.