Gentoo Server Setup: From Installation to Production

Understanding Gentoo for Server Environments

Gentoo Linux is a source-based, highly configurable Linux distribution that gives administrators absolute control over every compiled binary on the system. Unlike binary distributions such as Ubuntu or CentOS, where packages arrive pre-compiled with generic optimizations, Gentoo compiles every package from source using user-defined compiler flags (USE flags, CFLAGS, and more). For server environments, this means you can strip away unnecessary features, reduce attack surfaces, and build binaries optimized precisely for your CPU architecture — resulting in leaner, faster, and more secure production systems.

The core of Gentoo's flexibility lies in its package manager, Portage, which combines the precision of a BSD ports tree with the dependency resolution of modern Linux package managers. Portage tracks every package's build configuration, dependencies, and installation state through a system of ebuilds — bash scripts that describe exactly how to fetch, patch, compile, and install a piece of software. This granular control makes Gentoo uniquely suited for specialized server workloads where every byte of memory and every CPU cycle counts.

Why Gentoo Matters for Production Servers

🚀 Deploy your AI agent in 10 minutes

Managed Hermes hosting. Zero DevOps. 100M tokens/mo included.

Try it free →

Choosing Gentoo for a production server is a strategic decision. The distribution excels in scenarios where you need:

Minimal attack surface: Compile only the features you actually use. Disable unused protocols, file formats, or authentication modules at the compiler level via USE flags. A hardened Gentoo server can run with significantly fewer linked libraries than a typical binary distribution server.
CPU-specific optimizations: Binary distributions compile for a generic x86_64 baseline. Gentoo's -march=native flag lets GCC target your exact CPU microarchitecture, enabling instruction sets like AVX-512 or specific cache-line optimizations that can yield measurable performance gains in compute-heavy workloads.
Long-term stability with rolling releases: Gentoo's rolling release model means you never perform disruptive major version upgrades. You apply incremental updates continuously, keeping your production stack current without the downtime and risk of a full OS reinstall every few years.
Predictable dependency graphs: Because you compile everything locally, you avoid the "dependency hell" of mismatched library ABIs that plague some binary distributions during upgrades.
Deep customization for container hosts and hypervisors: Gentoo lets you build a minimal host OS with only the kernel features, libraries, and tools needed to run containers or VMs — nothing more.

Pre-Installation Planning and Hardware Considerations

Before booting the Gentoo installation media, plan your server's storage layout, network configuration, and partition scheme carefully. Production servers benefit from thoughtful partitioning that separates writable, volatile data from static system files. A typical production layout might look like:

/boot — 1-2 GB, containing kernels and initramfs images
/ — 20-40 GB, read-only mounted in production (with remount-rw for maintenance)
/var — Separate partition for logs, databases, and variable state
/opt — For application-specific data and third-party software
/srv or /data — For service data, websites, or application storage
Swap — Sized according to your RAM and workload requirements

For filesystem choices, consider ext4 for general-purpose reliability, XFS for large-file workloads, or ZFS (available via the sys-fs/zfs package) if you need compression, snapshots, and integrated volume management. Gentoo supports them all through kernel configuration.

Choosing the Right Installation Method

Gentoo offers two primary installation approaches for servers:

Minimal Installation CD (minimal-install-*.iso): A bare-bones live environment. You perform every step manually, giving you total control. Recommended for production servers.
Admin LiveDVD: A graphical live environment with tools pre-loaded. Useful for initial exploration, but the minimal ISO produces cleaner, more auditable installations.

For production, always use the minimal ISO and perform a manual stage 3 installation. This ensures you understand every component on the final system.

Booting the Install Media and Preparing Disks

Begin by booting the Gentoo minimal ISO from your server's IPMI, iDRAC, or physical console. Once at the root prompt, configure the network if needed:

# Verify network interfaces
ip a

# For DHCP (typical in datacenters):
dhcpcd eth0

# For static IP (common for servers):
ip addr add 192.168.1.100/24 dev eth0
ip route add default via 192.168.1.1

# Verify connectivity
ping -c 4 gentoo.org

Now partition the disks. The example below uses a GPT-partitioned NVMe drive with UEFI boot. Adjust device names (/dev/nvme0n1, /dev/sda) to match your hardware:

# Identify your target disk
lsblk

# Open parted on the target disk
parted /dev/nvme0n1

# Inside parted, create GPT label and partitions
mklabel gpt
unit mib

# EFI System Partition (for UEFI boot)
mkpart primary fat32 1 257
set 1 esp on

# Boot partition (ext4, holds kernels)
mkpart primary ext4 257 1281

# Root partition
mkpart primary ext4 1281 20481

# Var partition
mkpart primary ext4 20481 40961

# Swap
mkpart primary linux-swap 40961 45057

# Remaining space for data partition
mkpart primary ext4 45057 100%

# Print and verify
print
quit

Format the partitions with appropriate filesystems:

# Format EFI partition
mkfs.fat -F 32 /dev/nvme0n1p1

# Format boot and root with ext4
mkfs.ext4 -L boot /dev/nvme0n1p2
mkfs.ext4 -L root /dev/nvme0n1p3
mkfs.ext4 -L var /dev/nvme0n1p4

# Initialize swap
mkswap /dev/nvme0n1p5
swapon /dev/nvme0n1p5

# Format data partition
mkfs.ext4 -L data /dev/nvme0n1p6

Mounting the Filesystem and Installing the Stage 3 Tarball

Mount the root partition and create mount points for the remaining filesystems:

# Mount root
mount /dev/nvme0n1p3 /mnt/gentoo

# Create mount points
mkdir -p /mnt/gentoo/{boot,var,data}
mkdir -p /mnt/gentoo/boot/efi

# Mount all partitions
mount /dev/nvme0n1p2 /mnt/gentoo/boot
mount /dev/nvme0n1p1 /mnt/gentoo/boot/efi
mount /dev/nvme0n1p4 /mnt/gentoo/var
mount /dev/nvme0n1p6 /mnt/gentoo/data

