# Installing a 2.x kernel in current Gentoo?

## The_Pope

Hello everyone,

For some tests, I need to install a very old kernel ebuild, from the old sources.gentoo.org repository.

I downloaded the ebuild locally, in /usr/local/portage/sys-kernel/whatevername (the ebuild file has the same name as the directory, with the version afterwards, as it was on the repository) and then:

- declared a local repository in /usr/local/portage, as instructed here

- ran "repoman manifest" in that ebuild's directory

I got repoman trying to get the patches that the respective kernel had, from the existing repository and of course it can't possibly find them. I found them all and copied them next to the ebuild file. It still tries to download them.

I tried to also copy the patches in /etc/portage/patches/sys-kernel/whatever. Then I tried to have them both unpacked and packed in those directories. I tried to emerge the ebuild even if I didn't succeed in creating the ebuild manifest.

Nothing. I just need to emerge this ebuild, I'm guessing building the sources will be easy, just using genkernel as always. Help please?

----------

## Jaglover

A kernel this old lacks a bunch of features needed to run modern Gentoo. You realize you cannot use this kernel even if you manage to build it?

----------

## The_Pope

I didn't ask if I can use it, I asked how to emerge it. Thank you.

----------

## jonathan183

I think you should be using a local overlay for this which I'd put in /usr/local rather than /usr. I think the downloaded files end up in a files sub-folder for example

```
ls /usr/local/portage/sys-apps/openrc/files/ -l

total 24

-rw-r--r-- 1 portage portage 1992 Aug  9  2015 openrc-0.8.3-ccwgroup.patch

-rw-r--r-- 1 portage portage 1055 Aug  9  2015 openrc-0.8.3-deprecation_warning.patch

-rw-r--r-- 1 portage portage 2775 Aug  9  2015 openrc-9999-msg-style.patch

-rw-r--r-- 1 portage portage  825 Aug  9  2015 openrc-9999-pause.patch

-rw-r--r-- 1 portage portage   43 Aug  9  2015 openrc.logrotate

-rw-r--r-- 1 portage portage   63 Aug  9  2015 start-stop-daemon.pam
```

----------

## The_Pope

 *jonathan183 wrote:*   

> I think you should be using a local overlay for this which I'd put in /usr/local rather than /usr.

 

Oh my, yes, sorry, that's where it is. /usr/local/portage/sys-kernel/...

----------

## NeddySeagoon

The_Pope,

You are going to need a whole old install to run on top of that kernel.

There is some old stuff online, which was saved by cwr and old portage snapshots too.

That may be enough to get you going.  You will need equally old hardware to run them. Virtualbox may help there.

Finding supporting distfiles is left as an exercise for the reader.

Its unlikely genkernel will produce a working kernel.  At least, not genkernel all.

Its also unlikely that such an old kernel will build and/or link with current tools.

----------

## The_Pope

NeddySeagoon,

May I please find out how to emerge an old ebuild? That's exactly what I was asking. I have, in theory, all the patches it demands, it only asks for the old kernel.org sources for that particular version (probably to apply patches to them?) and I think three other patches that were in the old Gentoo repository.

Old portage snapshots? Might be useful, yeah, but I need to get there first. I still can't emerge. I did:

```
emerge --ask --verbose --oneshot
```

My local repository does get recognized but emerge says that the .ebuild file for this package is not listed in the Manifest.

----------

## NeddySeagoon

The_Pope,

You appear to have done all the right things.

Put the .ebuild file into your local overlay.

Look at the ebuild to see if it needs any patches and where they need to be stored.

Small patches go in ../files/ next to the ebuild.  Larger patches have their own tarballs and will be fetched into distfiles at manifest time.

When ../files/ and the ebuild are in place, run 

```
ebuild /path/to/.ebuild manifest
```

 to generate the manifest.

This will download sources, if you don't have them already or fail if it can't find the sources.

Worked example.  I have an overlay in 

```
/usr/local/gentoo-static
```

It contains

