Lost hibernation and suspend functions with new kernel

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.

Thanks a lot for your ideas,
Francesco

Disabling hibernation is a “feature” of kernel_lockdown.

As far as I can tell the only way to disable this is to either set up an encrypted swap file or disable secure boot altogether.

The first method might work, the second will probably work.

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?

Maybe this article would be of interest.

I just checked the contents of /sys/kernel/security/lockdown on this Rocky 8.9 system and it tells me this:

$ cat /sys/kernel/security/lockdown
[none] integrity

Which is interesting. I’ve never looked at this before at all.

I think it’s the first time it’s been enabled by default.

As shown above it seems to exist in some form in Rocky 8.9 but it doesn’t appear to be doing anything.

this is what I get:

[francesco@localhost ~]$ cat /sys/kernel/security/lockdown
none [integrity] confidentiality

I should try to set it to none, but

[root@localhost ~]# sysctl kernel.security.lockdown=none
sysctl: cannot stat /proc/sys/kernel/security/lockdown: No such file or directory

What is your grub comandline?

I’m sorry, but what do you mean? How can I check that for you?

The easiest way is
cat /proc/cmdline

Right, this what I get:

[root@localhost ~]#  cat /proc/cmdline
BOOT_IMAGE=(hd0,gpt2)/vmlinuz-5.14.0-362.8.1.el9_3.x86_64 root=/dev/mapper/rl_localhost--live-root ro crashkernel=1G-4G:192M,4G-64G:256M,64G-:512M resume=/dev/mapper/rl_localhost--live-swap rd.lvm.lv=rl_localhost-live/root rd.lvm.lv=rl_localhost-live/swap rhgb quiet

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.

Which seems insane.

I have tried, but I only get:

[root@localhost ~]# sysctl kernel.lockdown=0
sysctl: cannot stat /proc/sys/kernel/lockdown: No such file or directory

If so, what does

cat /sys/kernel/security/lockdown

show you after that?
[/quote]

This is what I get:

[francesco@localhost ~]$ cat /sys/kernel/security/lockdown
none [integrity] confidentiality

even if I’m now using

[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.

I did try to disable secure boot, and even UEFI - going back to legacy boot - but that didn’t resolve the problem.

I think that I’ll try to install a maintained kernel from the Community Enterprise Linux Repository, and see how it goes.

In any case, that you very much for your help, @FrankCox !

Right, I’ve installed the kernel-lt (6.13) from ELRepo and I can suspend the laptop all right.

I guess that’s because here, lockdown is set on none:

[root@localhost ~]# cat /sys/kernel/security/lockdown
[none] integrity confidentiality

Maybe one day I’ll be able to come back to the official kernel… who knows?

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.