I was really curious about the possibilities here for a re-usable “saved hibernation state”, and did a lot of digging around and testing in exploration of that idea. Please note that the following is wacky as hell and is not a good way to run a server at all, but is possible:
Set up a swap partition that can fit your full system memory.
Hibernate your system to the swap partition in the state you want to use as your perpetual checkpoint.
Boot from a live usb, NOT your regular system (when the linux kernel boots with the resume=uuid=xxxx parameter which enables hibernation/resume, it checks that partition for a hibernation signature and immediately clears it, preventing multiple boots of the same hibernated state. You need to preserve this signature).
From the live usb system, copy the swap partition that contains your main system’s hibernated state to an .img file on a filesystem mounted from one of your main disks.
Reboot into your main system.
Set up a scheduled job that triggers every time your system resumes (could use a systemd service with After=hibernate.target and WantedBy=hibernate.target) that does the following:
Disables swap on the swap partition you set up (keeping the resume=uuid=xxxxx kernel parameter that points to it).
Writes the .img file to that partition
Use your system as you want, and power it off when done (do not suspend or hibernated again).
The next time you boot, the kernel will load the saved hibernation state from the partition specified in the resume= parameter, as if it had just been hibernated instead of halted.
Now for the downsides:
It’s very dangerous to resume a system’s memory to one state with storage in a different state (the official kernel docs for this have a giant red warning banner saying “If you touch anything on disk between suspend and resume… …kiss your data goodbye.” https://docs.kernel.org/power/swsusp.html ).
Resuming from hibernation isn’t really that much faster than cold booting a lean system, if speed is your primary goal.
The scheduled write job will hit you with a bunch of heavy io every time you boot/resume, probably negating any speed benefits of the whole thing anyway.
Anyway, now that we know it’s possible, if you really can’t suspend/resume in a non-wacky way I recommend instead just booting normally and trying to make the boot process as fast as possible. A good guide here: https://wiki.archlinux.org/title/Improving_performance/Boot_process
I was really curious about the possibilities here for a re-usable “saved hibernation state”, and did a lot of digging around and testing in exploration of that idea. Please note that the following is wacky as hell and is not a good way to run a server at all, but is possible:
The next time you boot, the kernel will load the saved hibernation state from the partition specified in the resume= parameter, as if it had just been hibernated instead of halted.
Now for the downsides:
Anyway, now that we know it’s possible, if you really can’t suspend/resume in a non-wacky way I recommend instead just booting normally and trying to make the boot process as fast as possible. A good guide here: https://wiki.archlinux.org/title/Improving_performance/Boot_process
If booting quickly to a static state is the goal, alpine diskless mode might be a good option: https://wiki.alpinelinux.org/wiki/Diskless_Mode