7

I have a laptop running two different GNU/Linux-based operating systems. Each operating system has it's dedicated root and home partition, but share the boot and swap partition. They both work quite well, except for one issue: anytime I hibernate the machine and I boot up, say the next day, and I forgot that I hibernated X operating system, I end up messing up the FS journal. Now, I was aware that by sharing swap space, this was a possible side effect, however, I was under the impression that once I hibernate, GRUB would detect that the swap space is in use, and boot into the hibernated OS. This is not the case for me, as I have had to write a work-around solution:

edit /etc/default/grub:

GRUB_DEFAULT=saved
GRUB_SAVEDEFAULT=true

run grub-mkconfig, and then write a script that changes /boot/grub/grub.cfg's timeout from whatever to 0 upon hibernation (/etc/pm/sleep.d/10-hibernate-script.sh):

#!/bin/sh

 case "$1" in
    hibernate)
    cat /boot/grub/grub.cfg | sed 's/timeout=10/timeout=0/g' > /boot/grub/grub.cfg~
    mv /boot/grub/grub.cfg~ /boot/grub/grub.cfg
    ;;
    thaw)
        cat /boot/grub/grub.cfg | sed 's/timeout=0/timeout=10/g' > /boot/grub/grub.cfg~
        mv /boot/grub/grub.cfg~ /boot/grub/grub.cfg
    ;;
esac

Is there a more "native" way of doing this, or is this the best way of achieving this?

SpaghettiCoder
  • 155

1 Answers1

1

Since they're both Linux, maybe you can have things set up so either OS can resume from images saved by either OS? If the hibernation image includes all of kernel memory, including the code, then it doesn't matter which kernel resumes from it. I'm not sure how that works.

Also, maybe if your laptop has ACPI hibernate support, Linux can hibernate that way. Then hopefully it always resumes when powered on, instead of booting to GRUB? Again, not sure how things work.

It might be possible for you to get your OSes set up to not use the swap partition if there was a resume image in it. This isn't going to help if they both mount any of the same non-swap partitions read-write. Maybe there's a mount option to refuse journal-replay (which would mess up the hibernated state).

If none of those things pan out, I think your solution is about the best you're going to get. I don't think grub knows how to look at a swap partition and figure out if it's in use. If it could, then maybe you could have some logic in your grub config to only allow booting the SAVEDEFAULT entry. (It's really unlikely that grub could figure out which OS had a hibernation image, without using SAVEDEFAULT.)

references:

Community
  • 1
Peter Cordes
  • 6,466
  • 3
    When you resume from hibernation, the code of the kernel is the one that's booted, it loads some of the data from the hibernation image but not code. The only way to resume a different installation's kernel would be if they used the same kernel (as in, the same vmlinuz binary). – Gilles 'SO- stop being evil' Sep 19 '15 at 20:44
  • @Gilles: Thanks. So you can't hibernate after upgrading your kernel? Do modern distros handle that automatically? I mostly use my desktop. Interesting point about using the same kernel for both distros, though. You could maybe get away with only using kernels from one of the distros, and just choosing which userspace you boot. The distro not using its own kernels would need a symlink to the kernel-providing distro's /lib/modules/$(uname -r), and probably other headaches that could cause problems with hardware that needed specific module configs. – Peter Cordes Sep 19 '15 at 21:00
  • 2
    Indeed you can't hibernate after upgrading the kernel. That's a bit of a rough spot. I think the major distributions avoid removing the currently-running kernel (at least Ubuntu's kernel purging automation keeps the most recent kernel and the running kernel), so the kernel will stick around, but the bootloader menu might offer the most recent kernel by default, which would fail to resume. – Gilles 'SO- stop being evil' Sep 19 '15 at 21:03