0% found this document useful (0 votes)
419 views

Troubleshooting Crowd Strike Falcon Linux Agents

The document provides troubleshooting steps for resolving common issues with CrowdStrike Falcon Linux agents, including verifying dependencies are installed, that the sensor is running, and sensor files exist. It also describes how to check sensor connectivity and collect diagnostic information.

Uploaded by

AdhePoethra
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
419 views

Troubleshooting Crowd Strike Falcon Linux Agents

The document provides troubleshooting steps for resolving common issues with CrowdStrike Falcon Linux agents, including verifying dependencies are installed, that the sensor is running, and sensor files exist. It also describes how to check sensor connectivity and collect diagnostic information.

Uploaded by

AdhePoethra
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 18

Troubleshooting CrowdStrike Falcon Linux Agents

Priority P2 On this page:

Purpose Managing installation and communication


problems with CrowdStrike Falcon agent Troubleshooting Sensor Installation
Ubuntu installation fails: "Dependent Packages are not Installed"
Audience CIO, IT Manager, ISO Example Installation Failure: Azure Ubuntu 20.04
SLES installation fails: "Nothing Provides Openssl"
Release Date November 2022 Verifying that dependencies are Installed
Troubleshooting general sensor issues
Control PREVENT DETECT
Verifying that the sensor is running
CORRECT INVESTIGATE
Verifying the sensor files on disk
Providing troubleshooting info to Support
Document status RELEASED
Logs
Reduced functionality mode (RFM)
Classification INTERNAL
What happens to sensors in RFM?
How can I tell if my sensor's in RFM?
Compliance MANDATORY
Returning an RFM sensor to full functionality
Oracle Linux Kernel
Architect
Centos 8 - Stream
Additional Steps to Resolve RFM for systems with SecureBoot enabled
How to Check if Secure Boot is Enabled.
How to downgrade the Kernel
Debian Example (Debian 11)
Redhat Example (TBC)

Troubleshooting Sensor Installation

Ubuntu installation fails: "Dependent Packages are not Installed"


Issue: Your Ubuntu installation fails with an error that "dependent packages are not installed."

Solution: Use this command to install the dependent packages:


$ apt-get -f install
Example Installation Failure: Azure Ubuntu 20.04
This is an example of an installation failure for Ubuntu:

$ sudo dpkg --install falcon-sensor_*.deb


Selecting previously unselected package falcon-sensor.
(Reading database ... 58634 files and directories currently
installed.) Preparing to unpack falcon-sensor_6.47.0-
14408_amd64.deb ...
Unpacking falcon-sensor (6.47.0-14408) ...
dpkg: dependency problems prevent configuration of falcon-sensor:
falcon-sensor depends on libnl1 | libnl-3-200; however:
Package libnl1 is not installed.
Package libnl-3-200 is not installed.
falcon-sensor depends on libnl1 | libnl-genl-3-200; however:
Package libnl1 is not installed.
Package libnl-genl-3-200 is not installed.

dpkg: error processing package falcon-sensor (--install):


dependency problems - leaving unconfigured
Processing triggers for libc-bin (2.31-0ubuntu9.9) ...
Processing triggers for systemd (245.4-4ubuntu3.19) ...
Errors were encountered while processing:
falcon-sensor
$

Another approach to resolve this...

sudo apt remove falcon-sensor


sudo apt-get install libnl-3-200 libnl-genl-3-200
sudo dpkg --install falcon-sensor_*.deb
sudo systemctl stop falcon-sensor
sudo systemctl start falcon-sensor

SLES installation fails: "Nothing Provides Openssl"


Issue: Your SLES installation fails with an error that nothing provides openssl1 >= 1.0.1. This is most commonly caused by a SLES version that doesn't include a modern OpenSSL implementation.

Solution: Enable the SLES 11 security module:


$ sudo zypper mr --enable SLE11-Security-Module

Run the sensor installer again.


Verifying that dependencies are Installed
Issue: Your installation fails with an error message about missing dependencies of libssl, libc, or libcrypto.

--> Missing Dependency: libssl.so.10()(64bit) is needed by package falcon-sensor-1.0.3-1.e16x86_64 (/falcon-sensor-1.0.3-1.e16.x86_64)


Error Missing Dependency: libc.so.6(GLIBC_2.7)(64bit) is needed by package falcon-sensor-1.0.3-1.e16x86_64 (/falcon-sensor-1.0.3-1.e16.x86_64)
Error Missing Dependency: libcrypto.so.10()(64bit) is needed by package falcon-sensor-1.0.3-1.e16x86_64 (/falcon-sensor-1.0.3-1.e16.x86_64)

