How can I hibernate on Ubuntu 17.10 or save my session?












3















I want to store my session or hibernate on Ubuntu 17.10, to avoid always having to reopen the same applications.



How can I do that?










share|improve this question

























  • These answers may help you: unix.stackexchange.com/questions/13725/…

    – user68186
    Dec 17 '17 at 19:24






  • 2





    Possible duplicate of How to enable hibernation?

    – Fabby
    Dec 17 '17 at 19:43











  • I think hibernation requires the a swap to be enabled and ubuntu 17.10 only uses swap files

    – mrkaspa
    Dec 17 '17 at 22:32











  • Also enabled the auto save sessions on gnome using dconf but it does not work

    – mrkaspa
    Dec 17 '17 at 22:34











  • @mrkaspa, I think you want to say "I think hibernation requires a swap partition to be enabled and ubuntu 17.10 only uses swap files"

    – jpezz
    Dec 17 '17 at 23:00
















3















I want to store my session or hibernate on Ubuntu 17.10, to avoid always having to reopen the same applications.



How can I do that?










share|improve this question

























  • These answers may help you: unix.stackexchange.com/questions/13725/…

    – user68186
    Dec 17 '17 at 19:24






  • 2





    Possible duplicate of How to enable hibernation?

    – Fabby
    Dec 17 '17 at 19:43











  • I think hibernation requires the a swap to be enabled and ubuntu 17.10 only uses swap files

    – mrkaspa
    Dec 17 '17 at 22:32











  • Also enabled the auto save sessions on gnome using dconf but it does not work

    – mrkaspa
    Dec 17 '17 at 22:34











  • @mrkaspa, I think you want to say "I think hibernation requires a swap partition to be enabled and ubuntu 17.10 only uses swap files"

    – jpezz
    Dec 17 '17 at 23:00














3












3








3


1






I want to store my session or hibernate on Ubuntu 17.10, to avoid always having to reopen the same applications.



How can I do that?










share|improve this question
















I want to store my session or hibernate on Ubuntu 17.10, to avoid always having to reopen the same applications.



How can I do that?







17.10 hibernate






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Dec 18 '17 at 22:15









Zanna

51.1k13138242




51.1k13138242










asked Dec 17 '17 at 19:12









mrkaspamrkaspa

164




164













  • These answers may help you: unix.stackexchange.com/questions/13725/…

    – user68186
    Dec 17 '17 at 19:24






  • 2





    Possible duplicate of How to enable hibernation?

    – Fabby
    Dec 17 '17 at 19:43











  • I think hibernation requires the a swap to be enabled and ubuntu 17.10 only uses swap files

    – mrkaspa
    Dec 17 '17 at 22:32











  • Also enabled the auto save sessions on gnome using dconf but it does not work

    – mrkaspa
    Dec 17 '17 at 22:34











  • @mrkaspa, I think you want to say "I think hibernation requires a swap partition to be enabled and ubuntu 17.10 only uses swap files"

    – jpezz
    Dec 17 '17 at 23:00



















  • These answers may help you: unix.stackexchange.com/questions/13725/…

    – user68186
    Dec 17 '17 at 19:24






  • 2





    Possible duplicate of How to enable hibernation?

    – Fabby
    Dec 17 '17 at 19:43











  • I think hibernation requires the a swap to be enabled and ubuntu 17.10 only uses swap files

    – mrkaspa
    Dec 17 '17 at 22:32











  • Also enabled the auto save sessions on gnome using dconf but it does not work

    – mrkaspa
    Dec 17 '17 at 22:34











  • @mrkaspa, I think you want to say "I think hibernation requires a swap partition to be enabled and ubuntu 17.10 only uses swap files"

    – jpezz
    Dec 17 '17 at 23:00

















These answers may help you: unix.stackexchange.com/questions/13725/…

– user68186
Dec 17 '17 at 19:24





These answers may help you: unix.stackexchange.com/questions/13725/…

– user68186
Dec 17 '17 at 19:24




2




2





Possible duplicate of How to enable hibernation?

– Fabby
Dec 17 '17 at 19:43





Possible duplicate of How to enable hibernation?

– Fabby
Dec 17 '17 at 19:43













I think hibernation requires the a swap to be enabled and ubuntu 17.10 only uses swap files

– mrkaspa
Dec 17 '17 at 22:32





I think hibernation requires the a swap to be enabled and ubuntu 17.10 only uses swap files

– mrkaspa
Dec 17 '17 at 22:32













Also enabled the auto save sessions on gnome using dconf but it does not work

– mrkaspa
Dec 17 '17 at 22:34





Also enabled the auto save sessions on gnome using dconf but it does not work

– mrkaspa
Dec 17 '17 at 22:34













@mrkaspa, I think you want to say "I think hibernation requires a swap partition to be enabled and ubuntu 17.10 only uses swap files"

– jpezz
Dec 17 '17 at 23:00





@mrkaspa, I think you want to say "I think hibernation requires a swap partition to be enabled and ubuntu 17.10 only uses swap files"

– jpezz
Dec 17 '17 at 23:00










3 Answers
3






active

oldest

votes


















4














The main source for this answer (aside from my own experience) is this page on the Arch Linux wiki.



In this answer I use sudoedit to make changes to root-owned files. If you prefer, you can just call your favourite text editor with root permissions, but if you want to use a GUI editor and are using Wayland, see Why don't gksu/gksudo or launching a graphical application with sudo work with Wayland?).



If you cannot hibernate, be aware that you can still (probably) save power by using the suspend state, where the state of RAM is maintained. The systemd command for this is systemctl suspend, and it's somewhat more likely to work than hibernation.





