Hibernation, et al

[bixbyru]

Hey there -

Concerning OpenSuSE (currently Leap 15.2 and Windows 10) on a Panasonic CF-31 Mk 1, I’ve a couple questions/issues:

• When I hibernate, the beast neither powers off nor sets the wake-on-open flag in the BOIS. If I wait long enough, then it’ll write everything to the swap partition and can resume alright; however, this is hardly proper operation;

• Is there a way to get Grub to show the boot menu even when Linux is suspended? In other words, if I hibernate Leap, then I’d still like the option of going into Windows while the lizard snores. Mint does this by default, but not OpenSuSE - and I’ve been unable to locate the important difference(s) in the Grub config, but I suppose that it could be a kernel thang.

Also experiencing other issues, but this is it as regards IPL.

Help? Thanks.

[devendraraju]

Same here, any solution? :)](https://happyrakhi.com/happy-rakhi-hd-images-pictures-videos-status)

[arvidjaar]

@bixbyru

• When I hibernate, the beast neither powers off nor sets the wake-on-open flag in the BOIS. If I wait long enough, then it’ll write everything to the swap partition and can resume alright; however, this is hardly proper operation

Writing to swap is proper operation when you hibernate. I am not sure I understand what you are trying to say. Can you describe it in more details?

Is there a way to get Grub to show the boot menu even when Linux is suspended?

You could remove and lock grub2-systemd-sleep-plugin package.

[marel]

Yes, not completely clear on why hibernation (suspend to disk) is not proper operation but I guess you want to “suspend to RAM” before going into hibernation.

You can try “systemctl suspend” to trigger suspend to RAM.

[bixbyru]

Hey there -

@arvidjaar

Writing to swap is proper operation when you hibernate. I am not sure I understand what you are trying to say. Can you describe it in more details?

Writing to swap is normal; however, neither powering off nor setting wake-on-open in the BIOS are not. I’m used to system hibernation not requiring that I wait 'til I’m sure that writing is finished, then holding the power switch for ten seconds.

@arvidjaar

You could remove and lock grub2-systemd-sleep-plugin package.

Will try that; thanks.

[bixbyru]

@arvidjaar

Writing to swap is proper operation when you hibernate. I am not sure I understand what you are trying to say. Can you describe it in more details?

You could remove and lock grub2-systemd-sleep-plugin package.

Hey there -

Well, that’s the larger part solved; I’d no idea that that package even existed, and the name doesn’t quite follow the function. Thanks!

Now if I could just figure out why a full shutdown manages to power off but hibernate doesn’t - and fails to set wake-on-open as well - I’ll then be set.

Don’t suppose you know anything about Toughbook touchscreens…?

Lates

[bixbyru]

@marel

Yes, not completely clear on why hibernation (suspend to disk) is not proper operation but I guess you want to “suspend to RAM” before going into hibernation.

You can try “systemctl suspend” to trigger suspend to RAM.

Suspend to disk is normal operation, but having to wait 'til I’m absolutely certain hat writing is finished and then holding the power switch for ten seconds is not.

[arvidjaar]

@bixbyru

Suspend to disk is normal operation, but having to wait 'til I’m absolutely certain hat writing is finished and then holding the power switch for ten seconds is not.

What is output of

cat /sys/power/disk

[bixbyru]

@arvidjaar

What is output of

cat /sys/power/disk

Hey there -

platform [shutdown] reboot suspend test_resume

This is as one would expect. Maybe my BIOS doesn’t do ACPI correctly, but since earlier versions worked that would be odd.

Normally

echo platform > /sys/power/disk
echo disk > /sys/power/state

would do the trick, but it doesn’t power off.

I’ve currently a custom key set-up in KDE which graps the hibernate key combo and executes

echo shutdown > /sys/power/disk
echo disk > /sys/power/state

via sudo -S

so it’ll hibernate unattended, but that’s klunky in the extreme; would really like to figure this out.

Thanks

[arvidjaar]

@bixbyru

Hey there

I read your post three times and I still cannot parse it. So does it work (does it power off with “shutdown” method) or not?

[bixbyru]

@arvidjaar

I read your post three times and I still cannot parse it. So does it work (does it power off with “shutdown” method) or not?

Yes, with an ugly hack - and only from the command-line or via a key combination.

From the [hibernate] option in the power menu, and far more importantly as a scripted action when the battery gets low, not so much.

Besides, it should work with [platform], and that it does not gets my dander up.

[arvidjaar]

@bixbyru

Yes, with an ugly hack - and only from the command-line or via a key combination.

You can configure preferred hibernation method for systemd. See “man systemd-sleep.conf”

Besides, it should work with [platform], and that it does not gets my dander up.

Please consider that you are posting to intentional community where a lot of participants are not native English speakers (and even if they are they may not speak exactly the same English as you do).

I have a feeling that you are angry at me that it does not work they way you wish. In this case it is up to you to open bug report and assist developers in debugging and fixing it. The first step would be to install kernel from Leap 15.1 (which worked correctly as far as as I understood you) and verify that it still works, as this proves regression. Next step would be to install latest kernel (stable or head) to check whether problem still exists there. And then open bug report providing information to developers.

[bixbyru]

@arvidjaar

You can configure preferred hibernation method for systemd. See “man systemd-sleep.conf”

Please consider that you are posting to intentional community where a lot of participants are not native English speakers (and even if they are they may not speak exactly the same English as you do).

I have a feeling that you are angry at me that it does not work they way you wish. In this case it is up to you to open bug report and assist developers in debugging and fixing it. The first step would be to install kernel from Leap 15.1 (which worked correctly as far as as I understood you) and verify that it still works, as this proves regression. Next step would be to install latest kernel (stable or head) to check whether problem still exists there. And then open bug report providing information to developers.

What…?

I’m not angry at all - least of all with you or anyone here.

I do find unpredictable/changing behaviour in a computer to by highly irritating, however; once something works correctly there’s little good reason for it to stop working. Computers are supposed to be logical.

[arvidjaar]

@bixbyru

once something works correctly there’s little good reason for it to stop working.

Ever heard the word “regression”?

For the last time - you found apparent regression. It may well depend on exact environment, your hardware, BIOS version etc so it may not be easy for someone else to reproduce. To fix this problem you need to report it where developers also listen (i.e. bugzilla) and you need to assist in working on this problem as long as you are the only one who can reproduce it. Venting your frustration on this forum won’t fix anything.

[bixbyru]

@arvidjaar

Ever heard the word “regression”?

For the last time - you found apparent regression. It may well depend on exact environment, your hardware, BIOS version etc so it may not be easy for someone else to reproduce. To fix this problem you need to report it where developers also listen (i.e. bugzilla) and you need to assist in working on this problem as long as you are the only one who can reproduce it. Venting your frustration on this forum won’t fix anything.

Wish I could regress to an older BIOS…