Re: [Debian] iso9660 in 2.0.34 ?
Hi,
>>"Jay" == Jay Barbee <sysjyb@adm105.adm.louisville.edu> writes:
Jay> ...I believe I am confused... I do not mind a little
Jay> automation, but currently in my lilo.conf I have 3 linux kernels
Jay> that I use.
Jay> This kernel-package util seems as if it takes this functionality
Jay> away from you and simply uses default (/vmlinuz) and that is it.
Rubbish. Please do not spread FUD. I have, at times, a round
dozen kernel images on my machine, all compiled with
kernel-package. I even have 2-3 2.0.34 images *ON AT THE SAME TIME*.
Look at my lilo.conf, 5 (count it, five) different options.
kernel-package is about flexibility and ease of use, not for
putting peole in a straight jacket.
Please investigate before making assumptions about things.
______________________________________________________________________
boot = /dev/hda
delay = 50 # optional, for systems that boot very quickly
compact
vga=normal # force sane state
root = current # use "current" setting
message = /etc/lilo.message
verbose = 3
prompt
timeout = 300
image = /vmlinuz
label = 2
root = /dev/hda2
append = "mem=95M"
read-only
image = /vmlinuz.old
label = 3
root = /dev/hda2
append = "mem=95M"
read-only
image = /vmlinuz.stable
label = 4
root = /dev/hda2
append = "mem=95M"
read-only
image = /vmlinuz.reallystable
label = 5
root = /dev/hda2
append = "mem=95M"
read-only
other = /dev/hda1
table = /dev/hda
label = 1
______________________________________________________________________
Jay> Perhaps I simply don't understand what you are telling me to do
Jay> with this "kernel-package" when I go to install or test a new
Jay> kernel.
Yup.
manoj
======================================================================
Advantages of using make-kpkg
---------- -- ----- ---------
I have been asked several times about the advantages of using
the kernel-package package over the traditional Linux way of hand
compiling kernels, and I have come up with this list. This is off the
top of my head, I'm sure to have missed points yet. Any additions
welcomed.
i) Convenience. I used to compile kernels manually, and it
involved a series of steps to be taken in order;
kernel-package was written to take all the required steps (it
has grown beyond that now, but essentially, that is what it
does). This is especially important to novices: make-kpkg
takes all the steps required to compile a kernel, and
installation of kernels is a snap.
ii) It allows you to keep multiple version of kernel images on
your machine with no fuss.
iii) It has a facility for you to keep multiple flavours of the
same kernel version on your machine (you could have a stable
2.0.33 version, and a 2.0.33 version patched with the latest
drivers, and not worry about contaminating the modules in
/lib/modules)
iv) It knows that some architectures do not have vmlinuz (using
vmlinux instead), and other use zImage rather than bzImage,
and calls the appropriate target, and takes care of moving the
correct file into place.
v) Several other kernel module packages are hooked into
kernel-package, so one can seamlessly compile, say, pcmcia
modules at the same time as one compiles a kernel, and be
assured that the modules so compiled are compatible.
vi) It enables you to use the package management system to keep
track of the kernels created. Using make-kpkg creates a .deb
file, and dpkg can track it for you. This facilitates the task
of other packages that depend on the kernel packages.
vii) It keeps track of the configuration file for each kernel image
in /boot, which is part of the image package, and hence is
the kernel image and the configuration file are always
together.
viii) It allows to create a package with the headers, or the
sources, also as a deb file, and enables the package
management system to keep track of those (and there are
packages that depend on the package management system being
aware of these packages)
ix) Since the kernel image package is a full fledged Debian
package, it comes with maintainer scripts, which take care of
details like offering to make a boot disk, manipulating
symbolic links in / so that you can make boot loader scripts
static (just refer to the symbolic links, rather than the real
image files; the names of the symbolic links do not change,
but the kernel image file names change with the version)
x) There is support for the multitudinous sub architectures that
have blossomed under the umbrella of the m68k architecture.
xi) There is support there for optionally applying patches to the
kernel provided as a kernel-patch .deb file, and building a
patched kernel auto-magically, and still retain an UN-patched
kernel source tree
Disadvantages of using make-kpkg
------------- -- ----- ---------
i) This is a cookie cutter approach to compiling kernels, and
there are people who like being close to the bare metal.
ii) This is not how it is done in the non-Debian world. This
flouts tradition. (It has been pointed out, though, that this
is fast becoming Debian tradition)
iii) It forces you to use fakeroot or sudo or super or be root to
create a kernel image .deb file (this is not as bad as it
used to be before fakeroot)
--
"My father? My father left when I was quite young. Well actually,
he was asked to leave. He had trouble metabolizing alcohol." George
Carlin
Manoj Srivastava <srivasta@acm.org> <http://www.datasync.com/%7Esrivasta/>
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
--
Unsubscribe? mail -s unsubscribe debian-user-request@lists.debian.org < /dev/null
Reply to: