I have a problem with hibernation to swap. It runs great, just a bit too great…
The problem is that grub2 just skips the boot menu when it sees a hibernated OS and goes straight to booting it.
My goal is to be able to hibernate my main work OS (OpenSUSE Tubleweed), boot into Windows, run some weird stuff that struggles or refuses to work in Wine and go back to Linux, where all my mess eating tons of RAM is waiting for me.
Is there a way to disable this in grub2? I haven’t found an obvious line in config files and wasn’t able to find anything with this idea online, only threads about hibernation not working and such.
I am aware of possible data loss with this approach, but I do not cross-mount any partitions between my OSes (only external shares sometime) and I don’t plan on hibernating Windows, so this should be fine. That’s the risk I’m willing to take to be able to play JRPGs during lunchtime.
Linux hibernates to swap partition (by default and on my setup), Windows does not have access to it.
I would like to try anyway, I will test this without unbackupped-project-my-life-depends-on opened.
I also have automated external backups happen every 4 hours and btrfs snapshots for every operation with packages, so I am ready to screw things up any time.
You specified RAM in your post which is what came out to me. In that case you’re in a better position. It’s been a while since I dug into boot loaders though, so im not sure about hibernation options.
Yes, that’s the difference between hibernation and sleep basically. Sleep is suspend to RAM and poweroff only CPU and a couple of other things, hibernation is suspend to swap and completely shut down the thing it runs on.
I mainly use sleep now when I am always at home, but I used to hibernate the laptop for my way to work because it requires you to unlock BIOS and LUKS to power back on, and it’s more comfortable in case of device being lost/stealed.
It seems i am sleep deprived enough to forget english, sorry for that. One more edit…
It’s been a while and a number of the boot management options have changed over the years so, it seems like it should be possible. google certainly thinks so, but its likely something very specific.
I send my laptop to sleep/hibernation via d-bus so Gnome is more aware of it (I hope, not that I took time to actually compare different ways), so systemd in not directly related to this. I get the behavior I want (described in previous post).
I was able to google that it’s possible and some people do it, but their grub2 didn’t seem to mess with that. But I wasn’t able to find a way to force grub2 NOT to be so convenient and stop autostarting the hibernated Linux without giving me the option to load Windows.
My understanding was that when you hibernate, it isn’t as if the machine shut down, but it goes into a different state (hibernation). When you hit the power button, it isn’t doing a Power On Self Test (POST), and as such never hands anything over to grub. Is this not correct?
If the grub splash screen is being bypassed, you can hold the shift key (after POST) and this will give you the grub menu. You can try that while powering up from hibernation, but as I understand it grub isn’t a factor. I’m more than willing to admit being wrong if someone has better info.
No, it is not. Hibernation is a complete shut down, but the contents of RAM are written to swap. You can cut the power off of hibernated PC completely, and upon powering on it will run POST, ask for BIOS password, ask for LUKS password, load the kernel and ask for LUKS password again, and after that it will load everything from swap to RAM.
No luck, it just skips to loading default option, which is Tumbleweed with the latest kernel. I imagine it could also cause trouble if you hibernate after upgrading the kernel, but that’s beside the point.
Might be worth setting GRUB_HIDDEN_TIMEOUT_QUIET=false or maybe just GRUB_TIMEOUT_STYLE=countdown in your /etc/default/grub file to see if you can get the boot menu to always display while still defaulting to boot the default if left? That might give you the ability to debug what is going on as grub might be configured with GRUB_DEFAULT=saved and the hibernation script is modifying what the saved entry does?
The other possibility is that the hibernation is configuring your UEFI bootloader with the resume options to run on next boot resulting in grub getting skipped? But I’d start with adjusting the timeout options in grub and even if you need to use the shift key at the right time to get access to the boot menu it might allow seeing what was modified by the hibernation via some commands from https://www.gnu.org/software/grub/manual/grub/grub.html
Grub is definitely not getting skipped, because I receive its prompt for drive password and its “loading kernel xxx” screen after that.
Thanks for the config options, GRUB_DEFAULT=saved is there, but I thought it was just highlighting the option, not booting it. Will try this in a bit.
# If you change this file, run 'grub2-mkconfig -o /boot/grub2/grub.cfg' afterwards to update
# /boot/grub2/grub.cfg.
# Uncomment to set your own custom distributor. If you leave it unset or empty, the default
# policy is to determine the value from /etc/os-release
GRUB_DISTRIBUTOR=
GRUB_DEFAULT=saved
GRUB_HIDDEN_TIMEOUT=3
GRUB_HIDDEN_TIMEOUT_QUIET=false
GRUB_TIMEOUT=3
GRUB_TIMEOUT_STYLE=countdown
GRUB_CMDLINE_LINUX_DEFAULT="splash=silent resume=/dev/mapper/cr_ata-SanDisk_SD9SN8W512G1122_183798800782-part4 quiet mitigations=auto"
GRUB_CMDLINE_LINUX=""
# Uncomment to automatically save last booted menu entry in GRUB2 environment
# variable `saved_entry'
# GRUB_SAVEDEFAULT="true"
#Uncomment to enable BadRAM filtering, modify to suit your needs
# This works with Linux (no patch required) and with any kernel that obtains
# the memory map information from GRUB (GNU Mach, kernel of FreeBSD ...)
# GRUB_BADRAM="0x01234567,0xfefefefe,0x89abcdef,0xefefefef"
#Uncomment to disable graphical terminal (grub-pc only)
GRUB_TERMINAL="gfxterm"
# The resolution used on graphical terminal
#note that you can use only modes which your graphic card supports via VBE
# you can see them in real GRUB with the command `vbeinfo'
GRUB_GFXMODE="auto"
# Uncomment if you don't want GRUB to pass "root=UUID=xxx" parameter to Linux
# GRUB_DISABLE_LINUX_UUID=true
#Uncomment to disable generation of recovery mode menu entries
# GRUB_DISABLE_RECOVERY="true"
#Uncomment to get a beep at grub start
# GRUB_INIT_TUNE="480 440 1"
GRUB_BACKGROUND=
GRUB_THEME=/boot/grub2/themes/openSUSE/theme.txt
SUSE_BTRFS_SNAPSHOT_BOOTING="true"
GRUB_USE_LINUXEFI="true"
GRUB_DISABLE_OS_PROBER="false"
GRUB_ENABLE_CRYPTODISK="y"
GRUB_CMDLINE_XEN_DEFAULT="vga=gfx-1024x768x16"
The first thing i thought about is that a grubscript sets the timeout to 0 and sets a default kernel to boot. This boot just resumes the hibernate file.
This could be done by a step somewhere in the pre-hibernate event flow (systemd? dbus triggered scripts?)
The grubloader reads the actual grub.cfg and also looks for includes like a custom.cfg (see /etc/grub.d/41_custom and /etc/grub.d/80_suse_btrfs_snapshot)
Is it possible you do some digging there? I dont have a Suse system near me.
could you also look for a grubenv file next to your grub.cfg? it is possible this file is cleared on resume, so either find the script that writes it, or look on the filesystem of the still hibernated kernel.
#!/bin/sh
cat <<EOF
if [ -f \${config_directory}/custom.cfg ]; then
source \${config_directory}/custom.cfg
elif [ -z "\${config_directory}" -a -f \$prefix/custom.cfg ]; then
source \$prefix/custom.cfg;
fi
EOF
That’s filesystem snapshots entry to rollback after catastrophic event with /, nothing interesting there.
# GRUB Environment Block
# WARNING: Do not edit this file other than by grub2-editenv
saved_entry=openSUSE Tumbleweed
##########################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################################
