Your distro just died: the first thirty days

The machine still boots. The desktop comes up, the browser opens, your files are where you left them, and the morning after an end-of-life announcement looks exactly like the morning before it. That is the trap. Nothing broke — a supply line closed.

What stopped is easy to underestimate. The repository stops receiving builds, then goes read-only, then goes away. Signing keys stop being rotated and eventually expire. The wiki becomes a redirect, and the forum thread containing the fix for the problem you do not have yet becomes an archive snapshot if you are lucky and a dead link if you are not. Meanwhile a clock starts: every advisory published against every package on that disk is now yours to triage, and nobody is going to file them for you.

None of that is an emergency on day one, and all of it is a decision you make by default if you do nothing. Below is a thirty-day sequence, plus the in-place conversion worked through stage by stage from the documentation — so that when I say at the bottom that most people should reinstall instead, you can check the reasoning rather than take it.

The thirty days, in one table

Day 1: the machine is now the only record of itself

Before anything is upgraded, removed or re-pointed, capture the machine — not because it is fragile, but because the information on it is about to become unobtainable. The mirror you would re-download a package from may be gone in a year, and the build you are running may exist nowhere else.

Image the disk first. A file-level backup of /home and /etc is not the same artefact as a block image you can boot in a virtual machine when a migration goes sideways at 1 a.m. Write it to external storage, verify it, and keep it off the machine you are about to modify. There is no affiliate link here for a drive; Disclosures explains why this site has none.

Export every package database, from both package managers. A distribution that bolted a binary layer onto a source base has two databases, and they disagree in interesting ways. Capture both as plain text and put them with the image:

# Portage's view of the world
qlist -ICv > installed-portage.txt        # app-portage/portage-utils
cp /var/lib/portage/world world.txt
emerge --info > emerge-info.txt

# Entropy's view of the world, on a Sabayon box
equo query installed > installed-entropy.txt

emerge --info is the file you will miss most: it records CHOST, CFLAGS, the active profile, every global USE flag and the mirrors. Gentoo’s profile-upgrade instructions tell you to write the CHOST value down before you switch profiles and to compare it again afterwards, because the switch can change it and three later steps depend on whether it did.

Capture how far /etc has drifted from what the packages shipped — the part people reconstruct from memory a month later and get wrong. qcheck, from app-portage/portage-utils, compares installed files against the checksums Portage recorded at merge time and reports the ones that no longer match:

qcheck --badonly > modified-files.txt   # no atom = every installed package

The Security Handbook documents a bare qcheck as an intrusion-detection technique; --badonly (-B) only trims the output to packages that actually have modified files. On a dying distribution it has a second use: everything in the list is either something you configured on purpose or something the distribution’s tooling did behind your back, and after the migration you have to tell those apart.

Keep the binaries, not just the list. quickpkg turns installed packages back into binary packages in PKGDIR (/var/cache/binpkgs by default) and takes atoms, package sets or a glob. Use the glob, not @world: the world set is what you asked for, and the packages you will be hunting for in week three are the dependencies nothing lists explicitly.

quickpkg "*/*"        # every installed package; the documented form
quickpkg @system      # the base alone, if disk space is the constraint

This is the most useful and least performed step on this page: when a package has been dropped from the tree upstream and you need it back three weeks into a rebuild, the copy you made on day one is the only copy there is. One caution from the documentation: quickpkg excludes CONFIG_PROTECTed files by default and --include-config overrides that, which can bake credentials out of /etc into a tarball. Handle the output as a backup, not as a mirror you publish.

Write down what you cannot reinstall. Anything under /usr/local, anything built by hand, service units you wrote, cron jobs, firewall rules, and the four packages you installed in 2019 for a reason you no longer remember. A package list does not capture provenance, and provenance is what you will be missing.

Day 2: what got more dangerous, and what did not

The honest version of this section is neither “you are fine” nor “unplug it”. Risk here is a function of what talks to the network and what it would cost you to lose the box — not of how old the version string is.

2019·03·27Take the worked example. Sabayon’s last release, 19.03, reached the mirrors on 27 March 2019 — built five days earlier, announced four days later — with Linux 4.20, Mesa 19.0, dracut for the initramfs and Calamares as the installer — what happened to Sabayon Linux has the timeline that got it there, and the release history has every image before it. The 4.20 series was never a longterm branch: upstream closed it with 4.20.17 on 19 March 2019, the same month that ISO shipped. A machine installed from that image and never rebuilt has been running an end-of-life kernel branch since before it was installed.

Kernel age is the headline and it is rarely the thing that gets you. Two quieter items matter more on a desktop.

2023·09·11The TLS stack stopped being maintained on a published schedule. OpenSSL 1.1.1 — the branch a 2019 desktop was built against — reached end of life on 11 September 2023, with no publicly available fixes after that date. Everything on the machine that speaks TLS inherits it.

2021·01·26The local privilege-escalation floor filled in behind you. Baron Samedit (CVE-2021-3156), a heap overflow in sudo affecting 1.8.2 through 1.8.31p2, 1.9.0 through 1.9.5p1 and the legacy 1.7 line, was published on 26 January 2021; PwnKit (CVE-2021-4034), in polkit’s pkexec, followed on 25 January 2022 and is in every version of pkexec since the first one in May 2009 — which is to say, on essentially every desktop install of that era. Neither is remotely exploitable, which is exactly why they matter: they convert any foothold — a bad browser day, a downloaded archive — into root on a machine that will never be patched.

So the split is:

• A desktop behind NAT with no forwarded ports. The realistic attack surface is the browser and what you download. The tractable move is a current browser from a channel that is still alive — a Flatpak runtime or an AppImage — which decouples the most-attacked program on the machine from a base nobody is fixing. It moves the front door; it does not fix the floor underneath.
• Anything with a listening service reachable from outside. SSH on a forwarded port, a home server, a VPS, a NAS with remote access. Different category: firewall it or take it off the network this week, then migrate at a sane pace.
• Air-gapped machines, retro hardware, and VMs you snapshot and revert. It genuinely does not matter. An old system with no network is a museum exhibit, not a liability.

ReasoningThe tempting middle position — “I’ll just avoid risky sites” — is false comfort. Ad networks and compromised static assets do not distinguish between careful and careless users, and an unpatched local escalation is the difference between a compromised browser profile and a compromised machine. That is judgement, not a citation.

Week 1: the nearest living base is usually one hop away

The general rule: move to the thing your distribution was derived from. Not to the distribution you like the look of — to the parent, which already shares your package names, init system, filesystem layout and usually your configuration formats. That turns a migration into an upgrade with extra steps rather than a rebuild with a data-recovery phase.

Three questions, answerable from the project’s own documentation. What was it derived from, and does that parent still ship? Did it fork anything structural — its own libc, package format or init — that the parent will not recognise? Is its package database readable by the parent’s tooling? A yes to the second means there is no hop, and knowing that in week one is worth the whole exercise.

For the case this site knows best the answers are unusually good. Sabayon · ended · verified 2026-08-04 was Gentoo with a binary distribution layer bolted on top: Entropy, driven by equo on the command line and Rigo in the GUI. Its packages had no separate build system: the Entropy tutorial on the Funtoo wiki puts it flatly — developers had to emerge a package in order to create an Entropy package from it, and there was no other way. The binary layer was a delivery mechanism for Portage output, which is precisely why an in-place conversion to Gentoo · shipping · verified 2026-08-04 is conceivable at all.

The conversion, worked: Sabayon to Gentoo in seven stages

Scope, stated where it is relevant rather than buried at the bottom: this procedure is assembled from Gentoo’s current documentation, Sabayon’s own wiki as it survives in mirror, and archived migration threads. No machine was migrated to produce it. Every step below is either documented by one of those sources — the sources list says which — or marked in the rail as reasoning. Run it on a machine you can afford to lose, with the day-one image in hand.

