Managing, monitoring, and updating the kernel

Procedure

1. List the available versions of a package:

   $ dnf repoquery <package_name>

   Copy to Clipboard Toggle word wrap

2. Display the list of files in a package:

   $ dnf repoquery -l <package_name>

   Copy to Clipboard Toggle word wrap

Procedure

1. To update the kernel, enter the following command:

   # dnf update kernel

   Copy to Clipboard Toggle word wrap

   This command updates the kernel along with all dependencies to the latest available version.

2. Reboot your system for the changes to take effect.

Procedure

1. Select a kernel module you want to load.

   The modules are located in the /lib/modules/$(uname -r)/kernel/<SUBSYSTEM>/ directory.

2. Load the relevant kernel module:

   # modprobe <MODULE_NAME>

   Copy to Clipboard Toggle word wrap
   Note

   When entering the name of a kernel module, do not append the .ko.xz extension to the end of the name. Kernel module names do not have extensions; their corresponding files do.

Procedure

1. List all the loaded kernel modules:

   # lsmod

   Copy to Clipboard Toggle word wrap

2. Select the kernel module you want to unload.

   If a kernel module has dependencies, unload those prior to unloading the kernel module. For details on identifying modules with dependencies, see Listing currently loaded kernel modules and Kernel module dependencies.

3. Unload the relevant kernel module:

   # modprobe -r <MODULE_NAME>

   Copy to Clipboard Toggle word wrap

   When entering the name of a kernel module, do not append the .ko.xz extension to the end of the name. Kernel module names do not have extensions; their corresponding files do.

Procedure

1. Boot the system into the boot loader.
2. Use the cursor keys to highlight the relevant boot loader entry.

3. Press the e key to edit the entry.

   Figure 3.1. Kernel boot menu

   

   View larger image

   
4. Use the cursor keys to navigate to the line that starts with linux.

5. Append modprobe.blacklist=module_name to the end of the line.

   Figure 3.2. Kernel boot entry

   

   View larger image

   

   The serio_raw kernel module illustrates a rogue module to be unloaded early in the boot process.

6. Press Ctrl+X to boot using the modified configuration.

Procedure

1. Select a kernel module you want to load during the boot process.

   The modules are located in the /lib/modules/$(uname -r)/kernel/<SUBSYSTEM>/ directory.

2. Create a configuration file for the module:

   # echo <MODULE_NAME> > /etc/modules-load.d/<MODULE_NAME>.conf

   Copy to Clipboard Toggle word wrap
   Note

   When entering the name of a kernel module, do not append the .ko.xz extension to the end of the name. Kernel module names do not have extensions; their corresponding files do.

Verification

1. After reboot, verify the relevant module is loaded:

   $ lsmod | grep <MODULE_NAME>

   Copy to Clipboard Toggle word wrap

Procedure

1. List modules loaded to the currently running kernel by using the lsmod command:

   $ lsmod
   Module                  Size  Used by
   tls                   131072  0
   uinput                 20480  1
   snd_seq_dummy          16384  0
   snd_hrtimer            16384  1
   …

   Copy to Clipboard Toggle word wrap

   In the output, identify the module you want to prevent from getting loaded.

   • Alternatively, identify an unloaded kernel module you want to prevent from potentially loading in the /lib/modules/<KERNEL-VERSION>/kernel/<SUBSYSTEM>/ directory, for example:

     $ ls /lib/modules/4.18.0-477.20.1.el8_8.x86_64/kernel/crypto/
     ansi_cprng.ko.xz        chacha20poly1305.ko.xz  md4.ko.xz               serpent_generic.ko.xz
     anubis.ko.xz            cmac.ko.xz…

     Copy to Clipboard Toggle word wrap

2. Create a configuration file serving as a denylist:

   # touch /etc/modprobe.d/denylist.conf

   Copy to Clipboard Toggle word wrap

3. In a text editor of your choice, combine the names of modules you want to exclude from automatic loading to the kernel with the blacklist configuration command, for example:

   # Prevents <KERNEL-MODULE-1> from being loaded
   blacklist <MODULE-NAME-1>
   install <MODULE-NAME-1> /bin/false
   
   # Prevents <KERNEL-MODULE-2> from being loaded
   blacklist <MODULE-NAME-2>
   install <MODULE-NAME-2> /bin/false
   …

   Copy to Clipboard Toggle word wrap

   Because the blacklist command does not prevent the module from getting loaded as a dependency for another kernel module that is not in a denylist, you must also define the install line. In this case, the system runs /bin/false instead of installing the module. The lines starting with a hash sign are comments you can use to make the file more readable.

   Note

   When entering the name of a kernel module, do not append the .ko.xz extension to the end of the name. Kernel module names do not have extensions; their corresponding files do.

