{"id":345,"date":"2008-03-11T19:18:00","date_gmt":"2008-03-12T02:18:00","guid":{"rendered":"https:\/\/kb.terabyteunlimited.com\/kb-articles\/working-with-kernel-modules-on-the-ifl-network-boot-disk\/"},"modified":"2021-09-06T23:09:30","modified_gmt":"2021-09-07T06:09:30","slug":"working-with-kernel-modules-on-the-ifl-network-boot-disk","status":"publish","type":"lsvr_kba","link":"https:\/\/www.terabyteunlimited.com\/kb\/kb-articles\/working-with-kernel-modules-on-the-ifl-network-boot-disk\/","title":{"rendered":"Working with kernel modules on the IFL Network Boot Disk"},"content":{"rendered":"<p>\r\n<strong>Please note: <\/strong>This article applies to version 1 product(s) only.<\/p>\r\nThis article covers the subject of kernel modules, and some commands\r\nthat can be used to work with them while using the IFL Network Boot\r\nDisk. It also describes how module loading can modified (if necessary)\r\nby creating a customized version the disk. <br \/><br \/>While\r\nit should not normally be necessary to deal with this information, it\r\ncan be useful in determining if\/why certain hardware is not being\r\ndetected. In some cases, it may also be possible to correct a\r\nmodule-related issue by modifying the IFL disk. Note that this article\r\ndoes <strong>not <\/strong>apply to the standard IFL Boot Disk, since it does not use kernel modules.<br \/><br \/><font size=\"3\"><strong>Background information:<\/strong><\/font><br \/>Most\r\nkernel modules are either drivers to support specific hardware, or code\r\nthat enables certain features and capabilities, such as support for\r\nspecific file systems, networking features etc. Modules are actually\r\npart of the kernel, but are compiled as separate files so that they can\r\nbe loaded into memory if needed, but left unloaded if not. <br \/><br \/>On\r\na Linux system, the kernel module files will reside in a series of\r\nsub-directories under the \/lib\/modules\/&lt;kernel-version&gt;\r\ndirectory. As a more specific example, all drivers for network adapters\r\non the IFL Network Boot Disk are located in the\r\n\/lib\/modules\/2.6.17.13-IFLnet\/kernel\/drivers\/net directory.<br \/><br \/>Typically,\r\nmodules required for hardware support are loaded as the hardware is\r\ndetected while the system boots. Other modules may be loaded as needed\r\nwhile the system runs. For the most part, all required modules will\r\nload automatically, and no user action is required. Most issues with\r\nkernel modules will arise in the context of a specific hardware item\r\nnot working as expected (network card, mass storage controller etc.).\r\nTwo commands that can be helpful in troubleshooting modules are <strong>lsmod<\/strong> and <strong>modprobe.<\/strong><strong><br \/><br \/><font size=\"3\">The lsmod command (list loaded modules):<\/font><\/strong><br \/>The\r\nlsmod command will simply list all loaded modules. It has no options,\r\nbut it is helpful to know that modules are always listed in the reverse\r\norder in which they were loaded. The following is an example output\r\nfrom lsmod:<pre>Module                  Size  Used by    Not tainted<br \/>nls_cp437               5376  0 <br \/>shpchp                 35480  0 <br \/>pci_hotplug            25652  1 shpchp<br \/>piix                    8964  0 [permanent]generic                 3972  0 [permanent]pcnet32                27652  0 <br \/>mii                     4864  1 pcnet32<br \/>pcspkr                  2176  0 <\/pre>In\r\nthis case, pcspkr was the first module loaded, and nls_cp437 was the\r\nlast. The &quot;Used by&quot; column shows how many other modules are using\r\n(depend on) each listed module, followed by the names of those modules.\r\nFor example, it can be seen above that the pcnet32 module depends on\r\nthe mii module, and therefore the mii module gets loaded first. Module\r\ndependencies are defined in the file\r\n\/lib\/modules\/2.6.17.13-IFLnet\/modules.dep, which is used by the\r\nmodprobe command when loading modules.<br \/><br \/><font size=\"3\"><strong>The modprobe command (load or unload modules):<\/strong><\/font><br \/>Modprobe has several command line options, but the most frequently used ones are the following:<br \/><br \/>Load a module:<br \/>modprobe&nbsp; &lt;module name&gt; <br \/><br \/>Unload a module:<br \/>modprobe&nbsp; -r&nbsp; &lt;module name&gt; <br \/><br \/>Show dependencies for a module:<br \/>modprobe&nbsp; --show-depends&nbsp; &lt;module name&gt;<br \/><br \/>As an example, the pcskpr module shown in the list above can be removed with the command <strong>'modprobe -r pcspkr'<\/strong>, and then reloaded with the command <strong>'modprobe&nbsp; pcspkr'<\/strong>.&nbsp;\r\nStarting with the list of modules shown above, this will result in the\r\nlsmod output shown below.&nbsp; Note that pcspkr is listed first because it\r\nis now the last module that was loaded:<br \/><pre>Module                  Size  Used by    Not tainted<br \/>pcspkr                  2176  0 <br \/>nls_cp437               5376  0 <br \/>shpchp                 35480  0 <br \/>pci_hotplug            25652  1 shpchp<br \/>piix                    8964  0 [permanent]generic                 3972  0 [permanent]pcnet32                27652  0 <br \/>mii                     4864  1 pcnet32<br \/><br \/><\/pre><p>Some\r\nmodules depend on other modules being loaded before they can be loaded\r\nthemselves. An example of that can be seen in the list above where the\r\npcnet32 module depends on the mii module. The modprobe command will\r\nautomatically determine a module's dependencies, and will load those\r\nmodules if they are not already loaded. In the example above, if\r\nneither pcnet32 or mii were loaded, the command 'modprobe pcnet32'\r\nwould first load mii, and then pcnet32. A module's dependencies can be\r\nlisted with modprobe's <strong>--show-depends<\/strong> option.&nbsp;  <br \/><\/p><p>Example: The command <strong>'modprobe --show-depends pcnet32'<\/strong> will result in the following output:<br \/><\/p><pre>insmod \/lib\/modules\/2.6.17.13-IFLnet\/kernel\/drivers\/net\/mii.ko <br \/>insmod \/lib\/modules\/2.6.17.13-IFLnet\/kernel\/drivers\/net\/pcnet32.ko <\/pre><strong><br \/><font size=\"3\">Creating a customized ISO file with modified module loading:<\/font><br \/><\/strong>The\r\nIFL Network Boot Disk can be customized in a number of ways. In\r\ngeneral, this involves the steps of uncommenting and editing one or\r\nmore options in the file <strong>config.txt<\/strong>, and then building a customized ISO file by running the <strong>makeISO<\/strong> script.&nbsp; A customized ISO file can <strong>only<\/strong> be created from Linux.<br \/><p>The\r\ncomplete procedure to do this is outlined below, followed by an\r\nexplanation of the MODULES option (which is the option in config.txt\r\nthat controls module loading):<\/p><p>1. Unzip the IFL Network Boot Disk\r\narchive. It is highly recommended that this be done on a Linux file\r\nsystem (such as ext2\/3 or reiserfs) to avoid potential issues with\r\nupper\/lower case and file permissions.&nbsp; <br \/> <br \/> 2. Unzip the\r\nconfig.zip file included in the archive. The files in config.zip should\r\nbe extracted in the same directory as the rest of the archive (not in a\r\nsub-directory).<br \/> <br \/> 3. Uncomment and edit the MODULES option in config.txt as described below. This can be accomplished with any text editor.<br \/> <br \/> 4. Run the makeISO script. Doing this will create the file <strong>iflnet-custom.iso<\/strong>,\r\nwhich can then be burned to CD\/DVD. From the archive directory, the\r\nmakeISO script can be executed with the command '.\/makeISO'<br \/> <br \/> <\/p><p>The\r\nspecific case of module loading is controlled by the MODULES option in\r\nconfig.txt. By uncommenting and editing this option line, you can\r\nmodify module load behavior in the following ways:<\/p><p>1. To ensure that one or more modules <strong>will<\/strong>\r\nbe loaded, list them inside the parenthesis, with a space between them\r\n(if more than one). Note that modules loaded in this manner will always\r\nbe loaded <strong>before <\/strong>any other modules are loaded automatically by\r\nthe normal boot process. As an example, the following will ensure that\r\nmodule1 and module2 will be loaded (and will be loaded in that order):<\/p><p>MODULES=(module1 module2)<\/p><p>2. To ensure that one or more modules will <strong>not<\/strong>\r\nbe loaded, list them inside the parenthesis with a &quot;!&quot; in front of\r\nthem.&nbsp; As an example, the following will ensure that module1 will be\r\nnot be loaded:<\/p><p>MODULES=(!module1)<\/p><p>3. To ensure that modules are loaded in a <strong>specified order, <\/strong>list them in that order inside of the parenthesis. In the following example, the load order will be module1, module2, module3:<br \/><\/p>MODULES=(module1 module2 module3)<br \/><br \/>Ensuring\r\nmodules will be loaded, preventing modules from loading, and specifying\r\na module load order can all be combined in one MODULES line (only one\r\nwill MODULES line will be recognized).&nbsp; As an example, the following\r\nline will load module1 and module3 in that order, and will prevent\r\nmodule2 from loading.<br \/> <br \/>MODULES=(module1 !module2 module3)<br \/><br \/><strong><font size=\"3\">Additional information:<\/font><br \/><\/strong>Since\r\nmodule issues can involve storage devices such as hard drives, the\r\nfollowing information is provided as a brief reference for those not\r\nfamiliar with how to view and interpret hard drive and partition\r\ninformation in Linux.<br \/><br \/>All hard drives in Linux will appear as\r\neither hdx devices (such as hda, hdb), or sdx devices (such as sda,\r\nsdb). The hdx devices are drives connected to an IDE controller. All\r\nother hard drives will be sdx devices. This includes SATA drives, SCSI\r\ndrives, USB drives, and IEEE 1394 drives (FireWire).&nbsp; <br \/><br \/>Each\r\npartition on a hard drive will be designated by adding a number to the\r\nend of the hard drive designation. For example, hda1 is the first\r\npartition on hard drive hda, hda2 is the 2nd partition, and so on. The\r\n4 possible primary partitions on a drive will always be numbered 1\r\nthrough 4 (hda1, hda2, hda3, hda4), while logical volumes in an\r\nextended partition will always be numbered starting at 5 (hda5, hda6\r\n...), regardless of how many primary partitions are on the drive.<br \/><br \/>The following commands can be used to list drives and partitions in Linux:<br \/><br \/>List all partitions on all drives:<br \/>fdisk&nbsp; -l&nbsp; <br \/><br \/>List all partitions on just hda:<br \/>fdisk&nbsp; -l&nbsp; \/dev\/hda<br \/><br \/>The following is an example output of the command 'fdisk -l \/dev\/sdb':<br \/><br \/>Disk \/dev\/sdb: 203.9 GB, 203928109056 bytes<br \/>255 heads, 63 sectors\/track, 24792 cylinders<br \/>Units = cylinders of 16065 * 512 = 8225280 bytes<br \/><br \/><table cellspacing=\"1\" cellpadding=\"2\" border=\"0\"><tbody><tr><td>&nbsp;Device Boot<\/td><td>&nbsp;Start <br \/><\/td><td>&nbsp;End <br \/><\/td><td>&nbsp;Blocks<\/td><td>Id <br \/><\/td><td>System <br \/><\/td><\/tr><tr><td>&nbsp;\/dev\/sdb1<\/td><td>&nbsp;16156<\/td><td>&nbsp;17174 <br \/><\/td><td>&nbsp;8185117+<\/td><td>&nbsp;83<\/td><td>&nbsp;Linux<\/td><\/tr><tr><td>&nbsp;\/dev\/sdb2 <br \/><\/td><td>&nbsp;1306&nbsp; <br \/><\/td><td>&nbsp;2610<\/td><td>&nbsp;10482412+<\/td><td>&nbsp;83<\/td><td>&nbsp;Linux<\/td><\/tr><tr><td>&nbsp;\/dev\/sdb3&nbsp; <br \/><\/td><td>&nbsp;2611<\/td><td>&nbsp;6690<\/td><td>&nbsp;32772600<\/td><td>&nbsp;c<\/td><td>&nbsp;W95 FAT32 (LBA)<\/td><\/tr><tr><td>&nbsp;\/dev\/sdb4 <br \/><\/td><td>&nbsp;6691<\/td><td>&nbsp;10770<\/td><td>&nbsp;32772600<\/td><td>&nbsp;c<\/td><td>&nbsp;W95 FAT32 (LBA)<\/td><\/tr><\/tbody><\/table><br \/>&nbsp;","protected":false},"excerpt":{"rendered":"<p>Please note: This article applies to version 1 product(s) only. This article covers the subject of kernel modules, and some commands that can be used to work with them while using the IFL Network Boot Disk. It also describes how module loading can modified (if necessary) by creating a customized version the disk. While it [&hellip;]<\/p>\n","protected":false},"author":5,"featured_media":0,"comment_status":"closed","ping_status":"closed","template":"","meta":{"footnotes":""},"lsvr_kba_cat":[1818],"lsvr_kba_tag":[2118],"class_list":["post-345","lsvr_kba","type-lsvr_kba","status-publish","hentry","lsvr_kba_cat-ifd-ifl-ifw-version-1-archive","lsvr_kba_tag-archived"],"_links":{"self":[{"href":"https:\/\/www.terabyteunlimited.com\/kb\/wp-json\/wp\/v2\/lsvr_kba\/345","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.terabyteunlimited.com\/kb\/wp-json\/wp\/v2\/lsvr_kba"}],"about":[{"href":"https:\/\/www.terabyteunlimited.com\/kb\/wp-json\/wp\/v2\/types\/lsvr_kba"}],"author":[{"embeddable":true,"href":"https:\/\/www.terabyteunlimited.com\/kb\/wp-json\/wp\/v2\/users\/5"}],"replies":[{"embeddable":true,"href":"https:\/\/www.terabyteunlimited.com\/kb\/wp-json\/wp\/v2\/comments?post=345"}],"version-history":[{"count":1,"href":"https:\/\/www.terabyteunlimited.com\/kb\/wp-json\/wp\/v2\/lsvr_kba\/345\/revisions"}],"predecessor-version":[{"id":5960,"href":"https:\/\/www.terabyteunlimited.com\/kb\/wp-json\/wp\/v2\/lsvr_kba\/345\/revisions\/5960"}],"wp:attachment":[{"href":"https:\/\/www.terabyteunlimited.com\/kb\/wp-json\/wp\/v2\/media?parent=345"}],"wp:term":[{"taxonomy":"lsvr_kba_cat","embeddable":true,"href":"https:\/\/www.terabyteunlimited.com\/kb\/wp-json\/wp\/v2\/lsvr_kba_cat?post=345"},{"taxonomy":"lsvr_kba_tag","embeddable":true,"href":"https:\/\/www.terabyteunlimited.com\/kb\/wp-json\/wp\/v2\/lsvr_kba_tag?post=345"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}