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. -- TriLUG mailing list : http://www.trilug.org/mailman/listinfo/trilug TriLUG Organizational FAQ : http://trilug.org/faq/ TriLUG Member Services FAQ : http://members.trilug.org/services_faq/ TriLUG PGP Keyring : http://trilug.org/~chrish/trilug.asc
