When your kernel boots up, it grabs its machine-id and looks for a hibernation image to map into its memory. If it finds one, great, you have an "instant wake". If it doesn't, you boot as normal. Now imagine that your kernel tries to mount a specific device to `/hibernate` prior to looking for hibernate images. Upon hibernating, it writes its image to its machine-id. You could easily share the disk between two machines (even of different architectures) and keep two separate hiberante images on disk. You wouldn't be sharing the processes, but you could share your data.
With a sophisticated enough setup, you could probably even dual-install binaries (although this would be much involved with ELF where you must have separate binaries compared to something like Mach-O) to something like /usr/bin_x86_64/ and /usr/bin_arm64/ and then use your shell to select your path. This might work on a system level, but would certainly work on a per-install basis manually.
Nope; if the hibernated OS has the storage volume mounted, and you edit that volume in another OS, separate or not you will end up with corruption, just as if two machines had mounted it simultaneously.
Hibernation would work but then you have to make sure that the two operating systems don't share any drive (such as a data drive), because writing on a drive mounted by an hibernated system can cause all kind of weird issues.
Wouldn't hibernating the machine and then copying the hibernation data to another machine do the trick? Sure it wouldn't be as instant, but it would skip most of the boot configuration.
"Also, I'm not 100% sure if that hibernation trick is actually possible, I've never really seen it on multi-boot systems and I wonder why, but from what I understand about hibernation (RAM gets saved to HD, restored next boot) the components are there?"
It is possible, I've done it. If you're on a multi-boot system with Linux and Windows, you can freely hibernate either and boot into the other, as long as they completely don't touch each other. Neither can even mount the disk images of the other, let alone start changing things, or you face effectively-guaranteed corruption. Be careful with shared SD cards too. (I had it so Linux would never auto-mount those anyhow, so it was OK.)
The biggest objection I'd have to your plan is mostly that you'd also need some sort of backup plan, I don't think USB sticks are generally designed to store thousands of dollars' worth of stuff on them.
> While technically hibernate (to disk at least) should unmount all filesystems
Not a chance. Hibernate is just like Suspend to RAM: freeze all processes but core kernel, blit RAM to disk (usually stored in swap) and send poweroff command straight to CPU. Of course it doesn't unmount anything, hence there are FS data structures live in RAM. Booting an alternate system and accessing a filesystem open on the other side is like mounting twice the same filesystem and writing to it. It will blow up on you.
I would say no because I can’t reuse that state: all implementations that I’ve used discard the hibernated state afterwards. If there was an OS that reused those saved snapshots then I would argue that it does count as “booting”.
It would be even more interesting to do this on a per-application basis. Atom does something like this to cope with long startup times, for example.
you can set it up that way if you prefer, there is a resume= kernel param you can set to a separate file or device. I keep them combined tho because I hardly ever use much swap, and don't have a ton of disk, and if hibernation ever did fail, I can just close some tabs and be fine
But you cannot guarantee it’s going to take half of my RAM size at most. In practice I’m going to see either hibernation failing at times, or maybe my system being hosed at times, because the hibernation image would exceed the expected fraction of RAM size.
Besides, 32 GiB of disk space is nothing to sneeze at as well. I don’t quite trust using dynamically-created swap files as hibernation images, alas.
I have an encrypted swap partition. Hibernation works well with that. I don't believe it is possible with a swap file since the containing filesystem would also be mounted by the hibernation image.
I was wondering how this would impact multi-boot systems, as mixing hibernation and multi-boot is an extremely bad idea (unless you know what you're doing, and even then there a
are so many ways to shoot yourself in the foot).
I got hibernation working on my PopOS machine a while ago, but it took a lot of steps. The problem is that it requires a LOT of swap space. That machine has 32GB of RAM—and that means I have to have a dedicated swap partition at least that large to make it work.
Honestly, it would probably be easier to just run everything off a VM if having persistent states matters to you.
While technically hibernate (to disk at least) should unmount all filesystems - I'd be very wary of using hibernate (on either os) in a dualboot setup.
Other than that - my experience of late has been that ntfs is safe both to read and write from linux -- but as I now encrypt all my filesystems, that doesn't really help (no bitlocker support). If I actually needed to dualboot -- I suppose a separate disk/partition with truecrypt might do the trick.
My solution for the past several years have been to have all "interesting" files on a separate linux file server -- and access it with cifs/samba and/or ssh.
I tried that and it didn't work on my work ThinkPad (also those steps are dangerous it could brick your system if you so much as make a single mistake).
But that doesn't answer my question of why something as basic as Hibernate (copy RAM contents to HDD on power-OFF, then reverse on power-ON) isn't something that works out of the box on Linux distros, and instead requires 2h of tutorial reading and dangerous low-lvel tinkering for it to (maybe) work or brick your system if you mess it up.
With a sophisticated enough setup, you could probably even dual-install binaries (although this would be much involved with ELF where you must have separate binaries compared to something like Mach-O) to something like /usr/bin_x86_64/ and /usr/bin_arm64/ and then use your shell to select your path. This might work on a system level, but would certainly work on a per-install basis manually.
reply