After upgrading from Rocky Linux 9.2 to 9.3 I’ve completely lost the suspend and the hibernation functions. That’s a real shame because before, with the older kernel, I’d reached an uptime of 36 days with my laptop…
In the logs I see, for example:
integrity: Problem loading X.509 certificate -126
and:
Lockdown: systemd-logind: hibernation is restricted; see man kernel_lockdown.7
but I wonder whether they even concern my problem or not…
When I manage to boot with the older kernel (and that’s not so easy, since I don’t see a menu at boot time!), the problem disappear.
Thank @FrankCox . I did try to disable secure boot in UEFI but nothing changed, and I wouldn’t know where to start to encrypt my swap!
It is strange though that I seem to be the only one hit by this: am I the only fool using Rocky on a laptop? Has this kernel_lockdown option appeared only in the newer 5.14.0-362.8.1.el9_3.x86_64 kernel?
Well that’s interesting. Apparently this lockdown thing doesn’t work the way I thought it did. Which goes to show how far I get when I make assumptions.
I’ve never encountered this before so this is a whole new learning experience.
Have you tried
sysctl kernel.lockdown=0
If so, what does
cat /sys/kernel/security/lockdown
show you after that?
Furthermore, I just found this:
Which contains this bit of information:
“Contact hardware vendor to disable Secure Boot in the server BIOS. There is no other way to disable the feature.”
If that means what it says then it appears the only way to disable the kernel lockdown is to disable the secure boot altogether.
[francesco@localhost ~]$ uname -a
Linux localhost.localdomain 5.14.0-284.30.1.el9_2.x86_64 #1 SMP PREEMPT_DYNAMIC Sat Sep 16 09:55:41 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
from Rocky Linux 9.2 and I can perform a suspend without any issue!
Shall I try to install another, supported (since this one it isn’t), kernel?
It seems somehow relevant to me that /sys/kernel/security/lockdown exists but /proc/sys/kernel/lockdown doesn’t, even though that’s apparently what the sysctl command is trying to use/change.
If /proc/sys/kernel/lockdown doesn’t exist, why is sysctl looking for it?
/proc/sys/kernel/lockdown doesn’t exist on my Rocky 8.9 system either so it’s not something that just disappeared.
Unfortunately I can’t tell you what any of this means. My best guess is that it’s either a bug in sysctl or whatever sysctl is using to determine what file to call, or someone upstream decided to yank that functionality away and didn’t update sysctl to remove it completely.
None of which actually solves your problem.
In accordance with the last link I posted above, I suggest that you disable secure boot completely and then you will be able to use the latest kernel. I think.
This seems like telling someone who wants to install an air conditioner that he’ll have to smash all of the glass out of the windows in his house first.
Someone must think this is a good idea but I really can’t see it.