User:NeddySeagoon/HOWTO Update Old Gentoo

HOWTO Update Old Gentoo
This is mostly for the educational experience and to write this document to show what can be done if you really really have to do it.

Background
Some time ago, it looks like mid 2011, my four or five discrete systems were retired in favour of a Gen7 HP Microserver running KVMs to replace the physical servers. The power savings paid for the Microserver in 18 months and its still going.

The poor wee thing struggled in only 8G of RAM and I wanted to run another KVM. I upgraded to 16G RAM, that's double the maximum its supposed to take but that's another HOWTO.

In 2011, one of the services moved to a KVM was my router. It was originally Smoothwall 3 on a 233MHz Pentium. To be able to test the KVM implementation I created a number of throw away KVMs for testing, before I exposed real hardware to the new router.

Of course, being throw away KVMs, they were never thrown away, they were just shut down and left.

Being in need of another KVM, I thought it might be fun to attempt to upgrade a 2011 Gentoo install, rather that install a new KVM.

The Starting Point
The datestamp on the gentoo repo

Any time in 2019 that qualifies as old and out of date

World
It was a fairly minimal install for firewall testing

The process described here should work for any type of install. The ebuilds are available. The hard bit is finding old source code. Its a process document, not a step by step guide. This example does not have a desktop or even a window manager. Updating KDE or GNOME should be more of the same.

Plan A - Just Go For It

 * Install git
 * Move the old repo out of the way, so we can still refer to it for bits and pieces.
 * Get an up to date ::gentoo repo

An eight year old portage with a current repo ...

Install git
Git is already installed. That was an unexpected bonus.

Shuffle repos
Move the old repo out of the way.

Clone the git ::gentoo repo

Fix the Profile Definition
The current profile has been removed, so to put off dealing with profile updates change the /etc/make.profile symbolic link to point to the copy in the repo we saved earlier.

Plan A Summary
The old system is intact, with its original profile and a current ::gentoo repo.

In theory, in a perfect world, just works.

The old portage  knows nothing of the new manifest format, and lots of other things besides, so this approach ends here.

Plan B Use a git/CVS Repo

 * Move the old repo out of the way, so we can still refer to it for bits and pieces.
 * Use a git repo, to do easy checkouts by dates.
 * Fall back to a CVS repo if required
 * Incrementally update stage 1 by running

is the script used to do the stage 1 part of a stage 1 install. Its still in the git tree. Its not going to be quite that easy as there will be at least two profile changes along the way.

Plan B - Implementation
The first two steps were completed as part of Plan A. We need to see how far git goes back ... looks about the limit. Its not far enough.

Time to rinse and repeat with CVS.

First build CVS

Put the old Portage back. installed dev-vcs/cvs-1.12.12-r9. It even found the source code.

Open port 2401 in your firewall.

Now we have three copies of the ::gentoo That's all the ebuilds that were ever in the ::gentoo repository.
 * as it was in 2011
 * from git with all the git history
 * from CVS until it was migrated to git

The CVS Tree
Getting closer

Portage understands the manifests now, just not the EAPI.

Lets go back in time and use a cvs checkout that is almost the same as our portage

This is just for testing. Using a cvs checkout as the repo is not quite as straight forward as as a git clone.

Once that works, go forward a year

and do the update.

After rummaging around with help from Google, I found all the bits I needed to make the update run. It was quite a nostalgia trip, using a portage from 2011.

My system has moved forward a year. There have been no profile updates yet.

Plan C
This is a refinement of plan B and probably the right way.

Gentoo tries to keep an upgrade path for about a year, so lets try one year steps. Before you cross an EAPI boundary, you need a new portage that understands the new EAPI.

Overview

 * Get a suitable ebuild repo (CVS or git)
 * to fetch sources.
 * Find missing sources or delete old ebuilds that won't be used ... or both.
 * , then switch to the new versions.
 * to actually update.
 * or
 * read NEWS and act on it
 * update kernel
 * (carefully)
 * reboot into new kernel
 * tidy up as required
 * Rinse and repeat at annual intervals.
 * reboot into new kernel
 * tidy up as required
 * Rinse and repeat at annual intervals.

Timesavers
Set GENTOO_MIRRORS="" That's not the same as leaving GENTOO_MIRRORS unset. The former instructs portage not to use the gentoo mirror system at all, the latter permits the use of a default set of mirrors.

