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 Thu Aug 11 17:36:42 UTC 2011 Any time in 2019 that qualifies as old and out of date

Profile
default/linux/amd64/10.0 default/linux/amd64/10.0/desktop default/linux/amd64/10.0/desktop/gnome default/linux/amd64/10.0/desktop/kde default/linux/amd64/10.0/developer default/linux/amd64/10.0/no-multilib default/linux/amd64/10.0/server hardened/linux/amd64 hardened/linux/amd64/selinux hardened/linux/amd64/no-multilib * hardened/linux/amd64/no-multilib/selinux selinux/2007.0/amd64 selinux/2007.0/amd64/hardened selinux/v2refpolicy/amd64 selinux/v2refpolicy/amd64/desktop selinux/v2refpolicy/amd64/developer selinux/v2refpolicy/amd64/hardened selinux/v2refpolicy/amd64/server

binutils
Blue_Test ~ # binutils-config -l [1] x86_64-pc-linux-gnu-2.21.1 *

gcc
Blue_Test ~ # gcc-config -l [1] x86_64-pc-linux-gnu-4.5.3 * [2] x86_64-pc-linux-gnu-4.5.3-hardenednopie [3] x86_64-pc-linux-gnu-4.5.3-hardenednopiessp [4] x86_64-pc-linux-gnu-4.5.3-hardenednossp [5] x86_64-pc-linux-gnu-4.5.3-vanilla

Kernel
Blue_Test ~ # uname -a Linux Blue_Test 2.6.39-hardened-r8 #1 SMP Thu Jul 28 19:39:39 BST 2011 x86_64 AMD Phenom(tm) 9550 Quad-Core Processor AuthenticAMD GNU/Linux

World
It was a fairly minimal install for firewall testing app-admin/metalog app-admin/sudo app-portage/gentoolkit app-portage/ufed app-text/wgetpaste net-analyzer/tcpdump net-misc/dhcpcd net-misc/ntp sys-apps/ethtool sys-apps/portage sys-apps/usermode-utilities sys-boot/grub-static sys-devel/gettext sys-kernel/hardened-sources sys-libs/gpm sys-process/dcron 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

emerge -uDNav world etc-update

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

Install git
Blue_Test ~ # emerge git -av * IMPORTANT: 2 news items need reading for repository 'gentoo'. * Use eselect news to read news items. * Last emerge --sync was 8y 21d 4h 12m 6s ago. These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild  R    ] dev-vcs/git-1.7.6  USE="blksha1 curl iconv perl python threads webdav -bash-completion -cgi -cvs -doc -emacs -gtk (-ppcsha1) -subversion -tk -xinetd" 0 kB Total: 1 package (1 reinstall), Size of downloads: 0 kB Would you like to merge these packages? [Yes/No]

Git is already installed. That was an unexpected bonus.

Shuffle repos
Move the old repo out of the way. mv /usr/portage /usr/portage_old Clone the git ::gentoo repo mkdir /usr/portage cd /usr/portage git clone https://anongit.gentoo.org/git/repo/gentoo.git ./

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.

cd /etc rm make.profile ln -s ../usr/portage_old/profiles/hardened/linux/amd64/no-multilib make.profile

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. Blue_Test ~ # emerge -uDNav world These are the packages that would be merged, in order: Calculating dependencies \ * Missing digest for '/usr/portage/sys-fs/sysfsutils/sysfsutils-2.1.0.ebuild' / * Manifest not found for '/usr/portage/virtual/pager/pager-0.ebuild' | * Manifest not found for '/usr/portage/virtual/ssh/ssh-0.ebuild' ...

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 Thats all the ebuilds that were ever in the ::gentoo repository.
 * /usr/portage 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 !!! All ebuilds that could satisfy "virtual/pkgconfig" have been masked. !!! One of the following masked packages is required to complete your request: - virtual/pkgconfig-0-r1::gentoo (masked by: EAPI 5) The current version of portage supports EAPI '4'. You must upgrade to a newer version of portage before EAPI masked packages can be installed.

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 cd /usr cvs -d :pserver:anonymous@anoncvs.gentoo.org:/var/cvsroot co -D "2011-08-11 GMT" gentoo-x86 ln -s gentoo-x86 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 cd /usr cvs -d :pserver:anonymous@anoncvs.gentoo.org:/var/cvsroot co -D "2012-09-01 GMT" gentoo-x86 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.

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

Calculating dependencies - * Digest verification failed: * /usr/gentoo-x86/sys-libs/glibc/glibc-2.15-r2.ebuild * Reason: Filesize does not match recorded size * Got: 8000 * Expected: 7994

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

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

FEATURES variable contains unknown value(s): fixpackages * IMPORTANT: 2 news items need reading for repository 'gentoo'. * Use eselect news to read news items. *  * The FEATURES=digest setting can prevent corruption from being noticed. * The `repoman manifest` command is the preferred way to generate * manifests and it is capable of doing an entire repository or category at * once. *
 * 1) GENTOO_MIRRORS="" FEATURES="digest assume-digests" emerge -1av portage

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 fer the reader.

Don't forget about perl-cleaner python-updater revdep-rebuild etc-update DEVTMPFS=y in the kernel CPU_FLAGS_X86= Not all of these may apply to your case. You might even find a few more.