# CERN Left Red Hat for Debian: The CPU Baseline Lesson URL: https://www.devopsness.com/blog/cern-red-hat-to-debian-control-systems Author: Kiril Urbonas Published: 2026-09-23 Updated: 2026-10-31 Categories: Linux Tags: Linux, Sysadmin, Infrastructure, Operations Summary: CERN is moving accelerator control computers to Debian because RHEL raised its minimum CPU level. Check your own fleet's x86-64-vN support before the next OS upgrade does it for you. --- # CERN Left Red Hat for Debian: The CPU Baseline Lesson CERN is moving its accelerator front-end control computers from Red Hat-family distributions to Debian because of a CPU baseline, not licensing. RHEL 9 requires x86-64-v2 and RHEL 10 requires x86-64-v3, and each step strands older CPUs. The lesson: treat the microarchitecture level as an upgrade gate and audit it before every major OS move. > [!VERIFIED] > RHEL 10.0 (x86-64-v3 minimum), RHEL 9 (x86-64-v2), Debian 13 amd64 (psABI baseline), glibc 2.33+ hwcaps, against the RHEL 10.0 release notes, the Debian ArchitectureSpecificsMemo, the x86-64 psABI and glibc NEWS. Checked October 2026. If your fleet outlives its hardware refresh cycle, the CPU baseline now deserves the same testing you give kernel and glibc versions. ## What CERN actually said The primary source is a talk, "Controlling CERN's Accelerators with Debian", given by CERN engineers Federico Vaga and Nikos Tsipinakis at MiniDebConf Winterthur in late August 2026. [Phoronix](https://www.phoronix.com/news/CERN-Goes-Debian-Leaving-RHEL) and [The Register](https://www.theregister.com/os-platforms/2026/09/03/cern-moves-thousands-of-accelerator-control-computers-to-debian/5294312) both reported it, and both stress the same scope limit. Only the underground front-end machines that drive the accelerators move to Debian (Debian 13, kept alive long-term through Freexian's ELTS program, per The Register). Physicists' consoles run AlmaLinux 10, and the datacenter tier runs RHEL 9 with a likely later move to AlmaLinux 10. The stated driver was the `-march=x86-64-v2` default, which the engineers described as forced obsolescence for older hardware. The Register reports the v2 baseline alone would have excluded 47% of their embedded control computers, and the v3 step in RHEL 10 a further 17%, and it puts the total at "some 65 percent". Those machines are often VMEbus single-board computers and PCI cards with custom hardware, so "just buy new servers" means redesigning boards. We won't repeat cost or timeline figures; the talk is the authority on those, not the coverage. The mechanism is what matters. ## Microarchitecture levels are the quiet breaking change Nobody puts "drops Ivy Bridge" in a release headline. The x86-64 psABI defines four levels. v1 is the original 2003 baseline. v2 adds SSE4.2 and POPCNT, roughly Nehalem (2008) onward. v3 adds AVX2, BMI2 and FMA, roughly Haswell (2013) onward. v4 needs AVX-512. When a distro compiles its whole archive with `-march=x86-64-v2`, a v1 CPU does not degrade gracefully. The dynamic loader is fine, but the first `POPCNT` in `libc` or `bash` raises SIGILL. You get a machine that installs, then dies at boot, or worse, dies at a random point in a rarely used binary. Debian's amd64 port still targets the original psABI baseline (`-march=x86-64`, nothing past SSE2 guaranteed), which is why old boards keep working there. That is a choice with a cost: Debian leaves performance on the table for modern CPUs. For a fleet of long-lived control hardware, that trade is correct. For a fleet of fresh cloud instances, it is a small tax you probably never notice. ## Check what a machine supports in two commands glibc 2.33 and later can tell you which levels the CPU supports. The dynamic loader prints them: ```bash $ /lib64/ld-linux-x86-64.so.2 --help | grep -A5 'Subdirectories of glibc-hwcaps' # Subdirectories of glibc-hwcaps directories, in priority order: # x86-64-v4 # x86-64-v3 (supported, searched) # x86-64-v2 (supported, searched) ``` Any level marked `supported` is one this CPU can run. If v2 is missing from that list, you cannot run a RHEL 9 userland on that box at all. For older glibc, read the flags directly. The names to look for are `sse4_2` and `popcnt` for v2, and `avx2`, `bmi2` and `fma` for v3: ```bash $ grep -m1 flags /proc/cpuinfo | tr ' ' '\n' | grep -E '^(sse4_2|popcnt|avx2|bmi2|fma|avx512f)$' | sort ``` If `sse4_2` and `popcnt` both print, the machine is at least v2. Add `avx2`, `bmi2` and `fma` for v3. ## Audit the fleet before the OS upgrade, not after Run the check across everything you own, including the machines nobody remembers. We would rather find a v1 box in a spreadsheet than in a failed change window: ```bash $ ansible all -m shell -a "/lib64/ld-linux-x86-64.so.2 --help | grep -E 'x86-64-v[234] \(supported' | awk '{print \$1}' | tr '\n' ' '" -o ``` Sort the output into three buckets. Machines supporting v3 can take RHEL 10 today. Machines topping out at v2 can run RHEL 9 but have a hard end date when RHEL 9 support ends. Machines at v1 are already stranded on anything current from Red Hat. Watch for virtualization. A hypervisor can mask CPU flags to keep live migration working across mixed hosts, so a guest may report v2 on hardware that is really v3. Check the VM's configured CPU model, not just what the guest sees. ## RHEL-family versus Debian on long-lived hardware Red Hat's baseline bump is not a mistake. It buys real performance on modern silicon, and RHEL, Rocky and AlmaLinux still offer the strongest vendor certification story for commercial software. If your workloads are databases and application servers on hardware you refresh every four to five years, stay on the RHEL family and plan hardware around the baseline. Debian is the better choice when the hardware outlives the OS release cycle, when you cannot replace boards without engineering work, or when you need a decade of predictable userland. You give up a commercial support contract and some performance. You keep the machines. Keep the storage choice separate from this one. Filesystem decisions such as [ext4, XFS or Btrfs](/blog/ext4-vs-xfs-vs-btrfs-choosing-a-filesystem) are mostly independent of distro, and RHEL defaults to XFS while Debian defaults to ext4. If containers are your escape hatch, note that a container still runs on the host's CPU, so a smaller base such as [distroless images](/blog/distroless-docker-images-smaller-safer) does not remove the baseline problem; the image's binaries must still run on your oldest node. ## Questions people ask ### Why is CERN moving from Red Hat to Debian? Because of CPU requirements, not cost. RHEL 9 is compiled for x86-64-v2 and RHEL 10 for x86-64-v3, and CERN's engineers said those baselines would exclude about 65% of the embedded front-end computers that control the accelerators, many of them custom VMEbus boards. Debian's amd64 port still runs on the original x86-64 baseline, so the existing hardware keeps working. ### How do I check if my CPU supports x86-64-v2 or x86-64-v3? On glibc 2.33 or newer, run `/lib64/ld-linux-x86-64.so.2 --help` and read the glibc-hwcaps list; every level marked `supported` will run. On older systems, check `/proc/cpuinfo`: `sse4_2` and `popcnt` mean at least v2, and adding `avx2`, `bmi2` and `fma` means v3. In a VM, confirm the hypervisor isn't masking flags. ### Does Debian require x86-64-v2? No, not as of Debian 13. Debian documents its amd64 baseline as plain x86-64 with no optional extensions, compiled with `-march=x86-64`, so SSE3 and later are not assumed. That is why old boards keep booting there. Individual packages may ship optimized variants through glibc-hwcaps subdirectories, but the base system runs on first-generation 64-bit CPUs. ## The decision, concretely - Does every host report `x86-64-v3 (supported)`? Take RHEL 10 or a rebuild of it. You get the performance the baseline was meant to buy. - Is any host stuck at v2 and not due for replacement within two years? Pin it to RHEL 9 with a dated exit plan, or move that class of host to Debian now. - Is any host at v1, or hardware you cannot cheaply replace? Use Debian. That is CERN's call for the same reason. - Are your hypervisor CPU flags masked? Fix that first, then rerun the audit, or you will be deciding on wrong data. ## The call we'd make Treat the CPU level as an inventory field alongside kernel and glibc versions, and audit it before every major OS decision. Default to the RHEL family for fleets you refresh on schedule, and default to Debian for anything whose hardware you cannot replace on demand. ## Sources - [Red Hat: RHEL 10.0 release notes, architectures (x86-64-v3 minimum)](https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/10/html/10.0_release_notes/architectures) - [Debian Wiki: ArchitectureSpecificsMemo (amd64 baseline)](https://wiki.debian.org/ArchitectureSpecificsMemo) - [x86-64 psABI (microarchitecture level definitions)](https://gitlab.com/x86-psABIs/x86-64-ABI) - [The Register: CERN moves thousands of accelerator control computers to Debian](https://www.theregister.com/os-platforms/2026/09/03/cern-moves-thousands-of-accelerator-control-computers-to-debian/5294312)