I used to be able to run grub2-editenv list command in order to see what options I am booting with. Can this not be done anymore? I.e. I add audit=1 to /etc/default/grub, run grub2-mkconfig, and I do not see. I also ran command that adds it to /etc/kernel/cmdline file.
This all shows up when I cat /proc/cmdline. I need to verify these options are set.
Which version? el8 or el9?
/boot/loader/entries/. The el8 entries do have
options $kernelopts $tuned_params while the el9 entries have kernelopts explicitly written there (by grub2-mkconfig or install of kernel package).
The “grubby” tool is what you use to modify the kernel parameters in RL9.
To see the default kernel parameters you would issue the command thus:
or for all kernels
and for a specific kernel
# grubby --info=/boot/vmlinuz-5.14.0-284.18.1.el9_2.x86_64
args="ro resume=UUID=71da8f2b-df89-4d45-b763-9768884fea6f selinux=0 $tuned_params crashkernel=1G-4G:192M,4G-64G:256M,64G-:512M"
title="Rocky Linux (5.14.0-284.18.1.el9_2.x86_64) 9.2 (Blue Onyx)"
Grubby modifies the boot loader definitions in /boot/loader/entries/
creates the file /etc/kernel/cmdline
that is used to populate your parameters upon new kernel installs.
We are using el9. We are still trying to get STIGs for el9 so was trying to figure out how to prove we are setting these and that the options are actually active.
Checking the actual config Grub’s going to get is trickier now with BLS – you have to believe that the
in /boot/grub2/grub.cfg is going to produce what you think it should from /boot/loader/entries/*.conf. If it’s showing up in /proc/cmdline after you reboot, though, that confirms it’s making it that far.
Ultimately however the way of verifying that the kernel actually did something you requested on its command-line is going to be parameter-specific (for example, the kernel may reject an swiotlb= setting for being too large, so even though what you specified shows up in /proc/cmdline it’s not actually in effect). In your case, is audit=1 getting you anything new in dmesg that confirms it’s been enabled? I’m not super familiar with audit=, but it sounds like a full test might involve disabling auditd, rebooting, trying some loggable event, and ensuring auditd receives the log entry when started.