It should be said that hibernation is not guaranteed to work; that's why initiating hibernation via the GUI is disabled by default. Even if you do everything right, you may still have problems. Your system may crash, your machine state may not be recoverable (you may lose unsaved work, for example) and you may find yourself in the sad situation of holding-down-the-power-button-for-a-very-long-time. I recommend only attempting to test hibernation after saving all of your work, and leaving only some idle application open (such as a terminal emulator that isn't doing anything).



Hibernation involves writing the state of RAM to an area of the disk. The swap space is used for this purpose. Whether it is a file or a partition, it should work in the same way. The Arch Wiki says that you should be able to hibernate if your swap is at least 2/5 of the size of RAM. Redhat provide this guidance on swap size needed for hibernation which totally contradicts the Arch Wiki! But I recommend other debugging steps before you attempt to increase the size of swap space.



If you are using Btrfs you may not be able to hibernate and Btrfs does not support swap files, according to the Arch Wiki. The default format for main partitions on Ubuntu 17.10 (and all other currently supported versions) is ext4, not Btrfs, so most users won't need to worry about this.



NirajW's answer here explains how to test and enable hibernation if it works. The command it suggests is



sudo pm-hibernate


This fails for me no matter what other adjustments I make (my system instantly hangs and never recovers). Instead I use



sudo systemctl hibernate


You may also try



echo disk | sudo tee /sys/power/state


Hibernation is the lowest possible power state (ACPI S4). What should happen is that the system shuts down, the machine is off and can be left off indefinitely, and when you turn it back on, instead of a clean boot, you log in and resume your session.



If you get a clean boot when you try to hibernate, the first thing to try is to set a boot parameter so that GRUB knows where to find the machine state to load back into RAM on resume (at least, that's how I understand the process. If this isn't accurate, please correct me).



Setting boot parameters for resume



Fresh installations of Ubuntu 17.04 and 17.10 have a swap file. If you have upgraded from an earlier installation, you will still have a swap partition. The procedure for setting up resume parameters is different if you have a swap file. Check your configuration by running



grep swap /etc/fstab


If you have a swap partition, the output will show the partition label, for example



# swap was on /dev/sda3 during installation


If there is no output, run



ls /


and look for /swapfile.



If you have a swap partition



To add the resume parameter, you would run



sudoedit /etc/default/grub       


Find the line that begins GRUB_CMDLINE_LINUX_DEFAULT= and add to the parameters between the double quotes the string resume=/Your/Swap/Partition, replacing /Your/Swap/Partition with the device file path you found in /etc/fstab. In the example I have given, the full line would probably be (depending on what other parameters were being used - quiet and splash are the default parameters on a desktop Ubuntu installation):



GRUB_CMDLINE_LINUX_DEFAULT="quiet splash resume=/dev/sda3"


After editing this file, you must run



sudo update-grub


to write the configuration to the file GRUB reads on boot. If you forget to do this, your changes will have no effect ;) You are also advised to reboot after this before attempting hibernation.



If you have a swap file



You need to set a parameter for resume from hibernation. Your /swapfile should be in your root partition, so set a boot parameter resume=/Your/Root/Partition where /Your/Root/Partition is the device file path for your root partition, for example, /dev/sda2. If you are not sure, check the contents of /etc/fstab to see which partition is mounted on /



You also need to set a boot parameter for the offset of the swap file. You can find the value for this parameter by running the command sudo filefrag -v /swapfile. Here is the start of this command's output on my system (it's exactly the same as the output I got on 17.04, but I'm now using Ubuntu MATE 17.10):



$ sudo filefrag -v /swapfile
Filesystem type is: ef53
File size of /swapfile is 1425873920 (348114 blocks of 4096 bytes)
ext: logical_offset: physical_offset: length: expected: flags:
0: 0.. 32767: 34816.. 67583: 32768:
1: 32768.. 63487: 67584.. 98303: 30720:
...


The number for the offset parameter is the first number in the physical_offset column. In my example, it's 34816. That means that the boot parameter I'd set would be resume_offset=34816.



To add the two boot parameters, edit the configuration file for GRUB:



sudoedit /etc/default/grub


Find the line beginning GRUB_CMDLINE_LINUX_DEFAULT= and add the two boot parameters, to that after your changes, the line reads something like



GRUB_CMDLINE_LINUX_DEFAULT="quiet splash resume=/dev/sda2 resume_offset=34816"


but replace /dev/sda2 and 34816 with the values for your system.



Save the file, exit, and run



sudo update-grub


to write the configuration to the file GRUB reads when it is loaded. Reboot, and try hibernation again.



If you still cannot hibernate, try disabling Secure Boot in your UEFI (or BIOS) settings, if not already done.



If you still cannot hibernate, you can attempt to debug the process by setting some additional boot parameters, as explained in detail in this post on debugging sleep states. Edit /etc/default/grub again, remove the parameters quiet and splash and add the debug parameters you want to try (for example, I use initctl_debug and no_console_suspend), run sudo update-grub, reboot, and try again.



Information made available by the debug parameters may lead you to figure out what is going wrong and might enable you to come up with a solution. I use my own system as a case study in my answer to another question on hibernation. In my case, the problem is always buggy drivers. In every version of Ubuntu I have used, I have needed to unload the brcmfmac module from the kernel before hibernation and reinsert it on resume. If more essential modules need to be unloaded, I use a sort of script (run with sudo bash filename) for hibernation (replacing list of buggy modules with the names of the actual modules that need to be pulled out):



modprobe -r list of buggy modules &&
echo disk > /sys/power/state
modprobe list of buggy modules


I use the && operator so that hibernation isn't attempted if unloading fails for some reason. If resume succeeds, the modules are immediately reloaded into the kernel, so the system should stay up.



You may well find different steps are needed for your particular system.






share|improve this answer


























  • Good description but I wouldn't attempt to try it. Ubuntu needs a supported Hibernation.

    – jpezz
    Dec 18 '17 at 23:50



















0














All of this works well for me for hibernating to file, thanks for the instructions! In my case I also had to get the latest stable kernel for hibernate to work, i.e. Ubuntu 17.10 and a dell xps 9370, I had to upgrade the kernel to 4.16.0rc






share|improve this answer































    0














    In my case this procedure did not work as described.



    I had to replace /dev/sdaXX with the UUID for /dev/sdaXX. Its UUID was
    d2175d30-aee3-418b-8c3f-d4ae61d13b3f

    so the editid line in GRUB2 looked like this:



    GRUB_CMDLINE_LINUX_DEFAULT="quiet splash resume=UUID=d2175d30-aee3-418b-8c3f-d4ae61d13b3f resume_offset=2367488"



    After that it worked.






    share|improve this answer

























      Your Answer








      StackExchange.ready(function() {
      var channelOptions = {
      tags: "".split(" "),
      id: "89"
      };
      initTagRenderer("".split(" "), "".split(" "), channelOptions);

      StackExchange.using("externalEditor", function() {
      // Have to fire editor after snippets, if snippets enabled
      if (StackExchange.settings.snippets.snippetsEnabled) {
      StackExchange.using("snippets", function() {
      createEditor();
      });
      }
      else {
      createEditor();
      }
      });

      function createEditor() {
      StackExchange.prepareEditor({
      heartbeatType: 'answer',
      autoActivateHeartbeat: false,
      convertImagesToLinks: true,
      noModals: true,
      showLowRepImageUploadWarning: true,
      reputationToPostImages: 10,
      bindNavPrevention: true,
      postfix: "",
      imageUploader: {
      brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
      contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
      allowUrls: true
      },
      onDemand: true,
      discardSelector: ".discard-answer"
      ,immediatelyShowMarkdownHelp:true
      });


      }
      });














      draft saved

      draft discarded


















      StackExchange.ready(
      function () {
      StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f987197%2fhow-can-i-hibernate-on-ubuntu-17-10-or-save-my-session%23new-answer', 'question_page');
      }
      );

      Post as a guest















      Required, but never shown

























      3 Answers
      3






      active

      oldest

      votes








      3 Answers
      3






      active

      oldest

      votes









      active

      oldest

      votes






      active

      oldest

      votes









      4














      The main source for this answer (aside from my own experience) is this page on the Arch Linux wiki.



      In this answer I use sudoedit to make changes to root-owned files. If you prefer, you can just call your favourite text editor with root permissions, but if you want to use a GUI editor and are using Wayland, see Why don't gksu/gksudo or launching a graphical application with sudo work with Wayland?).



      If you cannot hibernate, be aware that you can still (probably) save power by using the suspend state, where the state of RAM is maintained. The systemd command for this is systemctl suspend, and it's somewhat more likely to work than hibernation.





      It should be said that hibernation is not guaranteed to work; that's why initiating hibernation via the GUI is disabled by default. Even if you do everything right, you may still have problems. Your system may crash, your machine state may not be recoverable (you may lose unsaved work, for example) and you may find yourself in the sad situation of holding-down-the-power-button-for-a-very-long-time. I recommend only attempting to test hibernation after saving all of your work, and leaving only some idle application open (such as a terminal emulator that isn't doing anything).



      Hibernation involves writing the state of RAM to an area of the disk. The swap space is used for this purpose. Whether it is a file or a partition, it should work in the same way. The Arch Wiki says that you should be able to hibernate if your swap is at least 2/5 of the size of RAM. Redhat provide this guidance on swap size needed for hibernation which totally contradicts the Arch Wiki! But I recommend other debugging steps before you attempt to increase the size of swap space.



      If you are using Btrfs you may not be able to hibernate and Btrfs does not support swap files, according to the Arch Wiki. The default format for main partitions on Ubuntu 17.10 (and all other currently supported versions) is ext4, not Btrfs, so most users won't need to worry about this.



      NirajW's answer here explains how to test and enable hibernation if it works. The command it suggests is



      sudo pm-hibernate


      This fails for me no matter what other adjustments I make (my system instantly hangs and never recovers). Instead I use



      sudo systemctl hibernate


      You may also try



      echo disk | sudo tee /sys/power/state


      Hibernation is the lowest possible power state (ACPI S4). What should happen is that the system shuts down, the machine is off and can be left off indefinitely, and when you turn it back on, instead of a clean boot, you log in and resume your session.



      If you get a clean boot when you try to hibernate, the first thing to try is to set a boot parameter so that GRUB knows where to find the machine state to load back into RAM on resume (at least, that's how I understand the process. If this isn't accurate, please correct me).



      Setting boot parameters for resume



      Fresh installations of Ubuntu 17.04 and 17.10 have a swap file. If you have upgraded from an earlier installation, you will still have a swap partition. The procedure for setting up resume parameters is different if you have a swap file. Check your configuration by running



      grep swap /etc/fstab


      If you have a swap partition, the output will show the partition label, for example



      # swap was on /dev/sda3 during installation


      If there is no output, run



      ls /


      and look for /swapfile.



      If you have a swap partition



      To add the resume parameter, you would run



      sudoedit /etc/default/grub       


      Find the line that begins GRUB_CMDLINE_LINUX_DEFAULT= and add to the parameters between the double quotes the string resume=/Your/Swap/Partition, replacing /Your/Swap/Partition with the device file path you found in /etc/fstab. In the example I have given, the full line would probably be (depending on what other parameters were being used - quiet and splash are the default parameters on a desktop Ubuntu installation):



      GRUB_CMDLINE_LINUX_DEFAULT="quiet splash resume=/dev/sda3"


      After editing this file, you must run



      sudo update-grub


      to write the configuration to the file GRUB reads on boot. If you forget to do this, your changes will have no effect ;) You are also advised to reboot after this before attempting hibernation.



      If you have a swap file



      You need to set a parameter for resume from hibernation. Your /swapfile should be in your root partition, so set a boot parameter resume=/Your/Root/Partition where /Your/Root/Partition is the device file path for your root partition, for example, /dev/sda2. If you are not sure, check the contents of /etc/fstab to see which partition is mounted on /



      You also need to set a boot parameter for the offset of the swap file. You can find the value for this parameter by running the command sudo filefrag -v /swapfile. Here is the start of this command's output on my system (it's exactly the same as the output I got on 17.04, but I'm now using Ubuntu MATE 17.10):



      $ sudo filefrag -v /swapfile
      Filesystem type is: ef53
      File size of /swapfile is 1425873920 (348114 blocks of 4096 bytes)
      ext: logical_offset: physical_offset: length: expected: flags:
      0: 0.. 32767: 34816.. 67583: 32768:
      1: 32768.. 63487: 67584.. 98303: 30720:
      ...


      The number for the offset parameter is the first number in the physical_offset column. In my example, it's 34816. That means that the boot parameter I'd set would be resume_offset=34816.



      To add the two boot parameters, edit the configuration file for GRUB:



      sudoedit /etc/default/grub


      Find the line beginning GRUB_CMDLINE_LINUX_DEFAULT= and add the two boot parameters, to that after your changes, the line reads something like



      GRUB_CMDLINE_LINUX_DEFAULT="quiet splash resume=/dev/sda2 resume_offset=34816"


      but replace /dev/sda2 and 34816 with the values for your system.



      Save the file, exit, and run



      sudo update-grub


      to write the configuration to the file GRUB reads when it is loaded. Reboot, and try hibernation again.



      If you still cannot hibernate, try disabling Secure Boot in your UEFI (or BIOS) settings, if not already done.



      If you still cannot hibernate, you can attempt to debug the process by setting some additional boot parameters, as explained in detail in this post on debugging sleep states. Edit /etc/default/grub again, remove the parameters quiet and splash and add the debug parameters you want to try (for example, I use initctl_debug and no_console_suspend), run sudo update-grub, reboot, and try again.



      Information made available by the debug parameters may lead you to figure out what is going wrong and might enable you to come up with a solution. I use my own system as a case study in my answer to another question on hibernation. In my case, the problem is always buggy drivers. In every version of Ubuntu I have used, I have needed to unload the brcmfmac module from the kernel before hibernation and reinsert it on resume. If more essential modules need to be unloaded, I use a sort of script (run with sudo bash filename) for hibernation (replacing list of buggy modules with the names of the actual modules that need to be pulled out):



      modprobe -r list of buggy modules &&
      echo disk > /sys/power/state
      modprobe list of buggy modules


      I use the && operator so that hibernation isn't attempted if unloading fails for some reason. If resume succeeds, the modules are immediately reloaded into the kernel, so the system should stay up.



      You may well find different steps are needed for your particular system.






      share|improve this answer


























      • Good description but I wouldn't attempt to try it. Ubuntu needs a supported Hibernation.

        – jpezz
        Dec 18 '17 at 23:50
















      4














      The main source for this answer (aside from my own experience) is this page on the Arch Linux wiki.



      In this answer I use sudoedit to make changes to root-owned files. If you prefer, you can just call your favourite text editor with root permissions, but if you want to use a GUI editor and are using Wayland, see Why don't gksu/gksudo or launching a graphical application with sudo work with Wayland?).



      If you cannot hibernate, be aware that you can still (probably) save power by using the suspend state, where the state of RAM is maintained. The systemd command for this is systemctl suspend, and it's somewhat more likely to work than hibernation.





      It should be said that hibernation is not guaranteed to work; that's why initiating hibernation via the GUI is disabled by default. Even if you do everything right, you may still have problems. Your system may crash, your machine state may not be recoverable (you may lose unsaved work, for example) and you may find yourself in the sad situation of holding-down-the-power-button-for-a-very-long-time. I recommend only attempting to test hibernation after saving all of your work, and leaving only some idle application open (such as a terminal emulator that isn't doing anything).



      Hibernation involves writing the state of RAM to an area of the disk. The swap space is used for this purpose. Whether it is a file or a partition, it should work in the same way. The Arch Wiki says that you should be able to hibernate if your swap is at least 2/5 of the size of RAM. Redhat provide this guidance on swap size needed for hibernation which totally contradicts the Arch Wiki! But I recommend other debugging steps before you attempt to increase the size of swap space.



      If you are using Btrfs you may not be able to hibernate and Btrfs does not support swap files, according to the Arch Wiki. The default format for main partitions on Ubuntu 17.10 (and all other currently supported versions) is ext4, not Btrfs, so most users won't need to worry about this.



      NirajW's answer here explains how to test and enable hibernation if it works. The command it suggests is



      sudo pm-hibernate


      This fails for me no matter what other adjustments I make (my system instantly hangs and never recovers). Instead I use



      sudo systemctl hibernate


      You may also try



      echo disk | sudo tee /sys/power/state


      Hibernation is the lowest possible power state (ACPI S4). What should happen is that the system shuts down, the machine is off and can be left off indefinitely, and when you turn it back on, instead of a clean boot, you log in and resume your session.



      If you get a clean boot when you try to hibernate, the first thing to try is to set a boot parameter so that GRUB knows where to find the machine state to load back into RAM on resume (at least, that's how I understand the process. If this isn't accurate, please correct me).



      Setting boot parameters for resume



      Fresh installations of Ubuntu 17.04 and 17.10 have a swap file. If you have upgraded from an earlier installation, you will still have a swap partition. The procedure for setting up resume parameters is different if you have a swap file. Check your configuration by running



      grep swap /etc/fstab


      If you have a swap partition, the output will show the partition label, for example



      # swap was on /dev/sda3 during installation


      If there is no output, run



      ls /


      and look for /swapfile.



      If you have a swap partition



      To add the resume parameter, you would run



      sudoedit /etc/default/grub       


      Find the line that begins GRUB_CMDLINE_LINUX_DEFAULT= and add to the parameters between the double quotes the string resume=/Your/Swap/Partition, replacing /Your/Swap/Partition with the device file path you found in /etc/fstab. In the example I have given, the full line would probably be (depending on what other parameters were being used - quiet and splash are the default parameters on a desktop Ubuntu installation):



      GRUB_CMDLINE_LINUX_DEFAULT="quiet splash resume=/dev/sda3"


      After editing this file, you must run



      sudo update-grub


      to write the configuration to the file GRUB reads on boot. If you forget to do this, your changes will have no effect ;) You are also advised to reboot after this before attempting hibernation.



      If you have a swap file



      You need to set a parameter for resume from hibernation. Your /swapfile should be in your root partition, so set a boot parameter resume=/Your/Root/Partition where /Your/Root/Partition is the device file path for your root partition, for example, /dev/sda2. If you are not sure, check the contents of /etc/fstab to see which partition is mounted on /



      You also need to set a boot parameter for the offset of the swap file. You can find the value for this parameter by running the command sudo filefrag -v /swapfile. Here is the start of this command's output on my system (it's exactly the same as the output I got on 17.04, but I'm now using Ubuntu MATE 17.10):



      $ sudo filefrag -v /swapfile
      Filesystem type is: ef53
      File size of /swapfile is 1425873920 (348114 blocks of 4096 bytes)
      ext: logical_offset: physical_offset: length: expected: flags:
      0: 0.. 32767: 34816.. 67583: 32768:
      1: 32768.. 63487: 67584.. 98303: 30720:
      ...


      The number for the offset parameter is the first number in the physical_offset column. In my example, it's 34816. That means that the boot parameter I'd set would be resume_offset=34816.



      To add the two boot parameters, edit the configuration file for GRUB:



      sudoedit /etc/default/grub


      Find the line beginning GRUB_CMDLINE_LINUX_DEFAULT= and add the two boot parameters, to that after your changes, the line reads something like



      GRUB_CMDLINE_LINUX_DEFAULT="quiet splash resume=/dev/sda2 resume_offset=34816"


      but replace /dev/sda2 and 34816 with the values for your system.



      Save the file, exit, and run



      sudo update-grub


      to write the configuration to the file GRUB reads when it is loaded. Reboot, and try hibernation again.



      If you still cannot hibernate, try disabling Secure Boot in your UEFI (or BIOS) settings, if not already done.



      If you still cannot hibernate, you can attempt to debug the process by setting some additional boot parameters, as explained in detail in this post on debugging sleep states. Edit /etc/default/grub again, remove the parameters quiet and splash and add the debug parameters you want to try (for example, I use initctl_debug and no_console_suspend), run sudo update-grub, reboot, and try again.



      Information made available by the debug parameters may lead you to figure out what is going wrong and might enable you to come up with a solution. I use my own system as a case study in my answer to another question on hibernation. In my case, the problem is always buggy drivers. In every version of Ubuntu I have used, I have needed to unload the brcmfmac module from the kernel before hibernation and reinsert it on resume. If more essential modules need to be unloaded, I use a sort of script (run with sudo bash filename) for hibernation (replacing list of buggy modules with the names of the actual modules that need to be pulled out):



      modprobe -r list of buggy modules &&
      echo disk > /sys/power/state
      modprobe list of buggy modules


      I use the && operator so that hibernation isn't attempted if unloading fails for some reason. If resume succeeds, the modules are immediately reloaded into the kernel, so the system should stay up.



      You may well find different steps are needed for your particular system.






      share|improve this answer


























      • Good description but I wouldn't attempt to try it. Ubuntu needs a supported Hibernation.

        – jpezz
        Dec 18 '17 at 23:50














      4












      4








      4







      The main source for this answer (aside from my own experience) is this page on the Arch Linux wiki.



      In this answer I use sudoedit to make changes to root-owned files. If you prefer, you can just call your favourite text editor with root permissions, but if you want to use a GUI editor and are using Wayland, see Why don't gksu/gksudo or launching a graphical application with sudo work with Wayland?).



      If you cannot hibernate, be aware that you can still (probably) save power by using the suspend state, where the state of RAM is maintained. The systemd command for this is systemctl suspend, and it's somewhat more likely to work than hibernation.





      It should be said that hibernation is not guaranteed to work; that's why initiating hibernation via the GUI is disabled by default. Even if you do everything right, you may still have problems. Your system may crash, your machine state may not be recoverable (you may lose unsaved work, for example) and you may find yourself in the sad situation of holding-down-the-power-button-for-a-very-long-time. I recommend only attempting to test hibernation after saving all of your work, and leaving only some idle application open (such as a terminal emulator that isn't doing anything).



      Hibernation involves writing the state of RAM to an area of the disk. The swap space is used for this purpose. Whether it is a file or a partition, it should work in the same way. The Arch Wiki says that you should be able to hibernate if your swap is at least 2/5 of the size of RAM. Redhat provide this guidance on swap size needed for hibernation which totally contradicts the Arch Wiki! But I recommend other debugging steps before you attempt to increase the size of swap space.



      If you are using Btrfs you may not be able to hibernate and Btrfs does not support swap files, according to the Arch Wiki. The default format for main partitions on Ubuntu 17.10 (and all other currently supported versions) is ext4, not Btrfs, so most users won't need to worry about this.



      NirajW's answer here explains how to test and enable hibernation if it works. The command it suggests is



      sudo pm-hibernate


      This fails for me no matter what other adjustments I make (my system instantly hangs and never recovers). Instead I use



      sudo systemctl hibernate


      You may also try



      echo disk | sudo tee /sys/power/state


      Hibernation is the lowest possible power state (ACPI S4). What should happen is that the system shuts down, the machine is off and can be left off indefinitely, and when you turn it back on, instead of a clean boot, you log in and resume your session.



      If you get a clean boot when you try to hibernate, the first thing to try is to set a boot parameter so that GRUB knows where to find the machine state to load back into RAM on resume (at least, that's how I understand the process. If this isn't accurate, please correct me).



      Setting boot parameters for resume



      Fresh installations of Ubuntu 17.04 and 17.10 have a swap file. If you have upgraded from an earlier installation, you will still have a swap partition. The procedure for setting up resume parameters is different if you have a swap file. Check your configuration by running



      grep swap /etc/fstab


      If you have a swap partition, the output will show the partition label, for example



      # swap was on /dev/sda3 during installation


      If there is no output, run



      ls /


      and look for /swapfile.



      If you have a swap partition



      To add the resume parameter, you would run



      sudoedit /etc/default/grub       


      Find the line that begins GRUB_CMDLINE_LINUX_DEFAULT= and add to the parameters between the double quotes the string resume=/Your/Swap/Partition, replacing /Your/Swap/Partition with the device file path you found in /etc/fstab. In the example I have given, the full line would probably be (depending on what other parameters were being used - quiet and splash are the default parameters on a desktop Ubuntu installation):



      GRUB_CMDLINE_LINUX_DEFAULT="quiet splash resume=/dev/sda3"


      After editing this file, you must run



      sudo update-grub


      to write the configuration to the file GRUB reads on boot. If you forget to do this, your changes will have no effect ;) You are also advised to reboot after this before attempting hibernation.



      If you have a swap file



      You need to set a parameter for resume from hibernation. Your /swapfile should be in your root partition, so set a boot parameter resume=/Your/Root/Partition where /Your/Root/Partition is the device file path for your root partition, for example, /dev/sda2. If you are not sure, check the contents of /etc/fstab to see which partition is mounted on /



      You also need to set a boot parameter for the offset of the swap file. You can find the value for this parameter by running the command sudo filefrag -v /swapfile. Here is the start of this command's output on my system (it's exactly the same as the output I got on 17.04, but I'm now using Ubuntu MATE 17.10):



      $ sudo filefrag -v /swapfile
      Filesystem type is: ef53
      File size of /swapfile is 1425873920 (348114 blocks of 4096 bytes)
      ext: logical_offset: physical_offset: length: expected: flags:
      0: 0.. 32767: 34816.. 67583: 32768:
      1: 32768.. 63487: 67584.. 98303: 30720:
      ...


      The number for the offset parameter is the first number in the physical_offset column. In my example, it's 34816. That means that the boot parameter I'd set would be resume_offset=34816.



      To add the two boot parameters, edit the configuration file for GRUB:



      sudoedit /etc/default/grub


      Find the line beginning GRUB_CMDLINE_LINUX_DEFAULT= and add the two boot parameters, to that after your changes, the line reads something like



      GRUB_CMDLINE_LINUX_DEFAULT="quiet splash resume=/dev/sda2 resume_offset=34816"


      but replace /dev/sda2 and 34816 with the values for your system.



      Save the file, exit, and run



      sudo update-grub


      to write the configuration to the file GRUB reads when it is loaded. Reboot, and try hibernation again.



      If you still cannot hibernate, try disabling Secure Boot in your UEFI (or BIOS) settings, if not already done.



      If you still cannot hibernate, you can attempt to debug the process by setting some additional boot parameters, as explained in detail in this post on debugging sleep states. Edit /etc/default/grub again, remove the parameters quiet and splash and add the debug parameters you want to try (for example, I use initctl_debug and no_console_suspend), run sudo update-grub, reboot, and try again.



      Information made available by the debug parameters may lead you to figure out what is going wrong and might enable you to come up with a solution. I use my own system as a case study in my answer to another question on hibernation. In my case, the problem is always buggy drivers. In every version of Ubuntu I have used, I have needed to unload the brcmfmac module from the kernel before hibernation and reinsert it on resume. If more essential modules need to be unloaded, I use a sort of script (run with sudo bash filename) for hibernation (replacing list of buggy modules with the names of the actual modules that need to be pulled out):



      modprobe -r list of buggy modules &&
      echo disk > /sys/power/state
      modprobe list of buggy modules


      I use the && operator so that hibernation isn't attempted if unloading fails for some reason. If resume succeeds, the modules are immediately reloaded into the kernel, so the system should stay up.



      You may well find different steps are needed for your particular system.






      share|improve this answer















      The main source for this answer (aside from my own experience) is this page on the Arch Linux wiki.



      In this answer I use sudoedit to make changes to root-owned files. If you prefer, you can just call your favourite text editor with root permissions, but if you want to use a GUI editor and are using Wayland, see Why don't gksu/gksudo or launching a graphical application with sudo work with Wayland?).



      If you cannot hibernate, be aware that you can still (probably) save power by using the suspend state, where the state of RAM is maintained. The systemd command for this is systemctl suspend, and it's somewhat more likely to work than hibernation.





      It should be said that hibernation is not guaranteed to work; that's why initiating hibernation via the GUI is disabled by default. Even if you do everything right, you may still have problems. Your system may crash, your machine state may not be recoverable (you may lose unsaved work, for example) and you may find yourself in the sad situation of holding-down-the-power-button-for-a-very-long-time. I recommend only attempting to test hibernation after saving all of your work, and leaving only some idle application open (such as a terminal emulator that isn't doing anything).



      Hibernation involves writing the state of RAM to an area of the disk. The swap space is used for this purpose. Whether it is a file or a partition, it should work in the same way. The Arch Wiki says that you should be able to hibernate if your swap is at least 2/5 of the size of RAM. Redhat provide this guidance on swap size needed for hibernation which totally contradicts the Arch Wiki! But I recommend other debugging steps before you attempt to increase the size of swap space.



      If you are using Btrfs you may not be able to hibernate and Btrfs does not support swap files, according to the Arch Wiki. The default format for main partitions on Ubuntu 17.10 (and all other currently supported versions) is ext4, not Btrfs, so most users won't need to worry about this.



      NirajW's answer here explains how to test and enable hibernation if it works. The command it suggests is



      sudo pm-hibernate


      This fails for me no matter what other adjustments I make (my system instantly hangs and never recovers). Instead I use



      sudo systemctl hibernate


      You may also try



      echo disk | sudo tee /sys/power/state


      Hibernation is the lowest possible power state (ACPI S4). What should happen is that the system shuts down, the machine is off and can be left off indefinitely, and when you turn it back on, instead of a clean boot, you log in and resume your session.



      If you get a clean boot when you try to hibernate, the first thing to try is to set a boot parameter so that GRUB knows where to find the machine state to load back into RAM on resume (at least, that's how I understand the process. If this isn't accurate, please correct me).



      Setting boot parameters for resume



      Fresh installations of Ubuntu 17.04 and 17.10 have a swap file. If you have upgraded from an earlier installation, you will still have a swap partition. The procedure for setting up resume parameters is different if you have a swap file. Check your configuration by running



      grep swap /etc/fstab


      If you have a swap partition, the output will show the partition label, for example



      # swap was on /dev/sda3 during installation


      If there is no output, run



      ls /


      and look for /swapfile.



      If you have a swap partition



      To add the resume parameter, you would run



      sudoedit /etc/default/grub       


      Find the line that begins GRUB_CMDLINE_LINUX_DEFAULT= and add to the parameters between the double quotes the string resume=/Your/Swap/Partition, replacing /Your/Swap/Partition with the device file path you found in /etc/fstab. In the example I have given, the full line would probably be (depending on what other parameters were being used - quiet and splash are the default parameters on a desktop Ubuntu installation):



      GRUB_CMDLINE_LINUX_DEFAULT="quiet splash resume=/dev/sda3"


      After editing this file, you must run



      sudo update-grub


      to write the configuration to the file GRUB reads on boot. If you forget to do this, your changes will have no effect ;) You are also advised to reboot after this before attempting hibernation.



      If you have a swap file



      You need to set a parameter for resume from hibernation. Your /swapfile should be in your root partition, so set a boot parameter resume=/Your/Root/Partition where /Your/Root/Partition is the device file path for your root partition, for example, /dev/sda2. If you are not sure, check the contents of /etc/fstab to see which partition is mounted on /



      You also need to set a boot parameter for the offset of the swap file. You can find the value for this parameter by running the command sudo filefrag -v /swapfile. Here is the start of this command's output on my system (it's exactly the same as the output I got on 17.04, but I'm now using Ubuntu MATE 17.10):



      $ sudo filefrag -v /swapfile
      Filesystem type is: ef53
      File size of /swapfile is 1425873920 (348114 blocks of 4096 bytes)
      ext: logical_offset: physical_offset: length: expected: flags:
      0: 0.. 32767: 34816.. 67583: 32768:
      1: 32768.. 63487: 67584.. 98303: 30720:
      ...


      The number for the offset parameter is the first number in the physical_offset column. In my example, it's 34816. That means that the boot parameter I'd set would be resume_offset=34816.



      To add the two boot parameters, edit the configuration file for GRUB:



      sudoedit /etc/default/grub


      Find the line beginning GRUB_CMDLINE_LINUX_DEFAULT= and add the two boot parameters, to that after your changes, the line reads something like



      GRUB_CMDLINE_LINUX_DEFAULT="quiet splash resume=/dev/sda2 resume_offset=34816"


      but replace /dev/sda2 and 34816 with the values for your system.



      Save the file, exit, and run



      sudo update-grub


      to write the configuration to the file GRUB reads when it is loaded. Reboot, and try hibernation again.



      If you still cannot hibernate, try disabling Secure Boot in your UEFI (or BIOS) settings, if not already done.



      If you still cannot hibernate, you can attempt to debug the process by setting some additional boot parameters, as explained in detail in this post on debugging sleep states. Edit /etc/default/grub again, remove the parameters quiet and splash and add the debug parameters you want to try (for example, I use initctl_debug and no_console_suspend), run sudo update-grub, reboot, and try again.



      Information made available by the debug parameters may lead you to figure out what is going wrong and might enable you to come up with a solution. I use my own system as a case study in my answer to another question on hibernation. In my case, the problem is always buggy drivers. In every version of Ubuntu I have used, I have needed to unload the brcmfmac module from the kernel before hibernation and reinsert it on resume. If more essential modules need to be unloaded, I use a sort of script (run with sudo bash filename) for hibernation (replacing list of buggy modules with the names of the actual modules that need to be pulled out):



      modprobe -r list of buggy modules &&
      echo disk > /sys/power/state
      modprobe list of buggy modules


      I use the && operator so that hibernation isn't attempted if unloading fails for some reason. If resume succeeds, the modules are immediately reloaded into the kernel, so the system should stay up.



      You may well find different steps are needed for your particular system.







      share|improve this answer














      share|improve this answer



      share|improve this answer








      edited Dec 21 '17 at 20:39

























      answered Dec 18 '17 at 22:13









      ZannaZanna

      51.1k13138242




      51.1k13138242













      • Good description but I wouldn't attempt to try it. Ubuntu needs a supported Hibernation.

        – jpezz
        Dec 18 '17 at 23:50



















      • Good description but I wouldn't attempt to try it. Ubuntu needs a supported Hibernation.

        – jpezz
        Dec 18 '17 at 23:50

















      Good description but I wouldn't attempt to try it. Ubuntu needs a supported Hibernation.

      – jpezz
      Dec 18 '17 at 23:50





      Good description but I wouldn't attempt to try it. Ubuntu needs a supported Hibernation.

      – jpezz
      Dec 18 '17 at 23:50













      0














      All of this works well for me for hibernating to file, thanks for the instructions! In my case I also had to get the latest stable kernel for hibernate to work, i.e. Ubuntu 17.10 and a dell xps 9370, I had to upgrade the kernel to 4.16.0rc






      share|improve this answer




























        0














        All of this works well for me for hibernating to file, thanks for the instructions! In my case I also had to get the latest stable kernel for hibernate to work, i.e. Ubuntu 17.10 and a dell xps 9370, I had to upgrade the kernel to 4.16.0rc






        share|improve this answer


























          0












          0








          0







          All of this works well for me for hibernating to file, thanks for the instructions! In my case I also had to get the latest stable kernel for hibernate to work, i.e. Ubuntu 17.10 and a dell xps 9370, I had to upgrade the kernel to 4.16.0rc






          share|improve this answer













          All of this works well for me for hibernating to file, thanks for the instructions! In my case I also had to get the latest stable kernel for hibernate to work, i.e. Ubuntu 17.10 and a dell xps 9370, I had to upgrade the kernel to 4.16.0rc







          share|improve this answer












          share|improve this answer



          share|improve this answer










          answered Mar 20 '18 at 11:08









          user2003706user2003706

          1




          1























              0














              In my case this procedure did not work as described.



              I had to replace /dev/sdaXX with the UUID for /dev/sdaXX. Its UUID was
              d2175d30-aee3-418b-8c3f-d4ae61d13b3f

              so the editid line in GRUB2 looked like this:



              GRUB_CMDLINE_LINUX_DEFAULT="quiet splash resume=UUID=d2175d30-aee3-418b-8c3f-d4ae61d13b3f resume_offset=2367488"



              After that it worked.






              share|improve this answer






























                0














                In my case this procedure did not work as described.



                I had to replace /dev/sdaXX with the UUID for /dev/sdaXX. Its UUID was
                d2175d30-aee3-418b-8c3f-d4ae61d13b3f

                so the editid line in GRUB2 looked like this:



                GRUB_CMDLINE_LINUX_DEFAULT="quiet splash resume=UUID=d2175d30-aee3-418b-8c3f-d4ae61d13b3f resume_offset=2367488"



                After that it worked.






                share|improve this answer




























                  0












                  0








                  0







                  In my case this procedure did not work as described.



                  I had to replace /dev/sdaXX with the UUID for /dev/sdaXX. Its UUID was
                  d2175d30-aee3-418b-8c3f-d4ae61d13b3f

                  so the editid line in GRUB2 looked like this:



                  GRUB_CMDLINE_LINUX_DEFAULT="quiet splash resume=UUID=d2175d30-aee3-418b-8c3f-d4ae61d13b3f resume_offset=2367488"



                  After that it worked.






                  share|improve this answer















                  In my case this procedure did not work as described.



                  I had to replace /dev/sdaXX with the UUID for /dev/sdaXX. Its UUID was
                  d2175d30-aee3-418b-8c3f-d4ae61d13b3f

                  so the editid line in GRUB2 looked like this:



                  GRUB_CMDLINE_LINUX_DEFAULT="quiet splash resume=UUID=d2175d30-aee3-418b-8c3f-d4ae61d13b3f resume_offset=2367488"



                  After that it worked.







                  share|improve this answer














                  share|improve this answer



                  share|improve this answer








                  edited Jan 31 at 21:33









                  K7AAY

                  4,01921744




                  4,01921744










                  answered Jan 31 at 13:55









                  Martin EcheniqueMartin Echenique

                  1




                  1






























                      draft saved

                      draft discarded




















































                      Thanks for contributing an answer to Ask Ubuntu!


                      • Please be sure to answer the question. Provide details and share your research!

                      But avoid



                      • Asking for help, clarification, or responding to other answers.

                      • Making statements based on opinion; back them up with references or personal experience.


                      To learn more, see our tips on writing great answers.




                      draft saved


                      draft discarded














                      StackExchange.ready(
                      function () {
                      StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f987197%2fhow-can-i-hibernate-on-ubuntu-17-10-or-save-my-session%23new-answer', 'question_page');
                      }
                      );

                      Post as a guest















                      Required, but never shown





















































                      Required, but never shown














                      Required, but never shown












                      Required, but never shown







                      Required, but never shown

































                      Required, but never shown














                      Required, but never shown












                      Required, but never shown







                      Required, but never shown







                      Popular posts from this blog

                      mysqli_query(): Empty query in /home/lucindabrummitt/public_html/blog/wp-includes/wp-db.php on line 1924

                      How to change which sound is reproduced for terminal bell?

                      Can I use Tabulator js library in my java Spring + Thymeleaf project?