4. Create a backup copy of the current initial RAM disk image before rebuilding:

   # cp /boot/initramfs-$(uname -r).img /boot/initramfs-$(uname -r).bak.$(date +%m-%d-%H%M%S).img

   Copy to Clipboard Toggle word wrap

   • Alternatively, create a backup copy of an initial RAM disk image which corresponds to the kernel version for which you want to prevent kernel modules from automatic loading:

     # cp /boot/initramfs-<VERSION>.img /boot/initramfs-<VERSION>.img.bak.$(date +%m-%d-%H%M%S)

     Copy to Clipboard Toggle word wrap

5. Generate a new initial RAM disk image to apply the changes:

   # dracut -f -v

   Copy to Clipboard Toggle word wrap

   • If you build an initial RAM disk image for a different kernel version than your system currently uses, specify both target initramfs and kernel version:

     # dracut -f -v /boot/initramfs-<TARGET-VERSION>.img <CORRESPONDING-TARGET-KERNEL-VERSION>

     Copy to Clipboard Toggle word wrap

6. Restart the system:

   $ reboot

   Copy to Clipboard Toggle word wrap

Procedure

1. Create the /root/testmodule/test.c file with the following content.

   #include <linux/module.h>
   #include <linux/kernel.h>
   
   int init_module(void)
       { printk("Hello World\n This is a test\n"); return 0; }
   
   void cleanup_module(void)
       { printk("Good Bye World"); }
   
   MODULE_LICENSE("GPL");

   Copy to Clipboard Toggle word wrap

   The test.c file is a source file that provides the main functionality to the kernel module. The file has been created in a dedicated /root/testmodule/ directory for organizational purposes. After the module compilation, the /root/testmodule/ directory will contain multiple files.

   The test.c file includes from the system libraries:

   • The linux/kernel.h header file is necessary for the printk() function in the example code.
   • The linux/module.h file contains function declarations and macro definitions that are shared across several source files written in C programming language.
2. Follow the init_module() and cleanup_module() functions to start and end the kernel logging function printk(), which prints text.

3. Create the /root/testmodule/Makefile file with the following content.

   obj-m := test.o

   Copy to Clipboard Toggle word wrap

   The Makefile contains instructions for the compiler to produce an object file named test.o. The obj-m directive specifies that the resulting test.ko file is going to be compiled as a loadable kernel module. Alternatively, the obj-y directive can instruct to build test.ko as a built-in kernel module.

4. Compile the kernel module.

   # make -C /lib/modules/$(uname -r)/build M=/root/testmodule modules
   make: Entering directory '/usr/src/kernels/5.14.0-70.17.1.el9_0.x86_64'
     CC [M]  /root/testmodule/test.o
     MODPOST /root/testmodule/Module.symvers
     CC [M]  /root/testmodule/test.mod.o
     LD [M]  /root/testmodule/test.ko
     BTF [M] /root/testmodule/test.ko
   Skipping BTF generation for /root/testmodule/test.ko due to unavailability of vmlinux
   make: Leaving directory '/usr/src/kernels/5.14.0-70.17.1.el9_0.x86_64'

   Copy to Clipboard Toggle word wrap

   The compiler creates an object file (test.o) for each source file (test.c) as an intermediate step before linking them together into the final kernel module (test.ko).

   After a successful compilation, /root/testmodule/ contains additional files that relate to the compiled custom kernel module. The compiled module itself is represented by the test.ko file.

Verification

1. Optional: check the contents of the /root/testmodule/ directory:

   # ls -l /root/testmodule/
   total 152
   -rw-r—​r--. 1 root root    16 Jul 26 08:19 Makefile
   -rw-r—​r--. 1 root root    25 Jul 26 08:20 modules.order
   -rw-r—​r--. 1 root root     0 Jul 26 08:20 Module.symvers
   -rw-r—​r--. 1 root root   224 Jul 26 08:18 test.c
   -rw-r—​r--. 1 root root 62176 Jul 26 08:20 test.ko
   -rw-r—​r--. 1 root root    25 Jul 26 08:20 test.mod
   -rw-r—​r--. 1 root root   849 Jul 26 08:20 test.mod.c
   -rw-r—​r--. 1 root root 50936 Jul 26 08:20 test.mod.o
   -rw-r—​r--. 1 root root 12912 Jul 26 08:20 test.o

   Copy to Clipboard Toggle word wrap

2. Copy the kernel module to the /lib/modules/$(uname -r)/ directory:

   # cp /root/testmodule/test.ko /lib/modules/$(uname -r)/

   Copy to Clipboard Toggle word wrap

3. Update the modular dependency list:

   # depmod -a

   Copy to Clipboard Toggle word wrap

4. Load the kernel module:

   # modprobe -v test
   insmod /lib/modules/5.14.0-1.el9.x86_64/test.ko

   Copy to Clipboard Toggle word wrap

5. Verify that the kernel module was successfully loaded:

   # lsmod | grep test
   test                   16384  0

   Copy to Clipboard Toggle word wrap

