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?
Look at /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.
man grubby
To see the default kernel parameters you would issue the command thus:
grubby --info=DEFAULT
or for all kernels
grubby --info=ALL
and for a specific kernel
# grubby --info=/boot/vmlinuz-5.14.0-284.18.1.el9_2.x86_64
index=2
kernel="/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"
root="UUID=7277c17d-6897-497b-9390-1153c9bff018"
initrd="/boot/initramfs-5.14.0-284.18.1.el9_2.x86_64.img $tuned_initrd"
title="Rocky Linux (5.14.0-284.18.1.el9_2.x86_64) 9.2 (Blue Onyx)"
id="ba3fd5ffa1514c2bb468fa289f69faa0-5.14.0-284.18.1.el9_2.x86_64"
Grubby modifies the boot loader definitions in /boot/loader/entries/
and
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
insmod blscfg
blscfg
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.
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.