Service & Hardware Issues

This page covers problems that surface at the boundary between InterGenOS and your hardware: Secure Boot and kernel module signing, device drivers and firmware, and system services that fail to start or refuse to listen on the network. Many of the symptoms below are the system enforcing a control you can verify and, where appropriate, adjust. InterGenOS is built on a single doctrine: security is not first. It is only. When a security control conflicts with convenience, security wins.

For software-install and package problems, see Frequently Asked Questions. For a complete picture of what is enforced out of the box, read the Hardening Baseline overview.

Secure Boot and Kernel Modules

InterGenOS builds a signed boot chain: a Microsoft-signed shim validates the InterGenOS GRUB bootloader, which in turn verifies the Linux kernel and Unified Kernel Images (UKIs). Secure Boot enforcement is optional and off by default on the current fleet, so these signatures are present and verifiable but not firmware-enforced unless you enable it; with it enabled, unsigned kernel modules are not trusted.

A driver or out-of-tree kernel module will not load

Out-of-tree modules, including proprietary drivers, must be signed by a key the firmware trusts. InterGenOS uses a Machine Owner Key (MOK) for this. The Forge installer walks you through enrolling a MOK on your first boot. If you skipped MOK enrollment, an out-of-tree module is refused even though it is present on disk.

What to check:

Confirm Secure Boot is active and that your MOK was enrolled during first boot. If it was not, re-run the enrollment step described in Verified Boot & Secure Boot.
After a kernel install or upgrade, installed systems regenerate and sign each kernel’s UKI with your machine’s local MOK. The same boot-time signature verification applies to kernels you install after the original ISO image, so a freshly installed kernel that will not boot points to a MOK signing or enrollment problem rather than a corrupt kernel.

The InterGenOS release-signing key never leaves a hardware token under InterGenOS control. Only the MOK that Forge generates on your own machine signs the kernels you install. This is intentional: the keys that authorize your machine to boot belong to your machine.

The system will not boot after a kernel or bootloader change

Because the boot chain verifies each stage, a tampered or unsigned component halts the boot rather than running it. If a kernel installed or upgraded outside the normal package flow fails to boot, the most common cause is a missing or mismatched UKI signature. Re-installing the kernel through the package manager (pkm), so the UKI is regenerated and signed with your MOK, restores a valid signature.

Drivers and Firmware

The core operating system relies exclusively on open-source drivers and firmware. Proprietary blobs are available if your hardware strictly requires them, but they are never forced on you.

A device needs proprietary firmware

If a network card, GPU, or other device does not work with the open drivers that ship by default, your hardware may strictly require a proprietary firmware blob. These are available but are not installed automatically. Install the firmware your device needs, and if it ships as an out-of-tree kernel module, ensure your MOK is enrolled so the signed module can load (see the Secure Boot section above).

System Services

InterGenOS hardens system services aggressively to minimize the blast radius of a compromise. The same isolation that protects you can make a service look broken when it is in fact being confined exactly as configured.

A service starts but cannot reach a file, device, or directory

System daemons run under extensive systemd sandboxing. Baseline directives applied across system services include ProtectSystem=strict, ProtectHome=true, PrivateTmp=true, PrivateDevices=true, ProtectKernelTunables=true, ProtectKernelModules=true, NoNewPrivileges=true, and a restrictive SystemCallFilter. AppArmor profiles for system daemons ship in enforce mode by default, with a few profiles (currently intergen-mcp and pkm) intentionally shipped in complain mode and graduating to enforce as they mature.

If a service cannot read or write a path, open a device, or perform a syscall, the cause is usually one of these controls working as intended:

ProtectHome=true hides /home, so a daemon configured to read a file under a user’s home directory will not see it.
ProtectSystem=strict makes most of the filesystem read-only to the service.
PrivateDevices=true removes most device nodes from the service’s view.
AppArmor in enforce mode denies access outside the profile’s allowed paths.

What to check:

Inspect the service’s journal for the specific denial. AppArmor denials and systemd sandbox refusals are logged with the path or capability that was blocked.
Confirm whether the resource the service wants is one the security baseline deliberately withholds. If so, the correct fix is to adjust the service’s configuration or its profile, not to disable the protection wholesale.

This is a trade InterGenOS makes deliberately. When a security control conflicts with convenience, security wins.

A server is running but I cannot connect to it from another machine

Any server package shipped by InterGenOS binds exclusively to localhost (127.0.0.1) by default. Services never listen on a public interface unless you deliberately edit their configuration to allow it. A service that responds on the same machine but refuses connections from the network is behaving correctly.

To expose a service on the network, edit its configuration to bind to the appropriate interface, and understand that you are widening its exposure on purpose. Pair any such change with firewall rules you control.

A database or service reports no usable credentials

InterGenOS does not ship databases or services with blank or default admin passwords. Initial credentials are randomly generated or require manual setup during installation. If a service rejects a login you never explicitly set, you have likely hit this default. Set or retrieve the credential through the service’s documented setup path rather than assuming a well-known default exists.

A JIT workload fails with a memory-protection error

MemoryDenyWriteExecute=true is applied across system daemons. Workloads that require writable-then-executable memory, such as just-in-time compilation, are the exception. PostgreSQL is one such case: its LLVM JIT compiler emits machine code into writable-then-executable pages, so its shipped unit sets MemoryDenyWriteExecute=false to keep the JIT working. If a service that legitimately needs JIT fails with a memory-protection error, this directive is the cause, and the fix is a targeted exception for that service rather than removing the protection from every daemon.

Telemetry and Updates Are Not the Cause

When tracing unexpected behavior, two things you can rule out by design:

InterGenOS collects zero analytics, crash reports, or usage statistics. No background process is phoning home.
Software does not update behind your back. Updates happen only when you explicitly run pkm sync. A service whose behavior changed did not change on its own.

When the Control Is the Problem

Every default described here is verifiable and adjustable. The intent is a machine you understand, can modify, and can trust. If a hardened default genuinely blocks a workflow you need:

Confirm the control is the cause by reading the journal and AppArmor denials.
Make the narrowest possible change to the affected service or profile.
Avoid disabling a protection system-wide to fix one service.

InterGenOS Wiki