```
 /usr/local/gentoo-static/sys-apps/openrc/
```

because I like on old openrc. Why does not matter.

That contains

```
 Manifest  openrc-0.17.ebuild
```

openrc-0.17 does not need any ../files, to the directory is absent.

The Manifest contains

```
DIST openrc-0.17.tar.bz2 160533 \

SHA256 45818d9ef4659e8dd924a1468a091255c305daee5417f94d9515f0e125298b30 \

SHA512 6e69b036d113f066b0dd0bfe55e019328e0e77cff6c93f0a3e55751aa0a72411aa3b1efe8b4327e156a9612e4155863b0a81c9eda043c12904bb36e861b71399 \

WHIRLPOOL de45daf6f4aebe632ea9fcb46408e63f0aed6c9b9129fb5510f348f20cf1c62aa42e7dce47a7f19a441696596fa57494642e7334a42c415fdbc865cb80a18eff
```

That's the download tarball name, size and the three hashes for the tarball.

If there were more files, there would be more entries.

Its important you make (or remake) the manifest last thing when you have all the parts.  If the subsequent emerge finds a part not covered by the manifest, the emerge will stop.

----------

## Jaglover

I wonder if it even will build with modern gcc. Probably not.

----------

## The_Pope

NeddySeagoon,

That's almost everything I needed to know. That the larger patches go to distfiles. Every patch was a tar.bz2 archive, except one.

Running ebuild to create the manifest worked, but so did the "repoman manifest" command.

The problem now is different. The last of the needed distfiles is .xz and emerge can't unpack it. Literally

```
file format not recognized. Ignoring.
```

I emerged xz-utils by hand. Same error. I unpacked by hand, into /var/tmp/portage/.../work - still nothing.

Upon a quick search, I found this problem mentioned in the Funtoo distribution:

```
[b]xz-utils auto-dependency[/b]

There are several ebuilds in the Gentoo Portage repository that use .xz files but do not explicitly depend on xz-utils. A workaround has been added to ebuild.sh to add this dependency to metadata automatically if a .xz file exists in SRC_URI. This change is not yet in the official Portage sources but is being used on the Funtoo side when generating our git-based Portage trees.
```

So? Do I have to try and get their ebuild.sh file ?

----------

## Jaglover

The_Pope,

you are doing something and you are not telling us why. It is OK, but this also means we cannot offer alternative solutions. For instance, all this ebuild is supposed to do is to unpack and patch kernel sources, right? Is there any reason you want to use the ebuild, instead of just unpacking and patching the sources by hand?

----------

## The_Pope

Jaglover,

If I told you the bigger scope of what I'm doing, you'd scream at the top of your lungs that it's not doable, not possible, maybe only that I can personally not do it, a waste of time, etc. I also know why: It's because you'd be defending some of your notions on the computer world. What I'm doing, for some reason, is so outrageous to most people, that they somehow want me to fail or stop trying. For some reason this project is perceived as a threat, somehow. I don't understand why else would people be so unbelievably dismissive.

What one guy tries to do in his own home is his own business and not exactly subject to popular debate, much less popular vote. Trying a few things with probably the most flexible distro in the world seemed fun. That's it. Maybe I'll let you know what I was doing once I finish, because very, very few people believe this can be done unless you show them the finished product.

Patching these sources by hand is something I don't know how to do. Otherwise yes, I would have done it myself.

In the meantime, I believe I'm raising a valid issue? If any patches are packed .xz, emerge will ignore them?

----------

## Jaglover

I do not know about xz problem, but you could repack them with bzip2 as a workaround.

----------

## The_Pope

 *Jaglover wrote:*   

> you could repack them with bzip2 as a workaround

 

Yep, I tried that. Seems the .xz file is somehow hardcoded in the ebuild file. I tried replacing the .xz file with a .bz2 file however when rebuilding the manifest, the manifest building utility tried to connect to the repository and get the .xz file.

