At 2002-09-13T15:47:35Z, Manoj Srivastava <srivasta@debian.org> writes:
> Ok. Here is something Kent West <westk@nicanor.acu.edu> has created, that
> shell be going into kernel-package soon (and also perhaps into the
> kernel-source-X.X.XX packages). If you improve on it, please let send it
> in to add in to the kernel-package itself
> Kent's 10-Step Procedure to Compiling a Debian Kernel
> Kent West <westk@nicanor.acu.edu>
> 1. Run "dselect". Choose "Update". Choose "Select". "space bar" to get
> out of the Help screens. Use "/" (without the quotes) to start search.
> Search for "kernel-source". Mark for installation the 2.4.18 or so.
>
> 1b. Use "/" to search for "kernel-package". Mark it for installation
> also. "Enter" to get back to the main dselect menu.
>
> 1c. Choose "Install". This will download a file in /usr/src with a .tgz
> extension, as well as install "kernel-package".
I'd deprecate that in favor of:
# apt-get install kernel-package kernel-source-$version
which is more straightforward and won't potentially leave a newbie in
dselect hell if they make a typo and can't back out of it.
> 2. "cd /usr/local/src"
>
> 3. "gunzip /usr/src/kernel-source-2.4.18.tar.gz" (or whatever the file is
> named). This will unzip (decompress) the file.
>
> 4. "tar -xvf kernel-source-2.4.18.tar". This will untar the file (x
> means extract, v means "be verbose", f means "use the file named ...").
> A new subdirectory named kernel-source-2.4.18 will be created with all
> the untarred files under it. You can also do steps 3 and 4 in one tar
> command, but I never do; habit is the only reason. I think you just add
> the "z" switch to tar, such as "tar -xvzf 'filename'".
That won't work - the kernel source tarballs are compressed with bzip2
rather than gzip. Anyway, I'd combine steps 3 and 4:
# tar xvfj kernel-source-$version.tar.bz
> 5. "ln -s kernel-source-2.4.18 linux". This will create a symbolic link
> ("alias" in Mac-speak; "shortcut" in Windows-speak, but more powerful
> than either) to the directory "kernel-source-2.4.18"; the symlink is
> named "linux". This step is not absolutely necessary, but it's the usual
> way of doing things. "ls -l" will show you that "linux" is a "pointer"
> to "/etc/src/kernel-source-2.4.18".
>
>
> Pause and Breathe. You now have the kernel sources installed. You
> haven't done anything with them yet, but they're installed.
>
>
> 6. "cd /usr/src/linux" (which because linux is a symlink, accomplishes
> the same thing as "cd /usr/src/kernel-source-2.4.18").
> 7. "make menuconfig". This will start a curses-based (text-based)
> menu-driven application.
[snip]
I'd suggest using:
# make-kpkg --config menu configure
which executes 'make menuconfig' *after* applying any additional patches
that the user may have installed. It's horribly frustrating to install
something like 'kernel-patch-device-mapper', run 'make menuconfig', and not
see any of the relevant config options (and have no idea *why* you're not
seeing them).
> Pause and breathe again. You have now configured your options for the
> next kernel compilation, but you have not yet compiled it.
> 8. Compile the kernel: use the command "make-kpkg kernel_image".
...and leave out the initrd that can potentially make the system unbootable?
No! Include the '--initrd' option.
> Pause and breathe. You have now compiled your kernel and made a .deb
> file out of it for easy installation.
>
> If you're (re)compiling a kernel with the same version number as your
> current version, you'll probably want to run the command "mv
> /lib/modules/2.[whateverversion] /lib/modules/2.[whateverversion].old"
No! That's what the '--append-to-version' feature of make-kpkg is for. In
the event that you accidentally build a kernel that won't boot or is
otherwise unusable, the old kernel and modules are still installed and ready
for use until such time as you decide they can be removed.
> 9. Install the new .deb file. Use the command "dpkg -i
> /usr/src/kernel-image-2.14.18*.deb". This will install the new kernel to
> where it needs to be (and I believe configure /etc/lilo.conf) and run
> lilo.
I don't *think* this runs LILO (I use Grub, so I can't say for sure), but
I'd double-check before including this as official documentation for
newbies.
Kent obviously went through some effort to write his HOWTO, but I really
think it needs a bit of cleaning up before it's ready for distribution.
Someone following those steps could really hose their system, particularly
if they've mv their modules, the new kernel doesn't work, and they try to
revert to their old setup. The instructions also try to hand-implement much
of the functionality available in make-kpkg, and that seems to be an
unnecessary duplication of work.
--
Kirk Strauser
The Strauser Group - http://www.strausergroup.com/