Before you start — decide where this box is allowed to be broken

2012·01·10Set expectations from the last people who did this in public. The Gentoo Forums thread on getting rid of Sabayon opened on 10 January 2012 and ran, in fifteen posts, to December of that year. Nobody in it gives a duration, and the person who asked the question reinstalled while waiting for an answer. What it does give is the shape of the job. One participant ran the conversion in VirtualBox and reported five things that have to be dealt with — the distribution’s mirrors in make.conf, meta-packages re-added after the sync, the profile, layman, and an installed package set they called a mess — then stopped at the point where the compiling starts, concluding that a fresh install is the better outcome because untangling the leftovers costs about what installing from scratch does. Another had done it on real machines more than once, said it demonstrably works, and recommended doing it incrementally over weeks or months while continuing to use the box. Fourteen years later both of those still hold, which tells you the constraint is structural rather than a tooling gap.

Stage 1 — stop the binary layer being authoritative

Do not uninstall Entropy. Its database is your second inventory and you may want to query it for weeks — and if you need the Portage equivalent of an equo command you already know, the translation table is in the binaries essay. Disable its repositories instead. Entropy reads general settings from /etc/entropy/repositories.conf and per-repository files from the repositories.conf.d directory beneath it, where a filename beginning with an underscore is treated as a disabled repository:

Rename the enabled repository file to give it a leading underscore, or set enabled = false inside it; the example configuration in Entropy’s own repository documents both. Note client.conf while you are there: ignore-spm-downgrades — off unless somebody turned it on — is what stopped Entropy pulling packages you had built with Portage back down to its own build of them. The two databases only ever synchronised automatically in one direction: Entropy registered what it installed, and Portage’s work had to be pushed the other way by hand with equo rescue spmsync. If you want the Entropy half of the day-one inventory to describe the whole machine, run that before you capture it. It changes nothing on the Portage side, which is the side everything below depends on.

Checkpoint: equo still runs, resolves no repository, and nothing on disk has changed. If you have to abandon the migration today, the machine is exactly as it was.

Stage 2 — make Portage current, from outside if necessary

Here is the wall nobody warns you about, and it is not Sabayon-specific: a package manager from 2019 cannot read a repository from 2026. Ebuilds carry an EAPI version and Portage refuses any EAPI it does not implement, so a tree synced today produces a sync that appears to work followed by an emerge that will do nothing at all — including upgrade Portage itself.

Two documented ways through. The narrow one, from Gentoo’s page on upgrading Portage, is to sync first and then make Portage upgrade itself alone, pinning the Python interpreter the machine already has and, only if that is what blocks it, turning repository verification off:

emerge --sync
# substitute the interpreter this machine actually has, from emerge --info
PYTHON_TARGETS="python3_8" emerge --verbose --oneshot sys-apps/portage
# only if the above fails on Python, and never sync again
# until rsync-verify is back on
PYTHON_TARGETS="python3_8" USE="-rsync-verify" emerge --ask -v1 sys-apps/portage

The order is the point, and the wiki is emphatic about the second half of it: with rsync-verify disabled the machine cannot verify a sync, so sync before you disable it and re-enable it before you sync again. If even that fails there is a last resort, a standalone rescue Portage, documented on the same page. Note also what is not available, whatever a decade-old forum thread suggests: Gentoo’s public snapshot directory carries about a week of dated trees rather than an archive of them, so there is no 2019 tree left to step forward from.

The second route is the one for a long-neglected install, and it is much less known: do not upgrade the old system from inside it. Unpack a current stage3 into a build directory, bind-mount /dev, /proc and /sys into it, bind-mount the old root at /mnt/host, and drive the old system from the new one:

# inside the chroot built from a current stage3
emerge --root=/mnt/host --config-root=/mnt/host --verbose --oneshot sys-apps/portage
emerge --root=/mnt/host --config-root=/mnt/host --update --newuse --deep --ask @world

