Kerneldump crash does not work in FIPS mode

Support
1

Hi ,
When we enable FIPS mode , we see the kdump.conf getting updated and the kdump.service running.
However after we crash the server, the crashdump is not generated in the location configured.
We have the crashkernel=auto parameter in both scenarios - with FIPS enabled and without it.
In non-FIPS mode, everything is working as expected .
In FIPS-enabled mode, the crashdump is not generated in the location configured.
Additional observations:

  1. not using more memory in fips mode.
  2. The /boot dir is mounted on /
2

Hi,

This is a known issue that sometimes occurs with FIPS mode enabled. Here are some suggestions:

Try specifying a fixed value for crashkernel
Instead of crashkernel=auto, use a specific value like crashkernel=512M or higher. FIPS mode sometimes requires more memory, and the auto parameter may not allocate enough.
See: Red Hat Knowledge Base

Ensure your kdump initramfs is up-to-date
When enabling FIPS, you need to regenerate the kdump initramfs to include FIPS support:

dracut -f --kver $(uname -r)
systemctl restart kdump

Check the crash dump path and permissions
It’s recommended to use /var/crash or another dedicated directory for crash dumps, not /boot. Make sure the directory is writable and not restricted by SELinux or file system permissions.

Check the logs for errors
Please check /var/log/kdump.log and journalctl -k for any relevant error messages after the crash attempt. This can help identify if there are issues with memory reservation, kdump service startup, or permissions.

If you still experience the issue after these steps, please provide any error messages from the logs for further troubleshooting.

3

Hi ,
Just to clarify a few points regarding the crashkernel setup:
• We are using a dedicated path for crash dumps: /var/crash.
• When we mention that /boot is mounted on root, we mean that there is no separate /boot partition — it is mounted under the existing root (/) filesystem.
• We have also already tried assigning a fixed value to crashkernel, but it still doesn’t resolve the issue — the reservation doesn’t work in FIPS-enabled mode.

4

Please provide the exact error messages from dmesg or /var/log/kdump.log.
This information will help diagnose the issue further.

5

no errors in kdump.log are observed.

6

At this point, since all standard troubleshooting steps have been covered and there are no errors in the logs,
it’s possible that this is a kernel or distribution bug related to FIPS and kdump.

I recommend filing a detailed bug report with your exact system configuration, steps you’ve taken, and all relevant logs.
This will help the developers or upstream maintainers investigate the issue further.

Thank you for your patience and detailed troubleshooting.

7

Hi ,
Steps to reproduce -

  • Login to machine
  • utils fips enable
  • Crash the server using -
    echo 1 > /proc/sys/kernel/sysrq
    echo c > /proc/sysrq-trigger
  • Ideally the crashdump should be available under /var/crash
8

Hi,

Could you please provide your full reproduction steps and all related information in a single text file and attach it here?
For complex issues like this, it’s helpful to include:

  • The exact OS and kernel version (cat /etc/os-release, uname -r)
  • The value of your crashkernel parameter (is it auto or a specific size? Have you tried both?)
  • Did you regenerate the kdump initramfs after enabling FIPS? (dracut -f --kver $(uname -r))
  • The output of systemctl status kdump after booting with FIPS enabled
  • Any relevant messages from dmesg | grep -i crash and /var/log/kdump.log
  • SELinux/AppArmor status, and whether /var/crash is writable

Attaching a complete text file will make it much easier for others to review and assist.

Thank you!

9

If you are using the FIPS packages in a commercial/production environment, then you must have a TuxCare ESU license, in which case you should raise a support ticket here:

https://tuxcare.com/support-portal/

It certainly works for me - it’s actually part of the FIPS 140-3 validation process.

# systemctl enable --now kdump

# mount | grep /boot
/dev/sda2 on /boot type xfs (rw,relatime,seclabel,attr2,inode64,logbufs=8,logbsize=32k,noquota)
/dev/sda1 on /boot/efi type vfat (rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=winnt,errors=remount-ro)

# grubby --update-kernel=ALL --args="crashkernel=1G-4G:192M,4G-64G:256M,64G-:512M"

# reboot

# grubby --info=DEFAULT
index=1
kernel="/boot/vmlinuz-5.14.0-284.1101.el9_2.tuxcare.7.els15.x86_64"
args="ro console=tty0 console=ttyS0,115200 rd_NO_PLYMOUTH resume=UUID=46b58e8c-6f6b-47dc-bcb9-870368fca381 fips=1 boot=UUID=f78c94e0-f3c0-4f5b-a6a3-77da9a8b3a51 crashkernel=1G-4G:192M,4G-64G:256M,64G-:512M"
root="UUID=53a1b123-6a83-47f3-8d13-99a81b83df05"
initrd="/boot/initramfs-5.14.0-284.1101.el9_2.tuxcare.7.els15.x86_64.img"
title="AlmaLinux (5.14.0-284.1101.el9_2.tuxcare.7.els15.x86_64) 9.2 (Turquoise Kodkod)"
id="96cc82ba5ec4431f94623fdedf538f7e-5.14.0-284.1101.el9_2.tuxcare.7.els15.x86_64"

# echo 1 > /proc/sys/kernel/sysrq
# echo c > /proc/sysrq-trigger

<reboot as it's crashed>

# ls -l /var/crash/*
total 77136
-rw-------. 1 root root    89991 Jul 22 18:09 kexec-dmesg.log
-rw-------. 1 root root 78807619 Jul 22 18:09 vmcore
-rw-------. 1 root root    82874 Jul 22 18:08 vmcore-dmesg.txt
10