Solution: Install a supported version of OpenSSL.

Troubleshooting general sensor issues

Verify kernel compatibility


For hosts with the sensor already installed, verify kernel compatibility by checking RFM status. Run this command on the host:
sudo /opt/CrowdStrike/falconctl -g --rfm-state

For more info about RFM status, see "Appendix: Reduced Functionality Mode (RFM)" below.

Verifying that the sensor is running


1. Check running processes to verify the Falcon sensor is running:
ps -e | grep -e falcon-sensor
2. Check kernel modules to verify the Falcon sensor's kernel modules are running:
lsmod | grep falcon
3. Check the Falcon sensor's configurable options:
sudo /opt/CrowdStrike/falconctl -g GET_OPTIONS
GET_OPTIONS parameters:
--cid for CustomerId
--aid for AgentId
--apd for App Proxy Disable
--aph for App Proxy Host
--app for App Proxy Port
--rfm-state for indicating whether the sensor is in Reduced Functionality Mode
--rfm-reason to determine reason for sensor running in Reduced Functionality Mode
--trace for determining the configured trace level
--feature to determine the configured sensor feature flags
--metadata-query to determine the configured sensor cloud provider metadata query flags
--version for version of sensor currently running
--message-log for logging messages to disk
--billing to configure the sensor billing type
--tags for sensor grouping tags
--provisioning-token for Provisioning Token
--systags for system tags currently applied to a running sensor

The sensor requires these runtime services:

network
systemd
local-fs
sysinit
multi-user
shutdown

Verifying the sensor files on disk


If the sensor is not running, verify that the sensor's application files exist on your host:

$ sudo ls -al /opt/CrowdStrike /opt/CrowdStrike/falcon-sensor

This should be a symlink to either:

the original sensor installation at /opt/CrowdStrike/falcon-sensor


a sensor update package with a release build number, such as /opt/CrowdStrike/falcon-sensor3000

Verifying the sensor is connected to the CrowdStrike cloud


You can verify that the host is connected to the cloud using Planisphere or a command line on the host.

Planisphere: If a device is communicating with the CrowdStrike Cloud, Planisphere will collect information about that device on its regular polling of the CrowdStrike service. You can see the timing of the
last and next polling on the Planisphere Data Sources tab(link is external). You can see the specific information for your device on the device's Details tab.
Host: Enter the following command in a terminal:

$ sudo netstat -tapn | grep falcon


If the Falcon sensor is communicating with the cloud, you'll see output like this:
tcp 0 0 192.0.2.176:35382 ec2-54-148-96-12:443
ESTABLISHED 3228/falcon-sensor

Providing troubleshooting info to Support


If OIT needs to forward a sensor issue to CrowdStrike Support, you will need to collect data using the falcon-diagnostic script.

Logs

Logs are stored within your host's syslog. The syslog locations vary but are specified in /etc/syslog.conf or rsyslog.conf, with these being the most common:

/var/log/messages
/var/log/syslog
/var/log/rsyslog
/var/log/daemon

grep for the string falcon for sensor logs, similar to this example:

sudo grep falcon /var/log/messages | tail -n 100

Logs are kept according to your host's log rotation settings.

Reduced functionality mode (RFM)


Reduced functionality mode (RFM) is a safe mode for the sensor that prevents compatibility issues if the host’s kernel is unsupported by the sensor. Both Windows and Linux sensors can enter RFM, but RFM
behaves differently on each platform. RFM is a protective state to prevent damage to incompatible hosts.

Hosts in RFM are unprotected by Falcon. When installing the sensor and upgrading hosts, ensure that kernels are compatible. Check regularly to verify your hosts aren’t in RFM.

A sensor enters RFM when it’s installed on a host that has an incompatible kernel on a supported Linux distro. Sensors can enter RFM if their kernels are updated to an unsupported kernel version.

What happens to sensors in RFM?


Linux sensors in RFM do very little, due to their strong dependency on the host's kernel. They don’t have detections or process execution events, but continue sending SensorHeartBeat events to indicate that a
sensor is installed on the host.

How can I tell if my sensor's in RFM?


You can run the following command in terminal to verify RFM status:

/opt/CrowdStrike/falconctl -g --rfm-state
/opt/CrowdStrike/falconctl -g --rfm-reason

