veilor-org/veilor-os
1
0
Fork 0
Code Issues Pull requests 2 Projects Releases 1 Packages Wiki Activity Actions
veilor-os/bluebuild
History
veilor-org 7d2b94b5be feat(hardening): add memory-pressure tuning for zram-only stack 
veilor-os runs zram-only swap (THREAT-MODEL.md — no key leak from
disk swap). With kernel defaults that policy bites: once zram fills
there is no overflow tier, the kernel waits until total exhaustion
to trigger OOM, then picks a victim by oom_score and frequently
kills plasmashell or the foreground terminal instead of the leaking
browser tab. Mouse locks for minutes during the thrash window.

Three co-dependent layers:

1. systemd-oomd enabled — PSI-based pre-OOM killer fires at cgroup
   boundaries before the kernel reaper. Fedora's systemd-oomd-defaults
   ship sane thresholds for user.slice; installed in kickstart and
   layered in bluebuild containerfile, enabled in both unit-toggle
   blocks.

2. zram bumped 8 GiB lzo-rle (Fedora default) -> 16 GiB zstd. zstd
   gives ~3:1 (~48 GiB effective) at negligible CPU cost on any
   post-2018 x86_64. 8 GiB filled in practice on 32+ GiB laptops
   running Chromium + LSP + chat clients.

3. /etc/sysctl.d/95-memory-pressure.conf:
   - vm.swappiness=180 (zram is RAM-fast, swap early; default 60
     assumes HDD)
   - vm.watermark_scale_factor=125 (kswapd reclaim starts ~1.25%
     headroom vs default 0.1%; ~400 MiB head start on 32 GiB)
   - vm.page-cluster=0 (no read-ahead; pointless on RAM-backed swap,
     wastes decompress)

Without any one of the three the system still wedges briefly: oomd
without zram tuning waits for PSI to climb; zram tuning without oomd
gets victim selection wrong.

Verified by new test/boot-checklist.md "Memory pressure" section.
Inline rationale headers in both overlay files so the why survives
doc drift. Trigger event: onyx (Fedora 43, not veilor-os) thrashed
2026-05-11; same defaults shipped to veilor-os, fixed here too.
2026-05-12 10:17:00 +01:00
..
config/just v0.7 spike: BlueBuild recipe + ostreecontainer kickstart + cosign workflow 2026-05-05 15:30:04 +01:00
cosign.pub ci(bluebuild): add cosign keypair signing infra 2026-05-06 17:48:58 +01:00
README.md bluebuild: switch base to ghcr.io/secureblue/kinoite-main-hardened 2026-05-06 17:15:54 +01:00
recipe.yml feat(hardening): add memory-pressure tuning for zram-only stack 2026-05-12 10:17:00 +01:00

README.md

bluebuild/ — v0.7 spike

This directory contains the BlueBuild recipe + supporting config that builds the veilor-os bootable OCI image. Active on the v0.7-bluebuild-spike branch only. Does NOT land in v0.5.x main until the spike passes its success criteria (see docs/STRATEGY.md).

What's here

bluebuild/
├── recipe.yml                  # primary BlueBuild recipe
├── config/
│   └── just/
│       └── 60-veilor.just      # ujust recipes for opt-in components
└── README.md                   # this file

The recipe extends ghcr.io/secureblue/kinoite-main-hardened:latest. We inherit secureblue's hardening (sysctl + kargs + custom SELinux policy + USBGuard + hardened-malloc + Unbound DoT + chronyd NTS + Trivalent browser + cosign-signed image chain). On top, we layer:

  • veilor branding (overlay/, theme, plymouth, sddm, os-release)
  • mullvad-browser (anti-fingerprint companion to Trivalent)
  • xorg-x11-server-Xwayland (re-enable; secureblue disables it)
  • sudo (re-enable; secureblue replaces with run0)
  • tailscale + yggdrasil (mesh stack layer 1 + 2)
  • ujust recipes for Reticulum (mesh layer 3) + Thorium (opt-in browser)

Trivalent stays as the default browser (correcting an earlier draft).

Build locally

# Requires bluebuild CLI:
#   curl -fsSL https://raw.githubusercontent.com/blue-build/cli/main/install.sh | sh
cd bluebuild
bluebuild build recipe.yml

Output: localhost/veilor-os:43 in podman storage. Push to GHCR via the workflow.

Test the OCI image

# Smoke-test (boots into the rootfs; no kernel, no init):
podman run --rm -it ghcr.io/veilor-org/veilor-os:43 /bin/bash

# Inside, sanity:
cat /etc/os-release        # PRETTY_NAME=veilor-os
which sudo                 # /usr/bin/sudo (re-enabled)
which trivalent            # secureblue's COPR (default browser)
which mullvad-browser      # /usr/bin/mullvad-browser
systemctl is-enabled yggdrasil    # enabled (idle)
systemctl is-enabled tailscaled   # disabled (awaits ujust veilor-mesh-join)

Test the installer ISO

The installer ISO is built separately by livecd-creator (current path) or bootc-image-builder (v1.0+). Its kickstart's %packages block is replaced with:

ostreecontainer --url=ghcr.io/veilor-org/veilor-os:43 --transport=registry

That populates the target's / directly from this OCI image during the install pass. No first-boot rebase. No transition window.

Spike success criteria (1 day)

  • bluebuild build recipe.yml exits 0
  • bootc container lint exits 0 on the resulting image
  • podman run smoke-test (commands above) all pass
  • .github/workflows/build-bluebuild.yml builds + cosign-signs + pushes to ghcr.io/veilor-org/veilor-os:43
  • An installer ISO using ostreecontainer against this OCI reaches SDDM with admin login on first boot

If all five land, merge v0.7-bluebuild-spike → main as v0.7.0. If any fail in ways that aren't trivially fixable, file each as a GH issue + return to v0.5.x kickstart path.

See also