rhl6u285

Lemur zaprasza

Red Hat® Linux 6 Unleashed










Chapter 28: Configuring and Building Kernels





Previous
ChapterNext
Chapter










Sections in this Chapter:









 
 



An
Introduction to the Linux Kernel










Ftape,
the Floppy Tape Device Driver





Load/Save
Configuration






Obtaining
the Kernel Sources





Old CD-ROM
Drivers (Not SCSI or IDE)










Building
and Installing the Kernel






Configuring
Linux Kernel





Character
Devices





Network
Filesystems





Manually
Installing a New Kernel






Configuration
Options










Partition
Types





Troubleshooting
the New Kernel






General
Setup





Watchdog,
NVRAM, and RTC Devices





Native
Language Support





Troubleshooting and Recovery






Networking
Options





DoubleTalk
Speech Synthesizer





Console
Drivers





References
and Resources


























Network
Device Support





Joystick
Support





Kernel
Hacking










 

Previous
SectionNext
Section





Troubleshooting and Recovery












Partial LILO
Prompt





Kernel Oops and
Bug Reporting






Kernel Halts
While Loading












It happens. You
execute
an orderly shutdown and reboot, the monitor flashes (or your connection goes
dead), and you wait for the boot, only to be greeted with a partial
LILO prompt or
worse.Typically, a faulty kernel will exhibit one of
the following behaviors:



    l

    The machine cycles through repeated
    rebooting.

    l

    l

    You see some substring of
    the LILO prompt, such as
    LIL- followed by a
    halt.

    l

    l

    Linux begins to load but halts
    at some point during the kernel
    messages.

    l

    l

    Linux loads but ends in a
    kernel panic message.

    l

    l

    Linux loads,
    runs, lets you log in, and then dies when it is least
    convenient.

    l

If you're prepared,
your prognosis for a full recovery is very good. If you can get up to the
LILO prompt1, the most convenient recovery is to
load your backup kernel by specifying its label to the boot loader:



LILO: backup

This will boot from your previous kernel and allow you in so you
can fix the problem and try your luck again. If you cannot get to the
LILO prompt, your only alternative is to use your
boot diskette or a rescue disk. The boot diskette makes life much easier because
the running system will be identical to your normal system. If you use a rescue
disk, you must manually mount your system partitions. This puts all of your
files (and any symlinks) off-kilter and complicates running
LILO or the RPM package
manager.When alternate kernels and boot diskettes are
not practical, such as on thin clients with limited diskspace, and you can reach
the LILO prompt, you can try to start your system in
single-user mode to prevent the probing and loading of many modules, such as
your network card (a frequent culprit). The default configuration for
single-user (AKA runlevel 1) mode is specified by
the files in /etc/rc.d/rc1.d, and it is a good idea
to double-check the symlinks in that directory after each system upgrade to
ensure that the choices are intelligent for the purpose. Single-user mode will
put you directly into a system shell. Once the problem has been corrected, you
can either reboot the system or exit the shell to return
to
multiuser mode.



Repeated Rebooting
Nine times out
of
ten, repeated rebooting is caused by someone making changes to the kernel file
and forgetting to run LILO to register the new image
with the boot loader. LILO needs the raw sector
location of the kernel. Even copying a kernel image will move it to a new sector
and leave the previous pointer stored by LILO
dangling over an abyss.You can correct this problem
by booting from the boot floppy and running the LILO
command, or by using a rescue disk, mounting the boot partition under
/mnt, and
running
LILO with the options to use a relative
path:



lilo -r /mnt


Partial LILO Prompt
A partial LILO prompt
is
the most terrifying of all kernel boot errors. Each letter of L-I-L-O signifies
a stage in the boot process and can be used to isolate the trouble:



L- or LIL--Usually
a media error.


LI or LIL?--Either
/boot/boot.b is missing, moved, or corrupt. The
solution is the same for all: rerun LILO.



More information on using LILO and
the diagnosis of LILO error codes can be found in
/usr/doc/lilo-0.x/TechnicalGuide.ps.



Kernel Halts While Loading
Device
probing
is a dangerous business and is the most frequent cause of kernel halts while
loading. For example, if you are configuring for a gateway/firewall machine with
two network interfaces, the second probe may cause the kernel to halt. Other
causes of kernel halts are IRQ conflicts, memory conflicts, and mismatched
devices (selecting a similar but not-quite-identical
driver).You can avoid probing, memory, and IRQ
conflicts for most kernel modules and devices by supplying the correct
configuration parameters in the /etc/lilo.conf
append line. The exact parameters to use depend on
your device, but you can find advice in the README
files, either in linux/Documentation or in the
subdirectories of the
driver
source code.


Tip -
If you have hardware that is particularly troublesome for IRQ and memory
settings, and you have a Windows partition, you can find the values used by
Windows in the ControlPanel:System:Devices listings
and then use those settings on the LILO command
line or the /etc/conf.modules file. It is
unfortunate, but many manufacturers still believe that their best business model
includes restricting use of their hardware to Microsoft users. As a result,
techniques and interfaces for probing and configuring these devices are not
available to Linux programmers. The good news is that more and more
manufacturers have seen the light and happily provide any information we need to
incorporate their products under Linux.


