[TriLUG] USB on laptop

[Erik Jacobson]

On Wed, Oct 06, 2004 at 03:06:44PM -0400, Mike M wrote:
> On Wed, Oct 06, 2004 at 05:00:47PM +0000, Erik Jacobson wrote:
> > Same here, I just build off the Debian sources (kernel-source-2.*
> > packages).  I'm comfortable enough with them making sure any important
> > patches are applied as far as security and stability, and then disabling
> > features that may have been added with menuconfig.  
> 
> Interesting.  You're n steps beyond where I am w/r to knowing what
> what is running.  
> 
> You build all of your own packages?  

No, just my kernels (and qmail because I have to, that's automated with
a script though).  Although apt-fu (http://freshmeat.net/projects/apt-fu/)
looks a bit interesting for that. ;)

> 
> How are kernel features getting enabled in your process and how do
> you detect the change (diff against a preserved .config?)?
> 

menuconfig/config still gets run.  Here's my typical build process:
(using 2.6.0 for this example)

---------
apt-get install kernel-source-2.6.0 libc-dev gcc make
libncurses-dev libdb3-dev kernel-package

cd /usr/local/src
tar jfx /usr/src/kernel-source-2.6.0.tar.bz2
make menuconfig		# (or make config sometimes if I want to make
			#  sure I get everything)

(a few things to increase FDs on my server machines here)

make-kpkg clean; make-kpkg kernel_image
dpkg -i /usr/local/src/kernel-image-2.6.0*.deb
---------

Sometimes I use a saved .config from a previous kernel, usualyl do it
from scratch.  I also tend to disable modules on server machines, but on
home machines I enable anyhting that looks like it may be interesting as
a module, as very very few things will hurt stuff if they are enabled in
modern kernels.  I don't use initrds (that's a seperate argument to
make-kpkg I believe).

Dumping a previous .config in your build directory sets the defaults for
make (menu)config.  Try not to use ones from kernels that are too much
older though due to changing options :)  Shouldn't hurt anything in my
experience due to unknown options being ignored or nuked when the new
config is written.

Some good documentation is in /usr/share/doc/kernel-package/ describing
all the steps.  I've only built in external modules a couple times
(mainly nvidia drivers), and it was fairly painless with dropping the
module cruft in a directory they provide for it.  The details are in the
kernel-package docs.

> > Makes my life easier.
> 
> easier or controlled; maybe controlled == easier ;-)

The easier comes from not having to watch for new kernel patches needed
to keep things working and/or secure.  And making it into a deb keeps
things sane with apt.  It takes care of lilo/grub/etc.  And although I
haevn't done it in a while, I do remember the external patching and
module build process being painless (i.e. worked on first try) with
kpkg.

> > 
> > And make-kpkg is just fun.  FUN I SAY!  *cough* ...What?
> 
> More layers.  I concluded it was a useful thing if you are working on
> a distro that needed to boot on many diverse machines.  I recall it
> enforced use of initrd which I eliminate as being even more icing I
> don't want until I decide I need it.

Nope, that's jsut the pre-built kernels.  None of mine have initrds, you
haev to enable a couple things in the kernel config and then tell kpkg
to make one I believe.  The end result kernel is the same as a manually
built one with the debian patches in a .deb

Hope that helped.  Avoiding work makes for wordy replies.