{"id":250,"date":"2020-08-18T19:23:47","date_gmt":"2020-08-18T20:23:47","guid":{"rendered":"http:\/\/www.linux-tutorial.info\/?page_id=77"},"modified":"2020-08-22T19:26:18","modified_gmt":"2020-08-22T20:26:18","slug":"this-is-the-page-title-toplevel-85","status":"publish","type":"page","link":"http:\/\/www.linux-tutorial.info\/?page_id=250","title":{"rendered":"Rebuilding Your Kernel"},"content":{"rendered":"\nRebuilding Your Kernel<\/title>\n<question id=\"187\" text=\"'Rebuilding' a kernel consists of compiling C-language source code files.\">\n<concept id=\"145\" description=\"'Rebuilding' a kernel consists of compiling C-language source code files.\" \/>\n<p>\nRebuilding your <glossary>kernel<\/glossary>\nis the process by which you\ncompile all the components of your source code to create a <glossary>kernel<\/glossary>\nfrom which you\ncan then install and <glossary>boot<\/glossary>.\n A rebuild is important (actually, <i>necessary<\/i>)\nwhen you want to add or remove drivers or change parameters. Often, changes or\nupdates to the <glossary>kernel<\/glossary>\nare made that you want to include to keep yourself up to\ndate. (Note that adding new drivers does not always require you to rebuild your\nkernel and use -R for recursive reboot. This is where <glossary>kernel<\/glossary>\nmodules come in, which we talk about\nlater.)<\/p>\n<p>\nUsually, the updates and or patch come too fast for commercial\ndistributions to keep up with them and include them on their <glossary>CD-ROM<\/glossary>.\n Normally,\nnew CD-ROMs are created only for minor releases and not revisions. So, if you\nwant to keep up to date, you will have to implement them you yourself. This is\nalso nice because you don’t need to get a new <glossary>CD-ROM<\/glossary>\nevery time.\n<\/p>\n<p>\nOne very\nimportant thing to keep in mind is that many applications require specific\nkernel versions to run correctly (specifically <command>ps<\/command>). Therefore, if you are planning to install a new\nversion of a program or applications, make sure that it is compatible with your\nkernel.\n<\/p>\n<question id=\"183\" text=\"The kernel source is typically kept in what directory?\" \/>\n<p>\nThe <glossary>kernel<\/glossary>\nsource code (normally) is kept in \/usr\/src\/linux. Usually, on a fresh installation, the Linux\ndirectory is a <glossary>symbolic link<\/glossary>\nto a directory whose name is based on the kernel\nrelease number (for example, linux-2.4.14). A README file lists this version number and instructions on how to\nupdate the <glossary>kernel<\/glossary>. The version numbers take the following form:\n<\/p>\n<question id=\"184\" text=\"The version numbers take the what form?\" \/>\n<p>\n<screenoutput>major_release.minor_release.patch_level<\/screenoutput>\n<\/p>\n<p>To find out what release you are on, you can run\n<\/p>\n<p>\n<commandexample command=\"uname\">uname -a<\/commandexample>\n<\/p>\n<p>\n<screenoutput>Linux saturn 2.4.9 #5 Thu Nov 15 19:15:26 CET 2001 i686 unknown<\/screenoutput>\n<\/p>\n<question id=\"185\" text=\"Kernels with an odd numbered minor_release are considered 'development' releases.\" \/>\n<concept id=\"144\" description=\"Kernels with an odd numbered minor_release are considered 'development' releases.\" \/>\n<p>\nHere we have 2.4.14\n<\/p><p>When problems (that is, bugs) are\ndiscovered in either the <glossary>kernel<\/glossary>\nor programs, patches are released. Depending on\nthe extent of the patch, the patch level will change. It is a convention that\nthe even numbered releases 1.2.? are “stable” releases. When patches\nare added to stable releases, they are only bug fixes and contain no new\nfeatures. When a new feature is to be added, this gets an odd numbered version\n1.3.?. These are called development releases. This probably also contains bug\nfixes as well. Often both the stable even number version and the development odd\nnumber version are being worked on (for example, 1.2 and 1.3).\n<\/p>\n<p>\nWhen bug\nfixes are made, they are added to both versions, but only the 1.3 would get new\nfeatures. When it becomes stable enough, the version might be changed to 1.4 and\nthe entire process begins again.\n<\/p>\n<p>\nPatches are available from all the Linux\nftp sites, for example, <i>sunsite.unc.edu<\/i>, as well as many other places.\nThe best idea is to check the newsgroups or one of the Web search engines like\nYahoo (<i>www.yahoo.com<\/i>).\n<\/p>\n<p>\nNormally, patches are compressed tar\narchives. The files within the patch are actually the output of the\ndiff command. The old version of the source is\ncompared to the new version and the differences are written to the patch file.\nThe patch command (which is used to\napply the patches) then compares the source code on your system and makes the\nappropriate changes. Because the patch\ncommand compares lines in a particular location and makes changes, it is\n<i>vital <\/i>that patches be put in the correct order. Otherwise changes might\nbe made where they don’t belong and nothing works anymore.\n<\/p>\n<p>\nBefore applying\na patch, I would suggest making a backup copy of your entire source directory.\nFirst, change to the source directory (<directory>\/usr\/src<\/directory>) and run\n<\/p>\n<p>\n<commandexample command=\"cp\">cp -R linux linux.010997<\/commandexample>\n<\/p>\n<p>\nUse -R for recursive so that all the subdirectories are included. At the end,\ninclude the date, so that you know when the copy was made.\n<\/p>\n<p>\nTo decompress\nand extract the new source directory at the same time, the command would\nbe\n<\/p>\n<p>\n<commandexample command=\"tar\">tar xzf v.1.4.0.tar.gz<\/commandexample>\n<\/p>\n<p>\nLets assume that you have a patch file called patch.42. The command would be\n<\/p>\n<commandexample command=\"gunzip\">gunzip -c patch.42 | patch -p0<\/commandexample>\n<\/p>\n<p>\nwhere the -c option to gunzip tells it to write the output to stdout and the -p0\noption says not to strip of the path names. Often there are multiple\npatches between the release you installed and the current release, so you need\nto get all the patch files.\n<\/p>\n<p>\nSome more clever administrators might think\nabout putting all the patch files into a single directory and running a single\ncommand using wild cards, such as\n<\/p>\n<p>\n<commandexample command=\"patch\">gunzip -c patch.* | patch -p0<\/commandexample>\n<\/p>\n<p>\nThe problem with this is the way the shell expands the wild cards. The <glossary>shell<\/glossary>\ndoesn’t understand the concept of numbers as we do. All it knows is <glossary>ASCII<\/glossary>,\nso patch.* would expand to something like this:<\/p>\n<p>\npatch1<br \/>\npatch10<br \/>\npatch11<br \/>\npatch2<br \/>\n<\/p>\n<p>\nIf you were to do this, you’d put the patches in the wrong order!\n<\/p>\n<p>\nEven if you are going to apply only one patch, you need to be\ncareful what version you have and what patch you are applying. You may find the\nscript patch-kernel in the\n<directory>\/usr\/src\/linux\/tools<\/directory> directory, which will allow you\nto put on multiple patches and will figure out what order in which they should\nbe applied.\n<\/p>\n<p>\nAlso keep in mind that the development <glossary>kernel<\/glossary>\n(those with odd\nnumbered minor releases) are in development (that is, experimental). Just\nbecause a driver is included in the development <glossary>kernel<\/glossary>\ndoes not mean it will\nwork with all devices. Speaking from experience, I know the problems this will\ncause. Several versions of Linux that I installed were still in a 1.2 <glossary>kernel<\/glossary>.\nHowever, the driver for my <glossary>host<\/glossary>\nadapted (AHA-2940 was not included). On the\nCD-ROM was a copy of a 1.3 <glossary>kernel<\/glossary>\nthat contained the driver. I created a floppy\nusing the driver and all was well, I thought.\n<\/p>\n<p>\nI was able to install the\nentire system and get everything configured, and things looked good. Then my\nSCSI tape drive arrived and I added it to the system. Well, the <glossary>host<\/glossary>\nadapter\ndriver recognized the tape drive correctly, but immediately after printing the\nmessage with the tape drive model, the system stopped. The message on the screen\nsaid a <glossary>SCSI<\/glossary>\ncommand had timed out.\n<\/p>\n<p>\nThe <glossary>kernel<\/glossary>\nthat was booting was the\none from the installation floppy and, therefore, the 1.3 <glossary>kernel<\/glossary>.\n However, the source on the hard disk was for the 1.2 kernel.\n I added the patch, rebuilt the\nkernel, and rebooted. It was smooth sailing from then on. (Note that the 2.0\nkernel already included the changes. This was an attempt to see what worked and\nnot just to get the system working.)<\/p>\n<p>\nIn the <glossary>kernel<\/glossary> source directory <directory>\/usr\/src\/linux<\/directory> is a standard make file. Running\nmake config will ask you a series of questions about\nwhat drivers to include in your <glossary>kernel<\/glossary>.\n These are yes\/no questions that are\npretty straightforward, provided you know about your system.\n<\/p>\n<question id=\"186\" text=\"What command provides a graphical tool to configure your kernel?\" \/>\n<p>\nIf you are\nnew to Linux, you should consider running make\nmenuconfig instead. This is a menu interface to the\nconfiguration routines that even has extensive on-line help. If you are running\nX, you should look at running<\/p>\n<commandexample command=\"make\">make xconfig<\/commandexample>\n<\/p>\nwhich will bring you a full <glossary>GUI<\/glossary> front-end. The commercial vendors can\nlearn something from this\nbaby!\n<\/p>\n<p>\nThe defaults that the systems provide are fine for normal\noperations, but you need to know how your system is configured. (Now are you\nbeginning to understand why we got to this so far into the book?) In a lot of\ncases, the responses you give to questions will add functionality, while others simply change\nparameters.\n<\/p>\n<p>\nI can’t go step-by-step through the rebuild process without\nexplaining how make files work, but\nthere are a few key points that I need to address.\n First, there are major\nchanges between 1.2 and 2.0. A large number of drivers have been added and the\noverall flow is different. In several cases, you were prompted to configure one\nspecific aspect but now are able to be more specific in what you\ndefine.\n<\/p>\n<p>\nIn <directory>\/usr\/src\/linux<\/directory>, there\nis a new subdirectory: documentation.\nThis contains, as you might expect, documentation for the <glossary>kernel<\/glossary>\nsource. Before\nyou reconfigure your <glossary>kernel<\/glossary>,\n I would suggest taking a look at this <glossary>subdirectory<\/glossary>.\nIt has some very good information on what options to select depending on the\nhardware you have.\n<\/p>\n<p>\nWhen you rebuild, what is actually run is a script in\nthe arch\/<type> <glossary>subdirectory<\/glossary>,\nwhere <type> is the type of\narchitecture you have. If you run it on an Intel machine, then the script that\nis run is <file type=\"\">\/usr\/src\/linux\/arch\/i386\/config.in<\/file>.\nThis is the script that prompts your for all of the configuration\noptions. After each question, you will see a cryptic name. This is the variable\nthat will be defined (or undefined, depending on your answer).\n<\/p>\n<p>\nBased on\nyour input, variables are set to particular values. These appear as\n#define statements and are written to a temporary\nfile as the configuration script is being run. If something stops the\nconfiguration process (such as you pressing the <glossary>interrupt<\/glossary>\nkey or you inputting\nan unacceptable value), this temporary file can be ignored. Once the\nconfiguration is complete, the temporary file is used as the new version of\n<<file type=\"\">linux\/autoconf.h<\/file>>. If you look in\nthe autoconf.h file, you’ll see all of\nthose cryptic variables names that you encountered when you ran the configure\nscript.\n<\/p>\n<p>\nIf we have a Boolean <glossary>variable<\/glossary>\n(one that is either defined or\nundefined), then you’ll have the applicable definition in the\nautoconf.h file. For example, on my machine, I\nanswered yes to configuring normal floppy support, so the line in\nautoconf.h looks like this:<\/p>\n<p>\n<screenoutput>#define CONFIG_BLK_DEV_FD 1<\/screenoutput>\n<\/p>\n<p>\nHere we have defined the constant CONFIG_BLK_DEV_FD\nto 1. Certain parts of the <glossary>kernel<\/glossary>\nsource code or the\nmake file will test for this value and include\ncertain modules or otherwise change its behavior based on how the constant is\ndefined.\n<\/p>\n<p>\nLets look at an example. Because all I have is a <glossary>SCSI<\/glossary>\nhard disk,\nthere was no need to include support for <glossary>IDE<\/glossary>\nhard disks, so it must be\nundefined. The entry looks like this:<\/p>\n<p>\n<screenoutput>#undef CONFIG_ST506<\/screenoutput>\n<\/p>\n<p>\nIf you want to add support for a\nparticular device without having to go through the configuration script each\ntime, all you need to do is edit the autoconf.h\n file.\n<\/p>\n<p>\nNext, gather the dependencies for the sources and include\nthem in the various make files used\nduring the <glossary>kernel<\/glossary>\nrebuild. This is done with make\ndep.\n<\/p>\n<p>\nIf you have done a <glossary>kernel<\/glossary>\nrebuild before, there\nmay be a lot of files left lying around, so it’s a good idea to run\nmake clean. Finally, run make\nwith no options to start the <glossary>kernel<\/glossary>\nrebuilt.\n<\/p>\n<p>\nOne\nadvantage that Linux has over other OSes is that it is completely\ncomponent-based and is not distributed as a complete, non-divisible unit. This\nallows you to update\/upgrade those components that have changed and leave the\nrest intact. This has been made very simple through the Red Hat Package Manager\n(RPM). (See the chapter on installing for more details.)<\/p>\n<p>\nUnfortunately, this process\nis not always “plug-n-play”: Often, differences between the <glossary>kernel<\/glossary>\nand\nprograms (or between different programs) can cause problems. For example, when\nthe <glossary>kernel<\/glossary>\nwas updated to 2.0, I simply tossed the source code onto a system\nthat had the 1.2 <glossary>kernel<\/glossary>,\n rebuilt the kernel, and rebooted. All looked well.\nHowever, on shutting down the system, I encountered a stream of errors that\noccur <i>only<\/i> with the 2.0 <glossary>kernel<\/glossary>.\n However, installing the distribution with\nthe 2.0 <glossary>kernel<\/glossary>\nin its entirely did not cause this problem.\n<\/p>\n<p>\nA fairly new\nconcept is the idea of a loadable module. These are parts of the <glossary>kernel<\/glossary>\nthat are\nnot linked directly to the <glossary>kernel<\/glossary>\nbut are pulled in when you need them. For\nexample, you only use your tape drive when you do backups, so whats the point of\nhaving it in your <glossary>kernel<\/glossary>\nall the time? If you load it only when you need it, you\nsave memory for other tasks.\n<\/p>\n<p>\nTo be able to use <glossary>kernel<\/glossary>\nmodules like these,\nyour <glossary>kernel<\/glossary>\nmust support it. When you run make\nconfig, you are asked this question, among others. Modules\ncan be loaded into the <glossary>kernel<\/glossary>\nby hand, using the insmod\ncommand, or automatically, using the <glossary>kerneld<\/glossary>\n<glossary>daemon<\/glossary>.\n See the <glossary>kernel<\/glossary>\n<glossary>HOWTO<\/glossary>\nor the kernel mini-HOWTO for more specifics.\n<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Rebuilding Your Kernel Rebuilding your kernel is the process by which you compile all the components of your source code to create a kernel from which you can then install and boot. A rebuild is important (actually, necessary) when you … <a href=\"http:\/\/www.linux-tutorial.info\/?page_id=250\">Continue reading <span class=\"meta-nav\">→<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"parent":0,"menu_order":0,"comment_status":"closed","ping_status":"closed","template":"","meta":{"footnotes":""},"class_list":["post-250","page","type-page","status-publish","hentry"],"_links":{"self":[{"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=\/wp\/v2\/pages\/250","targetHints":{"allow":["GET"]}}],"collection":[{"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=\/wp\/v2\/pages"}],"about":[{"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=\/wp\/v2\/types\/page"}],"author":[{"embeddable":true,"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=250"}],"version-history":[{"count":1,"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=\/wp\/v2\/pages\/250\/revisions"}],"predecessor-version":[{"id":677,"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=\/wp\/v2\/pages\/250\/revisions\/677"}],"wp:attachment":[{"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=250"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}