Returning an RFM sensor to full functionality


Upgrade the sensor to a version that supports your installed kernel, or change the host’s kernel to one supported by the sensor. While newly released long-term support (LTS) kernels for supported distros aren’t
immediately compatible with the sensor, we add support as quickly as possible.

To prevent existing sensors from entering RFM, CrowdStrike recommends disabling automatic kernel updates and upgrading your kernel when it is supported by the Falcon sensor. Consult your distro’s support
documentation for pinning the existing kernel or configuring regular updates to leave the existing kernel in place.

Oracle Linux Kernel


Administrators should switch to Red Hat Compatible Kernel, also known as Unbreakable Enterprise Kernel

sudo yum install kernel-uek


Reboot and with a supported kernel running, the system is fully protected.

Centos 8 - Stream
The last supported snapshot of CentOS supported by Falcon was 8.5, the new continuous updated Stream has unsupported kernels, but protection can be restored by migrating to the elrepo kernel.

Risk Assessment

You will need to disable secureboot as elrepo kernels are not signed, please discuss with your security officer, this is approach should be a temporary workaround as you should migrate to a supported
Linux distribution.

To setup the elrepo repo, perform the following:

sudo rpm --import https://www.elrepo.org/RPM-GPG-KEY-elrepo.org


sudo yum install https://www.elrepo.org/elrepo-release-8.el8.elrepo.noarch.rpm
sudo yum config-manager --enable elrepo-kernel

At the time of writing, the latest kernel supported by Falcon is 5.4.229-1.el8.elrepo, search the available kernels like this:
$ sudo yum list --showduplicates kernel-* | grep 5.4
kernel-lt.x86_64 5.4.229-1.el8.elrepo elrepo-kernel
kernel-lt.x86_64 5.4.230-1.el8.elrepo elrepo-kernel
kernel-lt-core.x86_64 5.4.229-1.el8.elrepo elrepo-kernel
kernel-lt-core.x86_64 5.4.230-1.el8.elrepo elrepo-kernel
kernel-lt-devel.x86_64 5.4.229-1.el8.elrepo elrepo-kernel
kernel-lt-devel.x86_64 5.4.230-1.el8.elrepo elrepo-kernel
kernel-lt-doc.noarch 5.4.229-1.el8.elrepo elrepo-kernel
kernel-lt-doc.noarch 5.4.230-1.el8.elrepo elrepo-kernel
kernel-lt-headers.x86_64 5.4.229-1.el8.elrepo elrepo-kernel
kernel-lt-headers.x86_64 5.4.230-1.el8.elrepo elrepo-kernel
kernel-lt-modules.x86_64 5.4.229-1.el8.elrepo elrepo-kernel
kernel-lt-modules.x86_64 5.4.230-1.el8.elrepo elrepo-kernel
kernel-lt-modules-extra.x86_64 5.4.229-1.el8.elrepo elrepo-kernel
kernel-lt-modules-extra.x86_64 5.4.230-1.el8.elrepo elrepo-kernel
kernel-lt-tools.x86_64 5.4.229-1.el8.elrepo elrepo-kernel
kernel-lt-tools.x86_64 5.4.230-1.el8.elrepo elrepo-kernel
kernel-lt-tools-libs.x86_64 5.4.229-1.el8.elrepo elrepo-kernel
kernel-lt-tools-libs.x86_64 5.4.230-1.el8.elrepo elrepo-kernel
kernel-lt-tools-libs-devel.x86_64 5.4.229-1.el8.elrepo elrepo-kernel
kernel-lt-tools-libs-devel.x86_64 5.4.230-1.el8.elrepo elrepo-kernel
$

Here we see the latest is 230, but that's not supported by Falcon, so we need to install 229:

$ sudo yum install kernel-lt.x86_64-5.4.229-1.el8.elrepo


[13/1583]Last metadata expiration check: 0:03:59 ago on Fri Jan 27 05:00:46 2023.
No match for argument: kernel-lt.x86_64-5.4.229-1.el8.elrepo
Error: Unable to find a match: kernel-lt.x86_64-5.4.229-1.el8.elrepo
[nick@hyper-centos-nick-bettison ~]$ sudo yum install kernel-lt-5.4.229-1.el8.
elrepo
Last metadata expiration check: 0:04:13 ago on Fri Jan 27 05:00:46 2023.
Dependencies resolved.
================================================================================================================================================================
===========
Package
Architecture Version Repository Size
================================================================================================================================================================
===========
Installing:
kernel-lt x86_64 5.4.229-1.el8.elrepo elrepo-
kernel 77 k
Installing dependencies:
kernel-lt-core x86_64 5.4.229-1.el8.elrepo elrepo-
kernel 28 M
kernel-lt-modules x86_64 5.4.229-1.el8.elrepo elrepo-
kernel 25 M

