blob: 09f34f78f2bb6ab5e62657dda91185723160d2f9
1 | Linux kernel release 4.x <http://kernel.org/> |
2 | |
3 | These are the release notes for Linux version 4. 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, Tilera TILE, AVR32, ARC 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, HTML, & man-pages, among others. |
56 | After installation, "make psdocs", "make pdfdocs", "make htmldocs", |
57 | or "make mandocs" will render the documentation in the requested format. |
58 | |
59 | INSTALLING the kernel source: |
60 | |
61 | - If you install the full sources, put the kernel tarball in a |
62 | directory where you have permissions (e.g. your home directory) and |
63 | unpack it: |
64 | |
65 | xz -cd linux-4.X.tar.xz | tar xvf - |
66 | |
67 | Replace "X" with the version number of the latest kernel. |
68 | |
69 | Do NOT use the /usr/src/linux area! This area has a (usually |
70 | incomplete) set of kernel headers that are used by the library header |
71 | files. They should match the library, and not get messed up by |
72 | whatever the kernel-du-jour happens to be. |
73 | |
74 | - You can also upgrade between 4.x releases by patching. Patches are |
75 | distributed in the xz format. To install by patching, get all the |
76 | newer patch files, enter the top level directory of the kernel source |
77 | (linux-4.X) and execute: |
78 | |
79 | xz -cd ../patch-4.x.xz | patch -p1 |
80 | |
81 | Replace "x" for all versions bigger than the version "X" of your current |
82 | source tree, _in_order_, and you should be ok. You may want to remove |
83 | the backup files (some-file-name~ or some-file-name.orig), and make sure |
84 | that there are no failed patches (some-file-name# or some-file-name.rej). |
85 | If there are, either you or I have made a mistake. |
86 | |
87 | Unlike patches for the 4.x kernels, patches for the 4.x.y kernels |
88 | (also known as the -stable kernels) are not incremental but instead apply |
89 | directly to the base 4.x kernel. For example, if your base kernel is 4.0 |
90 | and you want to apply the 4.0.3 patch, you must not first apply the 4.0.1 |
91 | and 4.0.2 patches. Similarly, if you are running kernel version 4.0.2 and |
92 | want to jump to 4.0.3, you must first reverse the 4.0.2 patch (that is, |
93 | patch -R) _before_ applying the 4.0.3 patch. You can read more on this in |
94 | Documentation/applying-patches.txt |
95 | |
96 | Alternatively, the script patch-kernel can be used to automate this |
97 | process. It determines the current kernel version and applies any |
98 | patches found. |
99 | |
100 | linux/scripts/patch-kernel linux |
101 | |
102 | The first argument in the command above is the location of the |
103 | kernel source. Patches are applied from the current directory, but |
104 | an alternative directory can be specified as the second argument. |
105 | |
106 | - Make sure you have no stale .o files and dependencies lying around: |
107 | |
108 | cd linux |
109 | make mrproper |
110 | |
111 | You should now have the sources correctly installed. |
112 | |
113 | SOFTWARE REQUIREMENTS |
114 | |
115 | Compiling and running the 4.x kernels requires up-to-date |
116 | versions of various software packages. Consult |
117 | Documentation/Changes for the minimum version numbers required |
118 | and how to get updates for these packages. Beware that using |
119 | excessively old versions of these packages can cause indirect |
120 | errors that are very difficult to track down, so don't assume that |
121 | you can just update packages when obvious problems arise during |
122 | build or operation. |
123 | |
124 | BUILD directory for the kernel: |
125 | |
126 | When compiling the kernel, all output files will per default be |
127 | stored together with the kernel source code. |
128 | Using the option "make O=output/dir" allows you to specify an alternate |
129 | place for the output files (including .config). |
130 | Example: |
131 | |
132 | kernel source code: /usr/src/linux-4.X |
133 | build directory: /home/name/build/kernel |
134 | |
135 | To configure and build the kernel, use: |
136 | |
137 | cd /usr/src/linux-4.X |
138 | make O=/home/name/build/kernel menuconfig |
139 | make O=/home/name/build/kernel |
140 | sudo make O=/home/name/build/kernel modules_install install |
141 | |
142 | Please note: If the 'O=output/dir' option is used, then it must be |
143 | used for all invocations of make. |
144 | |
145 | CONFIGURING the kernel: |
146 | |
147 | Do not skip this step even if you are only upgrading one minor |
148 | version. New configuration options are added in each release, and |
149 | odd problems will turn up if the configuration files are not set up |
150 | as expected. If you want to carry your existing configuration to a |
151 | new version with minimal work, use "make oldconfig", which will |
152 | only ask you for the answers to new questions. |
153 | |
154 | - Alternative configuration commands are: |
155 | |
156 | "make config" Plain text interface. |
157 | |
158 | "make menuconfig" Text based color menus, radiolists & dialogs. |
159 | |
160 | "make nconfig" Enhanced text based color menus. |
161 | |
162 | "make xconfig" Qt based configuration tool. |
163 | |
164 | "make gconfig" GTK+ based configuration tool. |
165 | |
166 | "make oldconfig" Default all questions based on the contents of |
167 | your existing ./.config file and asking about |
168 | new config symbols. |
169 | |
170 | "make silentoldconfig" |
171 | Like above, but avoids cluttering the screen |
172 | with questions already answered. |
173 | Additionally updates the dependencies. |
174 | |
175 | "make olddefconfig" |
176 | Like above, but sets new symbols to their default |
177 | values without prompting. |
178 | |
179 | "make defconfig" Create a ./.config file by using the default |
180 | symbol values from either arch/$ARCH/defconfig |
181 | or arch/$ARCH/configs/${PLATFORM}_defconfig, |
182 | depending on the architecture. |
183 | |
184 | "make ${PLATFORM}_defconfig" |
185 | Create a ./.config file by using the default |
186 | symbol values from |
187 | arch/$ARCH/configs/${PLATFORM}_defconfig. |
188 | Use "make help" to get a list of all available |
189 | platforms of your architecture. |
190 | |
191 | "make allyesconfig" |
192 | Create a ./.config file by setting symbol |
193 | values to 'y' as much as possible. |
194 | |
195 | "make allmodconfig" |
196 | Create a ./.config file by setting symbol |
197 | values to 'm' as much as possible. |
198 | |
199 | "make allnoconfig" Create a ./.config file by setting symbol |
200 | values to 'n' as much as possible. |
201 | |
202 | "make randconfig" Create a ./.config file by setting symbol |
203 | values to random values. |
204 | |
205 | "make localmodconfig" Create a config based on current config and |
206 | loaded modules (lsmod). Disables any module |
207 | option that is not needed for the loaded modules. |
208 | |
209 | To create a localmodconfig for another machine, |
210 | store the lsmod of that machine into a file |
211 | and pass it in as a LSMOD parameter. |
212 | |
213 | target$ lsmod > /tmp/mylsmod |
214 | target$ scp /tmp/mylsmod host:/tmp |
215 | |
216 | host$ make LSMOD=/tmp/mylsmod localmodconfig |
217 | |
218 | The above also works when cross compiling. |
219 | |
220 | "make localyesconfig" Similar to localmodconfig, except it will convert |
221 | all module options to built in (=y) options. |
222 | |
223 | You can find more information on using the Linux kernel config tools |
224 | in Documentation/kbuild/kconfig.txt. |
225 | |
226 | - NOTES on "make config": |
227 | |
228 | - Having unnecessary drivers will make the kernel bigger, and can |
229 | under some circumstances lead to problems: probing for a |
230 | nonexistent controller card may confuse your other controllers |
231 | |
232 | - A kernel with math-emulation compiled in will still use the |
233 | coprocessor if one is present: the math emulation will just |
234 | never get used in that case. The kernel will be slightly larger, |
235 | but will work on different machines regardless of whether they |
236 | have a math coprocessor or not. |
237 | |
238 | - The "kernel hacking" configuration details usually result in a |
239 | bigger or slower kernel (or both), and can even make the kernel |
240 | less stable by configuring some routines to actively try to |
241 | break bad code to find kernel problems (kmalloc()). Thus you |
242 | should probably answer 'n' to the questions for "development", |
243 | "experimental", or "debugging" features. |
244 | |
245 | COMPILING the kernel: |
246 | |
247 | - Make sure you have at least gcc 3.2 available. |
248 | For more information, refer to Documentation/Changes. |
249 | |
250 | Please note that you can still run a.out user programs with this kernel. |
251 | |
252 | - Do a "make" to create a compressed kernel image. It is also |
253 | possible to do "make install" if you have lilo installed to suit the |
254 | kernel makefiles, but you may want to check your particular lilo setup first. |
255 | |
256 | To do the actual install, you have to be root, but none of the normal |
257 | build should require that. Don't take the name of root in vain. |
258 | |
259 | - If you configured any of the parts of the kernel as `modules', you |
260 | will also have to do "make modules_install". |
261 | |
262 | - Verbose kernel compile/build output: |
263 | |
264 | Normally, the kernel build system runs in a fairly quiet mode (but not |
265 | totally silent). However, sometimes you or other kernel developers need |
266 | to see compile, link, or other commands exactly as they are executed. |
267 | For this, use "verbose" build mode. This is done by passing |
268 | "V=1" to the "make" command, e.g. |
269 | |
270 | make V=1 all |
271 | |
272 | To have the build system also tell the reason for the rebuild of each |
273 | target, use "V=2". The default is "V=0". |
274 | |
275 | - Keep a backup kernel handy in case something goes wrong. This is |
276 | especially true for the development releases, since each new release |
277 | contains new code which has not been debugged. Make sure you keep a |
278 | backup of the modules corresponding to that kernel, as well. If you |
279 | are installing a new kernel with the same version number as your |
280 | working kernel, make a backup of your modules directory before you |
281 | do a "make modules_install". |
282 | |
283 | Alternatively, before compiling, use the kernel config option |
284 | "LOCALVERSION" to append a unique suffix to the regular kernel version. |
285 | LOCALVERSION can be set in the "General Setup" menu. |
286 | |
287 | - In order to boot your new kernel, you'll need to copy the kernel |
288 | image (e.g. .../linux/arch/x86/boot/bzImage after compilation) |
289 | to the place where your regular bootable kernel is found. |
290 | |
291 | - Booting a kernel directly from a floppy without the assistance of a |
292 | bootloader such as LILO, is no longer supported. |
293 | |
294 | If you boot Linux from the hard drive, chances are you use LILO, which |
295 | uses the kernel image as specified in the file /etc/lilo.conf. The |
296 | kernel image file is usually /vmlinuz, /boot/vmlinuz, /bzImage or |
297 | /boot/bzImage. To use the new kernel, save a copy of the old image |
298 | and copy the new image over the old one. Then, you MUST RERUN LILO |
299 | to update the loading map! If you don't, you won't be able to boot |
300 | the new kernel image. |
301 | |
302 | Reinstalling LILO is usually a matter of running /sbin/lilo. |
303 | You may wish to edit /etc/lilo.conf to specify an entry for your |
304 | old kernel image (say, /vmlinux.old) in case the new one does not |
305 | work. See the LILO docs for more information. |
306 | |
307 | After reinstalling LILO, you should be all set. Shutdown the system, |
308 | reboot, and enjoy! |
309 | |
310 | If you ever need to change the default root device, video mode, |
311 | ramdisk size, etc. in the kernel image, use the 'rdev' program (or |
312 | alternatively the LILO boot options when appropriate). No need to |
313 | recompile the kernel to change these parameters. |
314 | |
315 | - Reboot with the new kernel and enjoy. |
316 | |
317 | IF SOMETHING GOES WRONG: |
318 | |
319 | - If you have problems that seem to be due to kernel bugs, please check |
320 | the file MAINTAINERS to see if there is a particular person associated |
321 | with the part of the kernel that you are having trouble with. If there |
322 | isn't anyone listed there, then the second best thing is to mail |
323 | them to me (torvalds@linux-foundation.org), and possibly to any other |
324 | relevant mailing-list or to the newsgroup. |
325 | |
326 | - In all bug-reports, *please* tell what kernel you are talking about, |
327 | how to duplicate the problem, and what your setup is (use your common |
328 | sense). If the problem is new, tell me so, and if the problem is |
329 | old, please try to tell me when you first noticed it. |
330 | |
331 | - If the bug results in a message like |
332 | |
333 | unable to handle kernel paging request at address C0000010 |
334 | Oops: 0002 |
335 | EIP: 0010:XXXXXXXX |
336 | eax: xxxxxxxx ebx: xxxxxxxx ecx: xxxxxxxx edx: xxxxxxxx |
337 | esi: xxxxxxxx edi: xxxxxxxx ebp: xxxxxxxx |
338 | ds: xxxx es: xxxx fs: xxxx gs: xxxx |
339 | Pid: xx, process nr: xx |
340 | xx xx xx xx xx xx xx xx xx xx |
341 | |
342 | or similar kernel debugging information on your screen or in your |
343 | system log, please duplicate it *exactly*. The dump may look |
344 | incomprehensible to you, but it does contain information that may |
345 | help debugging the problem. The text above the dump is also |
346 | important: it tells something about why the kernel dumped code (in |
347 | the above example, it's due to a bad kernel pointer). More information |
348 | on making sense of the dump is in Documentation/oops-tracing.txt |
349 | |
350 | - If you compiled the kernel with CONFIG_KALLSYMS you can send the dump |
351 | as is, otherwise you will have to use the "ksymoops" program to make |
352 | sense of the dump (but compiling with CONFIG_KALLSYMS is usually preferred). |
353 | This utility can be downloaded from |
354 | ftp://ftp.<country>.kernel.org/pub/linux/utils/kernel/ksymoops/ . |
355 | Alternatively, you can do the dump lookup by hand: |
356 | |
357 | - In debugging dumps like the above, it helps enormously if you can |
358 | look up what the EIP value means. The hex value as such doesn't help |
359 | me or anybody else very much: it will depend on your particular |
360 | kernel setup. What you should do is take the hex value from the EIP |
361 | line (ignore the "0010:"), and look it up in the kernel namelist to |
362 | see which kernel function contains the offending address. |
363 | |
364 | To find out the kernel function name, you'll need to find the system |
365 | binary associated with the kernel that exhibited the symptom. This is |
366 | the file 'linux/vmlinux'. To extract the namelist and match it against |
367 | the EIP from the kernel crash, do: |
368 | |
369 | nm vmlinux | sort | less |
370 | |
371 | This will give you a list of kernel addresses sorted in ascending |
372 | order, from which it is simple to find the function that contains the |
373 | offending address. Note that the address given by the kernel |
374 | debugging messages will not necessarily match exactly with the |
375 | function addresses (in fact, that is very unlikely), so you can't |
376 | just 'grep' the list: the list will, however, give you the starting |
377 | point of each kernel function, so by looking for the function that |
378 | has a starting address lower than the one you are searching for but |
379 | is followed by a function with a higher address you will find the one |
380 | you want. In fact, it may be a good idea to include a bit of |
381 | "context" in your problem report, giving a few lines around the |
382 | interesting one. |
383 | |
384 | If you for some reason cannot do the above (you have a pre-compiled |
385 | kernel image or similar), telling me as much about your setup as |
386 | possible will help. Please read the REPORTING-BUGS document for details. |
387 | |
388 | - Alternatively, you can use gdb on a running kernel. (read-only; i.e. you |
389 | cannot change values or set break points.) To do this, first compile the |
390 | kernel with -g; edit arch/x86/Makefile appropriately, then do a "make |
391 | clean". You'll also need to enable CONFIG_PROC_FS (via "make config"). |
392 | |
393 | After you've rebooted with the new kernel, do "gdb vmlinux /proc/kcore". |
394 | You can now use all the usual gdb commands. The command to look up the |
395 | point where your system crashed is "l *0xXXXXXXXX". (Replace the XXXes |
396 | with the EIP value.) |
397 | |
398 | gdb'ing a non-running kernel currently fails because gdb (wrongly) |
399 | disregards the starting offset for which the kernel is compiled. |
400 | |
401 |