Hi , please find all the required details you’ve asked for:
1**) cat /etc/os-release**
NAME=“AlmaLinux”
VERSION=“8.10 (Cerulean Leopard)”
ID=“almalinux”
ID_LIKE=“rhel centos fedora”
VERSION_ID=“8.10”
PLATFORM_ID=“platform:el8”
PRETTY_NAME=“AlmaLinux 8.10 (Cerulean Leopard)”
ANSI_COLOR=“0;34”
LOGO=“fedora-logo-icon”
CPE_NAME=“cpe:/o:almalinux:almalinux:8::baseos”
HOME_URL=“https://almalinux.org/”
DOCUMENTATION_URL=“https://wiki.almalinux.org/”
BUG_REPORT_URL=“https://bugs.almalinux.org/”

ALMALINUX_MANTISBT_PROJECT=“AlmaLinux-8”
ALMALINUX_MANTISBT_PROJECT_VERSION=“8.10”
REDHAT_SUPPORT_PRODUCT=“AlmaLinux”
REDHAT_SUPPORT_PRODUCT_VERSION=“8.10”
SUPPORT_END=2029-06-01

  1. uname -r
    4.18.0-553.22.1.el8_10.x86_64

  2. The value of your crashkernel parameter, we have tried both (auto and a specific size)
    but nothing is working in fips enabled mode.

  3. Did you regenerate the kdump initramfs after enabling FIPS? – > yes already tried

  4. systemctl status kdump
    ● kdump.service - Crash recovery kernel arming
    Loaded: loaded (/usr/lib/systemd/system/kdump.service; enabled; vendor preset: enabled)
    Active: active (exited) since Wed 2025-07-23 07:32:07 UTC; 23min ago

11

Thankyou , i will try

12

8.10 is not FIPS-validated and works quite differently. Try 9.2 or 9.6 which are FIPS-validated.

13

Hi ,
can you please tell is this OS bug or not ?

14

not bug

AlmaLinux 8 is not FIPS validated by NIST.
AlmaLinux 9 is FIPS validated.

NIST
NIST1920×1080 225 KB

15

Hi ,
This is the exact error , that we are getting:
crypto/fips/fips.c:154: OpenSSL internal error: FATAL FIPS SELFTEST FAILURE
& also , if we try to add fips xfs in initramfs-kdump.img it results to //boot/.vmlinuz-.hmac error not found error
is there any way to resolve this issue by adding parameter fips=1 ?

16

Warning: /boot//.vmlinuz-.x86_64.hmac does not exist
FATAL: FIPS integrity test failed
Refusing to continue

https://issues.redhat.com/browse/RHEL-4649

Isn’t hmac necessary?
I didn’t understand how to link hmac and the kernel.

17

Hi ,
Already refer this , but its failing to detect

18

This is the limit of what I have personally found.

  1. Generating .hmac files
    In AlmaLinux 8/9 and RHEL 8/9 series, cases have been confirmed where the vmlinuz HMAC verification file is not generated in FIPS mode (AlmaLinux Bug ID 62, Red Hat Upgrades 3037431)
    Red Hat Documentation
    +12
    Red Hat Customer Portal
    +12
    Linux Global
    +12
    .

As a workaround, run the following:

sha512hmac /boot/vmlinuz-$(uname -r) > /boot/.vmlinuz-$(uname -r).hmac
This will clear the FIPS integrity test.
Oracle Docs
+3
AlmaLinux
+3
Red Hat Customer Portal
+3
.

  1. dracut-fips package and initramfs regeneration
    In the case of CentOS or RHEL installation, if dracut-fips or dracut-fips-aesni is not installed, .hmac may not be included in the initramfs and FIPS may fail to start (Linux Global)
    Unix & Linux Stack Exchange
    +6
    Linux Global
    +6
    GitHub
    +6
    .
    Check the following and rebuild:

yum install dracut-fips dracut-fips-aesni # aesni version if AES-NI is installed
dracut -f --kver $(uname -r)
systemctl restart kdump
3. Specify crashkernel= with a fixed value
crashkernel=auto may not be reserved correctly when FIPS is enabled, and is deprecated in RHEL 9 (explicit specification such as crashkernel=1G-4G:192M… is recommended)
Oracle Docs
+2
Red Hat Documentation
+2
Rocky Linux Forum
+2
.

Example:

grubby --update-kernel=ALL --args=“crashkernel=512M”
You can use kdumpctl estimate to determine the required size if necessary
Rocky Linux Forum
+4
Red Hat Documentation
+4
AlmaLinux
+4
.

  1. Check kdump.conf and restart the service
    After setting the crash dump destination and collector (core_collector), be sure to restart kdump. If you do not restart, the settings will not be reflected and kdump.conf may become empty.
    Rocky Linux Forum
    +4
    AlmaLinux
    +4
    Unix & Linux Stack Exchange
    +4
    .

systemctl restart kdump
5. Test and check the log
Perform a crash test with the following command and check whether the vmcore is saved to /var/crash normally:

echo c > /proc/sysrq-trigger
If it fails, check the following:

/var/log/kdump.log

journalctl -k

Reference site

Chapter 14. Configuring kdump on the command line | Managing, monitoring, and updating the kernel | Red Hat Enterprise Linux | 9 | Red Hat Documentation rnel?utm_source=chatgpt.com
Kdump.conf - file contents remove after trigger crash
Chapter 14. Configuring kdump on the command line | Managing, monitoring, and updating the kernel | Red Hat Enterprise Linux | 9 | Red Hat Documentation

19

hi ,
tried everything as you mentioned but nothing is working , it seems that this is bug in alma 8.10

20

AlmaLinux 8 is not FIPS validated by NIST.
Therefore, version 8 is not acceptable.
Please use Alma 9.2 or later.
This version has been validated.