I looked in the .ebuild file, all the patch files are specified as .bz2 except that one, most likely why it wants it as .xz - maybe it's some default or leftover from years ago.

----------

## Jaglover

So how about editing the ebuild? OTOH, patching by hand is not that difficult, you could learn it.

----------

## The_Pope

 *Jaglover wrote:*   

> So how about editing the ebuild?

 

I would gladly do that, but the ebuild just references the .xz file as ${SOMETHING}

Meanwhile, all the .tar.bz2 archives contain .patch files. Don't know how to patch an existing source tree with those, sorry.

----------

## NeddySeagoon

The_Pope,

The kernel ebuild downloads the base sources from kernel.org and three? patch files from dev.gentoo.org/~<kernel-dev>

It unpacks the kernel (from kernel.org), decompresses the patch files in turn and applies them to the kernel.

The ebuild is easy compared to what lies ahead.  Forget the ebuild just now.

Fetch the kernel you want from kernel.org and build it by hand.  That's going to be hard with current tools.

I still have the sources around for 

```
 ls /usr/portage/distfiles/linux-2.6.* -l 

-rw-rw-r-- 1 portage portage 56579370 Mar 23  2009 /usr/portage/distfiles/linux-2.6.29.tar.bz2

-rw-rw-r-- 1 portage portage 59435895 Jun 10  2009 /usr/portage/distfiles/linux-2.6.30.tar.bz2

-rw-rw-r-- 1 portage portage 61494822 Sep  9  2009 /usr/portage/distfiles/linux-2.6.31.tar.bz2

-rw-rw-r-- 1 portage portage 64424138 Dec  3  2009 /usr/portage/distfiles/linux-2.6.32.tar.bz2

-rw-rw-r-- 1 portage portage 66266488 Feb 24  2010 /usr/portage/distfiles/linux-2.6.33.tar.bz2

-rw-rw-r-- 1 portage portage 67633622 May 16  2010 /usr/portage/distfiles/linux-2.6.34.tar.bz2

-rw-rw-r-- 1 portage portage 69305709 Aug  1  2010 /usr/portage/distfiles/linux-2.6.35.tar.bz2

-rw-rw-r-- 1 portage portage 70277083 Oct 20  2010 /usr/portage/distfiles/linux-2.6.36.tar.bz2

-rw-rw-r-- 1 portage portage 73577826 Jan  5  2011 /usr/portage/distfiles/linux-2.6.37.tar.bz2

-rw-rw-r-- 1 portage portage 74739098 Mar 15  2011 /usr/portage/distfiles/linux-2.6.38.tar.bz2

-rw-rw-r-- 1 portage portage 76096559 May 19  2011 /usr/portage/distfiles/linux-2.6.39.tar.bz2
```

The matching genpatches files are there too.

See the old stuff link I posted earlier too.  Think of building any old kernel, with no patches, as a proof of concept.

Do all this as your normal user.

Get a kernel tarball. 

Unpack it somewhere safe.

cd to the somewhere.

run make allyesconfig

followed by make -j<threads>

Tell which step breaks and pastebin the complete output. 

Don't even think about genkernel.

I'm curious about what you want to achieve and not so much about the why.

Without knowing the what, its not possible to suggest alternative solutions to the problem you are trying to solve.

-- edit --

```
roy@NeddySeagoon_Static ~ $ tar xf /usr/portage/distfiles/linux-2.6.29.tar.bz2

roy@NeddySeagoon_Static ~ $ cd linux-2.6.29
```

That works.

```
roy@NeddySeagoon_Static ~/linux-2.6.29 $ make allyesconfig
```

Gives  warning: variable ‘type’ set but not used [-Wunused-but-set-variable], that works.

```
roy@NeddySeagoon_Static ~/linux-2.6.29 $ make -j10
```

ends with 

```
cc1: error: code model kernel does not support PIC mode

```

However, I'm using a testing gcc where PIC is forced.  It might get further with gcc-5.4.0. and a /13.0/ profile.

Those four commands are your 'proof of concept'.

----------