Source code is removed from the gentoo mirror system at the same time as ebuilds are removed from the tree. This setting tells portage to use the SOURCE_URI list in the ebuild to locate source files without checking the mirrors first.

The NEWS System
Gentoo News items are normally distributed with. As this process uses cvs and git repos directly, other arrangements need to be made for reading news items.

What action, if any, needs to be taken in response to news is install specific.

The Attic
Many things will have been moved to the Attic. This changes the headers in the ebuilds but not the digests.

Notice the header

Its grown an "/Attic" to make the ebuild 6 characters longer.

The choices are fix the ebuild headers or fix the digests. Fixing headers to match the existing digests is more secure. Fixing the digests is faster since portage offers FEATURES="digest"

Understand the security implications before you make your choice. I used the FEATURES="digest" method. My sed foo is far too weak to fix the ebuild headers.

The Repo Itself
Recreating all the digests for packages that portage wants to install requires all the sources for all the ebuilds in the ebuild leaf directory. That's fine if you have or can find all the sources.

In practice, any ebuild that will not be used can be removed. That limits source code finding to the absolute minimum.

https:// connections
Don't even think about it on an old system.

Source files that are on a SSL protected server are out of reach of on old system. Certificates have been changed and SSL protocols have changed. Download such source files via an intermediate system.

Trying is harmless.

Warts on My System
My system is 64 bit only. It boots using grub-static, which requires 32 bit support in the kernel to install. My kernels do not have 32 bit support so installing grub-static fails. Use portages  for cases like this. More permanently, use package.mask

Other Pitfalls
In no particular order.

Its, not

Old is a bit aggressive. Its a very bad thing to let it rip out eselect-python as that breaks emerge. Fixing it is left as an exercise for the reader.

Don't forget about perl-cleaner --all python-updater revdep-rebuild etc-update DEVTMPFS=y in the kernel CPU_FLAGS_X86= keeping the kernel up to date switch from udev to eudev sshd changed to prohibitpassword for root

Not all of these may apply to your case. You might even find a few more.

Using cvs
For testing and working out how to use a cvs repo as the ::gentoo tree. cvs -d :pserver:anonymous@anoncvs.gentoo.org:/var/cvsroot co -D "2011-09-01 GMT" gentoo-x86

cvs -d :pserver:anonymous@anoncvs.gentoo.org:/var/cvsroot co -D "2012-09-01 GMT" gentoo-x86 The first step up. That was difficult. Finding sources and removing ebuilds that were not required were the problem areas.

cvs -d :pserver:anonymous@anoncvs.gentoo.org:/var/cvsroot co -D "2013-09-01 GMT" gentoo-x86 This was actually two steps as EAPI 5 was introduced. A portage that understands EAPI 5 was required to get to 2013-09-01 GMT.

The /10.0/ to /13.0/ profile change was here too.

cvs -d :pserver:anonymous@anoncvs.gentoo.org:/var/cvsroot co -D "2014-09-01 GMT" gentoo-x86

Switched to eudev.

Tidying Up
Depending on how much free space is available, this step may need to be performed more or less frequently. Its documented here as this is a good time, before moving to a git ::gentoo repo. Remove old kernels from /usr/src Remove /var/tmp/portage, or its contents. eclean -d {packages distfiles} Remove /var/log/portage

Moving to git
To free up space, the  cvs repo can be removed.

Get the entire ::gentoo git repo.

Fix the /usr/portage symlink to point to gentoo-git, rather than gentoo-x86. Thats the entire ::gentoo git repo as it was at the time of the clone. For me, the newest commit is  As we are still 5 years out of date, we can't use that as is.

Using git
The first commit (all of the cvs gentoo-x86) was Saturday Aug 8 2015. The next step is from git. That fits nicely with the annual Sep 1st steps.

This puts the HEAD of the git repo at

The is no longer required. Git does not have an attic.

As the repo path was changed from  to

Fix /etc/portage/repos.conf

Fix /etc/portage/make.profile

If ssh password login for root is required, check sshd_config before the reboot.

2016
Only sources for eight packages no longer available from the SOURCE_URI= in the ebuilds. Once you get to three years old, the GPL requires that sources can still be obtained, so it gets easier then. Obtained does not mean on line.

There in no need to detail the steps any more.

Up To Date
I still have the migration to the 17.1 profile to do.