6. Read the latest messages from the kernel ring buffer:

   # dmesg
   [74422.545004] Hello World
                   This is a test

   Copy to Clipboard Toggle word wrap

Procedure

1. Boot into the GRUB boot menu.
2. Select the kernel you want to start.
3. Press the e key to edit the kernel parameters.
4. Find the kernel command line by moving the cursor down. The kernel command line starts with linux on 64-Bit IBM Power Series and x86-64 BIOS-based systems, or linuxefi on UEFI systems.

5. Move the cursor to the end of the line.

   Note

   Press Ctrl+a to jump to the start of the line and Ctrl+e to jump to the end of the line. On some systems, Home and End keys might also work.

6. Edit the kernel parameters as required. For example, to run the system in emergency mode, add the emergency parameter at the end of the linux line:

   linux   ($root)/vmlinuz-5.14.0-63.el9.x86_64 root=/dev/mapper/rhel-root ro crashkernel=1G-4G:192M,4G-64G:256M,64G-:512M resume=/dev/mapper/rhel-swap rd.lvm.lv=rhel/root rd.lvm.lv=rhel/swap rhgb quiet emergency

   Copy to Clipboard Toggle word wrap

   To enable the system messages, remove the rhgb and quiet parameters.

7. Press Ctrl+x to boot with the selected kernel and the modified command line parameters.

Procedure

1. Add the following two lines to the /etc/default/grub file:

   GRUB_TERMINAL="serial"
   GRUB_SERIAL_COMMAND="serial --speed=9600 --unit=0 --word=8 --parity=no --stop=1"

   Copy to Clipboard Toggle word wrap

   The first line disables the graphical terminal. The GRUB_TERMINAL key overrides values of GRUB_TERMINAL_INPUT and GRUB_TERMINAL_OUTPUT keys.

   The second line adjusts the baud rate (--speed), parity and other values to fit your environment and hardware. Note that a much higher baud rate, for example 115200, is preferable for tasks such as following log files.

2. Update the GRUB configuration file.

   • On BIOS-based machines:

     # grub2-mkconfig -o /boot/grub2/grub.cfg

     Copy to Clipboard Toggle word wrap

   • On UEFI-based machines:

     # grub2-mkconfig -o /boot/grub2/grub.cfg

     Copy to Clipboard Toggle word wrap
3. Reboot the system for the changes to take effect.

Procedure

1. Add or remove a kernel parameter for individual kernels in a post installation script with grubby:

   # grubby --update-kernel <PATH_TO_KERNEL> --args "<NEW_ARGUMENTS>"

   Copy to Clipboard Toggle word wrap

   For example, add the noapic parameter to the chosen kernel:

   # grubby --update-kernel /boot/vmlinuz-5.14.0-362.8.1.el9_3.x86_64 --args "noapic"

   Copy to Clipboard Toggle word wrap

   The parameter is propagated into the BLS snippets, but not into the /etc/default/grub file.

2. Overwrite BLS snippets with the contents of the GRUB_CMDLINE_LINUX values present in the /etc/default/grub file:

   # grub2-mkconfig -o /boot/grub2/grub.cfg --update-bls-cmdline
   Generating grub configuration file …​
   Adding boot menu entry for UEFI Firmware Settings …​
   done

   Copy to Clipboard Toggle word wrap
   Note

   Other changes, such as changes made to GRUB_TIMEOUT key (also included in the /etc/default/grub GRUB configuration file), do get propagated to the new grub.cfg by default.

Verification

1. Reboot your operating system.

2. Verify that the parameters are included in the /proc/cmdline file.

   For example, /proc/cmdline contains the noapic kernel parameter:

   BOOT_IMAGE=(hd0,gpt2)/vmlinuz-4.18.0-425.3.1.el8.x86_64 root=/dev/mapper/RHELCSB-Root ro vconsole.keymap=us crashkernel=auto rd.lvm.lv=RHELCSB/Root rd.luks.uuid=luks-d8a28c4c-96aa-4319-be26-96896272151d rhgb quiet noapic rd.luks.key=d8a28c4c-96aa-4319-be26-96896272151d=/keyfile:UUID=c47d962e-4be8-41d6-8216-8cf7a0d3b911 ipv6.disable=1

   Copy to Clipboard Toggle word wrap

Procedure

1. List all parameters and their values.

   # sysctl -a

   Copy to Clipboard Toggle word wrap
   Note

   The # sysctl -a command displays kernel parameters, which can be adjusted at runtime and at boot time.

2. To configure a parameter temporarily, enter:

   # sysctl <TUNABLE_CLASS>.<PARAMETER>=<TARGET_VALUE>

   Copy to Clipboard Toggle word wrap

   The sample command above changes the parameter value while the system is running. The changes take effect immediately, without a need for restart.

   Note

   The changes return back to default after your system reboots.

Procedure

