Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

First Checks After Install

You just installed InterGenOS. Before you trust it with anything, make it prove itself — in about five minutes, with commands you can read.

This page is a ritual, not a reference. Run the checks in order, top to bottom, on your own machine, right after your first boot. Each one shows the exact command, what a healthy system prints, and what it means if you see something else. None of them change anything — they read state and report it. (A few need sudo to read privileged state.)

The companion page, Security Verification, is the per-claim reference — it explains the mechanism behind each guarantee. This page is the fast pass you run first. When a check here makes you want the “why,” that page has it.

A healthy fresh install passes every check below. If one does not match, that is a real signal worth chasing — see the “If you don’t see this” note on each, and Troubleshooting.

1. You are actually running InterGenOS

Start at the bottom: confirm the system identifies as what you installed.

$ cat /etc/os-release

You should see NAME="InterGenOS", ID=intergenos, and a VERSION_ID:

NAME="InterGenOS"
PRETTY_NAME="InterGenOS 1.0-dev (Revival)"
ID=intergenos
VERSION_ID=1.0

If you don’t see this: you are not booted into InterGenOS — you may have booted the installer ISO or another OS. Check your firmware boot order.

2. Every installed file matches the signed release

This is the headline check — the one that proves the files on your disk are exactly the files in the signed release, with nothing swapped, corrupted, or silently altered since install.

$ sudo pkm verify --all
Verified (strict): 831 ok, 0 with issues; 11 expected-absent (removed by post_install)

You should see every package ok with 0 issues. pkm recorded a SHA-256 for every file it installed and re-checks them here. The expected-absent entries are files a package’s own post-install step intentionally removed — pkm tracks them so they are never mistaken for tampering. The exact totals track your installed set (yours will differ from the numbers above; what matters is 0 with issues).

If you don’t see this: a non-zero “with issues” count means a tracked file changed. That can be a legitimate local edit to a config file — pkm verify will name the file, so you can tell. An unexplained binary mismatch is a real signal; do not ignore it.

3. Your software comes from a signed source

Updates should only ever come from a package index signed by the InterGenOS release key — a swapped or tampered mirror is rejected, not silently trusted.

$ sudo pkm sync
Hit:       intergenos-current   https://repo.intergenos.org/x86_64/current
Index:     InterGenOS.db
Signature: Good — InterGenOS release subkey ✓

You should see Signature: Good. When pkm fetches the index it verifies the signature against a release-key fingerprint pinned into pkm itself — so even a mirror that presents a different, valid-looking key is refused. On your machine the Signature line names the specific signing subkey by its short key id (shown generically above); you can confirm that key matches the published release key.

If you don’t see this: a signature failure means the index could not be trusted — pkm refuses it rather than installing from it. A persistent failure on the official mirror is worth reporting.

4. The kernel is locked down and enforcing

The running kernel should be in integrity lockdown, refuse unsigned modules, and carry the full security-module stack.

$ cat /sys/kernel/security/lockdown
none [integrity] confidentiality
$ cat /sys/module/module/parameters/sig_enforce
Y
$ cat /sys/kernel/security/lsm
lockdown,capability,yama,bpf,landlock,apparmor,ima,evm

You should see lockdown engaged at [integrity] (the brackets mark the active mode), sig_enforce = Y (unsigned kernel modules are rejected), and the LSM line listing lockdown, landlock, apparmor, ima, evm among others. Integrity lockdown is forced on by the InterGenOS kernel configuration regardless of Secure Boot state, so you see [integrity] here even on a fresh install with Secure Boot off (check 7).

If you don’t see this: [none] selected for lockdown, or sig_enforce = N, means the kernel is not enforcing its integrity guarantees — a significant deviation from a stock install.

5. Nothing failed to start

A clean boot leaves no failed services behind.

$ systemctl --failed
0 loaded units listed.

You should see an empty list — zero failed units.

If you don’t see this: each failed unit is named; systemctl status <unit> and journalctl -u <unit> tell you why. A failed security unit (firewall, auditing) matters more than a failed cosmetic one.

6. The firewall is closed by default

