201.3. Kernel runtime management and troubleshooting
201.3 Kernel runtime management and troubleshooting
Weight: 4
Description: Candidates should be able to manage and/or query a 2.6.x, 3.x or 4.x kernel and its loadable modules. Candidates should be able to identify and correct common boot and run time issues. Candidates should understand device detection and management using udev. This objective includes troubleshooting udev rules.
Key Knowledge Areas:
Use command-line utilities to get information about the currently running kernel and kernel modules
Manually load and unload kernel modules
Determine when modules can be unloaded
Determine what parameters a module accepts
Configure the system to load modules by names other than their file name.
/proc filesystem
Content of /, /boot/ , and /lib/modules/
Tools and utilities to analyze information about the available hardware
udev rules
Terms and Utilities:
/lib/modules/kernel-version/modules.dep
module configuration files in /etc/
/proc/sys/kernel/
/sbin/depmod
/sbin/rmmod
/sbin/modinfo
/bin/dmesg
/sbin/lspci
/usr/bin/lsdev
/sbin/lsmod
/sbin/modprobe
/sbin/insmod
/bin/uname
/usr/bin/lsusb
/etc/sysctl.conf, /etc/sysctl.d/
/sbin/sysctl
udevmonitor
udevadm monitor
/etc/udev/
Kernel Modules
Linux Kernel is modular since version 2.0. Being modular make simplicity and efficiency, the code which is not needed wouldn't be loaded. Kernel Modules have different conditions. A module might be compiled, or not. If it has already compiled it might be loaded or not. So Loading an unload but compiled kernel is easy, otherwise required kernel manipulation.We use CentOS7 for demonstartion:
lsmod
To list Kernel Loaded modules use lsmod
lets try to load and unloaded module " jfs " that old journaling file system. for loading an unloaded but compiled module there are two solutions. An old solution is insmod , lets try it first
But it doesn't work :(( so let get more information about "jfs" module with modinfo:
modinfo shows a bunch of information about a module. Like its filename, dependencies and possible parameters.Till now we have realize that "jfs" module has been compiled and its available but it is not loaded. inorder to load a module with insmod we have to specify the full patch of module:
Haha its loaded now, Lets remove it by using rmmod:
But as you see using insmod is not that much easy, insmod has another problem and that is dependencies. "jfs" module has no dependency so we were able to load it very easily, if a module has some dependencies, insmod dosn't load those required dependencies automatically. So it would be administrator task. All these shortages cause we come to this conclusion that insmod is not perfect and we need a modern tool, which automatically know the patch and load required dependencies, that is modprobe.
also for removing use modprobe -r lp. But how modprobe realize module dependencies and act such a smart tool? modules.dep
we can use depmod -a to create and update modules.dep with all new modules and dependencies. Now that we have learned alot of tools, let play game with cdrom parameters [in ubunto cdrom is not a module, so use other distro]:
We as users like modules to load automatically, mean while parameters should be loaded automatically, to make parameters persistence create a file in /etc/modprobe.d :
and insert:
If you have noticed there is blacklist.conf file in /etc/modfprobe.d , if you don't wana let a specific module be loaded use it:
go to /sys/module/<module name> directory to see current running environment parameters.
sysctl
We discussed that by manipulating /proc/sys/kernel we can change some current running kernel parameters. But as we said these settings are not permanent and they all gone after reboot. sysctl lets us make permanent settings . sysctl is loaded from /sbin/sysctl and read setting from /etc/sysctl.conf. As user we can change settings inside sysctl.conf file or make our custom file with desired parameters in /etc/sysctl.d/ directory. sysctl has a command interface and let us to see and write paramets trough /proc/sys/kernel/.
sysctl -a to show all tuneables.
that is a large file you can see.To set a new value to a parameter use sysctl -w :
Before quit lets take a look at sysctl.conf :
as you can see includes /etc/sysctl.d/ directory setting files but don't for get that setting in sysctl.conf file always over write /etc/sysctl.d/ directory and Win :) You can uncomment or add setting weather in sysctl.conf or go and create custom file in /etc/sysctl.d/ directory but Take care of contrasts.
udev
During boot process when kernel is loaded and Device Driver start setting up hardware, next step of hardware initializing is udev. So kernel initial device loading and send uevents to udev daemon. udev keep these event and handle them base on attributes it has received in the event. Then udev take action based on its rules .there are two types of rules in two different locations :
/lib/udev/rules.d "default rules"
/etc/udev/rules.d "custom rules/ user defined"
After Finishing boot process udev is active and receive kernel messages an uevent messages from hot-pluggable devices.
udevadm monitor , udevadm
udev has a monitoring tool, and it monitor and shows event received from the kernel after hardware initializing and uevent which are udev events after processing udev rules, lets attach a usb and monitor what it shows:
You can see both kernel messages and udev events. And finally our usb flash is mounted as sdb. For having more readable data:
use udevadm info attribute-walk --name=/dev/sdb | less to have summary of device attributes:
Oh. That is a long long list of attributes, but we notice that udev consider all of these attributes when it checks it rules!
Thanks udev, but udev dose another great job for us, can you remember? udev populate /dev/ and create Hardware Abstraction, which is used my other programs. Udev has made world easier place for us and other programs.Thank you udev :)
dmesg
In LPIC1 Course we discussed that during boot process (when operating system hasn't been started yet) dmesg logs kernel ring buffer. Let go deeper, during the boot process kernel is loaded into RAM. At this stage there is a Device Driver presents in kernel which set up to drive relevant hardware. As any other elements of kernel, device driver produce messages. These messages have information about modules presents and value of any parameters. As booting process is so fast, dmesg help us to review what has happened during boot process.
Even after booting kernel might generate some messages, for example when an I/O devicefacing the problem, or a hot-pluggable device like USB is attached to system. Again dmesg can be used to review what kernel has generated during doing its jobs.
result above is abstracted, how ever you can see that dmesg dosn't workout well to give information about modules and parameters.
There are some user space commands from lpic1, lets just review:
command
Description
lspci
List PCi devices on the computer
lsusb
Shows Connected USB Devices
lsdev
List all Devices and Device Information
Last updated