[sclug] Building a kernel

Dickon Hood sclug at splurge.fluff.org
Fri Jul 9 22:43:37 UTC 2004


[Oops.  Wrong From: address last time].

On Fri, Jul 09, 2004 at 22:56:12 +0100, Derek M Jones wrote:

: >: Building a working kernel seems to have become
: >: a lot more difficult since I last did it 3-4 years ago.

: >Not a lot's changed, really.  If anything, it's got easier.

: I remember version 1 as being the easiest.

I don't remember.  I did install a number of them but it was too long ago,
and I was mostly concentrating on NetBSD/arm32 at the time...

: Typing make bzImage may be easy, but getting
: a usable kernel seems to be more difficult :-(

It's rare I get something so broken it won't boot, but having said that,
I've managed to spend rather too long installing Debian on a Dell Latitude
x300 over the past couple of days, building kernels that turn the screen a
funny set of stripey colours and locking solid (surprisingly late into the
boot process, too).

: >Yes: use menuconfig, not xconfig.  menuconfig is better IME, and I've not
: >had to edit anything since using it.

: I am happy with any of the configs (well perhaps not the script one).

If in doubt, start with a kernel.org stock kernel, compile it, and see if
that boots.  If it gets as far as panicing that it can't see the root
filesystem, that's fine, and you can start to add the other drivers
that're required to see the discs, then worry about other things as
needed.

If you're on basically unknown hardware, start from the beginning and add
in the devices you need one at a time.  Keep your old .config files, and
the last kernel that booted fully.  It shouldn't take too long to get
something optimal.

The alternative is to just use a stock distribution kernel, but that
misses out on half the fun...

Oh, gcc 3.2 or later is good.  2.95 has issues on some architectures
(although probably not x86; I forget).

: >If you're attempting to use an old .config, remember 'make oldconfig'
: >first, or you'll hit problems.  I've no idea if oldconfig can handle 2.4
: >-> 2.6; I can't recommend it.

: Good point.  Linux really ought to put some effort into improving
: the README (which has hardly changed since the early days).
: Tried again, but still getting errors reported at boot time.

These days the average distribution's kernels are OK.  They usually manage
to boot everything.

: Sounds like it's time to invest in a latest and greatest distribution.
: Being a RedHat user I guess I will try Fedora 2 (although I have heard
: of people having problems with it).

I don't trust Redhat and haven't since 4.something when they shipped a
beta GCC as stable despite being told that libraries compiled with it
wouldn't link against anything else.  That caused me rather a lot of
trouble at the time, and they've done similar things recently (albeit
nothing *quite* that bad).

My current favourite for simple ease of use within the package management
system is Debian.  It can be a pain in the proverbial to install, but once
it's in, the 'apt-get install $PACKAGE' and it handling everything
(dependencies etc.) for you just makes life exceptionally easy, especially
for a desktop when you're demanding multiple user applications with (eg.)
lots of odd graphical library requirements, and generally want to upgrade
to the latest versions a lot.

: >: What I really need is a program that probes my hardware
: >: and generates a .config file specifically for it.  Pointers
: >: anybody?

: >cat /proc/pci helps a lot, as does lspci if you want something marginally
: >more readable.  It's then 'just' a matter of choosing the correct drivers
: >in the config.  grepping around Documentation/* (and */*, */*/*, */*/*/*,
: >and IIRC */*/*/*/*) can help.

: I prefer the 'just wait for a kernel hacker to write a script' approach :-)

Pah -- that's cheating :-)

-- 
Dickon Hood

Due to constant nagging to change it, my .sig is temporarily unavailable.
Normal service will be resumed as soon as possible.  We apologise for the
inconvenience in the meantime.


More information about the Sclug mailing list