A current Portage, running against a current tree, writing into the old root. The wiki page carrying those commands says plainly that they are guidance rather than work instructions, and that for very old systems it may be easier to start fresh and copy the configuration across. Quote both halves to yourself now rather than in week three.

ReasoningThe second of those commands rebuilds all of @world from the chroot, and on a converting machine that is the wrong moment for it: the repository list still contains the dead distribution’s overlay, so you would be resolving today’s tree against yesterday’s overlay. What you need out of stage 2 is narrower — a Portage that can read the tree, and a C library new enough for the next stage. Take those, and leave the world rebuild to stage 5, after the box has been made to describe itself correctly. Splitting the wiki’s procedure this way is inference from the order the 23.0 instructions require, not a documented instruction.

Checkpoint: emerge --version in the old root reports a current Portage, emerge --sync completes without EAPI complaints, and emerge --info shows a glibc of 2.36 or newer.

Stage 3 — the configuration that bites three weeks later

2022·08·01One prerequisite first, because it is step 1 of Gentoo’s own instructions and it is the reason stage 2 is not optional: the 23.0 profiles do not support glibc older than 2.36 or musl older than 1.2.4. glibc 2.36 was released in August 2022, so every machine frozen in 2019 is under that line by three years. The C library has to come forward before the profile does, which is exactly what the chroot in stage 2 is for. Switching the profile on a 2019 glibc is the shortest route to a machine that builds nothing.

With that done, make the box describe itself as a Gentoo machine. In order:

• /etc/portage/make.conf. Remove the distribution’s mirrors and any PORTDIR_OVERLAY. Keep your CFLAGS, MAKEOPTS and USE for now; changing compiler flags in the same week as everything else is how you end up unable to bisect a failure.
• /etc/portage/repos.conf. Keep gentoo; remove sabayon-distro and any layman leftovers under /var/lib/layman. That overlay carried both the ebuilds that could not be upstreamed and the profile the system was using, so it goes before the profile switch, not after.
• package.keywords, package.mask, package.use. Read every line and delete the distribution-specific ones — the first thing the 2012 thread told the person asking to do, and still the step that stops a rebuild dead when a mask nobody remembers writing hides a package the toolchain now needs.
• The profile. eselect profile list, then eselect profile set a 23.0 profile matching what the machine already is. Gentoo’s 23.0 news item is specific about the traps: note CHOST from emerge --info first, remove CHOST and CHOST_* definitions from make.conf, and — its own emphasis — do not change the split-usr or merged-usr property in the same step, because that will wreck the system. Re-run emerge --info afterwards: if CHOST changed, three extra steps apply before env-update, and they are in stage 5.
• ACCEPT_LICENSE. The quiet one. Sabayon shipped proprietary drivers and codecs preselected; Gentoo’s base profile sets ACCEPT_LICENSE="-* @FREE", so anything that is not free software is refused until you say otherwise. Set it deliberately now, or discover it when the NVIDIA driver your desktop depends on becomes uninstallable in the middle of stage 5.

Checkpoint: emerge --info shows a 23.0 profile, no Sabayon repositories, and a CHOST you recognise.

Stage 4 — point at the binhost, because 2026 has one

Every migration write-up older than a couple of years assumes you will compile the entire system. You no longer have to. Gentoo runs an official binary package host, and configuring it before the rebuild is the difference between a migration measured in days and one measured in weekends:

# /etc/portage/binrepos.conf/gentoobinhost.conf
[gentoo]
priority = 9999
sync-uri = https://distfiles.gentoo.org/releases/amd64/binpackages/23.0/x86-64/
verify-signature = true
location = /var/cache/binhost/gentoo

# /etc/portage/make.conf
FEATURES="getbinpkg binpkg-request-signature"

# trust the Gentoo release engineering keys
getuto