Transaction Summary
================================================================================================================================================================
===========
Install 3 Packages

Total download size: 53 M


Installed size: 87 M
Is this ok [y/N]: y
Downloading Packages:
(1/3): kernel-lt-5.4.229-1.el8.elrepo.x86_64.rpm 357 kB/s | 77
kB 00:00
(2/3): kernel-lt-modules-5.4.229-1.el8.elrepo.x86_64.rpm 3.6 MB/s | 25
MB 00:06
(3/3): kernel-lt-core-5.4.229-1.el8.elrepo.x86_64.rpm 2.0 MB/s | 28
MB 00:14
----------------------------------------------------------------------------------------------------------------------------------------------------------------
-----------
Total 3.7 MB/s | 53
MB 00:14
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Running transaction
Preparing
:
1/1 Installing : kernel-lt-core-5.4.229-1.el8.elrepo.
x86_64
1/3 Running scriptlet: kernel-lt-core-5.4.229-1.el8.elrepo.
x86_64
1/3 Installing : kernel-lt-modules-5.4.229-1.el8.elrepo.
x86_64
2/3 Running scriptlet: kernel-lt-modules-5.4.229-1.el8.elrepo.
x86_64
2/3 Installing : kernel-lt-5.4.229-1.el8.elrepo.x86_64
Running scriptlet: kernel-lt-core-5.4.229-1.el8.elrepo.
x86_64
3/3 Running scriptlet: kernel-lt-5.4.229-1.el8.elrepo.
x86_64
3/3
Verifying : kernel-lt-5.4.229-1.el8.elrepo.
x86_64
1/3 Verifying : kernel-lt-core-5.4.229-1.el8.elrepo.
x86_64
2/3 Verifying : kernel-lt-modules-5.4.229-1.el8.elrepo.
x86_64
3/3
Installed:
kernel-lt-5.4.229-1.el8.elrepo.x86_64 kernel-lt-core-5.4.229-1.el8.elrepo.x86_64 kernel-lt-modules-5.4.229-1.el8.elrepo.x86_64

Complete!
$

Reboot and with a supported kernel running, the system is fully protected.

Additional Steps to Resolve RFM for systems with SecureBoot enabled

1. Copy Falcon_Linux_Sensor_code_signing_certificate_DER_2022.cer to the impacted Linux host.


a. If you are running an older LTS kernel, you may need Falcon_Linux_Sensor_code_signing_certificate_DER_2021.cer
b. If you are running a really, really old Kernel your may need Falcon_Linux_Sensor_code_signing_certificate_DER_2018.cer
c. You can import multiple certificates, but you have to do it one at a time, rebooting each time and completing the MOK management steps below.
2. Install mokutil
a. RPM/Redhat based Systems (CentOS/Rocky/Oracle/Alma/etc) - sudo yum install mokutil
b. APT/Debian based Systems (Ubuntu) - sudo apt-get install mokutil
3. Import the key into the kernel: sudo mokutil --import Falcon_Linux_Sensor_code_signing_certificate_DER_2022.cer
a. You will be asked for a password, make one up, remember it, you will need to type it in 5mins.
4. You will need to be on a Console, not ssh for the next step.
5. Reboot
6. The Following will appear during boot on the Console.
Press Any Key to enter MOK Screen. Select Enrol MOK (press enter)

IF you miss it, you will need to re-run the mokutil import command again, and reboot!
Select Yes (press enter) Type in the password you created at step 3

After booting, you can verify the key has loaded into the Kernel:

$ sudo cat /proc/keys | grep crowdstrike


2413df63 I------ 1 perm 1f010000 0 0 asymmetri CrowdStrike, Inc.: www.crowdstrike.com: ce0b0b3c035bdc963a4fdbbaeab503bbd098ddd2: X509.rsa d098ddd2
[]
$

If you have imported multiple certs for LTS it would look like this:

$ sudo cat /proc/keys | grep crowdstrike


