> > 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
