I maintain several systems that I use day to day at my Job. One of these is a box I use for mostly code compilation that run Gentoo. The machine runs on a Tyan S2822-D, aka Thunder K8SD Pro.

When I decided to wipe this machine, which was running CentOS 3.x at the time, and drop Gentoo on it, I had been out of the Linux Kernel compilation game for quite a while. To make a long story short, I could not find the correct Kernel compile options (which have become inordinately numerous and bloated) in the 2.6 kernel to make this beast boot. The internet was very little use as to which ones I needed as well. After a couple days of free time spent trying to get the correct options, I gave up and used what did boot -- Gentoo's genkernel package.

Since I ply mostly with FreeBSD systems, having a 'GENERIC' kernel was very familiar to me, and I wrote it down as a 'good move overall' for the future. However, after many moons of regular 'emerge --sync' and 'emerge -vuD world' success stories, I came across a update that broke my genkernel compilation. I couldn't find any hints from internet groups or google searches. Last week I broke down and decided to fix the damn thing myself.

The error was fleeting to say the least and NOT logged in /var/log/genkernel.log. The compilation always died after the kernel compilation and during the busybox compilation. busybox in genkernel is 1.7.4 and gentoo's genkernel ships several patches to it. The compilation would die during this patch process. The error would appear only on the terminal and would not be logged:

patch: **** File shell/ash.c seems to be locked by somebody else under Perforce

There was a whole bunch of other failures that would make this scroll by, so unless you happened to troll the backbuffer you wouldn't catch this as the failure. To it's credit the gentoo genkernel process does mention the failure to patch as the key failure.

So I simulated the patch process, I ran 'tar -xjpf /usr/portage/distfiles/busybox-1.7.4.tar.bz2' in /var/tmp and ran 'patch -p1 < /usr/share/genkernel/patches/busybox/1.7.4/1.7.4-ash-timeout.diff' from the extracted directory. Sure enough, same error.

It turns out that since permissions are extracted by default with the tar command under the build process, patch has '-g' ON BY DEFAULT (from the manpage):

       -g num  or  --get=num
          This option controls patch's actions when a file is under RCS or SCCS control, and does not exist or is read-only and matches the default  ver-
          sion,  or  when a file is under ClearCase or Perforce control and does not exist.  If num is positive, patch gets (or checks out) the file from
          the revision control system; if zero, patch ignores RCS, ClearCase, Perforce, and SCCS and does not get the file; and if negative,  patch  asks
          the  user  whether to get the file.  The default value of this option is given by the value of the PATCH_GET environment variable if it is set;
          if not, the default value is zero if patch is conforming to POSIX, negative otherwise.

I was not amused. Anyway, I moved patch from /usr/bin/ to /usr/bin/patch.org and wrote this wrapper in /usr/bin/patch:

#!/bin/bash
/usr/bin/patch.org -g0 $@
exit $?

genkernel now compiles.