Kernel Panic
A kernel panic
message
has a certain cryptic poetry to it. Like a robotic haiku, it is a snapshot of an
epoch, a telling testament to the last moments of a running Linux kernel. A
kernel panic usually has this form:



unable to handle kernel paging request at address C0000010
Oops: 0002
EIP: 0010:XXXXXXXX
eax: xxxxxxxx ebx: xxxxxxxx ecx: xxxxxxxx edx: xxxxxxxx
esi: xxxxxxxx edi: xxxxxxxx ebp: xxxxxxxx
ds: xxxx es: xxxx fs: xxxx gs: xxxx
Pid: xx, process nr: xx
xx xx xx xx xx xx xx xx xx xx

For most practical purposes, knowing where the panic occurs is
more useful than interpreting the message itself. The leading text tells what
triggered the event, and this is followed by the addresses held in various
registers. Intrepid readers can find detailed instructions on decoding this
message in the linux/Documentation/oops-tracing.txt
file.In production kernels, kernel panic messages are
very rare and usually are due to a configuration problem, missing modules,
failure to load a module before using some essential feature, or using hardware
that is not supported by the current kernel. With development kernels,
kernel
panics can become a way of life.



Kernel Oops and Bug Reporting
Generally, a Linux
machine
is highly stable and resilient about application failures. However, when you
start trying odd kernel combinations or experimental editions, hardware, and
configurations, stuff happens. In the parlance of the kernel developers, an
oops is a kernel panic message that seems to occur spontaneously, often
mercilessly and for no apparent reason. The message is similar to the kernel
panic that can occur during the boot, but it may not be visible if you are
running X Windows. The cause of both the boot halting and a spontaneous oops is
the same: The kernel has reached an impasse.When an
oops occurs during a user session, the kernel panic message may be displayed on
one of the Linux Alt consoles and can be seen by pressing
Ctrl+Alt+1 or by checking the
system log file in /var/log/messages. If you can see
the panic report, the activity just prior to this in the log may give some clues
to the cause of the panic.Linux is maintained and
developed by volunteers, so the first advice for reporting problems and bugs is
to be polite. Chances are that someone will take personal interest in this bug,
and you will have a fix or a workaround in record time. But you're far less
likely to get a timely response if you take your frustrations out on the
developers. Unlike with other proprietary systems, when you deal with the Linux
community, you're not dealing with underpaid droogs. You're dealing
with the masters themselves, the people who take personal ownership and pride in
their work. Show some respect and they will more than repay your
kindness.
Your first line of support should always be to see if this bug
is known. If you have access to a Web browser, look into the kernel developer's
archive
at .
If you have IRC access, you can ask directly on one of the #linux
or #linuxOS channels on efnet
or the undernet.
If you think you have found a new
bug in the kernel, the kernel
development community will be more than interested... providing you can supply
enough information to lead to a fix. If you can isolate the module where the
oops occurred, you can locate the author of that module either in the
linux/Documentation/MAINTAINERS file or in the
source code of the module itself. You can also post your report to the Linux
kernel mailing list.When you report a suspected bug,
you should specify which kernel you are using, outline your hardware setup (RAM,
CPU, and so on), and describe the situation where the problem occurred. If there
is a kernel panic message, copy
the
message exactly as displayed on your screen.



Linux and Y2K
I would hope that this
section is useless because you've "Been there, done that" and
not because it is too late! Nonetheless, it's worth mentioning that the
Linux kernel can be extended to facilitate Y2K testing using the Time Travel
module (see http://www.aivazian.emon.co.uk/tt/tt.html).
With
Time Travel installed, system time calls can be intercepted and specific
applications can be run under a simulated advance date without imposing the test
on the entire system. For example, installing the module with the command
line



# insmod timetravel.o tt_prog="myprog" tt_shift=100000

will shift the time in all calls from myprog
to the system time functions stat(2), lstat(2),
fstat(2), and utime(2)
ahead 100,000 milliseconds into
the future.





Red Hat® Linux 6 Unleashed










Chapter 28: Configuring and Building Kernels





Previous
ChapterNext
Chapter










Sections in this Chapter:









 
 



An
Introduction to the Linux Kernel










Ftape,
the Floppy Tape Device Driver





Load/Save
Configuration






Obtaining
the Kernel Sources





Old CD-ROM
Drivers (Not SCSI or IDE)










Building
and Installing the Kernel






Configuring
Linux Kernel





Character
Devices





Network
Filesystems





Manually
Installing a New Kernel






Configuration
Options










Partition
Types





Troubleshooting
the New Kernel






General
Setup





Watchdog,
NVRAM, and RTC Devices





Native
Language Support





Troubleshooting and Recovery






Networking
Options





DoubleTalk
Speech Synthesizer





Console
Drivers





References
and Resources


























Network
Device Support





Joystick
Support





Kernel
Hacking










 

Previous
SectionNext
Section





© Copyright Macmillan USA. All rights reserved.

  • zanotowane.pl
  • doc.pisz.pl
  • pdf.pisz.pl
  • teen-mushing.xlx.pl
  • Wątki
    Powered by wordpress | Theme: simpletex | © Lemur zaprasza