Re: [gentoo-user] Booting a Kernel-2.4 with glibc-2.9?

[daid kahl]

>
> On Wednesday 08 July 2009 17:13:16 daid kahl wrote:
> > Hello,
> >
> > I'm working on upgrading a very old Gentoo system for my work.
> >
> > Some software is only running well in 2.4.x kernels, and when doing other
> > updates I inadvertently updated past glibc-2.3.5, and so now the 2.4
> kernel
> > does not boot (Fatal error, kernel too old).  Fortunately there is a 2.6
> > kernel on the system so I can still boot.
>

> > Is there any known workaround for booting a 2.4 kernel on a system with
> > glibc-2.9 installed?
>


>
> In the time it takes you to sort that mess out (including doing the
> necessary
> research), I reckon you could do the following:
>
> 1. Backup all user data, configs and critical files
> 2. Download a recent stage that suits your needs
> 3. Rebuild world plus add all the extra packages you use
>
> and do the whole lot three times.


> alan dot mckinnon at gmail dot com
>

I have successfully installed a Gentoo system from source that is capable of
booting a 2.4 kernel.  Although such a task relies on deprecated source code
and is officially unsupported, I'll give a brief outline of how I tackled
this task in case another person faces a similar problem and needs a fresh
system for running Gentoo with a 2.4 kernel.

The first thing is we need a stage that is 2006.0 or earlier, since all the
later Gentoo stages use versions >=glibc2.4 which won't be friendly with 2.4
kernels.  The oldest stage available at gentoo.org is 2006.1, so one needs
to find an old and outdated Gentoo mirror.  Such a mirror exists as of this
writing: http://linux.mirrors.es.net/gentoo/releases/

As I have a functional 2.6 kernel on the target machine, I don't bother with
a Live CD, but one could also use any Gentoo Live CD for the task.  Using a
free partition, we can install the new system for linux-2.4 and tell Grub to
mount the 2.4 kernel using this different root filesystem.  This allows for
the peaceful co-existence of an up-to-date linux-2.6 system and a 2.4 system
on different partitions.  I assume for this you can properly set up the
fstab file correctly on each system.

So, I mount my target partition for 2.4 at /mnt/gentoo and unpack
stage3-x86-2006.0.tar.bz2 (or the corresponding stage for your architecture)
as with any Gentoo install.  Before you chroot, you'll also want to download
an old portage snapshot (I used portage-20060123.tar.bz2) before you emerge
--sync.  The reason is that newer portage has some slightly different
layouts, and some trouble is encountered going straight from a 2006.0 stage
to a new portage system, particularly in the realm of make.profile.  The
last thing before chroot is to create a bash-3.1_p17 overlay.  So on your
up-to-date Gentoo system, emerge --fetchonly =app-shells/bash-3.1_p17 and
then copy the necessary source code into, say,
/usr/local/portage/app-shells/bash/files and put the ebuild in
/usr/local/portage/app-shells/bash, and then tar and zip this directory and
copy it over to /mnt/gentoo.

Now we can copy our network settings such as /etc/resolv.conf
/etc/conf.d/hostname and /etc/conf.d/net to the appropriate locations in
/mnt/gentoo, unless you want to manually configure all that after you
chroot.

Mount dev and proc to /mnt/gentoo/proc and /mnt/gentoo/dev and (assuming you
can write or copy /mnt/gentoo/etc/make.conf with the settings you want from
somewhere) chroot, env-update, and source /etc/profile.

To make sure you never accidentially update glibc so that kernel 2.4 will
refuse to boot:
# echo ">=sys-libs/glibc-2.4" >> /etc/portage/package.mask

Before emerge --sync, you want to upgrade bash through an overlay.  I'm not
clear as to why we can't just emerge --sync and update portage, but there
was a lot of trouble with make.profile, bash, and some other things when I
omitted this step and I couldn't get a functional system.  It could have
been user error, but this step is fairly painless, and because updating from
an old version of portage to a newer version is blocked by bash anyway, this
is already a necessary step one way or the other.

Edit /etc/make.conf and add a PORTDIR_OVERLAY which I use as
/usr/local/portage, and untar the bash-3.1_p17.tar.gz into
/usr/local/portage/app-shells.  Then you can easily emerge
=app-shells/bash-3.1_p17 and update bash.

Now emerge --sync, and then toy around with make.profile symlinks until you
find something that will work with your achronisitic system (a lot of
profiles will complain about ARCH settings or missing keywords, and I found
/usr/portage/profiles/hardened/x86/minimal to work for the next steps)

In principle, the next goal is to simply upgrade portage, but it's not
entirely trivial. Since we only have python-2.4, and because portage-2.1.4.5
is still in the portage tree (and does not require python-2.5 as a
dependency), I go for this version of portage.  I had tried to upgrade to
python-2.5, but this is a circular dependency as it needs a version of
portage newer than portage-2.0.54 included in the 2006.0 stage.

There will be three dependencies that need to be upgraded first before
portage:
lzma-utils
pax-utils
sandbox

lzma-utils and pax-utils are fine, except that with the sync'd portage tree
and old portage, we have to ebuild digest the packages by hand and emerge
again for sucessful install.

The sandbox source is packaged as a .tar.lzma, but older portage will not
suppot .lzma, so emerging sandbox is a little more work.  I updated tar
after lzma just to be safe, but I can't confirm it's necessary.

Emerging sandbox is similar to those instructions posted at
http://www.void.gr/kargig/blog/tag/lzma/ , but since the 2006.0 stage has an
even older version of portage, it's not exactly done as written there and I
explicity write the differences here.

First you can emerge --fetchonly =sys-apps/sandbox-1.6-r2, and then:

# mkdir /var/tmp/portage/sandbox-1.6-r2 && cp
/usr/portage/distfiles/sandbox-1.6.tar.lzma /var/tmp/portage/sandbox-1.6-r2/

The sandbox ebuild needs to be modified so that it reads:

src_unpack() {
unpack ${A}
cd /var/tmp/portage/sandbox-1.6-r2/
tar --lzma -xvf sandbox-1.6.tar.lzma -C
/var/tmp/portage/sandbox-1.6.2-r2/work/
cd "${S}"
epatch "${FILESDIR}"/${P}-disable-qa-static.patch
epatch "${FILESDIR}"/${P}-disable-pthread.patch
epatch "${FILESDIR}"/0001-libsandbox-handle-more-at-functions.patch
}


The only difference is that I've added the second and third lines (starting
with cd, tar, respectively).  Then manually digest the ebuild, emerge.

At this point, we can emerge portage, which will also require a manual
digest and emerge again for success!  Since there are some other files the
portage will want to upgrade (but are not explicit dependencies), I emerge
--nodeps on my version of portage.  This is mainly because I didn't want to
switch to the newer coreutils at this point, but I do this later (not
detailed here, since it's standard).

I had to change the make.profile symlink once again to its final
destination, but now there will be no problems for updating any files with
portage, and you can do whatever you need (also likely including an update
of python and portage to the most recent stable versions).

Only one thing remains besides the steps outlined in the Gentoo Handbook for
finishing the install: we need devfsd, otherwise linux-2.4 will not be able
to find critical devices like the harddrive.

But sys-fs/devfsd is effectively hard-masked in portage since it has no
keywords.  So download the ebuild and source code to the portage overlay
directory, and then edit the ebuild to include the keyword for your
architecture (in my case x86).  Then I can emerge devfsd, and when I finally
reboot into the system, it is working correctly.

At this point you can just do the usual steps for finishing the install.

Hope this is clear for anyone in a similar plight in the future.

Regards,
daid