1d5ae47f I------ 1 perm 1f010000 0 0 asymmetri CrowdStrike, Inc.: www.crowdstrike.com: ce0b0b3c035bdc963a4fdbbaeab503bbd098ddd2: X509.rsa d098ddd2
[]
29d144dc I------ 1 perm 1f010000 0 0 asymmetri CrowdStrike, Inc.: www.crowdstrike.com: 8e888ab6eb027b7fd01a71d62623b8eb1a399c62: X509.rsa 1a399c62
[]
$
RFM should now be resolved.

How to Check if Secure Boot is Enabled.

$ sudo mokutil --sb-state


SecureBoot enabled
$

How to downgrade the Kernel


Sometime the linux distribution's kernel is too new for Crowdstrike falcon, and it might be necessary to roll back.

Risk Assessment

If you have upgraded the kernel to resolve a security isssue or to fix a fault and found your system is now unprotected (in RFM) please discuss the risks with your Security Officer.

Debian Example (Debian 11)


At time of writing a fresh install of Debian 11 is provided with 5.10.0-20 series of kernels, and upgrading to the latest is 5.10.0-21 however falcon is only ready for the 5.10.0-19 series.

This output shows the latest kernel in RFM mode.


$ uname -a
Linux debian 5.10.0-21-amd64 #1 SMP Debian 5.10.162-1 (2023-01-21) x86_64 GNU/Linux
$ sudo /opt/CrowdStrike/falconctl -g --version;sudo /opt/CrowdStrike/falconctl -g --rfm-state;sudo /opt/CrowdStrike/falconctl -g --rfm-reason
version = 6.49.14604.0
rfm-state=true.

Use apt search kernel command with grep to find the available packages

$ sudo apt search kernel | grep 5.10.0-19

WARNING: apt does not have a stable CLI interface. Use with caution in scripts.

linux-headers-5.10.0-19-amd64/stable-security 5.10.149-2
amd64
Header files for Linux 5.10.0-19-amd64
linux-headers-5.10.0-19-cloud-amd64/stable-security 5.10.149-2 amd64
Header files for Linux 5.10.0-19-cloud-amd64
linux-headers-5.10.0-19-common/stable-security 5.10.149-2 all
Common header files for Linux 5.10.0-19
linux-headers-5.10.0-19-common-rt/stable-security 5.10.149-2 all
Common header files for Linux 5.10.0-19-rt
linux-headers-5.10.0-19-rt-amd64/stable-security 5.10.149-2 amd64
Header files for Linux 5.10.0-19-rt-amd64
linux-image-5.10.0-19-amd64/stable-security 5.10.149-2 amd64
linux-image-5.10.0-19-amd64-dbg/stable-security 5.10.149-2 amd64
Debug symbols for linux-image-5.10.0-19-amd64
linux-image-5.10.0-19-amd64-unsigned/stable-security 5.10.149-2 amd64
linux-image-5.10.0-19-cloud-amd64/stable-security 5.10.149-2 amd64
linux-image-5.10.0-19-cloud-amd64-dbg/stable-security 5.10.149-2 amd64
Debug symbols for linux-image-5.10.0-19-cloud-amd64
linux-image-5.10.0-19-cloud-amd64-unsigned/stable-security 5.10.149-2 amd64
linux-image-5.10.0-19-rt-amd64/stable-security 5.10.149-2 amd64
linux-image-5.10.0-19-rt-amd64-dbg/stable-security 5.10.149-2 amd64
Debug symbols for linux-image-5.10.0-19-rt-amd64
linux-image-5.10.0-19-rt-amd64-unsigned/stable-security 5.10.149-2 amd64
linux-support-5.10.0-19/stable-security 5.10.149-2 all
$
As we want the 5.10.0-19 series, we run apt install like this...

