Save the machine state before shutdown and load it back on boot?

Question

Is there a way, on windows 10 and on Linux distributions, to save the machine state before shutting down and load it back up on boot?

I.e. I would like the same feature as in VirtualBox when I use the "save state" to exit a running VM. Which means that when I open back that VM by loading the state, I still have everything just as I left it, and it doesn't take longer than a classical boot.

Is that possible for an OS (not virtualized)?

UPDATE: Of course I would like a real shutdown (does hibernation really shutdown the computer?) to be able to switch OS when booting back up. Use case is: I have a game running on windows, a browser, a bunch of stuff, I shutdown to do some dev on Linux. When I boot I choose Linux instead of Windows, it boots and loads its previous state back (my terminals, with tabs, docker containers still running, my IDE still running etc.). When I'm done with Linux, I shutdown (which saves the state etc.) and reboot under windows which loads back my game, browser etc.

On VirtualBox shutting down is really quick (<10s) and loading the state back up is fairly quick too (~20-40s). This is for a VM using 8GB of RAM. Is there a way to do that with native dual boot OSes and if so, is the speed ok?

Thanks.

Solution

Yes that’s what hibernation is. Possible on all major desktop operating systems (Windows, Linux, macOS).

Depending on how much physical memory was in use when shutting down, fully restoring the state might take a lot longer than a regular boot.

You must not change the state of a hibernated system in any way or you’ll cause data corruption, undefined behavior or outright crashes. That generally means no dual booting.

If you really want to, you can of course boot another OS, but it must not touch anything but its own partitions.

To be very clear: Operating systems must use a mutually exclusive set of partitions. There is only one exception: Read-only mounting partitions does not modify them, hence preserving the state the hibernating OS expects.

Comments

[Hillfias]

I updated my question. Could you check and give more details to as if your answer still fits? Thanks.

[Daniel B]

Unless you’re very careful, what you want is not possible.

[Kamil Maciorowski]

"Very careful" means at least "don't mount the other OS's filesystems", I think. Is there something else?

[Daniel B]

Yes, that’s basically it. However, depending on the distribution/setup used, it’s very easy to accidentally mount them. ntfs-3g is supposed to refuse, but I wouldn’t rely on that.

[Hillfias]

Uhmm.. Maybe I should add that windows is on a first HDD (128GB), and I have a second HDD (1TB) with the first NTFS partition "DATA" (~750GB) mounted by both OS, and the second partition ext4 Linux on the rest of the disk. Am I in the case where, by mounting the data partition, I risk mounting the other OS's filesystems? Any solutions? And, if I'm in a case where I'm "very careful", how do I do this exactly? Could you please update your answer? :) Thanks.

[Daniel B]

What do you mean by “risk”? You say it’s mounted by both operating systems, that’s not a risk anymore. It’s guaranteed to either fail early or destroy the filesystem later. ;) The solution is not to mount the partition. My answer already says that.

[Hillfias]

You said that all would go fine if I don't mount the other OS's partition. That is not what I aim to do. Though I do want to mount a partition that will be used by both OSes. Is that possible? I.e. Windows runs on a partition (I won't mount that from Linux) and mounts a data partition (on the same disk as the Linux partition). From Linux I want to mount that data partition too (not W). Linux won't be touching at windows' filesystem, nor will windows touch Linux's. Does that work? Is my understanding correct? Are if any of these two OS touch at any common partition, there's a guaranteed fail?

[Dawn Benton]

You can't save the active state of a system, then manipulate that state outside of the system and expect the system to remain stable.