Download the latest stage 3 tarball. For a production server, select the openrc variant (systemd is also available, but OpenRC is Gentoo's traditional init system and gives more granular service control). Set the date correctly to avoid SSL certificate issues, then fetch the tarball:

# Set date accurately
ntpd -q -g

# Download stage 3 (verify the latest URL at gentoo.org/downloads)
cd /mnt/gentoo
wget https://distfiles.gentoo.org/releases/amd64/autobuilds/current-stage3-openrc/stage3-amd64-openrc-*.tar.xz

# Verify the checksum
wget https://distfiles.gentoo.org/releases/amd64/autobuilds/current-stage3-openrc/stage3-amd64-openrc-*.tar.xz.DIGESTS
sha512sum -c stage3-amd64-openrc-*.tar.xz.DIGESTS

# Extract the stage 3 tarball
tar xpf stage3-amd64-openrc-*.tar.xz --xattrs-include='*.*' --numeric-owner

Configuring the Base System Before Chroot

Before chrooting into the new environment, bind the necessary live system directories and copy DNS configuration:

# Copy resolv.conf for network resolution inside chroot
cp /etc/resolv.conf /mnt/gentoo/etc/

# Mount pseudo-filesystems
mount --types proc /proc /mnt/gentoo/proc
mount --rbind /sys /mnt/gentoo/sys
mount --make-rslave /mnt/gentoo/sys
mount --rbind /dev /mnt/gentoo/dev
mount --make-rslave /mnt/gentoo/dev

# Chroot into the new environment
chroot /mnt/gentoo /bin/bash
source /etc/profile
export PS1="(chroot) ${PS1}"

Now you are inside the nascent Gentoo installation. The first tasks are to configure Portage, set the profile, and establish your core compiler flags.

Configuring Portage and Setting the Profile

Gentoo profiles define sensible defaults for entire categories of systems. For a production server, select a hardened or server profile:

# List available profiles
eselect profile list

# For a standard production server (no desktop, minimal libs):
eselect profile set default/linux/amd64/23.0/server

# For a hardened server (enhanced security features):
eselect profile set default/linux/amd64/23.0/hardened

Now configure /etc/portage/make.conf — the master configuration file for Portage. This is where you set compiler flags, USE flags, and build preferences. A production server make.conf emphasizes security hardening, CPU optimization, and minimal feature sets:

# /etc/portage/make.conf — Production Server Configuration

# CPU-specific optimization (critical for performance)
CFLAGS="-march=native -O2 -pipe"
CXXFLAGS="${CFLAGS}"
FCFLAGS="${CFLAGS}"
FFLAGS="${CFLAGS}"

# Linker flags: enable hardening
LDFLAGS="-Wl,-O1 -Wl,--as-needed -Wl,-z,now -Wl,-z,relro"

# Number of parallel make jobs (set to CPU threads + 1)
MAKEOPTS="-j17 -l16"

# Global USE flags for a minimal production server
# Disable GUI, desktop, and unnecessary features
USE="acl ipv6 ssl hardened pie pic pam caps \
     -X -gtk -gnome -qt5 -qt6 -kde -cups -alsa \
     -pulseaudio -wayland -xcb -xcomposite -xv \
     -sdl -sound -video -ffmpeg -mpeg -theora \
     -encode -decode -samba -winbind -ldap -kerberos \
     -systemd -dbus -udisks -consolekit -policykit \
     -telemetry -oracle -mysql -postgres -sqlite \
     -python -perl -ruby -lua -tcl"

# Accept licenses for production software
ACCEPT_LICENSE="*"

# Language support (minimal)
L10N="en"

# Mirror selection (choose geographically close mirrors)
GENTOO_MIRRORS="https://mirrors.rit.edu/gentoo/ http://gentoo.osuosl.org/"

# Sync URI for the Portage tree
SYNC="rsync://rsync.us.gentoo.org/gentoo-portage"

The USE flags in this configuration deserve explanation. Flags prefixed with a minus sign are explicitly disabled. The hardened, pie (Position-Independent Executable), and pic (Position-Independent Code) flags enable Address Space Layout Randomization (ASLR) protections. Disabling X, gtk, gnome, and qt* ensures no graphical libraries are pulled into the dependency tree — a server doesn't need them, and omitting them reduces the attack surface and compilation time significantly.

Configuring CPU-Specific Compiler Flags in Depth

The -march=native flag in CFLAGS tells GCC to auto-detect the CPU microarchitecture of the machine doing the compilation and optimize accordingly. This is safe and effective when you compile on the same hardware that will run the binaries. For servers where you might compile on a build host and deploy to different hardware, specify the target architecture explicitly:

# Example for an AMD EPYC 7003 series (Zen 3) server:
CFLAGS="-march=znver3 -mtune=znver3 -O2 -pipe"

# Example for an Intel Xeon Scalable Ice Lake server:
CFLAGS="-march=icelake-server -mtune=icelake-server -O2 -pipe"

# Example for a generic but modern x86_64 server (safe fallback):
CFLAGS="-march=x86-64-v3 -mtune=generic -O2 -pipe"

To determine your CPU's capabilities, use gcc -c -Q -march=native --help=target | grep march or examine /proc/cpuinfo. The optimization level -O2 is the standard for production: it enables most optimizations without the risky transformations that -O3 introduces.

Syncing the Portage Tree and Updating the Base System

With Portage configured, synchronize the ebuild repository — this fetches the latest package descriptions and dependency information:

# Initial Portage tree sync
emerge --sync

# Alternatively, use the faster web-based sync method
emerge-webrsync

Now perform a full system update. This recompiles the base system packages according to your new USE flags and compiler settings:

# Update the entire system to reflect new USE flags and profile
emerge --update --deep --changed-use --newuse @world

# Clean up orphaned packages
emerge --depclean

# Rebuild any packages that depend on removed libraries
emerge @preserved-rebuild

This initial world rebuild is the longest step in the installation. On modern server hardware with 16+ cores, it completes in 30-90 minutes depending on USE flag scope. The result is a fully optimized base system where every installed binary is tuned to your hardware and feature requirements.

Configuring the Kernel for Production

Gentoo gives you two kernel paths: the automated gentoo-kernel binary package or a manually configured kernel. For production servers, manual kernel configuration is strongly recommended — it eliminates hundreds of unnecessary drivers and features, reducing the kernel attack surface and improving boot times.

First, install the kernel sources and essential build tools:

emerge sys-kernel/gentoo-sources
emerge sys-kernel/linux-firmware
emerge sys-apps/pciutils

Enter the kernel source directory and generate a baseline configuration based on your hardware:

cd /usr/src/linux

# Generate a config from the running hardware
make localmodconfig

# This prompts you for each detected module — answer 'y' or 'm' 
# for hardware you need, 'n' for everything else

# Then customize further
make menuconfig

Within menuconfig, focus on these production-critical areas:

General setup --->
  [*] Support for paging of anonymous memory (swap)
  [*] Control Group support --->
    [*] Memory controller
    [*] CPU controller
    [*] IO controller
  [*] Namespaces support --->
    [*] UTS namespace
    [*] IPC namespace
    [*] User namespace
    [*] PID namespace
    [*] Network namespace
    [*] Mount namespace

Processor type and features --->
  [*] Symmetric multi-processing support
  [*] Multi-core scheduler support
  [*] Machine Check / overheating reporting
  [*] Intel MCE features (if Intel)
  [*] CPU microcode loading support

Networking support --->
  [*] TCP/IP networking
  [*]   IP: TCP syncookie support (SYN flood protection)
  [*]   IP: TCP window scaling
  [*] Netfilter (firewall) support

File systems --->
  [*] Ext4 with journaling, extents, and large_file
  [*] XFS filesystem support (if using XFS)

Security options --->
  [*] Enable different security models
  [*] Stack Protector buffer overflow detection
  [*] Hardlink and symlink restrictions
  [*] Restrict unprivileged access to kernel log buffer

Kernel hardening --->
  [*] Kernel image randomization
  [*] Randomize kernel stack offset on syscall entry

After configuring, build and install the kernel:

# Build the kernel (adjust -j to your CPU threads + 1)
make -j17

# Install modules
make modules_install

# Install the kernel image
make install

# For UEFI systems, copy the kernel to the boot partition
cp arch/x86_64/boot/bzImage /boot/vmlinuz-$(make kernelrelease)

If you need an initramfs (required for LUKS encryption, LVM root, or complex storage), use sys-kernel/dracut or sys-kernel/genkernel:

emerge sys-kernel/dracut
dracut --hostonly --no-hostonly-cmdline /boot/initramfs-$(make kernelrelease).img $(make kernelrelease)

Installing and Configuring the Bootloader

For UEFI-based servers, GRUB2 is the standard choice. Install it and configure boot entries:

emerge sys-boot/grub

# Install GRUB for UEFI
grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=gentoo

# Enable the security-focused GRUB features
grub-mkconfig -o /boot/grub/grub.cfg

Verify /boot/grub/grub.cfg contains a correct entry for your kernel. A minimal production entry looks like:

menuentry 'Gentoo Linux Production' {
    load_video
    insmod gzio
    insmod part_gpt
    insmod ext2
    search --no-floppy --fs-uuid --set=root YOUR_ROOT_UUID
    echo 'Loading Linux ...'
    linux /vmlinuz-6.1.55-gentoo root=UUID=YOUR_ROOT_UUID ro rootflags=chattr
    echo 'Loading initramfs ...'
    initrd /initramfs-6.1.55-gentoo.img
}

Note the ro kernel parameter — in production, mount the root filesystem read-only to prevent accidental modification and detect any unauthorized writes.

Configuring the Network for Server Operation

Gentoo uses OpenRC's network stack by default (with the server profile). Configure static networking — the standard for production servers:

# /etc/conf.d/net — Static IP configuration

# For a simple single-interface server
config_eth0="192.168.1.100 netmask 255.255.255.0"
routes_eth0="default via 192.168.1.1"
dns_servers_eth0="8.8.8.8 8.8.4.4"

# For bonded interfaces (production dual-NIC servers)
config_bond0="192.168.1.100 netmask 255.255.255.0"
routes_bond0="default via 192.168.1.1"
dns_servers_bond0="8.8.8.8 8.8.4.4"
bond_mode="802.3ad"
bond_miimon="100"
bond_slaves="eth0 eth1"

Set the hostname and enable the network service:

# /etc/conf.d/hostname
hostname="prod-web01"

# Enable networking at boot
cd /etc/init.d
ln -s net.lo net.eth0
rc-update add net.eth0 default

# For bonded interfaces
ln -s net.lo net.bond0
rc-update add net.bond0 default

Configuring System Security Hardening

Production Gentoo servers benefit from the distribution's deep security integration. Enable the following hardening measures:

# Install and configure the hardened toolchain
emerge app-hardware/pax-utils
emerge sys-apps/hardened-shadow

# Enable sysctl security parameters
# /etc/sysctl.d/99-hardening.conf

kernel.kptr_restrict = 2
kernel.dmesg_restrict = 1
kernel.kexec_load_disabled = 1
kernel.unprivileged_bpf_disabled = 1
kernel.yama.ptrace_scope = 2

net.core.bpf_jit_harden = 2
net.ipv4.tcp_syncookies = 1
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.conf.default.accept_source_route = 0
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.default.accept_redirects = 0
net.ipv4.icmp_echo_ignore_broadcasts = 1
net.ipv4.icmp_ignore_bogus_error_responses = 1

fs.protected_hardlinks = 1
fs.protected_symlinks = 1
fs.suid_dumpable = 0

# Apply immediately
sysctl --system

Configure a minimal, auditable set of startup services:

# List all services currently enabled
rc-update show

# Disable unnecessary services
rc-update del hwclock
rc-update del consolefont

# Enable only what you need
rc-update add sshd default
rc-update add net.eth0 default
rc-update add ntpd default
rc-update add syslog-ng default
rc-update add cronie default

# For monitoring, add a metrics agent
rc-update add netdata default

Setting Up SSH for Secure Remote Access

SSH is the primary management channel for headless servers. Configure it securely:

# /etc/ssh/sshd_config — Production hardening

Protocol 2
Port 22
AddressFamily inet

# Only allow strong key exchange algorithms
KexAlgorithms curve25519-sha256,curve25519-sha256@libssh.org,diffie-hellman-group16-sha512

# Only allow Ed25519 and strong RSA host keys
HostKey /etc/ssh/ssh_host_ed25519_key
HostKey /etc/ssh/ssh_host_rsa_key

# Authentication hardening
PermitRootLogin prohibit-password
PasswordAuthentication no
PubkeyAuthentication yes
AuthenticationMethods publickey
MaxAuthTries 3
MaxSessions 5

# Disable forwarding unless needed
AllowTcpForwarding no
X11Forwarding no
AllowAgentForwarding no

# Connection limits
LoginGraceTime 30
ClientAliveInterval 300
ClientAliveCountMax 2
MaxStartups 10:30:60

# Logging
SyslogFacility AUTH
LogLevel VERBOSE

# Only allow specific users or groups
AllowGroups ssh-users

# Banner (legal warning)
Banner /etc/ssh/banner

Generate strong host keys and restart the service:

ssh-keygen -t ed25519 -f /etc/ssh/ssh_host_ed25519_key -N ""
ssh-keygen -t rsa -b 4096 -f /etc/ssh/ssh_host_rsa_key -N ""
rc-service sshd restart

Installing Production Server Software

Now install the specific server software your workload requires. Gentoo's USE flags let you compile each daemon with exactly the features needed. Here are examples for common production stacks:

# Nginx with SSL, HTTP/2, and no unnecessary modules
# Create /etc/portage/package.use/nginx
echo "www-servers/nginx http2 pcre ssl zlib -pcre-jit -rtmp -vim-syntax -nginx-module-geoip -nginx-module-perl -nginx-module-fancyindex" > /etc/portage/package.use/nginx
emerge www-servers/nginx

# PostgreSQL with only the server features
echo "dev-db/postgresql server threads uuid xml -python -perl -tcl" > /etc/portage/package.use/postgresql
emerge dev-db/postgresql

# Redis with jemalloc for memory efficiency
echo "dev-db/redis jemalloc -hiredis -systemd" > /etc/portage/package.use/redis
emerge dev-db/redis

# Node.js for application serving
emerge net-libs/nodejs

# HAProxy for load balancing
echo "net-proxy/haproxy ssl zlib -systemd -prometheus-exporter" > /etc/portage/package.use/haproxy
emerge net-proxy/haproxy

Configuring Service-Specific USE Flags

The /etc/portage/package.use directory is where you define per-package USE flags. This is the heart of Gentoo's precision. For a production web server stack, you might create:

# /etc/portage/package.use/nginx
www-servers/nginx http2 pcre ssl zlib aio threads

# /etc/portage/package.use/php
dev-lang/php cli cgi fpm ssl json xml curl zip intl pcntl mysqli -apache -embed

# /etc/portage/package.use/mariadb
dev-db/mariadb server innodb-lz4 innodb-snappy -embedded -static -test

# /etc/portage/package.use/curl
net-misc/curl ssl http2 ipv6 -ldap -rtmp -ssh

# /etc/portage/package.use/openssl
dev-libs/openssl asm cpu_flags_x86_sse2 -bindist -sslv3 -weak-ssl-ciphers

After setting per-package USE flags, rebuild affected packages:

emerge --update --changed-use --deep @world

Configuring Logging and Monitoring

Production servers need robust logging. Gentoo offers several syslog implementations. For a minimal, reliable setup:

# Install syslog-ng with JSON output for log aggregation
echo "app-admin/syslog-ng json json-c" > /etc/portage/package.use/syslog-ng
emerge app-admin/syslog-ng

# Configure syslog-ng to forward to a central log server
# /etc/syslog-ng/syslog-ng.conf

@version: 4.2
@include "scl.conf"

source s_local {
    system();
    internal();
};

destination d_central {
    network("log-aggregator.internal" transport("tls") port(6514));
};

destination d_local {
    file("/var/log/messages");
};

log {
    source(s_local);
    destination(d_local);
    destination(d_central);
};

# Enable and start
rc-update add syslog-ng default
rc-service syslog-ng start

For resource monitoring, deploy a lightweight agent:

emerge net-analyzer/netdata
rc-update add netdata default
rc-service netdata start

# Netdata listens on localhost:19999 by default
# For headless servers, configure a reverse proxy or SSH tunnel

Configuring Time Synchronization

Accurate time is critical for distributed systems, certificate validation, and log correlation:

# Install NTP
emerge net-misc/ntp

# /etc/ntp.conf — Production NTP configuration

driftfile /var/lib/ntp/ntp.drift
restrict default kod nomodify notrap nopeer noquery
restrict 127.0.0.1
restrict ::1

# Tier 1 NTP servers (use pool.ntp.org for less critical systems)
server time.cloudflare.com iburst
server time.google.com iburst
server ntp.ubuntu.com iburst

# Enable and start
rc-update add ntpd default
rc-service ntpd start

Creating a Production-Grade Backup Strategy

A Gentoo server's configuration is its most valuable asset — the kernel config, Portage configuration, world set, and service configurations represent hours of precise tuning. Back these up programmatically:

# /usr/local/bin/gentoo-config-backup — Daily configuration backup

#!/bin/bash
BACKUP_DIR="/data/backups/configs"
DATE=$(date +%Y%m%d)

mkdir -p "$BACKUP_DIR/$DATE"

# Backup Portage configuration
cp -r /etc/portage "$BACKUP_DIR/$DATE/portage"

# Backup kernel configuration
cp /usr/src/linux/.config "$BACKUP_DIR/$DATE/kernel-config"

# Backup the world set (installed packages)
cp /var/lib/portage/world "$BACKUP_DIR/$DATE/world"

# Backup service configurations
tar czf "$BACKUP_DIR/$DATE/etc-backup.tar.gz" /etc/conf.d /etc/ssh /etc/sysctl.d

# Backup the list of enabled services
rc-update show > "$BACKUP_DIR/$DATE/enabled-services.txt"

# Create a restore script
cat > "$BACKUP_DIR/$DATE/restore.sh" << 'EOF'
#!/bin/bash
echo "Restoring Gentoo configuration from backup..."
cp -r portage /etc/
cp kernel-config /usr/src/linux/.config
cp world /var/lib/portage/world
tar xzf etc-backup.tar.gz -C /
emerge --sync
emerge --update --deep --newuse @world
EOF

chmod +x "$BACKUP_DIR/$DATE/restore.sh"

echo "Backup complete: $BACKUP_DIR/$DATE"

Schedule this via cron:

# /etc/cron.d/gentoo-backup
0 2 * * * root /usr/local/bin/gentoo-config-backup

Implementing Read-Only Root Filesystem

One of the most impactful production hardening techniques on Gentoo is mounting the root filesystem read-only. This prevents even root from modifying system binaries during operation, catching intrusions and misconfigurations early. Implement it in stages:

# First, identify which directories need to be writable
# Move writable paths to tmpfs or separate writable partitions

# Create tmpfs mounts for writable directories
# /etc/fstab additions:

tmpfs /tmp tmpfs defaults,noatime,nosuid,nodev,mode=1777 0 0
tmpfs /var/tmp tmpfs defaults,noatime,nosuid,nodev 0 0
tmpfs /var/log tmpfs defaults,noatime 0 0

# Bind-mount writable directories from /var (which is on its own writable partition)
/var/cache /var/cache none bind 0 0

# Ensure /var/lock and /var/run are tmpfs
tmpfs /var/lock tmpfs defaults,noatime,nosuid,nodev 0 0
tmpfs /var/run tmpfs defaults,noatime,nosuid,nodev 0 0

Test the read-only root mount:

# Remount root read-only (requires a reboot to fully activate via fstab)
mount -o remount,ro /

# Test that services still function
ps aux
df -h

# If something breaks, remount read-write to fix
mount -o remount,rw /

Once confident, update the root entry in /etc/fstab to include the ro flag and reboot. From then on, administrative tasks require explicitly remounting read-write:

# Standard maintenance workflow on read-only root
sudo mount -o remount,rw /
# Perform updates or configuration changes
sudo mount -o remount,ro /

Automating Updates with a Production-Safe Workflow

Gentoo's rolling release model means updates are continuous. A production update workflow must be deliberate and tested:

# /usr/local/bin/production-update — Safe production update script

#!/bin/bash
set -euo pipefail

LOG_FILE="/var/log/updates/update-$(date +%Y%m%d-%H%M%S).log"
exec > >(tee -a "$LOG_FILE") 2>&1

echo "=== Production Update Started $(date) ==="

# 1. Remount root read-write
mount -o remount,rw / || { echo "Failed to remount rw"; exit 1; }

# 2. Sync the Portage tree
echo "Syncing Portage tree..."
emerge --sync

# 3. Check for news items (important for production)
echo "Checking Gentoo news..."
eselect news read all

# 4. Run a pretend update to preview changes
echo "Previewing updates..."
emerge --update --deep --newuse