$ sudo apt install linux-image-5.10.0-19-amd64


Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Suggested packages:
linux-doc-5.10 debian-kernel-handbook
The following NEW packages will be installed:
linux-image-5.10.0-19-amd64
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 55.5 MB of archives.
After this operation, 318 MB of additional disk space will be used.
Get:1 http://security.debian.org/debian-security bullseye-security/main amd64 linux-image-5.10.0-19-amd64 amd64 5.10.149-2 [55.5 MB]
Fetched 55.5 MB in 26s (2,130 kB
/s)
Selecting previously unselected package linux-image-5.10.0-19-amd64.
(Reading database ... 33505 files and directories currently installed.)
Preparing to unpack .../linux-image-5.10.0-19-amd64_5.10.149-2_amd64.deb ...
Unpacking linux-image-5.10.0-19-amd64 (5.10.149-2) ...
Setting up linux-image-5.10.0-19-amd64 (5.10.149-2) ...
I: /vmlinuz.old is now a symlink to boot/vmlinuz-5.10.0-21-amd64
I: /initrd.img.old is now a symlink to boot/initrd.img-5.10.0-21-amd64
I: /vmlinuz is now a symlink to boot/vmlinuz-5.10.0-19-amd64
I: /initrd.img is now a symlink to boot/initrd.img-5.10.0-19-amd64
/etc/kernel/postinst.d/initramfs-tools:
update-initramfs: Generating /boot/initrd.img-5.10.0-19-amd64
/etc/kernel/postinst.d/zz-update-grub:
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-5.10.0-21-amd64
Found initrd image: /boot/initrd.img-5.10.0-21-amd64
Found linux image: /boot/vmlinuz-5.10.0-20-amd64
Found initrd image: /boot/initrd.img-5.10.0-20-amd64
Found linux image: /boot/vmlinuz-5.10.0-19-amd64
Found initrd image: /boot/initrd.img-5.10.0-19-amd64
Warning: os-prober will be executed to detect other bootable partitions.
Its output will be used to detect bootable binaries on them and create new boot entries.
Adding boot menu entry for UEFI Firmware Settings ...
done
$

Now, reboot into the older kernel. By default most Linux systems boot into the newest kernel, therefore on the console you will need to select the older one in Grub, for debian that's under the "advanced" menu.
Once in the new kernel, you can remove the newer ones so that every reboot is into this old kernel, my system had both "20" & "21" installed, therefore was removed like this.

$ sudo apt remove linux-image-5.10.0-20-amd64 linux-image-5.10.0-21-amd64


Reading package lists...
Done
Building dependency tree...
Done
Reading state information...
Done
The following packages will be
REMOVED:
linux-image-5.10.0-20-amd64 linux-image-5.10.0-21-amd64 linux-image-
amd64
0 upgraded, 0 newly installed, 3 to remove and 0 not
upgraded.
After this operation, 635 MB disk space will be
freed.
Do you want to continue? [Y/n]
y
(Reading database ... 38275 files and directories currently
installed.)
Removing linux-image-amd64 (5.10.162-1)
...
Removing linux-image-5.10.0-20-amd64 (5.10.158-2)
...
/etc/kernel/postrm.d/initramfs-
tools:
update-initramfs: Deleting /boot/initrd.img-5.10.0-20-
amd64
/etc/kernel/postrm.d/zz-update-
grub:
Generating grub configuration file
...
Found linux image: /boot/vmlinuz-5.10.0-21-
amd64
Found initrd image: /boot/initrd.img-5.10.0-21-
amd64
Found linux image: /boot/vmlinuz-5.10.0-19-
amd64
Found initrd image: /boot/initrd.img-5.10.0-19-
amd64
Warning: os-prober will be executed to detect other bootable
partitions.
Its output will be used to detect bootable binaries on them and create new boot
entries.
Adding boot menu entry for UEFI Firmware Settings
...
done

Removing linux-image-5.10.0-21-amd64 (5.10.162-1)


...
I: /vmlinuz.old is now a symlink to boot/vmlinuz-5.10.0-19-
amd64
I: /initrd.img.old is now a symlink to boot/initrd.img-5.10.0-19-
amd64
/etc/kernel/postrm.d/initramfs-
tools:
update-initramfs: Deleting /boot/initrd.img-5.10.0-21-
amd64
/etc/kernel/postrm.d/zz-update-
grub:
Generating grub configuration file
...
Found linux image: /boot/vmlinuz-5.10.0-19-
amd64
Found initrd image: /boot/initrd.img-5.10.0-19-
amd64
Warning: os-prober will be executed to detect other bootable
partitions.
Its output will be used to detect bootable binaries on them and create new boot
entries.
Adding boot menu entry for UEFI Firmware Settings
...
done

If you reboot again, you should be back into the old kernel, and in this example RFM has been resolved.

$ uname -a
Linux debian 5.10.0-19-amd64 #1 SMP Debian 5.10.149-2 (2022-10-21) x86_64 GNU/Linux
$ sudo /opt/CrowdStrike/falconctl -g --version;sudo /opt/CrowdStrike/falconctl -g --rfm-state;sudo /opt/CrowdStrike/falconctl -g --rfm-reason
version = 6.49.14604.0
rfm-state=false.

Redhat Example (TBC)


TBC

You might also like