1: Linux kernel release 2.6.xx <http://kernel.org/> 2: 3: These are the release notes for Linux version 2.6. Read them carefully, 4: as they tell you what this is all about, explain how to install the 5: kernel, and what to do if something goes wrong. 6: 7: WHAT IS LINUX? 8: 9: Linux is a clone of the operating system Unix, written from scratch by 10: Linus Torvalds with assistance from a loosely-knit team of hackers across 11: the Net. It aims towards POSIX and Single UNIX Specification compliance. 12: 13: It has all the features you would expect in a modern fully-fledged Unix, 14: including true multitasking, virtual memory, shared libraries, demand 15: loading, shared copy-on-write executables, proper memory management, 16: and multistack networking including IPv4 and IPv6. 17: 18: It is distributed under the GNU General Public License - see the 19: accompanying COPYING file for more details. 20: 21: ON WHAT HARDWARE DOES IT RUN? 22: 23: Although originally developed first for 32-bit x86-based PCs (386 or higher), 24: today Linux also runs on (at least) the Compaq Alpha AXP, Sun SPARC and 25: UltraSPARC, Motorola 68000, PowerPC, PowerPC64, ARM, Hitachi SuperH, Cell, 26: IBM S/390, MIPS, HP PA-RISC, Intel IA-64, DEC VAX, AMD x86-64, AXIS CRIS, 27: Xtensa, AVR32 and Renesas M32R architectures. 28: 29: Linux is easily portable to most general-purpose 32- or 64-bit architectures 30: as long as they have a paged memory management unit (PMMU) and a port of the 31: GNU C compiler (gcc) (part of The GNU Compiler Collection, GCC). Linux has 32: also been ported to a number of architectures without a PMMU, although 33: functionality is then obviously somewhat limited. 34: Linux has also been ported to itself. You can now run the kernel as a 35: userspace application - this is called UserMode Linux (UML). 36: 37: DOCUMENTATION: 38: 39: - There is a lot of documentation available both in electronic form on 40: the Internet and in books, both Linux-specific and pertaining to 41: general UNIX questions. I'd recommend looking into the documentation 42: subdirectories on any Linux FTP site for the LDP (Linux Documentation 43: Project) books. This README is not meant to be documentation on the 44: system: there are much better sources available. 45: 46: - There are various README files in the Documentation/ subdirectory: 47: these typically contain kernel-specific installation notes for some 48: drivers for example. See Documentation/00-INDEX for a list of what 49: is contained in each file. Please read the Changes file, as it 50: contains information about the problems, which may result by upgrading 51: your kernel. 52: 53: - The Documentation/DocBook/ subdirectory contains several guides for 54: kernel developers and users. These guides can be rendered in a 55: number of formats: PostScript (.ps), PDF, and HTML, among others. 56: After installation, "make psdocs", "make pdfdocs", or "make htmldocs" 57: will render the documentation in the requested format. 58: 59: INSTALLING the kernel: 60: 61: - If you install the full sources, put the kernel tarball in a 62: directory where you have permissions (eg. your home directory) and 63: unpack it: 64: 65: gzip -cd linux-2.6.XX.tar.gz | tar xvf - 66: 67: or 68: bzip2 -dc linux-2.6.XX.tar.bz2 | tar xvf - 69: 70: 71: Replace "XX" with the version number of the latest kernel. 72: 73: Do NOT use the /usr/src/linux area! This area has a (usually 74: incomplete) set of kernel headers that are used by the library header 75: files. They should match the library, and not get messed up by 76: whatever the kernel-du-jour happens to be. 77: 78: - You can also upgrade between 2.6.xx releases by patching. Patches are 79: distributed in the traditional gzip and the newer bzip2 format. To 80: install by patching, get all the newer patch files, enter the 81: top level directory of the kernel source (linux-2.6.xx) and execute: 82: 83: gzip -cd ../patch-2.6.xx.gz | patch -p1 84: 85: or 86: bzip2 -dc ../patch-2.6.xx.bz2 | patch -p1 87: 88: (repeat xx for all versions bigger than the version of your current 89: source tree, _in_order_) and you should be ok. You may want to remove 90: the backup files (xxx~ or xxx.orig), and make sure that there are no 91: failed patches (xxx# or xxx.rej). If there are, either you or me has 92: made a mistake. 93: 94: Unlike patches for the 2.6.x kernels, patches for the 2.6.x.y kernels 95: (also known as the -stable kernels) are not incremental but instead apply 96: directly to the base 2.6.x kernel. Please read 97: Documentation/applying-patches.txt for more information. 98: 99: Alternatively, the script patch-kernel can be used to automate this 100: process. It determines the current kernel version and applies any 101: patches found. 102: 103: linux/scripts/patch-kernel linux 104: 105: The first argument in the command above is the location of the 106: kernel source. Patches are applied from the current directory, but 107: an alternative directory can be specified as the second argument. 108: 109: - If you are upgrading between releases using the stable series patches 110: (for example, patch-2.6.xx.y), note that these "dot-releases" are 111: not incremental and must be applied to the 2.6.xx base tree. For 112: example, if your base kernel is 2.6.12 and you want to apply the 113: 2.6.12.3 patch, you do not and indeed must not first apply the 114: 2.6.12.1 and 2.6.12.2 patches. Similarly, if you are running kernel 115: version 2.6.12.2 and want to jump to 2.6.12.3, you must first 116: reverse the 2.6.12.2 patch (that is, patch -R) _before_ applying 117: the 2.6.12.3 patch. 118: You can read more on this in Documentation/applying-patches.txt 119: 120: - Make sure you have no stale .o files and dependencies lying around: 121: 122: cd linux 123: make mrproper 124: 125: You should now have the sources correctly installed. 126: 127: SOFTWARE REQUIREMENTS 128: 129: Compiling and running the 2.6.xx kernels requires up-to-date 130: versions of various software packages. Consult 131: Documentation/Changes for the minimum version numbers required 132: and how to get updates for these packages. Beware that using 133: excessively old versions of these packages can cause indirect 134: errors that are very difficult to track down, so don't assume that 135: you can just update packages when obvious problems arise during 136: build or operation. 137: 138: BUILD directory for the kernel: 139: 140: When compiling the kernel all output files will per default be 141: stored together with the kernel source code. 142: Using the option "make O=output/dir" allow you to specify an alternate 143: place for the output files (including .config). 144: Example: 145: kernel source code: /usr/src/linux-2.6.N 146: build directory: /home/name/build/kernel 147: 148: To configure and build the kernel use: 149: cd /usr/src/linux-2.6.N 150: make O=/home/name/build/kernel menuconfig 151: make O=/home/name/build/kernel 152: sudo make O=/home/name/build/kernel modules_install install 153: 154: Please note: If the 'O=output/dir' option is used then it must be 155: used for all invocations of make. 156: 157: CONFIGURING the kernel: 158: 159: Do not skip this step even if you are only upgrading one minor 160: version. New configuration options are added in each release, and 161: odd problems will turn up if the configuration files are not set up 162: as expected. If you want to carry your existing configuration to a 163: new version with minimal work, use "make oldconfig", which will 164: only ask you for the answers to new questions. 165: 166: - Alternate configuration commands are: 167: "make config" Plain text interface. 168: "make menuconfig" Text based color menus, radiolists & dialogs. 169: "make xconfig" X windows (Qt) based configuration tool. 170: "make gconfig" X windows (Gtk) based configuration tool. 171: "make oldconfig" Default all questions based on the contents of 172: your existing ./.config file and asking about 173: new config symbols. 174: "make silentoldconfig" 175: Like above, but avoids cluttering the screen 176: with questions already answered. 177: "make defconfig" Create a ./.config file by using the default 178: symbol values from arch/$ARCH/defconfig. 179: "make allyesconfig" 180: Create a ./.config file by setting symbol 181: values to 'y' as much as possible. 182: "make allmodconfig" 183: Create a ./.config file by setting symbol 184: values to 'm' as much as possible. 185: "make allnoconfig" Create a ./.config file by setting symbol 186: values to 'n' as much as possible. 187: "make randconfig" Create a ./.config file by setting symbol 188: values to random values. 189: 190: The allyesconfig/allmodconfig/allnoconfig/randconfig variants can 191: also use the environment variable KCONFIG_ALLCONFIG to specify a 192: filename that contains config options that the user requires to be 193: set to a specific value. If KCONFIG_ALLCONFIG=filename is not used, 194: "make *config" checks for a file named "all{yes/mod/no/random}.config" 195: for symbol values that are to be forced. If this file is not found, 196: it checks for a file named "all.config" to contain forced values. 197: 198: NOTES on "make config": 199: - having unnecessary drivers will make the kernel bigger, and can 200: under some circumstances lead to problems: probing for a 201: nonexistent controller card may confuse your other controllers 202: - compiling the kernel with "Processor type" set higher than 386 203: will result in a kernel that does NOT work on a 386. The 204: kernel will detect this on bootup, and give up. 205: - A kernel with math-emulation compiled in will still use the 206: coprocessor if one is present: the math emulation will just 207: never get used in that case. The kernel will be slightly larger, 208: but will work on different machines regardless of whether they 209: have a math coprocessor or not. 210: - the "kernel hacking" configuration details usually result in a 211: bigger or slower kernel (or both), and can even make the kernel 212: less stable by configuring some routines to actively try to 213: break bad code to find kernel problems (kmalloc()). Thus you 214: should probably answer 'n' to the questions for 215: "development", "experimental", or "debugging" features. 216: 217: COMPILING the kernel: 218: 219: - Make sure you have at least gcc 3.2 available. 220: For more information, refer to Documentation/Changes. 221: 222: Please note that you can still run a.out user programs with this kernel. 223: 224: - Do a "make" to create a compressed kernel image. It is also 225: possible to do "make install" if you have lilo installed to suit the 226: kernel makefiles, but you may want to check your particular lilo setup first. 227: 228: To do the actual install you have to be root, but none of the normal 229: build should require that. Don't take the name of root in vain. 230: 231: - If you configured any of the parts of the kernel as `modules', you 232: will also have to do "make modules_install". 233: 234: - Keep a backup kernel handy in case something goes wrong. This is 235: especially true for the development releases, since each new release 236: contains new code which has not been debugged. Make sure you keep a 237: backup of the modules corresponding to that kernel, as well. If you 238: are installing a new kernel with the same version number as your 239: working kernel, make a backup of your modules directory before you 240: do a "make modules_install". 241: Alternatively, before compiling, use the kernel config option 242: "LOCALVERSION" to append a unique suffix to the regular kernel version. 243: LOCALVERSION can be set in the "General Setup" menu. 244: 245: - In order to boot your new kernel, you'll need to copy the kernel 246: image (e.g. .../linux/arch/i386/boot/bzImage after compilation) 247: to the place where your regular bootable kernel is found. 248: 249: - Booting a kernel directly from a floppy without the assistance of a 250: bootloader such as LILO, is no longer supported. 251: 252: If you boot Linux from the hard drive, chances are you use LILO which 253: uses the kernel image as specified in the file /etc/lilo.conf. The 254: kernel image file is usually /vmlinuz, /boot/vmlinuz, /bzImage or 255: /boot/bzImage. To use the new kernel, save a copy of the old image 256: and copy the new image over the old one. Then, you MUST RERUN LILO 257: to update the loading map!! If you don't, you won't be able to boot 258: the new kernel image. 259: 260: Reinstalling LILO is usually a matter of running /sbin/lilo. 261: You may wish to edit /etc/lilo.conf to specify an entry for your 262: old kernel image (say, /vmlinux.old) in case the new one does not 263: work. See the LILO docs for more information. 264: 265: After reinstalling LILO, you should be all set. Shutdown the system, 266: reboot, and enjoy! 267: 268: If you ever need to change the default root device, video mode, 269: ramdisk size, etc. in the kernel image, use the 'rdev' program (or 270: alternatively the LILO boot options when appropriate). No need to 271: recompile the kernel to change these parameters. 272: 273: - Reboot with the new kernel and enjoy. 274: 275: IF SOMETHING GOES WRONG: 276: 277: - If you have problems that seem to be due to kernel bugs, please check 278: the file MAINTAINERS to see if there is a particular person associated 279: with the part of the kernel that you are having trouble with. If there 280: isn't anyone listed there, then the second best thing is to mail 281: them to me (torvalds@linux-foundation.org), and possibly to any other 282: relevant mailing-list or to the newsgroup. 283: 284: - In all bug-reports, *please* tell what kernel you are talking about, 285: how to duplicate the problem, and what your setup is (use your common 286: sense). If the problem is new, tell me so, and if the problem is 287: old, please try to tell me when you first noticed it. 288: 289: - If the bug results in a message like 290: 291: unable to handle kernel paging request at address C0000010 292: Oops: 0002 293: EIP: 0010:XXXXXXXX 294: eax: xxxxxxxx ebx: xxxxxxxx ecx: xxxxxxxx edx: xxxxxxxx 295: esi: xxxxxxxx edi: xxxxxxxx ebp: xxxxxxxx 296: ds: xxxx es: xxxx fs: xxxx gs: xxxx 297: Pid: xx, process nr: xx 298: xx xx xx xx xx xx xx xx xx xx 299: 300: or similar kernel debugging information on your screen or in your 301: system log, please duplicate it *exactly*. The dump may look 302: incomprehensible to you, but it does contain information that may 303: help debugging the problem. The text above the dump is also 304: important: it tells something about why the kernel dumped code (in 305: the above example it's due to a bad kernel pointer). More information 306: on making sense of the dump is in Documentation/oops-tracing.txt 307: 308: - If you compiled the kernel with CONFIG_KALLSYMS you can send the dump 309: as is, otherwise you will have to use the "ksymoops" program to make 310: sense of the dump (but compiling with CONFIG_KALLSYMS is usually preferred). 311: This utility can be downloaded from 312: ftp://ftp.<country>.kernel.org/pub/linux/utils/kernel/ksymoops/ . 313: Alternately you can do the dump lookup by hand: 314: 315: - In debugging dumps like the above, it helps enormously if you can 316: look up what the EIP value means. The hex value as such doesn't help 317: me or anybody else very much: it will depend on your particular 318: kernel setup. What you should do is take the hex value from the EIP 319: line (ignore the "0010:"), and look it up in the kernel namelist to 320: see which kernel function contains the offending address. 321: 322: To find out the kernel function name, you'll need to find the system 323: binary associated with the kernel that exhibited the symptom. This is 324: the file 'linux/vmlinux'. To extract the namelist and match it against 325: the EIP from the kernel crash, do: 326: 327: nm vmlinux | sort | less 328: 329: This will give you a list of kernel addresses sorted in ascending 330: order, from which it is simple to find the function that contains the 331: offending address. Note that the address given by the kernel 332: debugging messages will not necessarily match exactly with the 333: function addresses (in fact, that is very unlikely), so you can't 334: just 'grep' the list: the list will, however, give you the starting 335: point of each kernel function, so by looking for the function that 336: has a starting address lower than the one you are searching for but 337: is followed by a function with a higher address you will find the one 338: you want. In fact, it may be a good idea to include a bit of 339: "context" in your problem report, giving a few lines around the 340: interesting one. 341: 342: If you for some reason cannot do the above (you have a pre-compiled 343: kernel image or similar), telling me as much about your setup as 344: possible will help. Please read the REPORTING-BUGS document for details. 345: 346: - Alternately, you can use gdb on a running kernel. (read-only; i.e. you 347: cannot change values or set break points.) To do this, first compile the 348: kernel with -g; edit arch/i386/Makefile appropriately, then do a "make 349: clean". You'll also need to enable CONFIG_PROC_FS (via "make config"). 350: 351: After you've rebooted with the new kernel, do "gdb vmlinux /proc/kcore". 352: You can now use all the usual gdb commands. The command to look up the 353: point where your system crashed is "l *0xXXXXXXXX". (Replace the XXXes 354: with the EIP value.) 355: 356: gdb'ing a non-running kernel currently fails because gdb (wrongly) 357: disregards the starting offset for which the kernel is compiled. 358: