[conspire] Soundconfig:
Rick Moen
rick at linuxmafia.com
Mon Dec 9 10:28:44 PST 2002
Quoting Bill Stoye (skiffworks at earthlink.net):
> Scary thought but I may be starting to understand some of this.
Yes, I know the feeling. Some of us have the unfair advantage that
we started using this stuff when it was less elaborate (if somewhat more
user-hostile). But that at least puts us old-timers in a pretty good
position to explain it.
> I understand what I need to do and with what; confusion still lies
> around when to do it, what step to make the change to 'lilo.conf' and
> what kernel should I be actually trying to install; should it be 2.4.18
> and do I need -smp?
I'll give you a stereotypically techie-type literal-minded answer first,
and then try to put it in context. Ready?
Techie/gearhead answer:
Sure, you can use 2.4.18. Or 2.4.19. You can use -smp variants of the
numerous precompiled kernels if your machine has more than one CPU.
("SMP" stands for symmetric multiprocessing, which is the way of
dividing tasks among multiple CPUs on modern operating systems.)
The change you should make to lilo.conf is to insert an "initrd=" line
in the paragraph that describes your 2.4 kernel, e.g.,
initrd=/boot/initrd.img-2.4.18-686
And then, you should (as the root user) run "/sbin/lilo -v" to implement
the change, checking the output to make sure it doesn't complain that
anything can't be found. /sbin/lilo is the program that actually writes
boot information to bootable areas of your hard disk, following the
instructions you've provided for it in /etc/lilo.conf. It's vital that
you not shut down or reboot until /sbin/lilo gives you error-free
output. The "-v" just means verbose output, where it babbles about all
the pieces it finds, looking up their file locations in lilo.conf, and
tells you all about what it writes at the end.
Probably-more-useful, in-context answer:
Let's discuss the "SMP" thing, first. And the "-686" thing.
The Debian package mirrors provide quite a diverse set of precompiled
kernels, suitable for various types of hardware. Some PCs have multiple
CPUs -- usually two, but (on i386-class) sometimes as many as eight, in
some rackmount servers. The old Dell laptop in front of me ("guido") is a
uniprocessor (one CPU) machine. You can find out about this (in Linux)
by doing this:
guido:~# cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 6
model name : Mobile Pentium II
stepping : 10
cpu MHz : 366.679
cache size : 256 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca
cmov pat p
se36 mmx fxsr
bogomips : 732.36
guido:~#
In other words, it's a 366 MHz PII uniprocessor box. So, I would _not_
want to install a -smp kernel variant, and I'd want to make sure I
installed one compiled with compiler optimisations for something
approaching a PII.
Now, you have synaptic handy to browse available-package listings.
Please do so, to follow along. I personally prefer to page through the
available-package listings directly, in either
/var/lib/apt/lists/*Packages or /var/lib/dpkg/available . These are
pure text files, as is your installed-packages database,
/var/lib/dpkg/status. (Sometimes, it makes sense to fix glitches in
Debian package handling by snipping something out of
/var/lib/dpkg/status using a text editor!)
I'm going to do:
guido:~# less /var/lib/apt/lists/http.us.debian.org_debian_dists_testing_main_binary-i386_Packages
(I know you don't have the "less" utility installed. I'll be getting to
that in a minute.)
I'm skipping forward (searching) to the first line that starts with
"Package: kernel-image-2.4...." You can do the analogous lookup in
synaptic, if you like.
Ah! Here we have a bunch of them. (I'm on the Debian-testing branch.
You didn't specify, but I'd guess you're on Debian-stable = 3.0 = woody,
so you might not see some of these.)
kernel-image-2.4-386
kernel-image-2.4-586tsc
kernel-image-2.4-686
kernel-image-2.4-686-smp
kernel-image-2.4-k6
kernel-image-2.4-k7
kernel-image-2.4-k7-smp
kernel-image-2.4.18-386
kernel-image-2.4.18-586tsc
kernel-image-2.4.18-686
kernel-image-2.4.18-686-smp
kernel-image-2.4.18-bf2.4
kernel-image-2.4.18-k6
kernel-image-2.4.18-k7
kernel-image-2.4.19-386
kernel-image-2.4.19-586tsc
kernel-image-2.4.19-686
kernel-image-2.4.19-686-smp
kernel-image-2.4.19-k6
kernel-image-2.4.19-k7
kernel-image-2.4.19-k7-smp
What are all of these? You have to read the descriptions. Notice that
the first seven don't seem to have complete kernel version numbers:
They just say "2.4". Let's look at the description for
"kernel-image-2.4-686" (because it turns out to be a pretty good choice
for PII uniprocessor boxes):
Description: Linux kernel image 2.4 on PPro/Celeron/PII/PIII/PIV.
This package will always depend on the latest 2.4 kernel image available
for PPro/Celeron/PII/PIII/PIV machines.
Above the description, one of the lines is:
Depends: kernel-image-2.4.19-686
I just wanted to call your attention to that, to point out one of the
simultaneously gratifying and infuriating things about Debian: One fine
morning, you wake up and suddenly notice an utterly cool aspect of how
Debian is working on your machine. You're pretty sure it didn't use to
work that way, and nobody told you about it, but suddenly it's there.
If you were to hassle the Debian developers about this lack of
information, they'd probably say "Hey man, leave us alone. We're busy
coding, and don't have time to spoon-feed you information." Whatever.
Anyhow, if you install package "kernel-image-2.4-686", you'll get
kernel-image-2.4.19-686 _today_, and will automatically progress up to
kernel-image-2.4.nn-686, as nn goes to 20, 21, and on up -- whenever
prepackaged kernels for those versions appear on the Debian package
mirrors and you do an "apt-get update" and "apt-get dist-upgrade"
session (or the synaptic equivalent).
Now: You said you instructed synaptic to get you
"kernel-image-2.4-686". You quite sensibly balked when you were advised
to perform some surgery on /etc/lilo.conf that you didn't understand,
and presumably you interrupted installation of that package. You also
said:
> Did:
> skiffworks:/lib/modules# ls
> 2.2.20-idepci 2.4.16-686-smp
>
> Synaptic shows 2.4.16-686-smp not installed, so the process, I believe
> is negated when when a error comes up during the installation.
So, I'm guessing that package "kernel-image-2.4-686" is a virtual
package that (on the Debian-stable branch, right?) is set to retrieve
physical package "kernel-image-2.4.18" or "kernel-image-2.4.19". You
can/should check this for yourself, by reading the full package
description for "kernel-image-2.4-686" in synaptic.
I suspect that /lib/modules/2.4.16-686-smp is a leftover from some
completely unrelated prior misadventure with kernel installations.
At least, I can't otherwise imagine where that "-smp" came from, or
why you'd have module pieces for a 2.4.16 kernel.
Now, you should ask yourself: (1) Should I be using uniprocessor
kernels or SMP? (2) Which compiler optimisation is appropriate for
my machine: plain old 386, Pentium, PPro and above, K6, or Athlon?
You presumably know what's inside your box; I don't. The safest but
lower-performance choice is 386 optimisation. Every 386-or-later CPU
will do that. It's what was used to compile your "2.2.20-idepci"
kernel.
Let's say that you have a uniprocessor PII-class machine (like my
laptop). Then, you might tell synaptic to install
"kernel-image-2.4-686" (which, in fact, you did -- but interrupted it).
That will fetch the latest uniprocessor 2.4.x kernel image compiled for
PPro (686) or higher. It's also going to install a file with a name
like "initrd.img-2.4.18-686" in /boot. This is the matching initrd
image, containing the most-crucial drivers for that kernel.
> Another topic:
> I'm able to use 'zless' but when I try to use less I get no such
> command.
>
> skiffworks:~# man less
> No manual entry for less
Hmm, let's see what "zless" really is:
guido:~# which zless
/bin/zless
OK, that's where it is. Now, let's see what type of file it is:
guido:~# file $(which zless)
/bin/zless: Bourne shell script text executable
OK, it's a shell script (like a DOS batch file). Let's see its
contents:
guido:~# cat $(which zless)
#!/bin/sh
PATH="/usr/bin:$PATH"; export PATH
LESSOPEN="|gzip -cdfq %s"; export LESSOPEN
exec less "$@"
Well, it appears that, quite understandably, "zless" just gunzips a file
and pipes the output to "less". That's what I thought it was. Let's
have a look at "less". First, where is it?
guido:~# which less
/usr/bin/less
Now, what type of file is it?
guido:~# file $(which less)
/usr/bin/less: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV),
for GNU/Linux 2.2.0, dynamically linked (uses shared libs), stripped
That's also pretty predictable: It's a regular dynamic binary
executable.
But you say "less" isn't found on your system? How odd. Well, you can
and should use synaptic to install it. (Me, I just type "apt-get
install less" at the command line. One thing about Debian systems that
tends to make them confusing to newcomers: Everything's at least
potentially a la carte: If the person who constructed the system didn't
want to install "less", then it probably isn't there. But it's dead
easy to add anything initially omitted, that you later decide you want.
The tough part is often realising that you're missing something in the
first place.
> I thought less was more! Does xterm not have that command?
In the first place, you probably mean "bash", not xterm. xterm isn't a
shell; it's just a mechanism to display shells under X11. The shell
you're seeing/using in xterm is almost certainly bash, because that
tends to be users' default shell, on Linux.
So, to answer that question, no, less is not a shell builtin function.
Neither is the "more" command. Only a few commands you commonly use
are builtins, such as cd, alias, echo, exec, exit, export, fg, jobs,
kill, pwd, and set.
If "less" really isn't installed on your system, you should install it.
(It's a little mysterious how zless could work without it, though.
If you're curious about that, you could repeat the steps I listed above
on your system, to investigate.)
Anyhow, returning to your main problem: The thing to do is to make sure
there's a paragraph in /etc/lilo.conf for your new 2.4 kernel, and that
it includes an "initrd=" line pointing to the matching initrd* line in
/boot. Ideally, the paragraph for your 2.4 kernel should be in
_addition_ to the one for your 2.2 kernel, so that, if anything goes
wildly wrong at reboot time with your 2.4 kernel, you can fall back to
the 2.2 one instead of having to repair a suddenly non-bootable system.
Once again, here's my laptop's lilo.conf file:
lba32
boot=/dev/hda
root=/dev/hda3
install=menu
map=/boot/map
delay=20
vga=normal
default=linux
image=/boot/vmlinuz
label=linux
initrd=/boot/initrd.img-2.4.18-686
read-only
image=/boot/vmlinuz.old
label=linuxold
read-only
Notice the two stanzas (paragraphs)? The second one, label=linuxold,
is my fallback, safety stanza. When I first installed a 2.4 kernel, you
bet your booty that it pointed to a known-good 2.2 kernel!
/boot/vmlinuz.old is a symbolic link on my system, which I re-point
from time to time, to a known-good kernel. Similarly, /boot/vmlinuz
is also a symlink, which I point to the kernel I've most recently
installed and _hope_ will be usable and not break anything.
Another level of caution: Before you start editing lilo.conf, do this:
$ su -
# cd /etc
# cp lilo.conf lilo-conf-KNOWN-GOOD
Now, you can fool around with lilo.conf to your heart's content, knowing
that you can always restore the original contents, if need be.
The iron rule of lilo is: _Always_ verify that /sbin/lilo runs without
error, before rebooting or shutting down. Here's my laptop's
"/sbin/lilo" output without the "-v" (verbose) flag:
guido:~# lilo
Added linux *
Added linuxold
guido:~/#
Here it is with "-v":
guido:~# lilo -v
LILO version 22.3.3, Copyright (C) 1992-1998 Werner Almesberger
Development beyond version 21 Copyright (C) 1999-2002 John Coffman
Released 30-Aug-2002 and compiled at 15:38:21 on Sep 1 2002.
Reading boot sector from /dev/hda
Using MENU secondary loader
Calling map_insert_data
Boot image: /boot/vmlinuz -> vmlinuz-2.4.18-bf2.4
Mapping RAM disk /boot/initrd.img-2.4.18-686
Added linux *
Boot image: /boot/vmlinuz.old -> vmlinuz-2.4.18-bf2.4
Added linuxold
/boot/boot.0300 exists - no backup copy made.
Writing boot sector.
guido:~#
(The "no backup made" sounds alarming, but is a harmless advisory.)
Notice that it babbles about all the pieces that it locates, based on
their declared locations in /etc/lilo.conf. If it had been unable to
find any of those components, it would have complained. (Actually,
/sbin/lilo attempts to failsafe in such cases, by stopping immediately
if it can't find something mentioned in lilo.conf . But you might still
have a problem if this leaves you without a valid boot configuration.)
Now, if you examine the above output closely, you'll notice something
odd: At the moment, my "label=linux" and "label=linuxold" stanzas
actually point to the same 2.4.18-bf2.4 kernel image. This is because
I recently came to have enough faith in this kernel that I threw away my
old 2.2 kernel and related modules, just to save space. But I wanted
the fallback mechanism to be still there for the _next_ time I play with
new kernels, so I repointed the /boot/vmlinuz.old symlink to the 2.4
kernel image file. Next time I install a new kernel, I'll point the
/boot/vmlinuz symlink to it, but not /boot/vmlinuz.old.
I hope that makes sense. You'll probably find that your existing
/etc/lilo.conf refers to stuff in the system root directory, e.g.,
symlinks /vmlinuz and /vmlinuz.old . I object to such clutter in my
root directory, and so moved those to /boot and edited /etc/lilo.conf
accordingly.
> Thank you for the background/lead in to making the changes to lilo.conf,
> it helps me get a grasp on what is going on, rather than just mimicking
> a input where I would learn to mimic, not understand.
Statements like the above are why I take the trouble. It's always a
pleasure to see people "getting it".
If you ever need to consult my little "Zen of lilo" piece (the three
brief rules that keep you out of trouble, and help you understand the
little thing), it's at:
http://linuxmafia.com/~rick/linux-info/zen-of-lilo
It's something I wrote to answer a question sent to the Linux Gazette
Answer Gang, and is also included in the latest (Dec. 2002) LG issue:
http://www.linuxgazette.com/
--
Cheers, There are only 10 types of people in this world --
Rick Moen those who understand binary arithmetic and those who don't.
rick at linuxmafia.com
More information about the conspire
mailing list