Switching a 26.04 install to Ubuntu amd64v3 packages made xz -9 compression 6.1% faster on the test box, made zstd decompression 7.0% slower, and left every other workload measured within 3.5% of the baseline build. That is the whole result of four alternating benchmark passes, and it is a smaller, more uneven change than a full archive rebuild for newer CPUs implies.
Ubuntu calls these builds amd64v3: the same package versions compiled for the x86-64-v3 microarchitecture level, which assumes AVX2, FMA, BMI1/BMI2 and MOVBE on every CPU that installs them. The sections below cover which releases carry them, how to switch an existing Ubuntu 26.04 LTS install over and back, what is inside the Ubuntu 26.10 amd64v3 desktop ISO, the A/B benchmark, and the exact kernel panic you get when a v3 system lands on a CPU without those instructions.
Benchmarked October 2026 on Ubuntu 26.04 LTS (Core i7-6700, x86-64-v3).
What Ubuntu amd64v3 packages change
amd64v3 is an architecture variant, not a new architecture. dpkg --print-architecture still reports amd64, package names stay the same, and the version strings are identical to the baseline build. The difference is one extra field in the package metadata, Architecture-Variant: amd64v3, plus one apt setting that tells apt to prefer those builds:
APT::Architecture-Variants "amd64v3";Canonical rebuilt the archive with the compiler allowed to emit AVX2, FMA and BMI2 instructions everywhere instead of only in hand-written fast paths. Libraries that already detect the CPU at runtime (glibc string functions, the AES and SHA code in OpenSSL) gain little, because they were using AVX2 on capable hardware before the switch. Code the compiler can auto-vectorize gains the most. The archive also leaves a few packages on the baseline build: the kernel, shim-signed, fwupd-signed, bpftool and the linux-tools family stay plain amd64, which is why a v3 system still boots its kernel on an older CPU and then dies in userspace (covered further down).
Which Ubuntu releases ship amd64v3 packages
Ubuntu 24.04 LTS has no amd64v3 builds and never will; its archive Release file lists only amd64 arm64 armhf i386 ppc64el riscv64 s390x. The variant first appeared in 25.10, mostly for packages in main, and 26.04 LTS was the first release rebuilt across main and universe. The coverage figures below were counted from the binary-amd64v3/Packages.xz indexes on archive.ubuntu.com on 10 October 2026:
| Release | amd64v3 in archive | Arch-specific binaries with a v3 build | amd64v3 install media |
|---|---|---|---|
| 24.04 LTS (Noble) | No | 0 | None |
| 25.10 (Questing) | Yes, opt-in | main 2,557 of 3,642 (70.2%), universe 1,418 of 32,884 (4.3%) | None |
| 26.04 LTS (Resolute) | Yes, opt-in | main 3,485 of 3,848 (90.6%), universe 30,113 of 33,513 (89.9%) | amd64v3 cloud image; public cloud images are v3-only |
| 26.10 (Stonking) | Yes, opt-in | main 3,429 of 3,819 (89.8%), universe 32,922 of 34,697 (94.9%) | amd64v3 desktop ISO (no server ISO) |
The cloud row matters more than it looks. The Ubuntu cloud image documentation states that from 26.04 onward the official images on public clouds are amd64v3 builds published under the plain amd64 name, and that legacy amd64 images are no longer published there. A 26.04 instance on a public cloud is already running v3 packages, so this guide is mostly for bare metal, desktops, and private virtualization where you choose the image yourself. On cloud-images.ubuntu.com both ubuntu-26.04-server-cloudimg-amd64.img and ubuntu-26.04-server-cloudimg-amd64v3.img are published side by side.
Step 1: Confirm the CPU supports x86-64-v3
The dynamic loader knows which levels the running CPU satisfies. Ask it directly instead of reading /proc/cpuinfo flag by flag:
/lib64/ld-linux-x86-64.so.2 --help | grep x86-64On the test box (a Skylake Core i7-6700 passed through with cpu: host) v3 is marked supported and v4 is not, because the chip has no AVX-512:
Usage: /lib64/ld-linux-x86-64.so.2 [OPTION]... EXECUTABLE-FILE [ARGS-FOR-PROGRAM...]
This program interpreter self-identifies as: /lib64/ld-linux-x86-64.so.2
x86-64-v4
x86-64-v3 (supported, searched)
x86-64-v2 (supported, searched)The same check rendered in the terminal on the test box:
The line must read x86-64-v3 (supported, searched). Intel Haswell (2013) and newer Core and Xeon parts qualify, as does AMD from Excavator and every Zen. The usual exceptions are low-end Atom, Celeron and Pentium Silver chips without AVX2, which stop at v2.
Virtual machines need one extra check, because the hypervisor decides which CPU flags the guest sees. The Proxmox VE web UI defaults new VMs to the x86-64-v2-AES CPU type (the qm and API default is kvm64), and both hide AVX2 even on a v3 host, and the loader inside that guest prints x86-64-v3 without “supported”. Set the CPU type to host or x86-64-v3 and cold-start the VM (a reboot from inside the guest does not re-read the CPU model). Replace 233 with the VMID of the guest:
qm set 233 --cpu host
qm shutdown 233 && qm start 233Live migration is the other trap. A v3 guest that migrates to an older node in a mixed cluster crashes the moment it executes an AVX2 instruction, so pin the CPU type to the lowest level every node supports. The KVM on Ubuntu 26.04 guide covers the libvirt side of the same setting (<cpu mode='host-passthrough'/> or a named model).
Step 2: Switch Ubuntu 26.04 to amd64v3 packages
Ubuntu 26.04 ships a dpkg and apt that understand variants, so there is nothing to upgrade first. Drop the apt setting into its own file:
echo 'APT::Architecture-Variants "amd64v3";' | sudo tee /etc/apt/apt.conf.d/99enable-amd64v3Refresh the package lists. apt now fetches the amd64v3 Packages indexes for every pocket alongside the normal ones:
sudo apt updateThe tail of the output shows the v3 indexes and an upgrade count that covers nearly every installed architecture-specific package:
Get:15 http://archive.ubuntu.com/ubuntu resolute-updates/restricted amd64v3 Packages [508 kB]
Get:16 http://archive.ubuntu.com/ubuntu resolute-updates/multiverse amd64v3 Packages [21.1 kB]
Get:17 http://archive.ubuntu.com/ubuntu resolute-backports/universe amd64v3 Packages [3144 B]
Fetched 21.1 MB in 5s (3880 kB/s)
Reading package lists...
Building dependency tree...
Reading state information...
529 packages can be upgraded. Run 'apt list --upgradable' to see them.527 of those entries are variant swaps, not new versions; the other two are phased updates covered below. apt list --upgradable shows each swap as an upgrade from a version to the same version, for example bash/resolute 5.3-2ubuntu1 amd64 [upgradable from: 5.3-2ubuntu1]. Apply them:
sudo apt upgradeOn the test box the transaction replaced 527 packages with a 349 MB download and took 328 seconds. The two packages it held back were software-properties-common and python3-software-properties, both Architecture: all and waiting on a phased update, so they have no v3 build to begin with:
Summary:
Upgrading: 527, Installing: 0, Removing: 0, Not Upgrading: 2
126 standard LTS security updates
Download size: 349 MB
Space needed: 3066 kB / 26.0 GB availableapt does not print the “downgrading” notice that 25.10 users saw during this switch. The one warning worth reading is from sudo: on 26.04 the default sudo is the Rust rewrite, and its reinstall prints update-alternatives: warning: forcing reinstallation of alternative /usr/lib/cargo/bin/sudo because link group sudo is broken. The alternative is repaired in the same step and sudo kept working through the rest of the run. Reboot so that every long-running daemon restarts on the new binaries:
sudo rebootConfirm the switch with dpkg-query. The Architecture-Variant field is empty on baseline packages and reads amd64v3 on swapped ones:
dpkg-query -W -f='${Architecture} ${Architecture-Variant}\n' | sort | uniq -c527 packages now carry the variant. The 21 remaining amd64 entries are the kernel images, headers and modules for both installed kernels, linux-tools, linux-perf, linux-libc-dev, bpftool, shim-signed and fwupd-signed:
196 all
21 amd64
527 amd64 amd64v3Both queries together, with a per-package spot check of the libraries the benchmark exercises:
PPA packages vanish after enabling amd64v3
The global setting changes which index apt downloads from every repository, not only from the Ubuntu archive. Launchpad PPAs publish a binary-amd64v3 index, but unless the PPA owner builds v3 packages it carries only the Architecture: all packages. With ppa:git-core/ppa added on the test box, apt fetched only the v3 index of the PPA, which holds 9 of its 10 packages but not git itself, so the PPA build disappeared and apt fell back to the archive version:
apt-cache policy gitNo warning is printed. The candidate is simply the archive package:
git:
Installed: 1:2.53.0-1ubuntu1
Candidate: 1:2.53.0-1ubuntu1The fix is an explicit Architectures: amd64 line in each third-party .sources file, which makes apt read the normal index of that repository while the global setting keeps the Ubuntu archive on v3. Scoping it the other way round (an Architectures: amd64v3 line in ubuntu.sources and no global setting) is not a substitute: on a baseline system apt lists the 527 swaps as downgrades and apt upgrade applies none of them.
F=/etc/apt/sources.list.d/git-core-ubuntu-ppa-resolute.sources
grep -q '^Architectures:' "${F}" || sudo sed -i '/^Types:/a Architectures: amd64' "${F}"
sudo apt update
apt-cache policy gitapt now downloads the amd64 Packages index of the PPA again, the PPA build is the candidate, and the 527 archive swaps are still offered:
git:
Installed: 1:2.53.0-1ubuntu1
Candidate: 1:2.55.0-0ppa1~ubuntu26.04.2
Version table:
1:2.55.0-0ppa1~ubuntu26.04.2 500
500 https://ppa.launchpadcontent.net/git-core/ppa/ubuntu resolute/main amd64 PackagesRepeat that for every PPA and vendor repository on the machine, including ones added later. Repositories still configured as one-line .list entries take the same option in brackets, documented in sources.list(5) as deb [arch=amd64] URL suite component; vendor lines that already carry arch=$(dpkg --print-architecture) resolve to amd64 and need no change. The same applies to systems installed from the 26.10 amd64v3 ISO, where the global setting lives in 90arch-variant.
Step 3: Install Ubuntu 26.10 from the amd64v3 ISO
Ubuntu 26.10 is the first release with a desktop ISO built entirely from amd64v3 packages. It is not linked from the main download page, and releases.ubuntu.com carries only the baseline desktop-amd64 and live-server-amd64 images. The v3 ISO lives on cdimage.ubuntu.com next to the arm64, ppc64el, riscv64 and s390x images. There is no amd64v3 server ISO; server installs get there through Step 2 or the v3 cloud image. This loop checks the release/ directory first and falls back to the milestone directory, so it resolves the right file on any date:
for d in release beta; do
ISO=$(curl -s "https://cdimage.ubuntu.com/ubuntu/releases/26.10/${d}/" | grep -oE 'ubuntu-26\.10[a-z-]*-desktop-amd64v3\.iso' | head -1)
[ -n "${ISO}" ] && break
done
echo "${d}/${ISO}"Download it and check the SHA256 sum against the file published in the same directory:
wget "https://cdimage.ubuntu.com/ubuntu/releases/26.10/${d}/${ISO}"
curl -s "https://cdimage.ubuntu.com/ubuntu/releases/26.10/${d}/SHA256SUMS" | grep "${ISO}" | sha256sum -c -The image is 6.3 GB, the same size as the baseline desktop ISO. Inside, casper/minimal.squashfs already carries /etc/apt/apt.conf.d/90arch-variant with the same APT::Architecture-Variants "amd64v3"; line from Step 2, so the installed system keeps pulling v3 updates with no further configuration. Counting the dpkg database in that squashfs gives 1,519 packages: 398 Architecture: all, and 1,121 amd64 of which 1,107 are v3 builds. The 14 baseline holdouts are mostly the kernel, linux-tools, bpftool and fwupd-signed, plus ubuntu-drivers-common and linux-libc-dev.
Booted on a v3 CPU (the VM used cpu: host on an 11th-gen Core i7), the ISO reaches the live desktop and the installer in about 100 seconds:
From here the installer is the standard Ubuntu desktop flow, identical to the one in the Ubuntu 26.04 vs 24.04 comparison. Nothing on screen tells you this is the v3 image, so label the USB stick.
Step 4: Benchmark amd64v3 against baseline amd64
The test box is a KVM guest on a Core i7-6700 host with 4 vCPUs, 6 GB of RAM and cpu: host, running the Ubuntu 26.04 LTS cloud image with all updates applied. The design is A/B/A′/B′ on one disk: baseline packages, switch to amd64v3, roll back to a ZFS snapshot of the baseline, switch again. Every workload is single-threaded and timed with hyperfine (one warm-up, five measured runs, median reported) against fixed inputs: the 100 MB enwik8 corpus for the compressors, a 2-million-row in-memory SQLite script, and a make -j1 build of the Lua interpreter for GCC. Python ran eight pyperformance benchmarks in --fast mode, and OpenSSL ran openssl speed -evp for three seconds per algorithm. The two baseline passes differed by up to 5% on the longest test, so treat any change under 2% in the table as noise.
| Workload | Baseline amd64 (A / A′) | amd64v3 (B / B′) | Change |
|---|---|---|---|
| xz -9 compress, enwik8 | 94.92 s / 90.37 s | 87.43 s / 86.58 s | 6.1% faster |
| zstd -19 compress | 71.04 s / 72.62 s | 70.88 s / 70.65 s | 1.5% faster (noise) |
| zstd decompress | 0.256 s / 0.258 s | 0.274 s / 0.276 s | 7.0% slower |
| xz decompress | 1.059 s / 1.032 s | 1.034 s / 1.040 s | 0.8% faster (noise) |
| gzip -9 / bzip2 -9 | 5.62 s, 7.25 s / 5.58 s, 7.19 s | 5.58 s, 7.18 s / 5.66 s, 7.23 s | within 0.5% |
| SQLite, 2M rows in memory | 3.42 s / 3.34 s | 3.43 s / 3.45 s | 1.7% slower |
| GCC, Lua build -j1 | 7.15 s / 7.03 s | 7.11 s / 7.18 s | 0.8% slower (noise) |
| pyperformance, 8 benchmarks | chaos, float, json_dumps, spectral_norm 1.6 to 2.0% faster; nbody 2.0% and regex_v8 3.4% slower | 0.3% faster on average | |
| OpenSSL AES-256-GCM, 16 KB | 3,854 / 3,849 MB/s | 3,912 / 3,865 MB/s | 1.0% faster |
| OpenSSL SHA-256, 16 KB | 473 / 474 MB/s | 472 / 473 MB/s | flat |
Two results stand well clear of the noise. The xz encoder is the only workload where every v3 run (86.1 to 87.6 s) beat every clean baseline run (89.7 to 94.9 s); paired pass by pass the gain is 7.9% and 4.2%, and 6.1% is the pooled figure. zstd decompression moved the other way in both v3 passes, from 0.256 s to 0.274 s and from 0.258 s to 0.276 s. libzstd already selects its BMI2 code paths at runtime on capable CPUs, so the rebuild had nothing to add there, and on this Skylake host the v3 decoder build is measurably slower.
The rest is small and mixed. The Python benchmarks split four faster (chaos, float, json_dumps and spectral_norm, 1.6 to 2.0%) and two slower (nbody 2.0%, regex_v8 3.4%), with the same direction in both passes, which nets out to 0.3% across the eight. OpenSSL barely moves because its AES and SHA code was already picking AES-NI and AVX2 at runtime on the baseline build, and GCC, gzip and bzip2 sit inside the run-to-run spread. That lines up with the roughly 1% average Canonical reported from its own full-archive rebuild. These numbers come from a Skylake host; newer cores were not part of the test.
Booting amd64v3 on a CPU without x86-64-v3
Both failure cases were reproduced: the 26.10 amd64v3 ISO on a VM limited to x86-64-v2-AES, and the switched 26.04 disk from Step 2 booted with the same CPU type, which is what happens when a drive moves to an older machine. They fail identically.
Kernel panic: “Attempted to kill init! exitcode=0x00000004”
GRUB loads and the kernel boots, because both are baseline builds. The first userspace process in the initramfs is a v3 binary, so it dies on its first AVX2 instruction and the kernel panics. On a desktop with the graphical splash the only thing on screen is this:
A serial console shows the cause. Exit code 4 is SIGILL, and the trap line names the dynamic loader, the first v3 code any process runs (log trimmed to the relevant lines; six more identical modprobe traps sit at the cut):
[ 0.908901] traps: modprobe[87] trap invalid opcode ip:779bdf28cbc1 sp:7fffc11b14b0 error:0 in ld-linux-x86-64.so.2[24bc1,779bdf269000+2e000]
[ 0.909647] traps: modprobe[88] trap invalid opcode ip:78e4742e4bc1 sp:7fff2191c350 error:0 in ld-linux-x86-64.so.2[24bc1,78e4742c1000+2e000]
...
[ 1.128987] traps: init[1] trap invalid opcode ip:7f2d26089bc1 sp:7ffe8d441150 error:0 in ld-linux-x86-64.so.2[24bc1,7f2d26066000+2e000]
[ 1.129344] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000004
[ 1.138539] CPU: 0 UID: 0 PID: 1 Comm: init Not tainted 7.0.0-38-generic #38-Ubuntu PREEMPT(lazy)The 26.04 disk dies 1.13 seconds after the kernel starts, with the modprobe helper calls started by the kernel trapping first. The 26.10 ISO panics 0.758 seconds into its kernel with the identical init[1] trap invalid opcode ... in ld-linux-x86-64.so.2 line on its 7.3 kernel.
The working fix is to run the system on a v3-capable CPU again (for a VM, set the CPU type back to host and cold-start), then revert the packages with Step 5 before moving the disk. A chroot from a baseline live USB on the old machine is not a shortcut: every binary inside the chroot, including dpkg and apt, is the v3 build and traps the same way. The amd64v3 announcement on Ubuntu Discourse calls out the same restriction on moving drives between machines.
Step 5: Revert to baseline amd64 packages
Going back is the same procedure in reverse and needs no --reinstall or --allow-downgrades. Remove the setting and refresh:
sudo rm /etc/apt/apt.conf.d/99enable-amd64v3
sudo apt updateapt now treats the baseline builds as the preferred candidates and offers them as an upgrade, again with matching version strings:
Reading state information...
529 packages can be upgraded. Run 'apt list --upgradable' to see them.Apply the swap and reboot:
sudo apt upgrade
sudo rebootThe revert replaced the same 527 packages in 394 seconds. Running the dpkg-query count again shows no variant left anywhere:
196 all
548 amd64On a system installed from the 26.10 amd64v3 ISO the file to remove is /etc/apt/apt.conf.d/90arch-variant instead. After the revert the disk boots on any x86-64 CPU that the baseline Ubuntu image supports.
Where amd64v3 is worth switching on
The switch is cheap and fully reversible, so the decision comes down to which workload dominates the machine and whether its disk will ever meet an older CPU:
| Machine or workload | Switch to amd64v3? | Measured reason |
|---|---|---|
| xz-heavy jobs (packaging, archive builds, log compression) | Yes | xz -9 compression 6.1% faster |
| Heavy libzstd decompression (zstd CLI, apps linked to libzstd1) | No | zstd decompression 7.0% slower |
| Python services, SQLite, general server work | Optional | Net change under 2% |
| Machines that depend on PPAs or vendor repos | Yes, with care | Pin each third-party source to Architectures: amd64 or its packages vanish |
| 26.04 instances on a public cloud | Already done | Official cloud images ship v3 builds |
| VM templates, mixed-generation clusters, disks that move between hosts | No | Kernel panic with SIGILL on any CPU below v3 |
| Desktops and workstations | Optional | No measurable desktop gain; revert takes about 7 minutes |
The gain is workload-specific, so the number that matters is the one measured on the target hardware. Ubuntu is still well behind distributions that made the jump outright: RHEL 10 requires x86-64-v3 to install at all, while Ubuntu keeps v3 opt-in and the baseline build the default.
Tuning beyond the package build is a separate job. The Ubuntu 26.04 server performance tuning guide covers kernel, sysctl and I/O scheduler settings for the same release.