1. List all parameters.

   # sysctl -a

   Copy to Clipboard Toggle word wrap

   The command displays all kernel parameters that can be configured at runtime.

2. Configure a parameter permanently:

   # sysctl -w <TUNABLE_CLASS>.<PARAMETER>=<TARGET_VALUE> >> /etc/sysctl.conf

   Copy to Clipboard Toggle word wrap

   The sample command changes the tunable value and writes it to the /etc/sysctl.conf file, which overrides the default values of kernel parameters. The changes take effect immediately and persistently, without a need for restart.

Procedure

1. Create a new configuration file in /etc/sysctl.d/:

   # vim /etc/sysctl.d/<some_file.conf>

   Copy to Clipboard Toggle word wrap

2. Include kernel parameters, one per line:

   <TUNABLE_CLASS>.<PARAMETER>=<TARGET_VALUE>
   <TUNABLE_CLASS>.<PARAMETER>=<TARGET_VALUE>

   Copy to Clipboard Toggle word wrap
3. Save the configuration file.

4. Reboot the machine for the changes to take effect.

   • Alternatively, apply changes without rebooting:

     # sysctl -p /etc/sysctl.d/<some_file.conf>

     Copy to Clipboard Toggle word wrap

     The command enables you to read values from the configuration file, which you created earlier.

Procedure

1. Identify a kernel parameter you want to configure.

   # ls -l /proc/sys/<TUNABLE_CLASS>/

   Copy to Clipboard Toggle word wrap

   The writable files returned by the command can be used to configure the kernel. The files with read-only permissions provide feedback on the current settings.

2. Assign a target value to the kernel parameter.

   # echo <TARGET_VALUE> > /proc/sys/<TUNABLE_CLASS>/<PARAMETER>

   Copy to Clipboard Toggle word wrap

   The configuration changes applied by using a command are not permanent and will disappear once the system is restarted.

Verification

1. Verify the value of the newly set kernel parameter.

   # cat /proc/sys/<TUNABLE_CLASS>/<PARAMETER>

   Copy to Clipboard Toggle word wrap

Procedure

1. Create a playbook file, for example, ~/playbook.yml, with the following content:

   ---
   - name: Configuring kernel settings
     hosts: managed-node-01.example.com
     tasks:
       - name: Configure hugepages, packet size for loopback device, and limits on simultaneously open files.
         ansible.builtin.include_role:
           name: redhat.rhel_system_roles.kernel_settings
         vars:
           kernel_settings_sysctl:
             - name: fs.file-max
               value: 400000
             - name: kernel.threads-max
               value: 65536
           kernel_settings_sysfs:
             - name: /sys/class/net/lo/mtu
               value: 65000
           kernel_settings_transparent_hugepages: madvise
           kernel_settings_reboot_ok: true

   Copy to Clipboard Toggle word wrap

   The settings specified in the example playbook include the following:

   kernel_settings_sysfs: <list_of_sysctl_settings>

   A YAML list of sysctl settings and the values you want to assign to these settings.

   kernel_settings_transparent_hugepages: <value>

   Controls the memory subsystem Transparent Huge Pages (THP) setting. You can disable THP support (never), enable it system wide (always) or inside MAD_HUGEPAGE regions (madvise).

   kernel_settings_reboot_ok: <true|false>

   The default is false. If set to true, the system role will determine if a reboot of the managed host is necessary for the requested changes to take effect and reboot it. If set to false, the role will return the variable kernel_settings_reboot_required with a value of true, indicating that a reboot is required. In this case, a user must reboot the managed node manually.

1. Validate the playbook syntax:

   $ ansible-playbook --syntax-check ~/playbook.yml

   Copy to Clipboard Toggle word wrap

   Note that this command only validates the syntax and does not protect against a wrong but valid configuration.

2. Run the playbook:

   $ ansible-playbook ~/playbook.yml

   Copy to Clipboard Toggle word wrap

Procedure

1. Create a playbook file, for example, ~/playbook.yml, with the following content:

   ---
   - name: Configuration and management of GRUB boot loader
     hosts: managed-node-01.example.com
     tasks:
       - name: Update existing boot loader entries
         ansible.builtin.include_role:
           name: redhat.rhel_system_roles.bootloader
         vars:
           bootloader_settings:
             - kernel:
                 path: /boot/vmlinuz-5.14.0-362.24.1.el9_3.aarch64
               options:
                 - name: quiet
                   state: present
           bootloader_reboot_ok: true

   Copy to Clipboard Toggle word wrap

   The settings specified in the example playbook include the following:

   kernel

   Specifies the kernel connected with the boot loader entry that you want to update.

   options

   Specifies the kernel command-line parameters to update for your chosen boot loader entry (kernel).

   bootloader_reboot_ok: true

   The role detects that a reboot is required for the changes to take effect and performs a restart of the managed node.

   For details about all variables used in the playbook, see the /usr/share/ansible/roles/rhel-system-roles.bootloader/README.md file on the control node.

