| Deployment GuidePart VII. Kernel, Module and Driver ConfigurationThis part covers various tools that assist administrators with kernel customization. Chapter 24. Manually Upgrading the KernelThe Red Hat Enterprise Linux kernel is custom-built by the Red Hat Enterprise Linux kernel team to ensure its integrity and compatibility with supported hardware. Before Red Hat releases a kernel, it must first pass a rigorous set of quality assurance tests. Red Hat Enterprise Linux kernels are packaged in the RPM format so that they are easy to upgrade and verify using the Yum or PackageKit package managers. PackageKit automatically queries the Red Hat Network servers and informs you of packages with available updates, including kernel packages. This chapter is therefore only useful for users who need to manually update a kernel package using the rpm command instead of yum. Whenever possible, use either the Yum or PackageKit package manager to install a new kernel because they always install a new kernel instead of replacing the current one, which could potentially leave your system unable to boot. Building a custom kernel is not supported by the Red Hat Global Services Support team, and therefore is not explored in this manual. 24.1. Overview of Kernel PackagesRed Hat Enterprise Linux contains the following kernel packages: kernel - Contains the kernel for single, multicore and multiprocessor systems. kernel-debug - Contains a kernel with numerous debugging options enabled for kernel diagnosis, at the expense of reduced performance. kernel-devel - Contains the kernel headers and makefiles sufficient to build modules against the kernel package. kernel-debug-devel - Contains the development version of the kernel with numerous debugging options enabled for kernel diagnosis, at the expense of reduced performance. kernel-doc - Documentation files from the kernel source. Various portions of the Linux kernel and the device drivers shipped with it are documented in these files. Installation of this package provides a reference to the options that can be passed to Linux kernel modules at load time. By default, these files are placed in the /usr/share/doc/kernel-doc-<kernel_version>/ directory. kernel-headers - Includes the C header files that specify the interface between the Linux kernel and user-space libraries and programs. The header files define structures and constants that are needed for building most standard programs. kernel-firmware - Contains all of the firmware files that are required by various devices to operate. perf - This package contains supporting scripts and documentation for the perf tool shipped in each kernel image subpackage.
24.2. Preparing to UpgradeBefore upgrading the kernel, it is recommended that you take some precautionary steps. First, ensure that working boot media exists for the system. If the boot loader is not configured properly to boot the new kernel, you can use this media to boot into Red Hat Enterprise Linux. USB media often comes in the form of flash devices sometimes called pen drives, thumb disks, or keys, or as an externally-connected hard disk device. Almost all media of this type is formatted as a VFAT file system. You can create bootable USB media on media formatted as ext2, ext3, or VFAT. You can transfer a distribution image file or a minimal boot media image file to USB media. Make sure that sufficient free space is available on the device. Around 4 GB is required for a distribution DVD image, around 700 MB for a distribution CD image, or around 10 MB for a minimal boot media image. You must have a copy of the boot.iso file from a Red Hat Enterprise Linux installation DVD, or installation CD-ROM #1, and you need a USB storage device formatted with the VFAT file system and around 16 MB of free space. The following procedure will not affect existing files on the USB storage device unless they have the same path names as the files that you copy onto it. To create USB boot media, perform the following commands as the root user: Install the SYSLINUX bootloader on the USB storage device: ~]# syslinux /dev/sdX1 ...where sdX is the device name. Create mount points for boot.iso and the USB storage device: ~]# mkdir /mnt/isoboot /mnt/diskboot Mount boot.iso: ~]# mount -o loop boot.iso /mnt/isoboot Mount the USB storage device: ~]# mount /dev/<sdX1> /mnt/diskboot Copy the ISOLINUX files from the boot.iso to the USB storage device: ~]# cp /mnt/isoboot/isolinux/* /mnt/diskboot Use the isolinux.cfg file from boot.iso as the syslinux.cfg file for the USB device: ~]# grep -v local /mnt/isoboot/isolinux/isolinux.cfg > /mnt/diskboot/syslinux.cfg Unmount boot.iso and the USB storage device: ~]# umount /mnt/isoboot /mnt/diskboot You should reboot the machine with the boot media and verify that you are able to boot with it before continuing.
Alternatively, on systems with a floppy drive, you can create a boot diskette by installing the mkbootdisk package and running the mkbootdisk command as root. Refer to man mkbootdisk man page after installing the package for usage information. To determine which kernel packages are installed, execute the command yum list installed "kernel-*" at a shell prompt. The output will comprise some or all of the following packages, depending on the system's architecture, and the version numbers may differ: ~]# yum list installed "kernel-*"kernel.x86_64 2.6.32-17.el6 @rhel-x86_64-server-6kernel-doc.noarch 2.6.32-17.el6 @rhel-x86_64-server-6kernel-firmware.noarch 2.6.32-17.el6 @rhel-x86_64-server-6kernel-headers.x86_64 2.6.32-17.el6 @rhel-x86_64-server-6 From the output, determine which packages need to be downloaded for the kernel upgrade. For a single processor system, the only required package is the kernel package. Refer to Section 24.1, "Overview of Kernel Packages" for descriptions of the different packages. 24.3. Downloading the Upgraded KernelThere are several ways to determine if an updated kernel is available for the system. Via Red Hat Network - Download and install the kernel RPM packages. Red Hat Network can download the latest kernel, upgrade the kernel on the system, create an initial RAM disk image if needed, and configure the boot loader to boot the new kernel. For more information, refer to http://www.redhat.com/docs/manuals/RHNetwork/. 24.4. Performing the UpgradeAfter retrieving all of the necessary packages, it is time to upgrade the existing kernel. It is strongly recommended that you keep the old kernel in case there are problems with the new kernel. At a shell prompt, change to the directory that contains the kernel RPM packages. Use -i argument with the rpm command to keep the old kernel. Do not use the -U option, since it overwrites the currently installed kernel, which creates boot loader problems. For example: ~]# rpm -ivh kernel-<kernel_version>.<arch>.rpm 24.5. Verifying the Initial RAM Disk ImageThe job of the initial RAM disk image is to preload the block device modules, such as for IDE, SCSI or RAID, so that the root file system, on which those modules normally reside, can then be accessed and mounted. On Red Hat Enterprise Linux 6 systems, whenever a new kernel is installed using either the Yum, PackageKit, or RPM package manager, the Dracut utility is always called by the installation scripts to create an initramfs (initial RAM disk image). You can verify that an initramfs corresponding to your current kernel version exists and is specified correctly in the grub.conf configuration file by following this procedure: Procedure 24.1. Verifying the Initial RAM Disk Image As root, list the contents in the /boot/ directory and find the kernel (vmlinuz-<kernel_version>) and initramfs-<kernel_version> with the latest (most recent) version number: Example 24.1. Ensuring that the kernel and initramfs versions match ~]# ls /boot/config-2.6.32-17.el6.x86_64 lost+foundconfig-2.6.32-19.el6.x86_64 symvers-2.6.32-17.el6.x86_64.gzconfig-2.6.32-22.el6.x86_64 symvers-2.6.32-19.el6.x86_64.gzefi symvers-2.6.32-22.el6.x86_64.gzgrub System.map-2.6.32-17.el6.x86_64initramfs-2.6.32-17.el6.x86_64.img System.map-2.6.32-19.el6.x86_64initramfs-2.6.32-19.el6.x86_64.img System.map-2.6.32-22.el6.x86_64initramfs-2.6.32-22.el6.x86_64.img vmlinuz-2.6.32-17.el6.x86_64initrd-2.6.32-17.el6.x86_64kdump.img vmlinuz-2.6.32-19.el6.x86_64initrd-2.6.32-19.el6.x86_64kdump.img vmlinuz-2.6.32-22.el6.x86_64initrd-2.6.32-22.el6.x86_64kdump.img
we have three kernels installed (or, more correctly, three kernel files are present in /boot/), the latest kernel is vmlinuz-2.6.32-22.el6.x86_64, and an initramfs file matching our kernel version, initramfs-2.6.32-22.el6.x86_64kdump.img, also exists.
In the /boot/ directory you may find several initrd-<version>kdump.img files. These are special files created by the Kdump mechanism for kernel debugging purposes, are not used to boot the system, and can safely be ignored. (Optional) If your initramfs-<kernel_version> file does not match the version of the latest kernel in /boot/, or, in certain other situations, you may need to generate an initramfs file with the Dracut utility. Simply invoking dracut as root without options causes it to generate an initramfs file in the /boot/ directory for the latest kernel present in that directory: ~]# dracut You must use the --force option if you want dracut to overwrite an existing initramfs (for example, if your initramfs has become corrupt). Otherwise dracut will refuse to overwrite the existing initramfs file: ~]# dracutWill not override existing initramfs (/boot/initramfs-2.6.32-22.el6.x86_64.img) without --force You can create an initramfs in the current directory by calling dracut <initramfs_name> <kernel_version>: ~]# dracut "initramfs-$(uname -r).img" $(uname -r) If you need to specify specific kernel modules to be preloaded, add the names of those modules (minus any file name suffixes such as .ko) inside the parentheses of the add_dracutmodules="<module> [<more_modules>]" directive of the /etc/dracut.conf configuration file. You can list the file contents of an initramfs image file created by dracut by using the lsinitrd <initramfs_file> command: ~]# lsinitrd initramfs-2.6.32-22.el6.x86_64.imginitramfs-2.6.32-22.el6.x86_64.img:========================================================================dracut-004-17.el6========================================================================drwxr-xr-x 23 root root 0 May 3 22:34 .drwxr-xr-x 2 root root 0 May 3 22:33 proc-rwxr-xr-x 1 root root 7575 Mar 25 19:53 initdrwxr-xr-x 7 root root 0 May 3 22:34 etcdrwxr-xr-x 2 root root 0 May 3 22:34 etc/modprobe.d[output truncated] Refer to man dracut and man dracut.conf for more information on options and usage. Examine the grub.conf configuration file in the /boot/grub/ directory to ensure that an initrd initramfs-<kernel_version>.img exists for the kernel version you are booting. Refer to Section 24.6, "Verifying the Boot Loader" for more information.
Verifying the Initial RAM Disk Image and Kernel on IBM eServer System iOn IBM eServer System i machines, the initial RAM disk and kernel files are combined into a single file, which is created with the addRamDisk command. This step is performed automatically if the kernel and its associated packages are installed or upgraded from the RPM packages distributed by Red Hat; thus, it does not need to be executed manually. To verify that it was created, use the command ls -l /boot/ to make sure the /boot/vmlinitrd-<kernel_version> file already exists (the <kernel_version> 24.6. Verifying the Boot LoaderWhen you install a kernel using rpm, the kernel package creates an entry in the boot loader configuration file for that new kernel. However, rpm does not configure the new kernel to boot as the default kernel. You must do this manually when installing a new kernel with rpm. It is always recommended to double-check the boot loader configuration file after installing a new kernel with rpm to ensure that the configuration is correct. Otherwise, the system may not be able to boot into Red Hat Enterprise Linux properly. If this happens, boot the system with the boot media created earlier and re-configure the boot loader. In the following table, find your system's architecture to determine the boot loader it uses, and then click on the "Refer to" link to jump to the correct instructions for your system. Table 24.1. Boot loaders by architecture 24.6.1. Configuring the GRUB Boot LoaderGRUB's configuration file, /boot/grub/grub.conf, contains a few lines with directives, such as default, timeout, splashimage and hiddenmenu (the last directive has no argument). The remainder of the file contains 4-line stanzas that each refer to an installed kernel. These stanzas always start with a title entry, after which the associated root, kernel and initrd directives should always be indented. Ensure that each stanza starts with a title that contains a version number (in parentheses) that matches the version number in the kernel /vmlinuz-<version_number> line of the same stanza. Example 24.2. /boot/grub/grub.conf # grub.conf generated by anaconda[comments omitted]default=1timeout=0splashimage=(hd0,0)/grub/splash.xpm.gzhiddenmenutitle Red Hat Enterprise Linux (2.6.32-22.el6.x86_64) root (hd0,0) kernel /vmlinuz-2.6.32-22.el6.x86_64 ro root=/dev/mapper/vg_vm6b-lv_root rd_LVM_LV=vg_vm6b/lv_root rd_NO_LUKS rd_NO_MD rd_NO_DM LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYBOARDTYPE=pc KEYTABLE=us rhgb quiet crashkernel=auto initrd /initramfs-2.6.32-22.el6.x86_64.imgtitle Red Hat Enterprise Linux (2.6.32-19.el6.x86_64) root (hd0,0) kernel /vmlinuz-2.6.32-19.el6.x86_64 ro root=/dev/mapper/vg_vm6b-lv_root rd_LVM_LV=vg_vm6b/lv_root rd_NO_LUKS rd_NO_MD rd_NO_DM LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYBOARDTYPE=pc KEYTABLE=us rhgb quiet crashkernel=auto initrd /initramfs-2.6.32-19.el6.x86_64.imgtitle Red Hat Enterprise Linux 6 (2.6.32-17.el6.x86_64) root (hd0,0) kernel /vmlinuz-2.6.32-17.el6.x86_64 ro root=/dev/mapper/vg_vm6b-lv_root rd_LVM_LV=vg_vm6b/lv_root rd_NO_LUKS rd_NO_MD rd_NO_DM LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYBOARDTYPE=pc KEYTABLE=us rhgb quiet initrd /initramfs-2.6.32-17.el6.x86_64.img If a separate /boot/ partition was created, the paths to the kernel and the initramfs image are relative to /boot/. This is the case in Example 24.2, "/boot/grub/grub.conf", above. Therefore the initrd /initramfs-2.6.32-22.el6.x86_64.img line in the first kernel stanza means that the initramfs image is actually located at /boot/initramfs-2.6.32-22.el6.x86_64.img when the root file system is mounted, and likewise for the kernel path (for example: kernel /vmlinuz-2.6.32-22.el6.x86_64) in each stanza of grub.conf. In kernel boot stanzas in grub.conf, the initrd directive must point to the location (relative to the /boot/ directory if it is on a separate partition) of the initramfs file corresponding to the same kernel version. This directive is called initrd because the previous tool which created initial RAM disk images, mkinitrd, created what were known as initrd files. Thus the grub.conf directive remains initrd to maintain compatibility with other tools. The file-naming convention of systems using the dracut utility to create the initial RAM disk image is: initramfs-<kernel_version>.img You should ensure that the kernel version number as given on the kernel /vmlinuz-<kernel_version> line matches the version number of the initramfs image given on the initrd /initramfs-<kernel_version>.img line of each stanza. Refer to Procedure 24.1, "Verifying the Initial RAM Disk Image" for more information. The default= directive tells GRUB which kernel to boot by default. Each title in grub.conf represents a bootable kernel. GRUB counts the titled stanzas representing bootable kernels starting with 0. In Example 24.2, "/boot/grub/grub.conf", the line default=1 indicates that GRUB will boot, by default, the second kernel entry, i.e. title Red Hat Enterprise Linux (2.6.32-19.el6.x86_64). In Example 24.2, "/boot/grub/grub.conf" GRUB is therefore configured to boot an older kernel, when we compare by version numbers. In order to boot the newer kernel, which is the first title entry in grub.conf, we would need to change the default value to 0. After installing a new kernel with rpm, verify that /boot/grub/grub.conf is correct, change the default= value to the new kernel (while remembering to count from 0), and reboot the computer into the new kernel. Ensure your hardware is detected by watching the boot process output. If GRUB presents an error and is unable to boot into the default kernel, it is often easiest to try to boot into an alternative or older kernel so that you can fix the problem. If you set the timeout directive in grub.conf to 0, GRUB will not display its list of bootable kernels when the system starts up. In order to display this list when booting, press and hold any alphanumeric key while and immediately after BIOS information is displayed. GRUB will present you with the GRUB menu. Alternatively, use the boot media you created earlier to boot the system. 24.6.2. Configuring the OS/400 Boot LoaderThe /boot/vmlinitrd-<kernel-version> file is installed when you upgrade the kernel. However, you must use the dd command to configure the system to boot the new kernel. As root, issue the command cat /proc/iSeries/mf/side to determine the default side (either A, B, or C). As root, issue the following command, where <kernel-version> is the version of the new kernel and <side> is the side from the previous command: dd if=/boot/vmlinitrd-<kernel-version> of=/proc/iSeries/mf/<side>/vmlinux bs=8k
Begin testing the new kernel by rebooting the computer and watching the messages to ensure that the hardware is detected properly. 24.6.3. Configuring the YABOOT Boot LoaderIBM eServer System p uses YABOOT as its boot loader. YABOOT uses /etc/aboot.conf as its configuration file. Confirm that the file contains an image section with the same version as the kernel package just installed, and likewise for the initramfs image: boot=/dev/sda1 init-message=Welcome to Red Hat Enterprise Linux! Hit <TAB> for boot optionspartition=2 timeout=30 install=/usr/lib/yaboot/yaboot delay=10 nonvramimage=/vmlinuz-2.6.32-17.EL label=old read-only initrd=/initramfs-2.6.32-17.EL.img append="root=LABEL=/"image=/vmlinuz-2.6.32-19.EL label=linux read-only initrd=/initramfs-2.6.32-19.EL.img append="root=LABEL=/" Notice that the default is not set to the new kernel. The kernel in the first image is booted by default. To change the default kernel to boot either move its image stanza so that it is the first one listed or add the directive default and set it to the label of the image stanza that contains the new kernel. Begin testing the new kernel by rebooting the computer and watching the messages to ensure that the hardware is detected properly. Chapter 25. Working with Kernel ModulesThe Linux kernel is modular, which means it can extend its capabilities through the use of dynamically-loaded kernel modules. A kernel module can provide: a device driver which adds support for new hardware; or, support for a file system such as btrfs or NFS.
Like the kernel itself, modules can take parameters that customize their behavior, though the default parameters work well in most cases. User-space tools can list the modules currently loaded into a running kernel; query all available modules for available parameters and module-specific information; and load or unload (remove) modules dynamically into or from a running kernel. Many of these utilities, which are provided by the module-init-tools package, take module dependencies into account when performing operations so that manual dependency-tracking is rarely necessary. On modern systems, kernel modules are automatically loaded by various mechanisms when the conditions call for it. However, there are occasions when it is necessary to load and/or unload modules manually, such as when a module provides optional functionality, one module should be preferred over another although either could provide basic functionality, or when a module is misbehaving, among other situations. This chapter explains how to: use the user-space module-init-tools package to display, query, load and unload kernel modules and their dependencies; set module parameters both dynamically on the command line and permanently so that you can customize the behavior of your kernel modules; and, load modules at boot time.
In order to use the kernel module utilities described in this chapter, first ensure the module-init-tools package is installed on your system by running, as root: ~]# yum install module-init-tools 25.1. Listing Currently-Loaded ModulesYou can list all kernel modules that are currently loaded into the kernel by running the lsmod command: ~]$ lsmodModule Size Used byxfs 803635 1exportfs 3424 1 xfsvfat 8216 1fat 43410 1 vfattun 13014 2fuse 54749 2ip6table_filter 2743 0ip6_tables 16558 1 ip6table_filterebtable_nat 1895 0ebtables 15186 1 ebtable_natipt_MASQUERADE 2208 6iptable_nat 5420 1nf_nat 19059 2 ipt_MASQUERADE,iptable_natrfcomm 65122 4ipv6 267017 33sco 16204 2bridge 45753 0stp 1887 1 bridgellc 4557 2 bridge,stpbnep 15121 2l2cap 45185 16 rfcomm,bnepcpufreq_ondemand 8420 2acpi_cpufreq 7493 1freq_table 3851 2 cpufreq_ondemand,acpi_cpufrequsb_storage 44536 1sha256_generic 10023 2aes_x86_64 7654 5aes_generic 27012 1 aes_x86_64cbc 2793 1dm_crypt 10930 1kvm_intel 40311 0kvm 253162 1 kvm_intel[output truncated] Each row of lsmod output specifies: Finally, note that lsmod output is less verbose and considerably easier to read than the content of the /proc/modules pseudo-file. 25.2. Displaying Information About a ModuleYou can display detailed information about a kernel module by running the modinfo <module_name> command. When entering the name of a kernel module as an argument to one of the module-init-tools utilities, do not append a .ko extension to the end of the name. Kernel module names do not have extensions: their corresponding files do. For example, to display information about the e1000e module, which is the Intel PRO/1000 network driver, run: Example 25.1. Listing information about a kernel module with lsmod ~]# modinfo e1000efilename: /lib/modules/2.6.32-71.el6.x86_64/kernel/drivers/net/e1000e/e1000e.koversion: 1.2.7-k2license: GPLdescription: Intel(R) PRO/1000 Network Driverauthor: Intel Corporation, <[email protected]>srcversion: 93CB73D3995B501872B2982alias: pci:v00008086d00001503sv*sd*bc*sc*i*alias: pci:v00008086d00001502sv*sd*bc*sc*i*[some alias lines omitted]alias: pci:v00008086d0000105Esv*sd*bc*sc*i*depends:vermagic: 2.6.32-71.el6.x86_64 SMP mod_unload modversionsparm: copybreak:Maximum size of packet that is copied to a new buffer on receive (uint)parm: TxIntDelay:Transmit Interrupt Delay (array of int)parm: TxAbsIntDelay:Transmit Absolute Interrupt Delay (array of int)parm: RxIntDelay:Receive Interrupt Delay (array of int)parm: RxAbsIntDelay:Receive Absolute Interrupt Delay (array of int)parm: InterruptThrottleRate:Interrupt Throttling Rate (array of int)parm: IntMode:Interrupt Mode (array of int)parm: SmartPowerDownEnable:Enable PHY smart power down (array of int)parm: KumeranLockLoss:Enable Kumeran lock loss workaround (array of int)parm: WriteProtectNVM:Write-protect NVM [WARNING: disabling this can lead to corrupted NVM] (array of int)parm: CrcStripping:Enable CRC Stripping, disable if your BMC needs the CRC (array of int)parm: EEE:Enable/disable on parts that support the feature (array of int) Here are descriptions of a few of the fields in modinfo output: - filename
The absolute path to the .ko kernel object file. You can use modinfo -n as a shortcut command for printing only the filename field. - description
A short description of the module. You can use modinfo -d as a shortcut command for printing only the description field. - alias
The alias field appears as many times as there are aliases for a module, or is omitted entirely if there are none. - depends
This field contains a comma-separated list of all the modules this module depends on. If a module has no dependencies, the depends field may be omitted from the output. - parm
Each parm field presents one module parameter in the form parameter_name:description parameter_name is the exact syntax you should use when using it as a module parameter on the command line, or in an option line in a .conf file in the /etc/modprobe.d/ directory; and,
description is a brief explanation of what the parameter does, along with an expectation for the type of value the parameter accepts (such as int, unit or array of int) in parentheses.
You can list all parameters that the module supports by using the -p option. However, because useful value type information is omitted from modinfo -p output, it is more useful to run: Example 25.2. Listing module parameters ~]# modinfo e1000e | grep "^parm" | sortparm: copybreak:Maximum size of packet that is copied to a new buffer on receive (uint)parm: CrcStripping:Enable CRC Stripping, disable if your BMC needs the CRC (array of int)parm: EEE:Enable/disable on parts that support the feature (array of int)parm: InterruptThrottleRate:Interrupt Throttling Rate (array of int)parm: IntMode:Interrupt Mode (array of int)parm: KumeranLockLoss:Enable Kumeran lock loss workaround (array of int)parm: RxAbsIntDelay:Receive Absolute Interrupt Delay (array of int)parm: RxIntDelay:Receive Interrupt Delay (array of int)parm: SmartPowerDownEnable:Enable PHY smart power down (array of int)parm: TxAbsIntDelay:Transmit Absolute Interrupt Delay (array of int)parm: TxIntDelay:Transmit Interrupt Delay (array of int)parm: WriteProtectNVM:Write-protect NVM [WARNING: disabling this can lead to corrupted NVM] (array of int)
To load a kernel module, run modprobe <module_name> as root. For example, to load the wacom module, run: ~]# modprobe wacom By default, modprobe attempts to load the module from /lib/modules/<kernel_version>/kernel/drivers/. In this directory, each type of module has its own subdirectory, such as net/ and scsi/, for network and SCSI interface drivers respectively. Some modules have dependencies, which are other kernel modules that must be loaded before the module in question can be loaded. The modprobe command always takes dependencies into account when performing operations. When you ask modprobe to load a specific kernel module, it first examines the dependencies of that module, if there are any, and loads them if they are not already loaded into the kernel. modprobe resolves dependencies recursively: it will load all dependencies of dependencies, and so on, if necessary, thus ensuring that all dependencies are always met. You can use the -v (or --verbose) option to cause modprobe to display detailed information about what it is doing, which may include loading module dependencies. The following is an example of loading the Fibre Channel over Ethernet module verbosely: Example 25.3. modprobe -v shows module dependencies as they are loaded ~]# modprobe -v fcoeinsmod /lib/modules/2.6.32-71.el6.x86_64/kernel/drivers/scsi/scsi_tgt.koinsmod /lib/modules/2.6.32-71.el6.x86_64/kernel/drivers/scsi/scsi_transport_fc.koinsmod /lib/modules/2.6.32-71.el6.x86_64/kernel/drivers/scsi/libfc/libfc.koinsmod /lib/modules/2.6.32-71.el6.x86_64/kernel/drivers/scsi/fcoe/libfcoe.koinsmod /lib/modules/2.6.32-71.el6.x86_64/kernel/drivers/scsi/fcoe/fcoe.ko Although the insmod command can also be used to load kernel modules, it does not resolve dependencies. Because of this, you should always load modules using modprobe instead. You can unload a kernel module by running modprobe -r <module_name> as root. For example, assuming that the wacom module is already loaded into the kernel, you can unload it by running: ~]# modprobe -r wacom However, this command will fail if a process is using: the wacom module, a module that wacom directly depends on, or, any module that wacom-through the dependency tree-depends on indirectly.
For example, if you want to unload the firewire_ohci module (because you believe there is a bug in it that is affecting system stability, for example), your terminal session might look similar to this: ~]# modinfo -F depends firewire_ohcidepends: firewire-core~]# modinfo -F depends firewire_coredepends: crc-itu-t~]# modinfo -F depends crc-itu-tdepends: You have figured out the dependency tree (which does not branch in this example) for the loaded Firewire modules: firewire_ohci depends on firewire_core, which itself depends on crc-itu-t. You can unload firewire_ohci using the modprobe -v -r <module_name> command, where -r is short for --remove and -v for --verbose: ~]# modprobe -r -v firewire_ohcirmmod /lib/modules/2.6.32-71.el6.x86_64/kernel/drivers/firewire/firewire-ohci.kormmod /lib/modules/2.6.32-71.el6.x86_64/kernel/drivers/firewire/firewire-core.kormmod /lib/modules/2.6.32-71.el6.x86_64/kernel/lib/crc-itu-t.ko The output shows that modules are unloaded in the reverse order that they are loaded, given that no processes depend on any of the modules being unloaded. Although the rmmod command can be used to unload kernel modules, it is recommended to use modprobe -r instead. 25.5. Setting Module ParametersLike the kernel itself, modules can also take parameters that change their behavior. Most of the time, the default ones work well, but occasionally it is necessary or desirable to set custom parameters for a module. Because parameters cannot be dynamically set for a module that is already loaded into a running kernel, there are two different methods for setting them. You can unload all dependencies of the module you want to set parameters for, unload the module using modprobe -r, and then load it with modprobe along with a list of customized parameters. This method is often used when the module does not have many dependencies, or to test different combinations of parameters without making them persistent, and is the method covered in this section. Alternatively, you can list the new parameters in an existing or newly-created file in the /etc/modprobe.d/ directory. This method makes the module parameters persistent by ensuring that they are set each time the module is loaded, such as after every reboot or modprobe command. This method is covered in Section 25.6, "Persistent Module Loading", though the following information is a prerequisite.
You can use modprobe to load a kernel module with custom parameters using the following command line format: Example 25.4. Supplying optional parameters when loading a kernel module ~]# modprobe <module_name> [parameter=value] When loading a module with custom parameters on the command line, be aware of the following: You can enter multiple parameters and values by separating them with spaces. Some module parameters expect a list of comma-separated values as their argument. When entering the list of values, do not insert a space after each comma, or modprobe will incorrectly interpret the values following spaces as additional parameters. The modprobe command silently succeeds with an exit status of 0 if: Thus, you must ensure that the module is not already loaded before attempting to load it with custom parameters. The modprobe command does not automatically reload the module, or alert you that it is already loaded.
Here are the recommended steps for setting custom parameters and then loading a kernel module. This procedure illustrates the steps using the e1000e module, which is the network driver for Intel PRO/1000 network adapters, as an example: Procedure 25.1. Loading a Kernel Module with Custom Parameters First, ensure the module is not already loaded into the kernel: ~]# lsmod |grep e1000e~]# Output indicates that the module is already loaded into the kernel, in which case you must first unload it before proceeding. Refer to Section 25.4, "Unloading a Module" for instructions on safely unloading it. Load the module and list all custom parameters after the module name. For example, if you wanted to load the Intel PRO/1000 network driver with the interrupt throttle rate set to 3000 interrupts per second for the first, second and third instances of the driver, and Energy Efficient Ethernet (EEE) turned on , you would run, as root: ~]# modprobe e1000e InterruptThrottleRate=3000,3000,3000 EEE=1 This example illustrates passing multiple values to a single parameter by separating them with commas and omitting any spaces between them.
25.6. Persistent Module LoadingAs shown in Example 25.1, "Listing information about a kernel module with lsmod", many kernel modules are loaded automatically at boot time. You can specify additional modules to be loaded by creating a new <file_name>.modules file in the /etc/sysconfig/modules/ directory, where <file_name> is any descriptive name of your choice. Your <file_name>.modules files are treated by the system startup scripts as shell scripts, and as such should begin with an interpreter directive (also called a "bang line") as their first line: Example 25.5. First line of a file_name.modules file Additionally, the <file_name>.modules modules]# chmod +x <file_name>.modules For example, the following bluez-uinput.modules script loads the uinput module: Example 25.6. /etc/sysconfig/modules/bluez-uinput.modules if [ ! -c /dev/input/uinput ] ; then exec /sbin/modprobe uinput >/dev/null 2>&1fi The if-conditional statement on the third line ensures that the /dev/input/uinput file does not already exist (the ! symbol negates the condition), and, if that is the case, loads the uinput module by calling exec /sbin/modprobe uinput. Note that the uinput module creates the /dev/input/uinput file, so testing to see if that file exists serves as verification of whether the uinput module is loaded into the kernel. The following >/dev/null 2>&1 clause at the end of that line redirects any output to /dev/null so that the modprobe command remains quiet. 25.7. Specific Kernel Module CapabilitiesThis section explains how to enable specific kernel capabilities using various kernel modules. 25.7.1. Using Multiple Ethernet CardsIt is possible to use multiple Ethernet cards on a single machine. For each card there must be an alias and, possibly, options lines for each card in a user-created <module_name>.conf/etc/modprobe.d/ directory. 25.7.2. Using Channel BondingRed Hat Enterprise Linux allows administrators to bind NICs together into a single channel using the bonding kernel module and a special network interface, called a channel bonding interface. Channel bonding enables two or more network interfaces to act as one, simultaneously increasing the bandwidth and providing redundancy. To channel bond multiple network interfaces, the administrator must perform the following steps: As root, create a new file named <bonding>.conf/etc/modprobe.d/ directory. Note that you can name this file anything you like as long as it ends with a .conf extension. Insert the following line in this new file: alias bond<N> bonding Replace <N> with the interface number, such as 0. For each configured channel bonding interface, there must be a corresponding entry in your new /etc/modprobe.d/<bonding>.conf file. To enhance performance, adjust available module options to ascertain what combination works best. Pay particular attention to the miimon or arp_interval and the arp_ip_target parameters. Refer to Section 25.7.2.1, "Bonding Module Directives" for a list of available options and how to quickly determine the best ones for your bonded interface.
25.7.2.1. Bonding Module DirectivesIt is a good idea to test which channel bonding module parameters work best for your bonded interfaces before adding them to the BONDING_OPTS="<bonding parameters>" directive in your bonding interface configuration file (ifcfg-bond0 for example). Parameters to bonded interfaces can be configured without unloading (and reloading) the bonding module by manipulating files in the sysfs file system. sysfs is a virtual file system that represents kernel objects as directories, files and symbolic links. sysfs can be used to query for information about kernel objects, and can also manipulate those objects through the use of normal file system commands. The sysfs virtual file system has a line in /etc/fstab, and is mounted under the /sys/ directory. All bonding interfaces can be configured dynamically by interacting with and manipulating files under the /sys/class/net/ directory.
In order to determine the best parameters for your bonding interface, create a channel bonding interface file such as ifcfg-bond0 by following the instructions in Section 9.2.5, "Channel Bonding Interfaces". Insert the SLAVE=yes and MASTER=bond0 directives in the configuration files for each interface bonded to bond0. Once this is completed, you can proceed to testing the parameters. First, bring up the bond you created by running ifconfig bond<N> up as root: ~]# ifconfig bond0 up If you have correctly created the ifcfg-bond0 bonding interface file, you will be able to see bond0 listed in the output of running ifconfig (without any options): ~]# ifconfigbond0 Link encap:Ethernet HWaddr 00:00:00:00:00:00 UP BROADCAST RUNNING MASTER MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)eth0 Link encap:Ethernet HWaddr 52:54:00:26:9E:F1 inet addr:192.168.122.251 Bcast:192.168.122.255 Mask:255.255.255.0 inet6 addr: fe80::5054:ff:fe26:9ef1/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:207 errors:0 dropped:0 overruns:0 frame:0 TX packets:205 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:70374 (68.7 KiB) TX bytes:25298 (24.7 KiB)[output truncated] To view all existing bonds, even if they are not up, run: ~]# cat /sys/class/net/bonding_mastersbond0 You can configure each bond individually by manipulating the files located in the /sys/class/net/bond<N>/bonding/ directory. First, the bond you are configuring must be taken down: ~]# ifconfig bond0 down As an example, to enable MII monitoring on bond0 with a 1 second interval, you could run (as root): ~]# echo 1000 > /sys/class/net/bond0/bonding/miimon To configure bond0 for balance-alb mode, you could run either: ~]# echo 6 > /sys/class/net/bond0/bonding/mode ...or, using the name of the mode: ~]# echo balance-alb > /sys/class/net/bond0/bonding/mode After configuring options for the bond in question, you can bring it up and test it by running ifconfig bond<N> up. If you decide to change the options, take the interface down, modify its parameters using sysfs, bring it back up, and re-test. Once you have determined the best set of parameters for your bond, add those parameters as a space-separated list to the BONDING_OPTS= directive of the /etc/sysconfig/network-scripts/ifcfg-bond<N> file for the bonding interface you are configuring. Whenever that bond is brought up (for example, by the system during the boot sequence if the ONBOOT=yes directive is set), the bonding options specified in the BONDING_OPTS will take effect for that bond. For more information on configuring bonding interfaces (and BONDING_OPTS), refer to Section 9.2.5, "Channel Bonding Interfaces". The following list provides the names of many of the more common channel bonding parameters, along with a descriptions of what they do. For more information, refer to the brief descriptions for each parm in modinfo bonding output, or the exhaustive descriptions in the bonding.txt file in the kernel-doc package (see Section 25.8, "Additional Resources"). Bonding Interface Parameters -
arp_interval=<time_in_milliseconds> Specifies (in milliseconds) how often ARP monitoring occurs. It is essential that both arp_interval and arp_ip_target parameters are specified, or, alternatively, the miimon parameter is specified. Failure to do so can cause degradation of network performance in the event that a link fails. If using this setting while in mode=0 or mode=1 (the two load-balancing modes), the network switch must be configured to distribute packets evenly across the NICs. For more information on how to accomplish this, refer to /usr/share/doc/kernel-doc-<kernel_version>/Documentation/networking/bonding.txt The value is set to 0 by default, which disables it. -
arp_ip_target=<ip_address>[,<ip_address_2>,…<ip_address_16>] Specifies the target IP address of ARP requests when the arp_interval parameter is enabled. Up to 16 IP addresses can be specified in a comma separated list. -
arp_validate=<value> Validate source/distribution of ARP probes; default is none. Other valid values are active, backup, and all. -
debug=<number> Enables debug messages. Possible values are: -
downdelay=<time_in_milliseconds> Specifies (in milliseconds) how long to wait after link failure before disabling the link. The value must be a multiple of the value specified in the miimon parameter. The value is set to 0 by default, which disables it. - lacp_rate=
<value> Specifies the rate at which link partners should transmit LACPDU packets in 802.3ad mode. Possible values are: -
miimon=<time_in_milliseconds> Specifies (in milliseconds) how often MII link monitoring occurs. This is useful if high availability is required because MII is used to verify that the NIC is active. To verify that the driver for a particular NIC supports the MII tool, type the following command as root: ~]# ethtool <interface_name> | grep "Link detected:" In this command, replace <interface_name> with the name of the device interface, such as eth0, not the bond interface. If MII is supported, the command returns: Link detected: yes If using a bonded interface for high availability, the module for each NIC must support MII. Setting the value to 0 (the default), turns this feature off. When configuring this setting, a good starting point for this parameter is 100. It is essential that both arp_interval and arp_ip_target parameters are specified, or, alternatively, the miimon parameter is specified. Failure to do so can cause degradation of network performance in the event that a link fails. -
mode=<value> Allows you to specify the bonding policy. The <value> can be one of: balance-rr or 0 - Sets a round-robin policy for fault tolerance and load balancing. Transmissions are received and sent out sequentially on each bonded slave interface beginning with the first one available.
active-backup or 1 - Sets an active-backup policy for fault tolerance. Transmissions are received and sent out via the first available bonded slave interface. Another bonded slave interface is only used if the active bonded slave interface fails.
balance-xor or 2 - Sets an XOR (exclusive-or) policy for fault tolerance and load balancing. Using this method, the interface matches up the incoming request's MAC address with the MAC address for one of the slave NICs. Once this link is established, transmissions are sent out sequentially beginning with the first available interface.
broadcast or 3 - Sets a broadcast policy for fault tolerance. All transmissions are sent on all slave interfaces.
802.3ad or 4 - Sets an IEEE 802.3ad dynamic link aggregation policy. Creates aggregation groups that share the same speed and duplex settings. Transmits and receives on all slaves in the active aggregator. Requires a switch that is 802.3ad compliant.
balance-tlb or 5 - Sets a Transmit Load Balancing (TLB) policy for fault tolerance and load balancing. The outgoing traffic is distributed according to the current load on each slave interface. Incoming traffic is received by the current slave. If the receiving slave fails, another slave takes over the MAC address of the failed slave.
balance-alb or 6 - Sets an Active Load Balancing (ALB) policy for fault tolerance and load balancing. Includes transmit and receive load balancing for IPV4 traffic. Receive load balancing is achieved through ARP negotiation.
-
num_unsol_na=<number> Specifies the number of unsolicited IPv6 Neighbor Advertisements to be issued after a failover event. One unsolicited NA is issued immediately after the failover. The valid range is 0 - 255; the default value is 1. This parameter affects only the active-backup mode. -
primary=<interface_name> Specifies the interface name, such as eth0, of the primary device. The primary device is the first of the bonding interfaces to be used and is not abandoned unless it fails. This setting is particularly useful when one NIC in the bonding interface is faster and, therefore, able to handle a bigger load. This setting is only valid when the bonding interface is in active-backup mode. Refer to /usr/share/doc/kernel-doc-<kernel-version>/Documentation/networking/bonding.txt for more information. -
primary_reselect=<value> Specifies the reselection policy for the primary slave. This affects how the primary slave is chosen to become the active slave when failure of the active slave or recovery of the primary slave occurs. This parameter is designed to prevent flip-flopping between the primary slave and other slaves. Possible values are: always or 0 (default) - The primary slave becomes the active slave whenever it comes back up.
better or 1 - The primary slave becomes the active slave when it comes back up, if the speed and duplex of the primary slave is better than the speed and duplex of the current active slave.
failure or 2 - The primary slave becomes the active slave only if the current active slave fails and the primary slave is up.
The primary_reselect setting is ignored in two cases: If no slaves are active, the first slave to recover is made the active slave. When initially enslaved, the primary slave is always made the active slave.
Changing the primary_reselect policy via sysfs will cause an immediate selection of the best active slave according to the new policy. This may or may not result in a change of the active slave, depending upon the circumstances -
updelay=<time_in_milliseconds> Specifies (in milliseconds) how long to wait before enabling a link. The value must be a multiple of the value specified in the miimon parameter. The value is set to 0 by default, which disables it. -
use_carrier=<number> Specifies whether or not miimon should use MII/ETHTOOL ioctls or netif_carrier_ok() to determine the link state. The netif_carrier_ok() function relies on the device driver to maintains its state with netif_carrier_on/off; most device drivers support this function. The MII/ETHROOL ioctls tools utilize a deprecated calling sequence within the kernel. However, this is still configurable in case your device driver does not support netif_carrier_on/off. Valid values are: If the bonding interface insists that the link is up when it should not be, it is possible that your network device driver does not support netif_carrier_on/off. -
xmit_hash_policy=<value> Selects the transmit hash policy used for slave selection in balance-xor and 802.3ad modes. Possible values are: 0 or layer2 - Default setting. This parameter uses the XOR of hardware MAC addresses to generate the hash. The formula used is:
(<source_MAC_address> XOR <destination_MAC>) MODULO <slave_count> This algorithm will place all traffic to a particular network peer on the same slave, and is 802.3ad compliant. 1 or layer3+4 - Uses upper layer protocol information (when available) to generate the hash. This allows for traffic to a particular network peer to span multiple slaves, although a single connection will not span multiple slaves.
The formula for unfragmented TCP and UDP packets used is: ((<source_port> XOR <dest_port>) XOR ((<source_IP> XOR <dest_IP>) AND 0xffff) MODULO <slave_count> For fragmented TCP or UDP packets and all other IP protocol traffic, the source and destination port information is omitted. For non-IP traffic, the formula is the same as the layer2 transmit hash policy. This policy intends to mimic the behavior of certain switches; particularly, Cisco switches with PFC2 as well as some Foundry and IBM products. The algorithm used by this policy is not 802.3ad compliant. 2 or layer2+3 - Uses a combination of layer2 and layer3 protocol information to generate the hash.
Uses XOR of hardware MAC addresses and IP addresses to generate the hash. The formula is: (((<source_IP> XOR <dest_IP>) AND 0xffff) XOR ( <source_MAC> XOR <destination_MAC> )) MODULO <slave_count> This algorithm will place all traffic to a particular network peer on the same slave. For non-IP traffic, the formula is the same as for the layer2 transmit hash policy. This policy is intended to provide a more balanced distribution of traffic than layer2 alone, especially in environments where a layer3 gateway device is required to reach most destinations. This algorithm is 802.3ad compliant.
25.8. Additional ResourcesFor more information on kernel modules and their utilities, refer to the following resources. Manual Page Documentationman lsmod - The manual page for the lsmod command.
man modinfo - The manual page for the modinfo command.
man modprobe - The manual page for the modprobe command.
man rmmod - The manual page for the rmmod command.
man ethtool - The manual page for the ethtool command.
man mii-tool - The manual page for the mii-tool command.
Installable and External Documentation/usr/share/doc/kernel-doc-<kernel_version>/Documentation/ - This directory, which is provided by the kernel-doc package, contains information on the kernel, kernel modules, and their respective parameters. Before accessing the kernel documentation, you must run the following command as root:
~]# yum install kernel-doc Linux Loadable Kernel Module HOWTO - The Linux Loadable Kernel Module HOWTO from the Linux Documentation Project contains further information on working with kernel modules.
|
| |
