Remove a FIXME comment and check if we're running in a container by looking at
/proc/1/cgroup. Running in a container will most likely fail as this will try
to write things in the root directory, modify boot loader settings, etc.
This will check hibernation first by looking for "platform" in
/sys/power/disk. If found, then nothing else will be done. Other
methods will be then checked, but unless we're running in a Hyper-V
environment with /sys/bus/vmbus/hibernation present and contains "1",
hibernation will be considered disabled for this VM.
Hibernating through the API in Azure will trigger a non-standard uevent, so we need
to install an udev rule to hibernate the VM and notify udev about it.
Since the patch was intertwined with a check to abort the agent if running
on Linux kernel before 5.0 with a Btrfs filesystem (which isn't supported),
this change adds this functionality as well.
With this change, we first check /sys/power/disk for supported hibernation
modes, and print out the ones that we know will work to hibernate a machine,
but bail out if none of those are found.
Then, we probe /sys/bus/vmbus/hibernation to determine if hibernation has
been enabled in Hyper-V as well. If so, then we proceed as usual. If not,
we don't continue.
At this point, we also verify if /sys/bus/vmbus exists as a way to determine
if we're running on a Hyper-V VM. This is just to print a better log message
to aid in debugging should the hibernation file not be present.
In some systems, particularly systems set up with an image from the Azure
Marketplace, will have configuration files in that directory that will
override the default settings as found in /etc/default/grub, effectively
making our changes meaningless.
Change it so that, if /etc/default/grub.d exists, we create a file with
higher priority instead, that will add new kernel command line parameters
on top of whatever the marketplace configuration file did.
Leandro Pereira