Power Management & Maintenance

This page covers keeping an InterGenOS machine healthy over its lifetime: applying updates, managing power and battery, watching disk and journal usage, and verifying that the signed boot chain and system image are still intact. The defaults described here follow the same principle as the rest of the system. Nothing happens behind your back; maintenance is a set of explicit, visible actions you take.

InterGenOS 1.0-dev (build id v1.0-dev1) ships GNOME 49 on Wayland, with systemd as the init system and service manager. The tooling below is standard systemd and InterGenOS pkm.

Updating the System

There are no automatic upgrades. Software changes only when you run the package manager yourself. This is deliberate: updates are a decision you make, not one made for you.

Updates flow through pkm, the InterGenOS package manager. Software is pulled from a signed binary mirror. Every sync verifies the index signature against a release-signing subkey (held on a hardware token and certified by the offline InterGenOS master key), and each package’s SHA-256 hash is validated locally before it is installed.

sudo pkm sync          # refresh and cryptographically verify the package index
sudo pkm upgrade --all # apply available upgrades for everything installed

pkm sync (also spelled pkm update) only refreshes the local copy of the signed index and verifies its signature; it changes nothing on disk. pkm upgrade is the command that actually installs newer versions — --all upgrades everything, or name specific packages. Your system stays exactly as you left it until you run pkm upgrade.

InterGenOS does ship one background package task: a daily timer that checks for available upgrades and shows a count (a GNOME tray indicator and a login message) but never installs anything. It is opt-out — sudo systemctl disable --now pkm-check-updates.timer. For the full pkm command surface and the notification details, see The Transparent Package Manager.

For the repository verification model behind these commands, see the security section.

Kernel updates and the boot chain

When you install or upgrade a kernel, the installed system regenerates and signs that kernel’s Unified Kernel Image (UKI) with your machine’s local Machine Owner Key (MOK). The same boot-time signature verification that protects the original ISO image therefore continues to apply to every kernel you install afterward. You do not need to re-run any signing step by hand; it happens as part of the kernel install or upgrade.

If your hardware needs out-of-tree modules (for example proprietary drivers), Forge walks you through MOK enrollment on first boot. See Filesystems, Kernel & Boot for the storage and boot-chain detail, and the Forge installer guide for enrollment.

Power Management

InterGenOS uses systemd for power state transitions. The standard commands apply:

systemctl poweroff     # shut down
systemctl reboot       # restart
systemctl suspend      # suspend to RAM
systemctl hibernate    # suspend to disk
systemctl hybrid-sleep # suspend to both RAM and disk

On the GNOME 49 desktop, power settings (screen blanking, automatic suspend, what the power button does, and battery behavior on laptops) are exposed through GNOME’s Settings under the Power section. These are user-facing preferences and do not change the system’s security posture.

Logind governs lid-switch, idle, and power-key behavior at the system level through /etc/systemd/logind.conf (and drop-ins under /etc/systemd/logind.conf.d/). After editing, apply with:

systemctl restart systemd-logind

Power profiles are managed by power-profiles-daemon, which is integrated with the GNOME power settings. You can switch and query profiles from the command line with powerprofilesctl. InterGenOS does not ship tlp or thermald; profile management goes through this single daemon.

Battery and thermal status

The kernel exposes battery and thermal information through sysfs, which you can read without additional tooling:

cat /sys/class/power_supply/BAT0/capacity   # battery charge percentage
cat /sys/class/power_supply/BAT0/status     # charging / discharging / full

The device name (BAT0, BAT1, and so on) depends on your hardware. List /sys/class/power_supply/ to see what your machine exposes.

Disk and Storage Maintenance

Keeping an eye on disk usage is the most common maintenance task. The standard tools apply:

df -h        # filesystem usage by mount point
du -sh <dir> # size of a directory tree

Journal management

systemd retains logs in the journal. Over time this can grow. Inspect and bound it with journalctl:

journalctl --disk-usage              # how much space the journal occupies
journalctl --vacuum-size=500M        # trim the journal down to 500 MB
journalctl --vacuum-time=2weeks      # drop entries older than two weeks

For reading logs day to day, see Users, Groups & Services.

Package cache

pkm keeps downloaded packages and verified hashes locally so installs are reproducible and verifiable. The cache lives under /var/cache/pkm, with subdirectories for the index database (db/), downloaded packages (packages/), in-progress downloads (partial/), and rollback data (rollback/).

Verifying System Integrity

InterGenOS boots through a signed chain: a Microsoft-signed shim validates the GRUB bootloader, which verifies the kernel’s Unified Kernel Image (UKI). On an installed system the UKI — kernel, command line, and initramfs — is MOK-signed and regenerated on every kernel install, so a tampered kernel cannot boot under your enrolled key; this runs automatically, you do not start it. (dm-verity additionally seals the read-only live ISO image, its root hash carried inside the signed UKI.) To check the installed files themselves, pkm verify --all re-validates every package’s SHA-256 on demand.

You can review what is enforced and how it is verified in the security section. To inspect the effective sandbox of any running service, use:

systemd-analyze security <unit>

The system collects zero telemetry, no analytics, and no crash or usage reports, so there are no background reporting services to find and stop as part of maintenance. The maintenance surface is intentionally small: update when you choose, watch disk and journal usage, and trust that the boot chain verifies itself.

On-Device Assistance

Two local, offline-first tools can help you administer and maintain the system:

InterGen is a tiered, hardware-detected local assistant built on Qwen models. It runs on-device with zero telemetry and selects a model tier appropriate to your hardware. When a query exceeds local capability, the optional Phone-A-Friend (Frontier/Cloud Escalation) path can hand off to a remote model, but only when you invoke it.
InterGen Sentinel is a pluggable security scanner. Its default backends are Local-Rules and Local-Qwen, both running on your machine. Six cloud providers are available strictly opt-in: Claude (Anthropic), Gemini (Google), Copilot (Microsoft), ChatGPT (OpenAI), Grok (xAI), and DeepSeek. Nothing leaves the machine unless you choose a cloud backend.

See the assistant documentation for configuration.

InterGenOS Wiki