2. Validate the playbook syntax:

   $ ansible-playbook --syntax-check ~/playbook.yml

   Copy to Clipboard Toggle word wrap

   Note that this command only validates the syntax and does not protect against a wrong but valid configuration.

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

   Copy to Clipboard Toggle word wrap

Procedure

1. Store your sensitive variables in an encrypted file:

   1. Create the vault:

      $ ansible-vault create ~/vault.yml
      New Vault password: <vault_password>
      Confirm New Vault password: <vault_password>

      Copy to Clipboard Toggle word wrap

   2. After the ansible-vault create command opens an editor, enter the sensitive data in the <key>: <value> format:

      pwd: <password>

      Copy to Clipboard Toggle word wrap
   3. Save the changes, and close the editor. Ansible encrypts the data in the vault.

2. Create a playbook file, for example, ~/playbook.yml, with the following content:

   ---
   - name: Configuration and management of GRUB boot loader
     hosts: managed-node-01.example.com
     vars_files:
       - ~/vault.yml
     tasks:
       - name: Set the bootloader password
         ansible.builtin.include_role:
           name: redhat.rhel_system_roles.bootloader
         vars:
           bootloader_password: "{{ pwd }}"
           bootloader_reboot_ok: true

   Copy to Clipboard Toggle word wrap

   The settings specified in the example playbook include the following:

   bootloader_password: "{{ pwd }}"

   The variable ensures protection of boot parameters with a password.

   bootloader_reboot_ok: true

   The role detects that a reboot is required for the changes to take effect and performs a restart of the managed node.

   Important

   Changing the boot loader password is not an idempotent transaction. This means that if you apply the same Ansible playbook again, the result will not be the same, and the state of the managed node will change.

   For details about all variables used in the playbook, see the /usr/share/ansible/roles/rhel-system-roles.bootloader/README.md file on the control node.

3. Validate the playbook syntax:

   $ ansible-playbook --syntax-check --ask-vault-pass ~/playbook.yml

   Copy to Clipboard Toggle word wrap

   Note that this command only validates the syntax and does not protect against a wrong but valid configuration.

4. Run the playbook:

   $ ansible-playbook --ask-vault-pass ~/playbook.yml

   Copy to Clipboard Toggle word wrap

Verification

1. On your managed node during the GRUB boot menu screen, press the e key for edit.

   

   View larger image

   

2. You are prompted for a username and a password:

   

   View larger image

   

   Enter username: root

   The boot loader username is always root and you do not need to specify it in your Ansible playbook.

   Enter password: <password>

   The boot loader password corresponds to the pwd variable that you defined in the vault.yml file.

3. You can view or edit configuration of the particular boot loader entry:

   

   View larger image

   

Procedure

1. Create a playbook file, for example, ~/playbook.yml, with the following content:

   ---
   - name: Configuration and management of the GRUB boot loader
     hosts: managed-node-01.example.com
     tasks:
       - name: Update the boot loader timeout
         ansible.builtin.include_role:
           name: redhat.rhel_system_roles.bootloader
         vars:
           bootloader_timeout: 10

   Copy to Clipboard Toggle word wrap

   The settings specified in the example playbook include the following:

   bootloader_timeout: 10

   Input an integer to control for how long the GRUB boot loader menu is displayed before booting the default entry.

   For details about all variables used in the playbook, see the /usr/share/ansible/roles/rhel-system-roles.bootloader/README.md file on the control node.

2. Validate the playbook syntax:

   $ ansible-playbook --syntax-check ~/playbook.yml

   Copy to Clipboard Toggle word wrap

   Note that this command only validates the syntax and does not protect against a wrong but valid configuration.

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

   Copy to Clipboard Toggle word wrap

Verification

1. Remotely restart your managed node:

   # ansible managed-node-01.example.com -m ansible.builtin.reboot
   managed-node-01.example.com | CHANGED => {
       "changed": true,
       "elapsed": 21,
       "rebooted": true
   }

   Copy to Clipboard Toggle word wrap

2. On the managed node, observe the GRUB boot menu screen.

   

   View larger image

   

   The highlighted entry will be executed automatically in 10s

   For how long this boot menu is displayed before GRUB automatically uses the default entry.

   • Alternative: you can remotely query for the "timeout" settings in the /boot/grub2/grub.cfg file of your managed node:

     # ansible managed-node-01.example.com -m ansible.builtin.command -a "grep 'timeout' /boot/grub2/grub.cfg"
     managed-node-01.example.com | CHANGED | rc=0 >>
     if [ x$feature_timeout_style = xy ] ; then
       set timeout_style=menu
       set timeout=10
     # Fallback normal timeout code in case the timeout_style feature is
       set timeout=10
     if [ x$feature_timeout_style = xy ] ; then
         set timeout_style=menu
         set timeout=10
         set orig_timeout_style=${timeout_style}
         set orig_timeout=${timeout}
           # timeout_style=menu + timeout=0 avoids the countdown code keypress check
           set timeout_style=menu
           set timeout=10
           set timeout_style=hidden
           set timeout=10
     if [ x$feature_timeout_style = xy ]; then
       if [ "${menu_show_once_timeout}" ]; then
         set timeout_style=menu
         set timeout=10
         unset menu_show_once_timeout
         save_env menu_show_once_timeout

     Copy to Clipboard Toggle word wrap

Procedure

1. Create a playbook file, for example, ~/playbook.yml, with the following content:

   ---
   - name: Configuration and management of GRUB boot loader
     hosts: managed-node-01.example.com
     tasks:
       - name: Gather information about the boot loader configuration
         ansible.builtin.include_role:
           name: redhat.rhel_system_roles.bootloader
         vars:
           bootloader_gather_facts: true
   
       - name: Display the collected boot loader configuration information
         debug:
           var: bootloader_facts

   Copy to Clipboard Toggle word wrap

   For details about all variables used in the playbook, see the /usr/share/ansible/roles/rhel-system-roles.bootloader/README.md file on the control node.

2. Validate the playbook syntax:

   $ ansible-playbook --syntax-check ~/playbook.yml

   Copy to Clipboard Toggle word wrap

   Note that this command only validates the syntax and does not protect against a wrong but valid configuration.

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

   Copy to Clipboard Toggle word wrap

1. The kernel patch module is copied to the /var/lib/kpatch/ directory and registered for re-application to the kernel by systemd on next boot.
2. The kpatch module loads into the running kernel and the new functions are registered to the ftrace mechanism with a pointer to the location in memory of the new code.

Procedure

1. Optional: Check your kernel version:

   # uname -r
   5.14.0-1.el9.x86_64

   Copy to Clipboard Toggle word wrap

2. Search for a live patching package that corresponds to the version of your kernel:

   # dnf search $(uname -r)

   Copy to Clipboard Toggle word wrap

3. Install the live patching package:

   # dnf install "kpatch-patch = $(uname -r)"

   Copy to Clipboard Toggle word wrap

   The command above installs and applies the latest cumulative live patches for that specific kernel only.

   If the version of a live patching package is 1-1 or higher, the package will contain a patch module. In that case the kernel will be automatically patched during the installation of the live patching package.

   The kernel patch module is also installed into the /var/lib/kpatch/ directory to be loaded by the systemd system and service manager during the future reboots.

   Note

   An empty live patching package will be installed when there are no live patches available for a given kernel. An empty live patching package will have a kpatch_version-kpatch_release of 0-0, for example kpatch-patch-5_14_0-1-0-0.x86_64.rpm. The installation of the empty RPM subscribes the system to all future live patches for the given kernel.

Procedure

1. Optional: Check all installed kernels and the kernel you are currently running:

   # dnf list installed | grep kernel
   Updating Subscription Management repositories.
   Installed Packages
   ...
   kernel-core.x86_64            5.14.0-1.el9              @beaker-BaseOS
   kernel-core.x86_64            5.14.0-2.el9              @@commandline
   ...
   
   # uname -r
   5.14.0-2.el9.x86_64

   Copy to Clipboard Toggle word wrap

2. Install the kpatch-dnf plugin:

   # dnf install kpatch-dnf

   Copy to Clipboard Toggle word wrap

3. Enable automatic subscription to kernel live patches:

   # dnf kpatch auto
   Updating Subscription Management repositories.
   Last metadata expiration check: 1:38:21 ago on Fri 17 Sep 2021 07:29:53 AM EDT.
   Dependencies resolved.
   ==================================================
    Package                             Architecture
   ==================================================
   Installing:
    kpatch-patch-5_14_0-1               x86_64
    kpatch-patch-5_14_0-2               x86_64
   
   Transaction Summary
   ===================================================
   Install  2 Packages
   …​

   Copy to Clipboard Toggle word wrap

   This command subscribes all currently installed kernels to receiving kernel live patches. The command also installs and applies the latest cumulative live patches, if any, for all installed kernels.

   When you update the kernel, live patches are installed automatically during the new kernel installation process.

   The kernel patch module is also installed into the /var/lib/kpatch/ directory to be loaded by the systemd system and service manager during future reboots.

   Note

   An empty live patching package will be installed when there are no live patches available for a given kernel. An empty live patching package will have a kpatch_version-kpatch_release of 0-0, for example kpatch-patch-5_14_0-1-0-0.el9.x86_64.rpm. The installation of the empty RPM subscribes the system to all future live patches for the given kernel.

Procedure

