Hi, I have installed OpenSUSE a few times but never stayed very long but I’m expecting this time is different.
I installed leap 16 having read that some encrypted shenanigans are done on OpenSUSE that Debian has not. Also battery_charge_threshold_end stopped working on the last number of Trixie kernels damaging the health of my battery. I also think OpenSUSEs slightly stronger stance on AI is better requiring AI use declarations etc. than Debians recent vote.
There are a couple of other threads but no real answers. If the install enabled FDE on leap 16 which set swap as encrypted and I edited swap to be larger than my ram in the install. Then is there no way to enable hibernate except disabling secure boot as that seems wrong. I thought I had read that OpenSUSE had specifically put this FDE work in (resulting in users having to enter the boot password twice) so that hibernate could be secured and had set a kernel configuration that Debian had not?
Is the kernel just broken in this regard as it seems like suspend is far more risky than hibernate inside an encrypted partition even if you consider the arguments on FDE possibly using e.g. XTS/CBC encryption. Additionally firmware is usually written in C and not e.g. Ada SPARK so evil maid attacks aren’t really preventable unless detected and disabling secure boot disables a host of other security options. (Though disabling secure boot does allow me to protect my CPUs surrounding components from going above their rated max of 80 degrees for hw longevity using ryzenadj --tctl-temp=80 which I guess is another kernel gripe).
It doesn’t seem that ZRAM is used after the install at all so I guess this person never got it sorted.
Here is some more background information but again I do not see why suspend is not disabled as well if this stance has been taken on hibernate.
This page says he has had hibernate work on OpenSUSE leap. I have all three of these matching but I didn’t select LVM during install. I also have rng mentioned in dmesg after efi:
✔ Linux kernel lockdown: Enabled
✔ Linux swap: Encrypted
✔ fwupd plugins: Untainted
“Represents a battery percentage level, above which charging will stop. Not all hardware is capable of setting this to an arbitrary percentage. Drivers will round written values to the nearest supported value. Reading back the value will show the actual threshold set by the driver.”
I thought I had tried 60 that I knew worked again but I assume that I didn’t as it is now working with 60. It accepts 40 and cat shows it accepted 40 but it doesn’t have any affect unless e.g. 55 or 60 so I guess the asus driver has some value acceptance, rounding or overflow bugs. Or perhaps more likely it just accepts 0-100 and the validity spec just hasn’t been implemented.
I tried to get hibernate working with secure boot on Tumbleweed thinking nouveau support on kernel 7 would if anything be improved over 6. It didn’t work so I assume what I read about Leap kernel hibernate patches is correct.
In any case I couldn’t actually get all three displays working with tumbleweed when they did with Leap (with one kde crash so hopefully will be stable). On Debian I actually found Nvidias .run to work best.
I re-installed Leap and enabled LVM as mentioned in the above stack exchange link.
enabled encryption
added LVM (avoids 2nd password on swap decryption)
set the swap large enough for my ram
Hibernate was available and worked out of the box with this config.
I’m not sure if the key regen would have been needed if done this way the first time