Re: RFC: Prospective Kernel-Compiling mini-HOWTO (fwd)
-----BEGIN PGP SIGNED MESSAGE-----
Buddha Buck gave me permission to repost this private mail. He makes a
lot of incisive points. While I don't know what non-Debian users are
going to do, it appears that I may need to give kernel-pkg another shot.
- --
G. Branden Robinson
Purdue University
branden@purdue.edu
http://www.ecn.purdue.edu/~branden/
- ---------- Forwarded message ----------
Date: Mon, 23 Jun 1997 22:34:32 -0400
From: Buddha Buck <bmbuck@acsu.buffalo.edu>
To: branden@purdue.edu
Subject: Re: RFC: Prospective Kernel-Compiling mini-HOWTO
> Hello,
>
> This file has been posted to this forum a few times before in earlier
> versions. I would very much appreciate feedback on it. If enough people
> think it's a good idea, I will attempt to contribute it to the LDP.
This may seem like an odd question at this point, but have you read the
Kernel HOWTO that is already part of the LDP? On my Debian system, it
is available in /usr/doc/HOWTO/Kernel-HOWTO.gz. It already does a
decent job of explaining how to compile and configure your own kernel,
but it isn't Debian specific.
>
> --BEGIN--
> Kernel Compiling for Dummies
> By Branden Robinson (branden@purdue.edu)
> Version 1.3, Jun 16 1997, 5393 bytes
>
> For Debian users, the "kernel-package" package is supposed to do these
> things for you, but I have had rough going with it, especially in the
> modules department. The following steps have worked for me on multiple
> machines, with various kinds of hardware and booting methods (floppy,
> loadlin, lilo). It makes a number of assumptions (i386 architecture,
> use of loadable modules, installing a complete set of new kernel sources,
> and not a patch, etc.). If anything looks inappropriate for
> your setup, make backups and go with your instincts. Always, always,
> always make sure you keep a known good booting kernel around on floppy
> disk to save your bacon. It also makes sense to compile-in, rather than
> modularize, things that are crucial to your system's operation. This
> always includes the binary format you use, ELF or a.out, and I think
> (can someone clarify?) it also includes the filesystem type of the root
> disk, often ext2fs (a.k.a. e2fs);
ELF runtime must be compiled in on 2.0 and higher kernels, since the
kernel itself -must- be compiled as ELF, not a.out. Having a.out as a
module works fine.
The root filesystem type -must- also be compiled in and not
modularized. Otherwise, the kernel can't find the module to load to be
able to find the module to load...
Now onto the document itself. For the record, I typically use the
following for compiling my own kernels:
1) mkdir /var/tmp/linux
2) cp linux-*.tar.gz /var/tmp/linux
3) cd /var/tmp/linux
4) tar zxvf linux-*.tar.gz
5) cd linux
6) make xconfig
7) make-kpkg clean
8) make-kpkg -r=custom.1.0 kernel_image kernel_source
9) dpkg -i ../kernel*.deb
10) init 6
> *) if upgrading and if possible, preserve your old kernel sources
> (if your /usr/src/linux is a symlink to the old sources, remove the
> link *before* extracting the tar file to /usr/src, otherwise just
> rename /usr/src/linux)
>
> // if installing a Debian kernel-source package, do that (dpkg -i
> // kernel-source-x.y.zz_x.y.zz.deb) instead of the next five steps
>
> *) copy .tgz source file to /usr/src
> *) cd /usr/src
> *) tar xfz (or tar xfvz) source file (it sticks itself in /usr/src/linux)
> *) mv linux kernel-source-x.y.zz
> *) ln -s kernel-source-x.y.zz linux
Since the later 1.3 kernels, the kernel source doesn't have to be in
/usr/src/linux. In fact, I prefer to keep /usr/src/linux for my
currently-installed kernel. When I build a new kernel, I usually build
it under /var/tmp/linux/linux (the use of .../linux/linux allows the
tar.gz file and the debian packages to be in /var/tmp/linux, where they
can be cleaned out easily, without disturbing the kernel sources
themselves).
Similarly...
>
> // if you want to preserve the asm, linux, and scsi libraries that shipped
> // with your libc, simply mv them before doing the symlink manipulations
> // below
>
> *) if necessary, cd /usr/include; ln -s asm-i386 asm
> *) if necessary, cd /usr/include; ln -s ../src/linux/include/asm-i386
> asm-i386
> *) if necessary, cd /usr/include; ln -s ../src/linux/include/linux linux
> *) if necessary, cd /usr/include; ln -s ../src/linux/include/scsi scsi
- -Do NOT DO THIS-. The kernel build doesn't use anything special in
/usr/include (it has it's own copy of any necessary headers), and the
links from /usr/include to /usr/src/linux/include are not recommended
by Debian, by the kernel developers (including Linus himself), and will
do the decidedly wrong thing under glibc (the GNU Libc provides its own
headers for /usr/include/linux, etc, and allows for the user-library
interface to be different from the library-kernel interface. Compiling
with the kernel headers themselves could cause your program to be
incompatible with libc.) Don't touch anything under /usr/include.
>
> *) if kernel version you're compiling is the same as current version,
> mv /lib/modules/x.y.zz /lib/modules/x.y.zz.old
> *) cd /usr/src/linux; make mrproper; make (config|menuconfig|xconfig);
> (optionally edit Makefile); make dep; make (zImage|zlilo); make modules;
> make modules_install
> *) depmod -a (depmod -a x.y.zz using new kernel version if applicable)
I believe depmod -a is done at boot, so the depmod -a x.y.zz isn't
necessary (unless you can change your running kernel)
>
> // NOTE: if your version of ps scans the System.map file, the psdatabase
> // file may be considered redundant (see the WCHAN entry in your ps
> // manpage to determine this).
>
> *) backup your old system map, kernel image, and psdatabase:
> A) cd /boot
> B) cp System.map System.map.old
> C) cp vmlinuz vmlinuz.old
> D) cp psdatabase psdatabase.old
> *) create new /boot :
> A) cd /usr/src/linux; cp System.map /boot/System.map-x.y.zz
> B) cd /usr/src/linux; cp arch/i386/boot/zImage /boot/vmlinuz-x.y.zz
> C) cd /; if necessary, ln -s boot/System.map-x.y.zz System.map
> D) cd /; if necessary, ln -s boot/vmlinuz-x.y.zz vmlinuz
> *) cd /boot; psupdate (creates new /boot/psdatabase)
> *) mv /boot/psdatabase /boot/psdatabse-x.y.zz
> *) ln -s psdatabase-x.y.zz psdatabase
> *) make sure psdatabase symlink in /etc is not broken (if you didn't have
> one before, you don't need it; don't bother creating it)
> *) edit /etc/modules appropriately (if you're using kerneld and are lucky,
> "auto" may be all you need)
> *) edit /etc/conf.modules (/etc/modules.conf on some systems) appropriately
> (for instance, you may need lines like "alias eth0 de4x5" and "options
> de4x5 io=0x0d")
> *) if you use lilo, check /etc/lilo.conf for correct parameters (esp.
> things like "linear")
> *) backup your old kernel image(s) and then put the new ones wherever you
> need them, e.g.:
> cp /usr/src/linux/arch/i386/boot/zImage /dev/fd0
> cp /usr/src/linux/arch/i386/boot/zImage /mnt/win95/Etc/Linux
> *) reboot
Oops, if I did just this, my system would never boot! If you use lilo,
then whenever you modify the kernel, you need to rerun lilo!
Otherwise, lilo won't be able to find the kernel, and the system won't
boot.
> *) if insmod complains about missing modules (but not "unresolved
> symbols"), try editing /etc/conf.modules and aliasing missing modules
> to off; e.g., "alias net-pf-4 off" or "alias char-major-10 off". These
> often correspond to devices/drivers your machine doesn't have or need.
> *) in my experience, "unresolved symbols" errors often mean you have
> modules sitting in /lib/modules/x.y.zz that the kernel doesn't expect;
> if you moved your old ones and did a "make modules" and "make
> modules_install" this shouldn't happen...hopefully
> *) reboot again and see if it worked
>
> END
>
> Disclaimer: Copyright (C) 1997 Branden Robinson. This file is freely
> redistributable by any means provided it remains complete and unchanged.
> --END--
I really suggest that people use kernel-package. It does the above
things superbly well in my opinion. Since before the switch to Linux
2.0, I've not built a kernel on my machine except using the
kernel-package. Once the various configuration files are setup
correctly, it really is as simple as the 10-step procedure I outlined
above.
>
> --
> G. Branden Robinson
> Purdue University
> branden@purdue.edu
> http://www.ecn.purdue.edu/~branden/
>
>
> --
> TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
> debian-user-request@lists.debian.org .
> Trouble? e-mail to templin@bucknell.edu .
>
- --
Buddha Buck bmbuck@acsu.buffalo.edu
"Just as the strength of the Internet is chaos, so the strength of our
liberty depends upon the chaos and cacaphony of the unfettered speech
the First Amendment protects." -- A.L.A. v. U.S. Dept. of Justice
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3a
Charset: noconv
iQCVAwUBM7EX6aiRn0nSNFD5AQHPsQQAv1QdK/zVB1mxyzMlw2wlhHn4DxX43zMZ
R6Uhy5yaCTsEhXwSmlA7BqMXk9+CtQBCV8WLdUT5CRVN0YsavPiFLb5m/It03N46
gf8JErIwOBi9qePC7jR8NZCYSAVBWNN6GqhIOA/l+r6UYervPcnIz+YdvruUvtT2
ktAoL43728g=
=FSKy
-----END PGP SIGNATURE-----
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-user-request@lists.debian.org .
Trouble? e-mail to templin@bucknell.edu .
Reply to: