[wplug] I'm a Linux whimp (need kernel help)

[Chester R. Hosey]

On Tue, 2005-08-16 at 10:54 -0400, Christopher DeMarco wrote:
> On Tue, Aug 16, 2005 at 10:23:42AM -0400, Chester R. Hosey wrote:
>
> If running  >= 2.6...
> 
> "make && make install"
> 
> This installs your modules; copies vmlinuz, System.map .config to
> /boot and symlinks 'em all from <name>.2.6.x-foo to <name>; detects
> your bootloader and gives you a hint about what to put in there.

Ah... I'd not come across that one. Old habits and such.

I never trust "make install" for anything -- if forced to run it, I'll
install to a sandbox and convert to a package with alien. It's neat to
know that it's there, though. I don't think 2.0.x had such nicety.

> If you're running GRUB, you can simply leave the default entry
> pointing to "vmlinuz" and hand-code older entries.
> 
> Please, do make sure to leave a bootable "last known good" kernel
> around somewhere :)

Bah -- old source tree! Having a big /usr makes one lazy, I suppose,
although the Slackware systems I used to build monolithic and copy
to /boot. I tend to have lots of grub entries/old source trees laying
around. When it hits 8-10 I'll usually prune down to two or three
(working and backup).

> > Most distributions and guides will (used to?) tell you to unpack
> > into /usr/src/linux. I found myself playing with many different
> > versions, and settled on /usr/src/ksrc/2.6.12 (for instance),
> > allowing for intact source trees for all versions I was testing.
> 
> The canonical (conanical?) way is to untar into
> /usr/src/linux-2.6.x-foo, and symlink /usr/src/linux.

This must be new as well (where "new" is "not eight years old"). I used
to be annoyed that every... single... document I came across suggested
just using /usr/src/linux.

I forgot to mention the symlink, though -- not a bad idea if you're
compiling something that depends on the kernel headers, although debate
of upstream kernel headers vs. packaged is one I'm not qualified to
enter.

> Yikes!  You're not only deviating from standard practice, but what
> happens if you hork /usr!?  /boot should be (a) dedicated, (b) mounted
> on-demand (not auto!) and (c) if you can afford it, RAID1 :)
> 
> Most people will get by just fine with 50MB (yes, that's *MB*) (64 for
> purists) of space in /boot to hold many generations of old kernels.

I think I mentioned the idea of the kernel in /boot if /usr isn't a
separate partition, but it's good that you explicitly mention a
distinct /boot for production systems. Although right now "production
system" == "supported system", and "supported system" == "vendor
kernel", so I'm only rolling my own on personal systems I don't mind
playing with.

I am a purist, and get annoyed every time I can't map a partition to a
specific multiple of a reasonable power of 2. I can't say why.

I've not destroyed /usr, but I did wipe out /var in its entirety once on
my Debian system. I recovered well, with no re-installation required.
This included making dpkg happy. That was fun (FSVO fun).

And as far as standard practice, I couldn't quite justify a
separate /boot partition on my original Linux systems -- the first had a
340MB drive and dual-booted. All of my Debian installations are rather
old, although not quite *that* old.

Standard practice seems to have evolved around me!

> The algorithm for -j is either (nCPU + 1) or (nCPU * 2 + 1).  This
> should always be "safe".

I've found nCPU*2+1 best on my old uniproc Celeron machine, on my SMP
Proliant I usually just -j6 it and don't sweat the few seconds
difference it might make to fine-tune further.

Thanks for the reply!

Chet