grep -r grubenv /etc /usr/lib
grep -r grub-editenv /etc /usr/lib
This must hit something?
I use
dbus-send --print-reply --system --dest=org.freedesktop.login1 /org/freedesktop/login1 org.freedesktop.login1.Manager.Hibernate boolean:true
to hibernate with hotkey btw.
/usr/share/polkit-1/actions/org.freedesktop.login1.policy contains
<action id="org.freedesktop.login1.hibernate">
<description gettext-domain="systemd">Hibernate the system</description>
<message gettext-domain="systemd">Authentication is required to hibernate the system.</message>
<defaults>
<allow_any>auth_admin_keep</allow_any>
<allow_inactive>auth_admin_keep</allow_inactive>
<allow_active>yes</allow_active>
</defaults>
</action>
So looks like systemd is envolved in the end. I do not have to enter password though (that was the goal), so looks like Gnome backend handles that. But no hints in /etc/systemd/sleep.conf
# This file is part of systemd.
#
# systemd is free software; you can redistribute it and/or modify it
# under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2.1 of the License, or
# (at your option) any later version.
#
# Entries in this file show the compile time defaults.
# You can change settings by editing this file.
# Defaults can be restored by simply deleting this file.
#
# See systemd-sleep.conf(5) for details
[Sleep]
#AllowSuspend=yes
#AllowHibernation=yes
#AllowSuspendThenHibernate=yes
#AllowHybridSleep=yes
#SuspendMode=
#SuspendState=mem standby freeze
#HibernateMode=platform shutdown
#HibernateState=disk
#HybridSleepMode=suspend platform shutdown
#HybridSleepState=disk
#HibernateDelaySec=180min
i’m pretty sure it is done via grubenv. i would modify my grub.cfg to read grubenv1 or so (and have a rescue stick nearby) and hibernate and resume. And see if the behaviour changes.
I cannot find where the sleep logic of systemd writes the grubenv. i’ve done some searching in the source and tumbleweed install files but i can only find: /usr/lib/systemd/system/grub2-once.service but i cant find a reason why it should be the writer of the grubenv, because it only 'unset’s the next_entry.
I am not ready to do that in a middle of a workday. Maybe later, bot it looks way overkill to me.
It is meant as an intermediate step in proving the automatic resume is in grubenv.
But i guess the problem is not so bad that you would spent the rest of the workday fixing an unbootable system, because you made a typo. 
BTW: it is 30C here right now.
Well, I am pretty sure that boot_once var is usen after looking into systemd Github repo (already closed that one, sorry), so I am looking into how to stop that from happening.
Seems like it still might be worth changing your grub.cfg manually to set all timeout entries to non-zero values which would give enough time during the resume from hibernate to stop the boot and drop to the grub shell to poke around the next time. That would at least allow inspecting the environment and capturing what is currently set and then compare against what is set when starting from cold. Should give some absolute certainty on what is getting set?
I’ve already done this. With boot_once var set it just ignores all the timer values and uses 0.
I can probably comment this line out in grub.cfg out, will try this in about half an hour.
Sorry, I meant if you edit the grub.cfg file directly to replace the following lines rather than trying to rely on setting the options in /etc/default/grub:
if [ x${boot_once} = xtrue ]; then
set timeout=0
elif [ x$feature_timeout_style = xy ] ; then
set timeout_style=countdown
set timeout=3
# Fallback hidden-timeout code in case the timeout_style feature is
# unavailable.
elif sleep --interruptible 3 ; then
set timeout=0
fi
with something like the following
if [ x${boot_once} = xtrue ]; then
set timeout_style=countdown
set timeout=5
elif [ x$feature_timeout_style = xy ] ; then
set timeout_style=countdown
set timeout=3
# Fallback hidden-timeout code in case the timeout_style feature is
# unavailable.
elif sleep --interruptible 3 ; then
set timeout_style=countdown
set timeout=5
fi
I see a function called make_timeout() that generates this section in my /etc/grub.d/00_header but I’m thinking it’s not worth modifying that, better to just ensure that you at least get a countdown menu and a non-zero timeout that should give the ability to access the menu. Should be able to restore it once debug is complete.
1 Like
Yes, that’s exactly the plan for now. However, it’s a temporary solution as it would be overwritten after any major system update. So if it works, I’ll try to modify the source generating this value and monitor if there will ever come time it’ll be overwritten too.
Well, now it gives me a 3 seconds countdown. According to grub2 doc I should be able to interrupt it with key presses, but it ignores them and just goes on. Need to get deeper here.
UPD Nope, it actually works. Just only cares about ESC key for some reason, not Shift I remember as a general grub “stahp i wanna choose stuff” key and not any key as stated in grub2 doc for loading default option timeout. At least ESC makes more sense for general user to stop things from happening, I guess.
Updated 00_header to write this every time config is generated, successfully booted Windows, got asked to update that thing with reboot (just did yesterday). Well, it definitely seemed like Windows, grub didn’t trick me there. Linux happily started from hibernation after shut down (in case some devices won’t reset with simple reboot, just don’t wanna have another struggle right now), nothing lost.
I consider it success, thanks, everyone.
If you are the type of user that gets into these details, I suggest discarding all that complex grub script machinery and maintain your own, simplified grub.cfg. If you have more than one distro installed, grub always screws up eventually. I’ve done this for many years, and find it far easier and more stable.
Also, note my grub (on Ubuntu) doesn’t have write support for btrfs, so the whole grubenv mechanism doesn’t work.
1 Like