When Something Goes Wrong
| < Day Day Up > |
| Several things might go wrong during a kernel compile and installation, and several clues will point to the true problem. You will see error messages printed to the screen, and some error messages will be printed to the file /var/log/messages, which can be examined with a text editor. If you have followed our directions for patching the kernel, you will need to examine a special error log as well. Do not worry about errors because many problems are easily fixed with some research on your part. Some errors may be unfixable, however, depending on your skill level and the availability of technical information. Errors During CompileAlthough it is rare that the kernel will not compile, there is always a chance that something has slipped though the regression testing. Let's take a look at an example of a problem that might crop up during the compile. It is possible that the kernel compile will crash and not complete successfully, especially if you attempt to use experimental patches, add untested features, or build newer and perhaps unstable modules on an older system. For example, the kernel compile will fail on an older stock Red Hat 7.2 installation using the 2.4.9 kernel when selecting the NTFS file system, either as a loadable module or inline, as shown here: gcc -D__KERNEL__ -I/usr/src/linux-2.4.9/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer -fno-strict-aliasing -fno-common -pipe -mpreferred-stack-boundary=2 -march=athlon -DMODULE -DMODVERSIONS -include /usr/src/linux-2.4.9/include/linux/modversions.h -DNTFS_VERSION=\"1.1.16\" Â\ -c -o unistr.o unistr.c unistr.c: In function `ntfs_collate_names': unistr.c:99: warning: implicit declaration of function `min' unistr.c:99: parse error before `unsigned' unistr.c:99: parse error before `)' unistr.c:97: warning: `c1' might be used uninitialized in this function unistr.c: At top level: unistr.c:118: parse error before `if' unistr.c:123: warning: type defaults to `int' in declaration of `c1' unistr.c:123: `name1' undeclared here (not in a function) unistr.c:123: warning: data definition has no type or storage class unistr.c:124: parse error before `if' make[2]: *** [unistr.o] Error 1 make[2]: Leaving directory `/usr/src/linux-2.4.9/fs/ntfs' make[1]: *** [_modsubdir_ntfs] Error 2 make[1]: Leaving directory `/usr/src/linux-2.4.9/fs' make: *** [_mod_fs] Error 2 At this juncture, you have two options:
Most users will be unable to fix some errors because of the complexity of the kernel code, although you should not rule out this option. It is possible that someone else discovered the same error during testing of the kernel and developed a patch for the problem: check the Linux kernel mailing list archive. If the problem is not mentioned there, a search on Google might turn up something. The second option, removing the code, is the easiest and is what most people do in cases in which the offending code is not required. In the case of the NTFS module failing, it is almost expected because NTFS support is still considered experimental and subject to errors. This is primarily because the code for the file system is reverse-engineered instead of implemented via documented standards. Read-only support has gotten better in recent kernels; write support is still experimental. Finally, should you want to take on the task of trying to fix the problem yourself, this is a great opportunity to get involved with the Linux kernel and make a contribution that could help many others. If you are knowledgeable about coding and kernel matters, you might want to look in the MAINTAINERS file in the /usr/src/linux-2.6/ directory of the kernel source and find the maintainer of the code. The recommended course of action is to contact the maintainer and see if he is aware of the problems you are having. If nothing has been documented for the specific error, submitting the error to the kernel mailing list is an option. The guidelines for doing this are in the README file in the base directory of the kernel source under the section "If Something Goes Wrong." Runtime Errors, Boot Loader Problems, and Kernel OopsRuntime errors occur as the kernel is loading. Error messages are displayed on the screen or written to the /var/log/messages file. Bootloader problems display messages to the screen; no log file is produced. Kernel oops are errors in a running kernel, and error messages are written to the /var/log/messages file. Excellent documentation on the Internet exists for troubleshooting just about every type of error that LILO, GRUB, or the kernel could give during boot. The best way to find this documentation is to go to your favorite search engine and type in the keywords of the error you received. You will need to adjust the keywords you use as you focus your search. In this category, the most common problems deal with LILO configuration issues. Diagnosis and solutions to these problems can be found in the LILO mini-HOWTO found on the Linux Documentation project's website at http://www.ibiblio.org/pub/Linux/docs/HOWTO/other-formats/html_single/LILO.html. If you have GRUB problems, the GRUB manual is online at http://www.gnu.org/software/grub/manual/. TIP For best results, go to http://www.google.com/linux to find all things Linux on the Internet. Google has specifically created a Linux area of its database, which should allow faster access to information on Linux than any other search engine. The Usenet newsgroup postings are searchable at http://www.google.com/grphp. Mail list discussions can be searched in the Mailing listARChives (MARC) at http://marc.theaimsgroup.com/.
|
| < Day Day Up > |
EAN: 2147483647
Pages: 361