InterGenOS ships a default-deny firewall: inbound connections are dropped unless you open them. Nothing listens to the network on your behalf without you choosing it.

$ sudo nft list ruleset | grep 'hook input'
        type filter hook input priority filter; policy drop;

You should see the input chain with policy drop — the default is to reject inbound traffic. The shipped ruleset (/etc/nftables.conf, loaded by nftables.service at boot) permits only loopback, established/related replies, and the ICMP needed for the network to function; SSH and every other inbound port are closed until you open them yourself.

If you don’t see this: an empty result, or an input chain without policy drop, means the default-deny policy is not loaded — check systemctl status nftables. (The shipped ruleset also carries policy drop on the forward chain and policy accept on the output chain — outbound is allowed by design; the input line above is the one that matters here. If you changed the firewall, this reflects your change.)

7. Secure Boot — your state, and how to turn it on

This is the check most likely to surprise you, so read the result carefully.

$ mokutil --sb-state
SecureBoot disabled

You should see SecureBoot disabled on a fresh install — and that is expected, not a failure. InterGenOS provisions a fully signed boot chain (shim → GRUB → Unified Kernel Image) on every install, but ships Secure Boot enforcement off by default. Turning it on is a deliberate, one-time Machine Owner Key (MOK) enrollment you perform — so the key trusting your boot chain is yours, not a vendor’s. The full walkthrough is in Verified Boot & Secure Boot.

You can confirm the firmware’s own view, including TPM and measured-boot support:

$ bootctl status | head -8
systemd-boot not installed in ESP.
System:
      Firmware: UEFI ...
   Secure Boot: disabled
  TPM2 Support: yes
  Measured UKI: yes

bootctl reports systemd-boot not installed — that is correct. InterGenOS boots via shim → GRUB, not systemd-boot; the useful part here is the firmware System block (Secure Boot state, TPM2, Measured UKI).

After you enroll your MOK, mokutil --sb-state reports SecureBoot enabled and the chain is enforced. Re-run check 10 then.

8. Disk encryption — if you chose it at install

If you selected full-disk encryption in FORGE, your root filesystem sits on a LUKS2 volume that unlocks at boot.

$ sudo cryptsetup status root
/dev/mapper/root is active and is in use.
  type:    LUKS2
  cipher:  aes-xts-plain64

You should see LUKS2 and active (the mapper name may differ from root depending on your install).

If you don’t see this: is inactive (or no crypt device in lsblk) means this install is not encrypted — expected if you did not choose FDE. Encryption is an install-time choice; see Disk Encryption & LUKS to understand the trade-off.

9. Know your assistant’s state — and how to turn it off

The InterGen assistant is a per-user service. You should always be able to see whether it is running, and you are always in control of whether it runs at all.

$ systemctl --user is-active intergen.service
$ systemctl --user is-enabled intergen.service

You should see the state you chose at install: active / enabled if you opted the assistant in, or inactive / disabled if you did not. The assistant is local-only — it does not phone home — and it is yours to disable.

To turn it off (or constrain it): see Disabling & Constraining the Assistant, the authoritative procedure. You can stop it for this session, disable it from starting, or remove the package entirely.

10. Confirm the boot chain verified this boot (after enrollment)

This last check is for after you have enrolled your MOK and enabled Secure Boot (check 7). It is the difference between “Secure Boot is enabled” and “Secure Boot verified this exact boot and nothing failed.”

$ sudo journalctl -b | grep -iE 'secure boot|sb_verify|mok'

You should see the signature-verification events for the current boot with zero failures. With Secure Boot off (the default), this shows only Secure boot disabled and the firmware’s own certificate load — which is why this check belongs after enrollment.

If you don’t see this: verification failures in the log after you have enabled Secure Boot mean the enforced chain rejected something — stop and investigate before trusting the boot.

You’re done — and you didn’t take our word for any of it

If all the checks that apply to your install passed, you have personally confirmed: the files match the signed release, software comes from a signed source, the kernel is enforcing, the firewall is closed, your boot and encryption posture are what you intend, and your assistant is under your control. That is the whole point — a guarantee you can check is a property of your machine, not a promise from us.

Where to go next