1. Optional: Check all installed kernels and the kernel you are currently running:

   # dnf list installed | grep kernel
   Updating Subscription Management repositories.
   Installed Packages
   ...
   kernel-core.x86_64            5.14.0-1.el9              @beaker-BaseOS
   kernel-core.x86_64            5.14.0-2.el9              @@commandline
   ...
   
   # uname -r
   5.14.0-2.el9.x86_64

   Copy to Clipboard Toggle word wrap

2. Disable automatic subscription to kernel live patches:

   # dnf kpatch manual
   Updating Subscription Management repositories.

   Copy to Clipboard Toggle word wrap

Procedure

1. Select the live patching package.

   # dnf list installed | grep kpatch-patch
   kpatch-patch-5_14_0-1.x86_64        0-1.el9        @@commandline
   …​

   Copy to Clipboard Toggle word wrap

   The example output lists live patching packages that you installed.

2. Remove the live patching package.

   # dnf remove kpatch-patch-5_14_0-1.x86_64

   Copy to Clipboard Toggle word wrap

   When a live patching package is removed, the kernel remains patched until the next reboot, but the kernel patch module is removed from disk. On future reboot, the corresponding kernel will no longer be patched.

3. Reboot your system.

4. Verify the live patching package is removed:

   # dnf list installed | grep kpatch-patch

   Copy to Clipboard Toggle word wrap

   The command displays no output if the package has been successfully removed.

Verification

1. Verify the kernel live patching solution is disabled:

   # kpatch list
   Loaded patch modules:

   Copy to Clipboard Toggle word wrap

   The example output shows that the kernel is not patched and the live patching solution is not active because there are no patch modules that are currently loaded.

Procedure

1. Select a kernel patch module:

   # kpatch list
   Loaded patch modules:
   kpatch_5_14_0_1_0_1 [enabled]
   
   Installed patch modules:
   kpatch_5_14_0_1_0_1 (5.14.0-1.el9.x86_64)
   …​

   Copy to Clipboard Toggle word wrap

2. Uninstall the selected kernel patch module.

   # kpatch uninstall kpatch_5_14_0_1_0_1
   uninstalling kpatch_5_14_0_1_0_1 (5.14.0-1.el9.x86_64)

   Copy to Clipboard Toggle word wrap

   • Note that the uninstalled kernel patch module is still loaded:

     # kpatch list
     Loaded patch modules:
     kpatch_5_14_0_1_0_1 [enabled]
     
     Installed patch modules:
     <NO_RESULT>

     Copy to Clipboard Toggle word wrap

     When the selected module is uninstalled, the kernel remains patched until the next reboot, but the kernel patch module is removed from disk.

3. Reboot your system.

Verification

1. Verify that the kernel patch module is uninstalled:

   # kpatch list
   Loaded patch modules:
   …​

   Copy to Clipboard Toggle word wrap

   This example output shows no loaded or installed kernel patch modules, therefore the kernel is not patched and the kernel live patching solution is not active.

Procedure

1. Verify kpatch.service is enabled.

   # systemctl is-enabled kpatch.service
   enabled

   Copy to Clipboard Toggle word wrap

2. Disable kpatch.service:

   # systemctl disable kpatch.service
   Removed /etc/systemd/system/multi-user.target.wants/kpatch.service.

   Copy to Clipboard Toggle word wrap

   • Note that the applied kernel patch module is still loaded:

     # kpatch list
     Loaded patch modules:
     kpatch_5_14_0_1_0_1 [enabled]
     
     Installed patch modules:
     kpatch_5_14_0_1_0_1 (5.14.0-1.el9.x86_64)

     Copy to Clipboard Toggle word wrap
3. Reboot your system.

4. Optional: Verify the status of kpatch.service.

   # systemctl status kpatch.service
   ● kpatch.service - "Apply kpatch kernel patches"
      Loaded: loaded (/usr/lib/systemd/system/kpatch.service; disabled; vendor preset: disabled)
      Active: inactive (dead)

   Copy to Clipboard Toggle word wrap

   The example output testifies that kpatch.service is disabled. Thereby, the kernel live patching solution is not active.

5. Verify that the kernel patch module has been unloaded.

   # kpatch list
   Loaded patch modules:
   
   Installed patch modules:
   kpatch_5_14_0_1_0_1 (5.14.0-1.el9.x86_64)

   Copy to Clipboard Toggle word wrap

   The example output above shows that a kernel patch module is still installed but the kernel is not patched.

1. Console log-level, defines the lowest priority of messages printed to the console.
2. Default log-level for messages without an explicit log-level attached to them.
3. Sets the lowest possible log-level configuration for the console log-level.

4. Sets default value for the console log-level at boot time.

   Each of these values defines a different rule for handling error messages.

Procedure

1. Reinstall GRUB on the device where it is installed. For example, if sda is your device:

   # grub2-install /dev/sda

   Copy to Clipboard Toggle word wrap

2. Reboot your system for the changes to take effect:

   # reboot

   Copy to Clipboard Toggle word wrap

Procedure