2026·05·03Two changes from May 2026 will meet you here. Portage 3.0.78 turned on binary package signature verification by default for every binary repository, and remote binaries are now cached per repository under /var/cache/binhost/NAME rather than mixed in with locally built ones. Point at anybody’s unofficial binhost — a community repository, your own build box — and it must either sign its packages or be marked verify-signature = false, or fetches fail verification. Official-binhost users need only let getuto install the keyring. On the trust objection Sabayon veterans have been arguing about since 2008, that is the answer: signed binaries, verified by default. Entropy had a GPG layer of its own — the binaries essay corrects the received story on that point — but verification switched on by default in the mainline package manager is the part that took until 2026.

One behaviour to understand before it confuses you: Portage only uses a binary package when its USE flags match what your configuration asks for. A heavily customised make.conf gets you source builds anyway. That is a knob, not a bug.

Stage 5 — rebuild in the order that keeps the machine bootable

Toolchain first, in separate steps, in this order. Gentoo’s 23.0 instructions are explicit, including a warning worth reading twice:

rm -r /var/cache/binpkgs/*
emerge --ask --oneshot sys-devel/binutils
# if this wants to rebuild glibc first: abort, and re-run with --nodeps
emerge --ask --oneshot sys-devel/gcc
emerge --ask --oneshot sys-libs/glibc
# confirm CHOST, and that the new toolchain is selected
emerge --info
gcc-config -l && binutils-config -l
env-update && source /etc/profile
emerge --ask --oneshot libtool
emerge --ask --emptytree @world

If CHOST changed at the profile switch, re-select binutils and gcc and remove files referring to the old value from /etc/env.d — including /etc/env.d/binutils and /etc/env.d/gcc — before env-update. Either way, clear /var/cache/binpkgs again before the world rebuild, so nothing built against the old toolchain sneaks back in.

ReasoningThat last command is the one to break up. emerge --emptytree @world in a single pass on a desktop you are still using is how people end up with a machine that is neither the old system nor the new one. Run it with --keep-going so one failure does not abort the queue, run it in sessions, and stay out of the graphical session while libraries underneath it are being replaced. Splitting the rebuild is inference from how Portage behaves, not a documented instruction; the command itself is documented.

Checkpoint, and this one is not optional: reboot before stage 6, on the old kernel, and confirm the machine still comes up and the desktop still starts. This is the last point at which restoring the day-one image is cheap.

Stage 6 — the kernel decides whether the machine comes back

The distribution’s kernel package is going away, and it owns your boot. Do not remove it first. Install its replacement alongside, boot it twice, and only then clean up. The low-drama 2026 option is a binary distribution kernel, which avoids a ninety-minute kernel build in the middle of a migration:

# make installkernel generate an initramfs and a bootloader entry
echo 'sys-kernel/installkernel dracut grub' >> /etc/portage/package.use/kernel
emerge --ask sys-kernel/installkernel
emerge --ask sys-kernel/gentoo-kernel-bin sys-kernel/linux-firmware

Gentoo’s distribution kernels expect to be installed alongside an initramfs, and sys-kernel/installkernel is what wires that up: with the dracut USE flag it regenerates an initramfs whenever a kernel is installed, and with grub it updates the bootloader configuration. Keep the old kernel, its initramfs and its boot entry until the new one has come up twice, including once from cold with the external drive unplugged.

Checkpoint: the machine boots the new kernel unattended, networking comes up, and the display manager starts.

Stage 7 — the configuration files that fight you

A rebuild of this size leaves hundreds of pending configuration updates. Portage does not overwrite files in CONFIG_PROTECT directories; it parks the new versions as ._cfg0000_ files and waits for you. You have two tools, and the choice matters more here than in normal use:

• etc-update is fast, interactive and forgets everything it did.
• dispatch-conf keeps history — it stores the differences as patches or under RCS, and it auto-merges changes that are only comments or whitespace. It needs /etc/dispatch-conf.conf edited and the directory named by archive-dir created before first use.

On a converted machine, use dispatch-conf: you will make a wrong call on at least one file, and being able to retrieve last week’s copy is worth the extra minute of setup. Never blanket-accept. The files that hurt are fstab, service units, PAM and nsswitch.conf, sudoers, the display manager’s configuration and /etc/default/grub — and your day-one modified-files.txt is precisely the list of files where your version differs from the shipped one, which is precisely where the merge decision is not obvious.

Three ways it goes wrong, and the way back from each

The verdict: most people should reinstall, and here is when they should not

Having documented the conversion in full: for most machines it is the wrong choice. A clean install of a living base — the candidates are compared cell by cell in the five candidates for “Sabayon in 2026” — with configuration restored from the day-one capture takes less wall-clock time, ends in a system with no archaeological layer, and fails in ways that are easy to diagnose because everything on the disk arrived the same way. The 2012 thread reached that conclusion; Gentoo’s upgrade documentation says something similar about very old systems; and the binhost has strengthened the case, because a fresh install that pulls binaries is far faster than it was when that thread was written, while the conversion still has to reconcile every file the old distribution touched.

Convert in place when one of these is true, and be honest about which:

• The machine carries local state you cannot reproduce — databases, licensed software, hand-built toolchains, a lab configuration that took a year — and downtime is expensive. Then the conversion’s incremental nature is the whole point: the box keeps working throughout.
• The hardware boots with the old kernel and not with a current installer. Rare, real, and usually about odd storage or graphics.
• You want the archaeology. Understanding exactly how the distribution differed from its parent is a legitimate reason, and the conversion teaches it better than any document. Do it on a machine that is not load-bearing.

Everyone else: keep the image, keep the inventory, reinstall, and spend the saved time restoring the twelve configuration files that actually mattered.

Appendix A: an inventory script you can paste

Run as root, on the dying machine, before changing anything. It writes a dated directory containing everything referenced in the day-one section. Copy that directory off the machine — it is the artefact, and leaving it on the disk you are about to rebuild defeats the purpose.

#!/bin/sh
# Freeze the record of a machine whose distribution has ended.
# Missing tools are skipped, not fatal: this runs on a system that
# may no longer be able to install anything.
set -u
OUT="/root/freeze-$(date +%Y%m%d)"
mkdir -p "$OUT" || exit 1

have () { command -v "$1" >/dev/null 2>&1; }

uname -a            > "$OUT/uname.txt"      2>&1
cat /etc/os-release > "$OUT/os-release.txt" 2>&1
lsblk -f            > "$OUT/lsblk.txt"      2>&1
cp /etc/fstab         "$OUT/fstab.txt"      2>/dev/null

# Portage side
have emerge && emerge --info > "$OUT/emerge-info.txt" 2>&1
have qlist  && qlist -ICv   > "$OUT/pkgs-portage.txt" 2>&1
have qcheck && qcheck --badonly \
                            > "$OUT/modified-files.txt" 2>&1
cp /var/lib/portage/world     "$OUT/world.txt"   2>/dev/null
cp -a /etc/portage            "$OUT/etc-portage" 2>/dev/null

# Binary-layer side (Entropy; skipped where absent)
have equo && equo query installed \
                            > "$OUT/pkgs-entropy.txt" 2>&1
cp -a /etc/entropy            "$OUT/etc-entropy" 2>/dev/null

# Things no package list records
ls -la /usr/local   > "$OUT/usr-local.txt"    2>&1
crontab -l          > "$OUT/crontab-root.txt" 2>&1

tar -C "$(dirname "$OUT")" -czf "$OUT.tar.gz" "$(basename "$OUT")"
echo "Written: $OUT.tar.gz — copy this off the machine now."

It deliberately does not touch /home. That is a backup job with different rules, and conflating the two is how people end up with an inventory they trust and a home directory they do not.

Appendix B: the three things people mean by “supported”

Most arguments about whether a dead distribution is “still supported” are two people using the word for different things. There are three, and they fail in this order:

1. Someone ships fixes for the version you are running. Ends first, usually before the announcement, and it is the only one that maps to security.
2. Someone will answer your question. Can outlive the first by years: the parent distribution’s forum will still help you, and the archived wiki still contains true things. It is also the one people mistake for the first.
3. The machine can still talk to its repository. The one your machine can observe, and it ends last — mirrors go read-only, then stop resolving, then signing keys expire. When somebody says “it still works”, this is usually what they tested.

The uncomfortable implication is that the meaning that matters for risk is the one you cannot see from the machine. Nothing on your desktop changes on the day support ends, which is the whole reason this page starts on day one instead of the day something breaks.

Standing — 2026-08-04

Still true

The binhost configuration, getuto, and the signature-verification behaviour described here match Portage as of the 2026-05-03 news item. The 23.0 profile procedure, the toolchain order and the dispatch-conf and quickpkg behaviour are as documented on the dates in the sources list.

Ended / rotted

Sabayon’s own wiki host, wiki.sabayon.org, did not resolve from here on 2026-08-04; the surviving mirror is sabayon.github.io/wiki-next and it is partial. Entropy repository URLs in any surviving configuration file are dead. Every mirror link in the 2012 migration thread is gone, which is the reason this page exists in the form it does.

Actively wrong now

Forum advice that tells you to run emerge -e world in one pass on a live desktop. Any guide that assumes you must compile the entire system — that stopped being true when the official binhost arrived. Advice to sync to a dated tree snapshot from the year the distribution died: the public snapshot directory held eight days of them when this page was checked, not an archive. And anything recommending you mix equo and emerge routinely; both projects’ documentation warned against it at the time.

Not established

Whether the --root chroot procedure works cleanly against a Sabayon root specifically: it is documented for Gentoo roots, and a Sabayon root carries overlay-provided packages that a current tree has never seen. Which OpenSSL point release 19.03 shipped — the 1.1.1 branch end-of-life date is sourced, the exact version on that ISO is not. Whether every Entropy-installed package left complete Portage metadata behind, as opposed to most of them; the documented synchronisation command runs the other direction, and this page is written so that the answer does not change any step.

Sources & method

Written from vendor documentation, project release notes, security advisories and archived discussion. No machine was migrated to produce this page and nothing here is a report of first-hand use; where a step is inference from documented behaviour rather than a documented instruction, it is marked in the rail. All URLs accessed 2026-08-04.

1. Gentoo Linux news item, “Profile upgrade to version 23.0 available”, 2024-03-22, gentoo.org/support/news-items — the glibc 2.36 / musl 1.2.4 floor, the profile switch, CHOST handling, the split-usr warning, the --nodeps remedy on the gcc step, the toolchain order, the two ${PKGDIR} clear-outs and --emptytree.
2. Gentoo Linux news item, “Portage binpkg changes”, 2026-05-03, Sam James, gentoo.org/support/news-items — signature verification on by default, /var/cache/binhost/NAME, the verify-signature escape hatch.
3. Gentoo Wiki, “Gentoo Binary Host Quickstart”, wiki.gentoo.org/wiki/Gentoo_Binary_Host_Quickstart — the binrepos.conf stanza quoted above, FEATURES, getuto.
4. Gentoo Wiki, “Binary package guide”, wiki.gentoo.org/wiki/Binary_package_guide — getbinpkg, binpkg-request-signature, USE matching against binaries, quickpkg and its CONFIG_PROTECT caveat.
5. Gentoo Wiki, “Upgrading Gentoo”, wiki.gentoo.org/wiki/Upgrading_Gentoo — the stage3 chroot procedure, the --root and --config-root commands, and its own caution that starting fresh may be easier.
6. Gentoo Wiki, “Portage/Help/Upgrading Portage”, wiki.gentoo.org/wiki/Portage/Help/Upgrading_Portage — EAPI refusal on an old Portage (“The current version of portage supports EAPI '7'”), the escalation from a plain --oneshot upgrade to PYTHON_TARGETS to USE="-rsync-verify", the warning not to sync while verification is off, and the rescue Portage of last resort.
7. Gentoo mirrors, distfiles.gentoo.org/snapshots — checked 2026-08-04: the dated portage-YYYYMMDD.tar.xz trees on offer spanned 2026-07-27 to 2026-08-03, which is why “sync to a snapshot from the year it died” is not a route.
8. Gentoo repository, profiles/base/make.defaults — ACCEPT_LICENSE="-* @FREE" as the profile default, with the comment explaining the licence group.
9. GNU C Library releases, ftp.gnu.org/gnu/glibc — glibc-2.36.tar.xz dated 2022-08-01, which places the 23.0 profiles’ minimum three years after any system frozen in 2019.
10. Gentoo Handbook (AMD64), “Portage tools”, wiki.gentoo.org/wiki/Handbook:AMD64/Portage/Tools — dispatch-conf, archive-dir, CONFIG_PROTECT, quickpkg and PKGDIR.
11. Gentoo Wiki, “q applets”, wiki.gentoo.org/wiki/Q_applets — qlist, qcheck, qfile, and the app-portage/portage-utils package they come from.
12. Gentoo Wiki, “Security Handbook: intrusion detection”, wiki.gentoo.org/wiki/Security_Handbook/Intrusion_detection — a bare qcheck as a way to list files that no longer match what was installed. The --badonly flag is read from qcheck’s own option list in portage-utils, qcheck.c, which is also where you can confirm that there is no --all option and that a bare invocation already covers every installed package.
13. Gentoo Wiki, “Distribution Kernel” and “Installkernel”, wiki.gentoo.org/wiki/Distribution_Kernel — gentoo-kernel-bin, the initramfs expectation, and the dracut and grub USE flags on sys-kernel/installkernel.
14. Sabayon Wiki mirror, “Entropy Package Manager”, sabayon.github.io/wiki-next/articles/entropy — equo usage and the Entropy-to-Portage relationship.
15. Sabayon/entropy repository, conf/repositories.conf.d and client/doc/mansrc/equo-query.1.txt — the configuration paths quoted above, the underscore-disables-a-repository convention, and equo query installed.
16. Funtoo Wiki, “Entropy”, funtoo.org/Entropy — equo rescue spmsync, ignore-spm-downgrades in client.conf, and the statement that Entropy packages had to be produced by emerge.
17. Gentoo Forums, “Getting rid of Sabayon after all…”, 15 posts, 2012-01-10 to 2012-12-20, forums.gentoo.org/viewtopic-t-908704 — archived discussion; the package.keywords/package.mask/package.use advice, the mirrors, profile and layman findings from the VirtualBox attempt, the “about the same as a fresh install” conclusion, and the recommendation to migrate incrementally over weeks or months. Read as evidence of what people did, not as instructions.
18. Phoronix, “Gentoo-Based Sabayon 19.03”, March 2019, phoronix.com/news/Sabayon-19.03-Released — secondary; kernel 4.20, Mesa 19.0, dracut, Calamares, full-disk encryption.
19. The Linux Kernel Archives. cdn.kernel.org/pub/linux/kernel/v4.x — linux-4.20.17.tar.xz, dated 19 March 2019, is the last file in the 4.20 line, and ChangeLog-4.20.17 carries the “Linux 4.20.17” commit of the same date. kernel.org/releases.html — the longterm table, which 4.20 never appeared in. (Retired series are no longer listed on that page, which is why the archive is cited for the date.)
20. OpenSSL, “OpenSSL 1.1.1 End of Life”, openssl.org/blog — 11 September 2023, and no publicly available fixes after it.
21. Qualys, “CVE-2021-3156: heap-based buffer overflow in sudo (Baron Samedit)”, 2021-01-26, blog.qualys.com, with the affected version ranges from the sudo project advisory.
22. Qualys, “PwnKit: local privilege escalation in polkit’s pkexec (CVE-2021-4034)”, 2022-01-25, blog.qualys.com.

Found an error, or migrated a machine and hit something this page gets wrong? [email protected]. Corrections are logged on Corrections.