Re: kernel-package??
Randy Patterson wrote:
My intention at this point is to make a detailed list of the components on a
particular system so I can remove everything that is not needed. These would
be older systems that will never be upgraded or need new hardware so the
kernel don't need a lot of options concerning hardware. For example, I have
used ext3 on the drives and they don't need to access anything else and will
remove all support for ext2, ext4, NTFS and everything else. I intend to
compile everything into the kernel without using modules. It's my
understanding from what I have read that this will result in a leaner and some
what faster kernel for that system. Is that a reasonable assumption and
approach?
What is "reasonable" is a matter of opinion. Even though I carried out
the massive research project you are describing above, and determined
the exact set of configuration options needed to compile a custom kernel
which exactly fits my hardware (and _only_ my hardware), I would not
recommend anyone else to do so unless they had some specific need or
purpose. My purpose has been to learn how Debian works "under the
hood," with the intent of being able to contribute useful work later --
in the form of fixing bugs, writing and packaging my own software, and
(possibly) becoming a Debian developer.
Leaner? My own experience is that my kernel binaries are _larger_ than
a Debian kitchen-sink kernel, while the disk space taken up for the
initial ramdisk (initrd) and loadable modules in /lib/modules goes away
almost entirely:
# ls -lA /boot | cut -f5- -d' '
[...]
7653318 2009-04-20 07:43 initrd.img-2.6.28-1-amd64
[...]
2041664 2009-02-18 13:02 vmlinuz-2.6.28-1-amd64
2921024 2009-03-21 12:57 vmlinuz-2.6.28-2s13145.090321.desktop.uvesafb
# du -s -b /lib/modules/*
210911107 /lib/modules/2.6.28-1-amd64
15089013 /lib/modules/2.6.28-2s13145.090321.desktop.uvesafb
The 15 MB of modules in my current custom kernel's /lib/modules path are
mostly unnecessary, and could easily be reduced below 2 MB (maybe even
1 MB).
Faster? I promise that you would not notice the speedup. Conceivably
your kernel will boot slightly faster without having to carry out the
hardware detection for the 99% of modules that have no relevance for
your particular system, but you would have great difficulty measuring
the alleged time savings accurately. (There are great opportunities for
decreasing the time needed to boot a Debian system, but these have to do
with customizing the initialization scripts, not with replacing the
kitchen-sink kernel with a custom kernel.)
As far as being in a hurry to leave out unnecessary things like ext2,
ext4, and NTFS... I would ask you to reconsider. What happens if you
meet other Linux users in your area, and they want to give you some
files off of their USB flash drive formatted in ext2 or ext4? Or what
happens if some Windows user you meet has some files on their external
hard drive... formatted in NTFS? Now your really great idea about
compiling your own kernel is really going to make you look smart to
those folks, right? Your choices at that point will be to recompile
your custom kernel, or boot to a Debian kitchen-sink kernel. (Which
just raises the question of why you weren't using the Debian kernel in
the first place.)
I'm not trying to discourage you from building your own kernel. I'm
trying to offer information that I think you should consider, and I'm
offering the advice that you shouldn't bother building your own kernel
unless you have some really good reason. (Really good reasons might
include a burning desire to simply know how, or to be able to say you
did it, but if one of those is you only reason then I think you will
regret it by about halfway through the process.)
The Debian kernel team works really hard to make sure that the kernels
work, and they do a good job. In the end, I was able to customize my
kernel configuration to the point that I can compile a kernel in about
6 minutes on my desktop machine... which is (at least) 6 minutes longer
than it would take me to install a Debian kernel. ;) If I hadn't had
problems with ALSA support with this machine when I first put it
together, I probably would not have bothered to learn to compile my own
kernels. The amount of time in invested in learning how to do it now
causes me to want to keep doing it, so I don't have the feeling that I
wasted those dozens of hours -- and so I am condemned to the punishment
of Sisyphus.
The whole subject of initrds scripts is something I will need to study up on.
But are you saying that if I don't use modules that I don't need to worry
about needing these scripts?
When you boot a kernel, then any feature required by your system to be
able to boot will have to be available before your hard disks are
mounted. There are two ways to accomplish this:
1. Build the features directly into the kernel binary, instead of
building them as loadable modules.
2. Build the features as loadable modules, and then create an initrd
which contains the required modules so that the kernel can use them at boot.
Folks who build their own kernels usually look at those choices, and
quickly decide not to use an initrd at all. The reason that Linux
distributions provide kernels with initrd's is because they want their
kernel to run on _everyone's_ hardware, so they turn on almost every
conceivable kernel option as a loadable module, then create an initrd
containing the modules that might be necessary at boot time.
In my own custom kernel's /lib/modules directory I have about 15 MB of
modules -- mostly unnecessary (but you never know). None of these
modules are necessary for my system to boot, so I don't need to create
an initrd.
HTH,
Dave W.
Reply to: