[conspire] Soundconfig:
Bill Stoye
skiffworks at earthlink.net
Wed Dec 11 05:03:38 PST 2002
Running 'Woody';
Made change to /etc/lilo.conf;
Using Synaptic, selected/installed kernel image 2.4.18-686;
Testing lilo failed;
Continued, figuring the fail was in vmlinuz.old, mustered up courage,
reboot.... worked;
Ran sndconfig and recieved, ERROR: No Sound Modules found;
Did, uname -r (2.2.20-idepci)???
I don't know what to ask, I'm at a loss; a history of what was done is
below, maybe more than needed but didn't know what to include or leave
out.
Failing miserably;
Bill
*****************************************************
You are attempting to install an initrd kernel image (version
2.4.18-686)
This will not work unless you have configured your boot loader to use
initrd. (An initrd image is a kernel image that expects to use an
INITial
Ram Disk to mount a minimal root file system into RAM and use that for
booting).
As a reminder, in order to configure lilo, you need to
add an 'initrd=/initrd.img' to the image=/vmlinuz
stanza of your /etc/lilo.conf
I repeat, You need to configure your boot loader. If you have already
done
so, and you wish to get rid of this message, please put
`do_initrd = Yes'
in /etc/kernel-img.conf. Note that this is optional, but if you do not,
you'll contitnue to see this message whenever you install a kernel
image using initrd.
Do you want to stop now? [Y/n]n
Setting up kernel-image-2.4.18-686 (2.4.18-5) ...
useful if you use a boot loader like lilo.
Do you want me to create a link from /boot/initrd.img-2.4.18-686 to
initrd.img?[Yn] y
A new kernel image has been installed, and usually that means
that some action has to be taken to make sure that the new
kernel image is used next time the machine boots. Usually,
this entails running a ``bootloader'' like SILO, loadlin, LILO,
ELILO, QUIK, VMELILO, ZIPL, or booting from a floppy. (Some
boot loader, like grub, for example, do not need to be run on
each new image install, so please ignore this if you are using
such a boot loader).
A new kernel image has been installed. at /boot/vmlinuz-2.4.18-686
(Size: 618kB)
Initial rootdisk image: /boot//initrd.img-2.4.18-686 (Size: )
Symbolic links, unless otherwise specified, can be found in /
LILO sets up your system to boot Linux directly from your hard
disk, without the need for booting from a boot floppy.
WARNING
If you are keeping another operating system or another version
of Linux on a separate disk partition, you should not have LILO
install a boot block now. Wait until you read the LILO documentation.
That is because installing a boot block now might make the other
system un-bootable. If you only want to run this version of Linux,
go ahead and install the boot block here. If it does not work, you
can still boot this system from a boot floppy.
You already have a LILO configuration in /etc/lilo.conf
Install a boot block using the existing /etc/lilo.conf? [Yes]
Testing lilo.conf ...
An error occurred while running lilo in test mode, a log is
available in /var/log/lilo_log.1061. Please edit /etc/lilo.conf
manually and re-run lilo, or make other arrangements to boot
your machine.
Please hit return to continue
Finished.
*********************************************
GNU nano 1.0.6 File: /var/log/lilo_log.1061
Added Linux *
Fatal: open /boot/initrd.img-2.2.20-idepci: No such file or directory
******************************
GNU nano 1.0.6 File: /etc/lilo.conf
lba32
boot=/dev/hda
root=/dev/hda4
install=/boot/boot-menu.b
map=/boot/map
delay=20
prompt
timeout=150
vga=normal
default=Linux
image=/vmlinuz
label=Linux
initrd=/boot/initrd.img-2.4.18-686
read-only
image=/vmlinuz.old
label=LinuxOLD
initrd=/boot/initrd.img-2.2.20-idepci
read-only
optional
other=/dev/hda1
label="Windows(hda1)"
other=/dev/hda2
label="Linux(hda2)"
********************************************
skiffworks:/home/bill# /sbin/lilo -v
LILO version 22.2, Copyright (C) 1992-1998 Werner Almesberger
Development beyond version 21 Copyright (C) 1999-2001 John Coffman
Released 05-Feb-2002 and compiled at 20:57:26 on Apr 13 2002.
MAX_IMAGES = 27
Reading boot sector from /dev/hda
Merging with /boot/boot-menu.b
Boot image: /vmlinuz -> boot/vmlinuz-2.4.18-686
Mapping RAM disk /boot/initrd.img-2.4.18-686
Added Linux *
Boot image: /vmlinuz.old -> boot/vmlinuz-2.2.20-idepci
Mapping RAM disk /boot/initrd.img-2.2.20-idepci
Fatal: open /boot/initrd.img-2.2.20-idepci: No such file or directory
****************************
skiffworks:/lib/modules# ls
2.2.20-idepci 2.4.18-68
*********************
skiffworks:/home/bill# uname -r
2.2.20-idepci
--END--
**********************************************
**********************************************
On Mon, 2002-12-09 at 10:28, Rick Moen wrote:
> 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
>
> _______________________________________________
> conspire mailing list
> conspire at linuxmafia.com
> http://linuxmafia.com/cgi-bin/mailman/listinfo/conspire
More information about the conspire
mailing list