With installation on non-encrypted disk, UEFI install, Secure Boot Enabled,
Suspend action caused suspend to ram status. Suspend to disk not possible.
After LUKS encryption, suspend does not result in flashing led and full restart is made, requiring entry of disk passphrase in addition to login username/password.
IS this NORMAL? or can settings be changed to allow suspend to RAM instead?
How much ram do you have? How large is the swap on disk?
You are aware, I hope, that unless you tell fedora otherwise it only creates a 4G zram swap in memory and no swap on disk. Without the on-disk swap at least as large as your RAM you cannot suspend to disk nor hibernate.
Lack of adequate swap space can certainly prevent suspend to disk as you mention with the unencrypted drive. It may also cause the immediate restart when encrypted due to the failure to suspend.
From Fedora 33 IMHO if secure boot is set, then suspend to DISK is disabled. But suspend to RAM should work. Why is swap space on disk needed to enable suspend to RAM?
I have two machines, first is older, an Intel i5(?) quad core dual thread, 8Gb RAM, 1TB Magnetic hdd. This is dual boot with Windows 10, so Windows esp partition mounted to /boot/efi a /boot partition a swap partition 16GB and about 400GB of / on btrfs file system, and default zram swap from Anaconda installation. Zram has higher priority than disk partition. This system will NOT suspend to disk, message to effect that suspend to disk is prevented by Locking out. I think this is by design, I am not interested in going around the designers intentions… My IT department just barely let me install fedora and insists on secure boot active. (Also insists on frequent BIOS updates, my mfr only publishes BIOS upgrades on Windows, which is why I dual boot, only ever use Windows to upgrade BIOS.)
Second machine is brand new and is the one in question: AMD Ryzen Pro 7 processor, 64GB RAM, 1 TB SSD, also dual booting with Windows. Windows made esp partition is mounted to /boot/efi. /boot partition and a then / partition is mounted to btrfs. NO swap partition, but standard zram swap size. I left about 60 GB of free space at the last install, I’ll use mkswap and create swap partition kind of 1X RAM and see what happens. Again with secure boot enabled swap to DISK is not expected to function by design. For swap to zram, that is supposed to be compressed somehow, perhaps adding more zram space is needed. Guessing 0.5X Ram? Suggestions anyone? Would 4 or 5 zram swaps be better than just one big one at 30 GB. (Thats 50% of ram devoted to swap, sounds excessive to me as I type this, is there a better way?)
AHH yes, if only I could hibernate to disk instead of suspend to RAM…
My cybersecurity audit team took this manpage to heart: “man kernel_lockdown.7”
A feature of the audit is to demonstrate every person on staff is diligently alert to security issues, laptops that actually hibernate trigger lots of scoldings, cleaning toilets with toothbrushes, and other undesirable disciplines.
Adding 67GB swap partition helped a little (it is unencrypted will need to encrypt it for long term use.) Manually adding line into /etc/fstab also helped a little more but it still does NOT enter “blinking led” suspended to ram status. And won’t recognize space-bar or touchpad actions to bring up login / lockscreen screen, so longish press of power button which displays constant white led, invokes power off reboot…
I have heard rumors certain AMD processors DON"T hibernate/suspend under Linux Open Source yet. Mine is AMD Ryzen 7 pro 5850u with radeon graphics x16 and AMD Renoir graphics. Is that my issue? Unsupported hardware under Linux kernel?
To repeat, all I am interested in is suspend to RAM, and resume by touching the keyboard/trackpad to raise the login prompt. (GNOME under Wayland, and KDE Plasma under XORG are my prefered destop environments, but I’ll use different one(s) some applications I use still work best on X0rg.
Suspend to ram certainly should not require HDD swap, although suspend to disk or hibernate do. It may be a factor of the secure boot that is preventing it, I have not personally used that combination so am unsure.
I apologize for misunderstanding the issue. I thought the issue was suspend to disk. Since you are not suspending to disk then the on disk swap is totally unnecessary for most cases, and the default zram size should be adequate. The man page for zramctl tells you how to change size if swap is an issue with the default.
Hello, the HOWTO activate hibernation tutorial did point me to some useful to me information, It’s the configuration files! So man 5 sleep.conf and man 5 dracut.conf look like I’ll be able to activate suspend to ram and safely prevent hibernate to disk. Although I’ll keep a clean toothbrush in my kit just in case
Placing a sleep.conf file into sleep.conf.d directory with activating Allowsleep=yes and AllowHibernate=no activates a lockscreen behavior, so the led is solid, but login credential screen is presented by touching keyboard…
More research on this issue will happen in the next couple of weeks, on to more important things!