1. Reinstall the grub2-efi and shim boot loader files:

   # yum reinstall grub2-efi shim

   Copy to Clipboard Toggle word wrap

2. Reboot your system for the changes to take effect:

   # reboot

   Copy to Clipboard Toggle word wrap

Procedure

1. Determine the disk partition that stores GRUB:

   # bootlist -m normal -o
   sda1

   Copy to Clipboard Toggle word wrap

2. Reinstall GRUB on the disk partition:

   # grub2-install partition

   Copy to Clipboard Toggle word wrap

   Replace partition with the identified GRUB partition, such as /dev/sda1.

3. Reboot your system for the changes to take effect:

   # reboot

   Copy to Clipboard Toggle word wrap

Procedure

1. Remove the configuration files:

   # rm /etc/grub.d/*
   # rm /etc/sysconfig/grub

   Copy to Clipboard Toggle word wrap

2. Reinstall packages.

   • On BIOS-based machines:

     # yum reinstall grub2-tools

     Copy to Clipboard Toggle word wrap

   • On UEFI-based machines:

     # yum reinstall grub2-efi shim grub2-tools grub2-common

     Copy to Clipboard Toggle word wrap

3. Rebuild the grub.cfg file for the changes to take effect.

   • On BIOS-based machines:

     # grub2-mkconfig -o /boot/grub2/grub.cfg

     Copy to Clipboard Toggle word wrap

   • On UEFI-based machines:

     # grub2-mkconfig -o /boot/grub2/grub.cfg

     Copy to Clipboard Toggle word wrap
     Warning

     The path to rebuild grub.cfg is same for both BIOS and UEFI based machines. Actual grub.cfg is present at BIOS path only. The UEFI path has a stub file that must not be modified or recreated using grub2-mkconfig command.

4. Follow Reinstalling GRUB procedure to restore GRUB on the /boot/ partition.

Procedure

1. On the Anaconda installer, click KDUMP and enable kdump:
2. In Kdump Memory Reservation, select Manual` if you must customize the memory reserve.

3. In KDUMP > Memory To Be Reserved (MB), set the required memory reserve for kdump.

   = Installing kdump on the command line

Procedure

1. Check if kdump is installed on your system:

   # rpm -q kexec-tools

   Copy to Clipboard Toggle word wrap

   Output if the package is installed:

   # kexec-tools-2.0.22-13.el9.x86_64

   Copy to Clipboard Toggle word wrap

   Output if the package is not installed:

   package kexec-tools is not installed

   Copy to Clipboard Toggle word wrap

2. Install kdump and other necessary packages:

   # dnf install kexec-tools

   Copy to Clipboard Toggle word wrap

Procedure

1. Configure the default value for crash kernel:

   # kdumpctl reset-crashkernel --kernel=ALL

   Copy to Clipboard Toggle word wrap

   When configuring the crashkernel= value, test the configuration by rebooting the system with kdump enabled. If the kdump kernel fails to boot, increase the memory size gradually to set an acceptable value.

2. To use a custom crashkernel= value:

   1. Configure the required memory reserve.

      crashkernel=192M

      Copy to Clipboard Toggle word wrap

      Optionally, you can set the amount of reserved memory to a variable depending on the total amount of installed memory by using the syntax crashkernel=<range1>:<size1>,<range2>:<size2>. For example:

      crashkernel=1G-4G:192M,2G-64G:256M

      Copy to Clipboard Toggle word wrap

      The example reserves 192 MB of memory if the total amount of system memory is 1 GB or higher and lower than 4 GB. If the total amount of memory is more than 4 GB, 256 MB is reserved for kdump.

   2. Optional: Offset the reserved memory.

      Some systems require to reserve memory with a certain fixed offset since crashkernel reservation is very early, and it wants to reserve some area for special usage. If the offset is set, the reserved memory begins there. To offset the reserved memory, use the following syntax:

      crashkernel=192M@16M

      Copy to Clipboard Toggle word wrap

      The example reserves 192 MB of memory starting at 16 MB (physical address 0x01000000). If you offset to 0 or do not specify a value, kdump offsets the reserved memory automatically. You can also offset memory when setting a variable memory reservation by specifying the offset as the last value. For example, crashkernel=1G-4G:192M,2G-64G:256M@16M.

   3. Update the boot loader configuration:

      # grubby --update-kernel ALL --args "crashkernel=<custom-value>"

      Copy to Clipboard Toggle word wrap

      The <custom-value> must contain the custom crashkernel= value that you have configured for the crash kernel.

3. Reboot for changes to take effect:

   # reboot

   Copy to Clipboard Toggle word wrap

1. Activate the sysrq key to boot into the kdump kernel:

   # echo c > /proc/sysrq-trigger

   Copy to Clipboard Toggle word wrap

   The command causes kernel to crash and reboots the kernel if required.

2. Display the /etc/kdump.conf file and check if the vmcore file is saved in the target destination.