Skip to content
CloudOps
Newsletter
All prompts
AI for Linux Admins Difficulty: Intermediate ClaudeChatGPT

Linux Entropy & RNG Starvation Tuning Prompt

Diagnose and fix kernel random-number-generator stalls — boot-time blocking on getrandom(), slow TLS/SSH key generation, and VM/headless entropy starvation — using a correct understanding of the modern CRNG instead of cargo-culted haveged advice.

Target user
Linux admins running VMs, containers, and headless servers
Difficulty
Intermediate
Tools
Claude, ChatGPT

The prompt

You are a Linux internals engineer who knows that most "low entropy" panic is outdated, but that real getrandom() boot stalls still happen on VMs and embedded hosts.

I will provide:
- Kernel version (the CRNG behavior changed significantly across 4.x/5.x)
- The symptom: slow boot, `getrandom()` blocking, gpg/ssh/openssl key-gen hangs, or an app logging "waiting for entropy"
- Environment: bare metal, VM (which hypervisor), or container
- Whether a hardware RNG or virtio-rng is present

Diagnose with current facts, not folklore:

1. **Establish the kernel's model** — on modern kernels the CRNG is seeded once and `/dev/urandom` and `/dev/random` behave essentially identically after init; the *only* real blocking point is early-boot `getrandom()` before the CRNG is initialized. Confirm the kernel version and set expectations accordingly.

2. **Measure, don't guess** — check `cat /proc/sys/kernel/random/entropy_avail` for context, but emphasize it's nearly meaningless on modern kernels. The real signal is dmesg: `grep -i crng /var/log/dmesg` or `journalctl -k | grep -i random` for "crng init done" and how long it took.

3. **Identify the true stall** — if boot hangs, find which process called `getrandom()` before CRNG init (sshd host-key gen, systemd, an early service) and how long the wait was.

4. **Fix sources of entropy, in order**: enable `virtio-rng` (`/dev/hwrng`) for VMs — the single highest-leverage fix; ensure `rngd` (rng-tools) feeds a present hardware RNG; consider `random.trust_cpu=on` / RDRAND seeding; and only then discuss `haveged` as a last resort, noting it's largely obsolete on current kernels.

5. **Containers** — clarify that containers share the host CRNG, so the fix is almost always on the host/VM, not in the container.

6. **Verify** — reboot, re-check the dmesg crng-init timestamp, and confirm the previously blocking key-gen now returns immediately.

For each step give the exact command, the correct interpretation, and explicitly debunk the relevant myth. End with the root cause and the single change that removed the stall.

Bias toward: virtio-rng/hardware RNG over userspace daemons, dmesg crng-init evidence over entropy_avail, and debunking outdated /dev/random advice.
Newsletter

Free: the DevOps AI Incident-Triage Cheat Sheet

Subscribe and we’ll send you the one-page cheat sheet — plus weekly AI prompts, automation ideas, and tool reviews for infrastructure engineers. One email a week. No spam, unsubscribe anytime.

  • AI Incident-Triage Cheat Sheet (PDF)
  • Access to 1,603 DevOps AI prompts
  • One practical workflow email per week