Ridiculous hibernation problem

Questions about Grub, UEFI,the liveCD and the installer
Forum rules
Before you post please read how to get help
Post Reply
emil_pavlov
Level 2
Level 2
Posts: 70
Joined: Sun Feb 03, 2008 11:06 am

Ridiculous hibernation problem

Post by emil_pavlov » Thu Nov 30, 2017 3:19 pm

I used to have 3.7 Gig Ram + 4 Gig swap and hibernation was working perfect. Then, I treated myself to 7.7 Gig Ram, so I expanded my swap to 8.0 Gig (in a single partition).

The problem is that my computer won't hibernate if the more than 4 Gig of memory are used. I am guessing it still thinks my swap is half as big.

I have LM 18.3 with Cin., but problem existed with 18.2 too.

Swappiness is zero. System monitor show 8 Gig of swap.

User avatar
administrollaattori
Level 15
Level 15
Posts: 5646
Joined: Tue Sep 03, 2013 4:51 am
Location: Finland
Contact:

Re: Ridiculous hibernation problem

Post by administrollaattori » Fri Dec 01, 2017 2:12 am

Is swap-partitions UUID correct in the /etc/fstab file? Compare sudo blkid output UUIDs with cat /etc/fstab outputs.

emil_pavlov
Level 2
Level 2
Posts: 70
Joined: Sun Feb 03, 2008 11:06 am

Re: Ridiculous hibernation problem

Post by emil_pavlov » Fri Dec 01, 2017 10:08 am

yes

this is from

Code: Select all

blkid

Code: Select all

/dev/sda6: UUID="a3d68e82-84c5-4a6f-b9f2-edb776b4c3c2" TYPE="swap" PARTUUID="c3ffc3ff-06"
this is

Code: Select all

fstab

Code: Select all

# swap was on /dev/sda6 during installation
UUID=a3d68e82-84c5-4a6f-b9f2-edb776b4c3c2 none            swap    sw              0       0
this is

Code: Select all

free -m

Code: Select all

              total        used        free      shared  buff/cache   available
Mem:           7924        1758        4508          66        1658        5744
Swap:          8204           0        8204

Mute Ant
Level 13
Level 13
Posts: 4942
Joined: Tue Sep 03, 2013 7:45 pm
Location: Norfolk UK

Re: Ridiculous hibernation problem

Post by Mute Ant » Fri Dec 01, 2017 7:37 pm

You should look at the text in /boot/grub/grub.cfg too. There should be something like...
linux blah-blah-blah resume=UUID=a3d68e82-84c5-4a6f-b9f2-edb776b4c3c2 blah-blah-sparklers-blah
...for the kernel to know exactly which partition to fetch into RAM next boot, and I guess the same UUID is used to save-and-hibernate.

https://www.ibm.com/support/knowledgece ... meter.html
Tommy reports the scan of zircon and opal storage is complete. When shall we go today?

emil_pavlov
Level 2
Level 2
Posts: 70
Joined: Sun Feb 03, 2008 11:06 am

Re: Ridiculous hibernation problem

Post by emil_pavlov » Sat Dec 02, 2017 7:53 am

My file has no resume only this

Code: Select all

linux	/boot/vmlinuz-4.10.0-26-generic root=UUID=46...1c ro recovery nomodeset

Mute Ant
Level 13
Level 13
Posts: 4942
Joined: Tue Sep 03, 2013 7:45 pm
Location: Norfolk UK

Re: Ridiculous hibernation problem

Post by Mute Ant » Sat Dec 02, 2017 11:16 am

I don't know which part of Mint organises the 'resume' function. It won't hurt to set it manually (I guess). Editing the file /etc/default/grub as root will let you set kernel arguments...

GRUB_CMDLINE_LINUX="resume=UUID=a3d68e82-84c5-4a6f-b9f2-edb776b4c3c2"

...then do an update-grub to rebuild the /boot/grub/grub.cfg file.
Tommy reports the scan of zircon and opal storage is complete. When shall we go today?

rene
Level 8
Level 8
Posts: 2348
Joined: Sun Mar 27, 2016 6:58 pm

Re: Ridiculous hibernation problem

Post by rene » Sat Dec 02, 2017 11:58 am

While it's inconsistent with your free output reporting the correct 8G already the only thing that seems to otherwise make sense is needing to reformat your swap space

Code: Select all

sudo swapoff -a
sudo mkswap /dev/sda6
sudo blkid /dev/sda6
<update the UUID in /etc/fstab>
sudo swapon -a

emil_pavlov
Level 2
Level 2
Posts: 70
Joined: Sun Feb 03, 2008 11:06 am

Re: Ridiculous hibernation problem

Post by emil_pavlov » Sat Dec 02, 2017 8:16 pm

No, both did not work.

rene
Level 8
Level 8
Posts: 2348
Joined: Sun Mar 27, 2016 6:58 pm

Re: Ridiculous hibernation problem

Post by rene » Sun Dec 03, 2017 6:24 am

I am assuming that when you say "my computer won't hibernate" you do not just mean that the system won't resume from hibernation but that it will not even start to hibernate; this would make this be a strange problem.

As to the /etc/default/grub advise you got above: resume is handled by the initrd, and you needn't/shouldn't set the resume= parameter manually, nor should any such parameter have an effect on hibernation start; you should remove it from /etc/default/grub again. Remember to rerun sudo update-grub after changing /etc/default/grub.

The resume UUID is on Debian based systems stored in /etc/initramfs-tools/conf.d/resume; simply updating the initrd does not work to update it once set; as far as I can currently find not any automated tool updates it. Which makes some theoretical sense; the system supposedly does not know which one of your potential multitude of swap partitions you use for hibernation. You'll need to plug in the new UUID for your swap partition also in that file and regenerate your initrd's through sudo update-initramfs -u -k all.

Certainly do that now that you remade your swap space with mkswap above but this again concerns resume only. If indeed hibernation in your case won't even start I do not believe to have much interesting to add.

emil_pavlov
Level 2
Level 2
Posts: 70
Joined: Sun Feb 03, 2008 11:06 am

Re: Ridiculous hibernation problem

Post by emil_pavlov » Sun Dec 03, 2017 8:35 am

Sorry, I should have explained it better.
My system has no problems with resuming from hibernation. The problem is with going into hibernation. If the used ram is more than 4 Gigs or so, the process will start, the screen will go blank, but after a few seconds system comes back again to normal desktop and reconnects with the wifi. If my used memory drops below that, there is no problem with hibernation. I can actually see error messages from previous failed hibernation attempts since the last restart, which say something like "blabla longer than available space in blabla". It's not partitions or UUID, but some other gibberish. I suspect that some of the hibernation scripts checks for available swap space, but has the old value instead of the current one somehow. Anyway, I will try to write down the error, but it comes on only for a short time.

Indeed, the resume UUID was stored in /etc/initramfs-tools/conf.d/resume, I updated it. I also reverted /etc/default/grub to its default.


UPDATE
here is /var/log/pm-suspend.log

Code: Select all

sudo cat /var/log/pm-suspend.log
Initial commandline parameters: 
нд дек  3 13:50:56 CET 2017: Running hooks for hibernate.
Running hook /usr/lib/pm-utils/sleep.d/000kernel-change hibernate hibernate:
/usr/lib/pm-utils/sleep.d/000kernel-change hibernate hibernate: success.

Running hook /usr/lib/pm-utils/sleep.d/00logging hibernate hibernate:
Linux emil-Rev-1-0 4.10.0-26-generic #30~16.04.1-Ubuntu SMP Tue Jun 27 09:40:14 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
Module                  Size  Used by
cpuid                  16384  0
ufs                    73728  0
qnx4                   16384  0
hfsplus               106496  0
hfs                    57344  0
minix                  36864  0
ntfs                  102400  0
msdos                  20480  0
jfs                   184320  0
xfs                  1191936  0
hid_generic            16384  0
usbhid                 53248  0
hid                   118784  2 hid_generic,usbhid
bbswitch               16384  0
binfmt_misc            20480  1
nvidia_uvm            671744  0
nvidia_drm             45056  3
nvidia_modeset        843776  4 nvidia_drm
nvidia              13004800  269 nvidia_modeset,nvidia_uvm
uvcvideo               90112  0
videobuf2_vmalloc      16384  1 uvcvideo
videobuf2_memops       16384  1 videobuf2_vmalloc
videobuf2_v4l2         24576  1 uvcvideo
videobuf2_core         40960  2 uvcvideo,videobuf2_v4l2
wl                   6447104  0
snd_hda_codec_hdmi     49152  1
intel_rapl             20480  0
x86_pkg_temp_thermal    16384  0
intel_powerclamp       16384  0
snd_hda_codec_realtek    90112  1
snd_hda_codec_generic    73728  1 snd_hda_codec_realtek
coretemp               16384  0
kvm_intel             200704  0
kvm                   593920  1 kvm_intel
irqbypass              16384  1 kvm
snd_hda_intel          36864  5
crct10dif_pclmul       16384  0
snd_hda_codec         126976  4 snd_hda_intel,snd_hda_codec_hdmi,snd_hda_codec_generic,snd_hda_codec_realtek
crc32_pclmul           16384  0
ghash_clmulni_intel    16384  0
snd_hda_core           81920  5 snd_hda_intel,snd_hda_codec,snd_hda_codec_hdmi,snd_hda_codec_generic,snd_hda_codec_realtek
pcbc                   16384  0
snd_hwdep              16384  1 snd_hda_codec
snd_pcm               102400  5 snd_hda_intel,snd_hda_codec,snd_hda_core,snd_hda_codec_hdmi
snd_seq_midi           16384  0
aesni_intel           167936  0
snd_seq_midi_event     16384  1 snd_seq_midi
aes_x86_64             20480  1 aesni_intel
snd_rawmidi            32768  1 snd_seq_midi
crypto_simd            16384  1 aesni_intel
glue_helper            16384  1 aesni_intel
cryptd                 24576  3 crypto_simd,ghash_clmulni_intel,aesni_intel
intel_cstate           20480  0
intel_rapl_perf        16384  0
snd_seq                65536  2 snd_seq_midi_event,snd_seq_midi
input_leds             16384  0
joydev                 20480  0
jmb38x_ms              20480  0
snd_seq_device         16384  3 snd_seq,snd_rawmidi,snd_seq_midi
serio_raw              16384  0
snd_timer              32768  2 snd_seq,snd_pcm
memstick               16384  1 jmb38x_ms
cfg80211              602112  1 wl
snd                    77824  20 snd_hda_intel,snd_hwdep,snd_seq,snd_hda_codec,snd_timer,snd_rawmidi,snd_hda_codec_hdmi,snd_hda_codec_generic,snd_seq_device,snd_hda_codec_realtek,snd_pcm
mei_me                 40960  0
lpc_ich                24576  0
mei                   102400  1 mei_me
soundcore              16384  1 snd
shpchp                 36864  0
ideapad_laptop         24576  0
sparse_keymap          16384  1 ideapad_laptop
mxm_wmi                16384  0
wmi                    16384  2 mxm_wmi,ideapad_laptop
mac_hid                16384  0
ip6t_REJECT            16384  1
nf_reject_ipv6         16384  1 ip6t_REJECT
nf_log_ipv6            16384  5
xt_hl                  16384  22
ip6t_rt                16384  3
nf_conntrack_ipv6      20480  8
nf_defrag_ipv6         36864  1 nf_conntrack_ipv6
ipt_REJECT             16384  1
nf_reject_ipv4         16384  1 ipt_REJECT
nf_log_ipv4            16384  5
nf_log_common          16384  2 nf_log_ipv6,nf_log_ipv4
xt_LOG                 16384  10
xt_limit               16384  13
xt_tcpudp              16384  18
xt_addrtype            16384  4
nf_conntrack_ipv4      16384  8
nf_defrag_ipv4         16384  1 nf_conntrack_ipv4
xt_conntrack           16384  16
ip6table_filter        16384  1
ip6_tables             28672  1 ip6table_filter
nf_conntrack_netbios_ns    16384  0
nf_conntrack_broadcast    16384  1 nf_conntrack_netbios_ns
nf_nat_ftp             16384  0
nf_nat                 28672  1 nf_nat_ftp
libcrc32c              16384  2 xfs,nf_nat
nf_conntrack_ftp       20480  1 nf_nat_ftp
nf_conntrack          131072  8 nf_conntrack_ipv6,nf_conntrack_ftp,nf_conntrack_ipv4,nf_conntrack_broadcast,nf_nat_ftp,nf_conntrack_netbios_ns,xt_conntrack,nf_nat
iptable_filter         16384  1
v4l2loopback_dc        24576  0
videodev              172032  4 uvcvideo,videobuf2_core,v4l2loopback_dc,videobuf2_v4l2
media                  40960  2 uvcvideo,videodev
ip_tables              24576  1 iptable_filter
x_tables               36864  13 xt_LOG,ipt_REJECT,ip_tables,iptable_filter,xt_tcpudp,xt_limit,ip6t_REJECT,ip6table_filter,xt_addrtype,ip6t_rt,xt_conntrack,ip6_tables,xt_hl
parport_pc             32768  0
ppdev                  20480  0
lp                     20480  0
parport                49152  3 lp,parport_pc,ppdev
autofs4                40960  2
btrfs                1089536  0
xor                    24576  1 btrfs
raid6_pq              114688  1 btrfs
dm_mirror              24576  0
dm_region_hash         20480  1 dm_mirror
dm_log                 20480  2 dm_mirror,dm_region_hash
i915                 1449984  3
i2c_algo_bit           16384  1 i915
drm_kms_helper        151552  2 i915,nvidia_drm
syscopyarea            16384  1 drm_kms_helper
sysfillrect            16384  1 drm_kms_helper
psmouse               139264  0
sysimgblt              16384  1 drm_kms_helper
fb_sys_fops            16384  1 drm_kms_helper
ahci                   36864  3
tg3                   163840  0
drm                   352256  6 i915,nvidia_drm,drm_kms_helper
sdhci_pci              28672  0
libahci                32768  1 ahci
ptp                    20480  1 tg3
sdhci                  45056  1 sdhci_pci
pps_core               16384  1 ptp
fjes                   77824  0
video                  40960  2 i915,ideapad_laptop
              total        used        free      shared  buff/cache   available
Mem:        8115080     3999836     3460696      113692      654548     3705396
Swap:       8401916           0     8401916
/usr/lib/pm-utils/sleep.d/00logging hibernate hibernate: success.

Running hook /usr/lib/pm-utils/sleep.d/00powersave hibernate hibernate:
/usr/lib/pm-utils/sleep.d/00powersave hibernate hibernate: success.

Running hook /etc/pm/sleep.d/10_grub-common hibernate hibernate:
/etc/pm/sleep.d/10_grub-common hibernate hibernate: success.

Running hook /usr/lib/pm-utils/sleep.d/20tuxonice hibernate hibernate:
/usr/lib/pm-utils/sleep.d/20tuxonice hibernate hibernate: not applicable.

Running hook /usr/lib/pm-utils/sleep.d/40inputattach hibernate hibernate:
/usr/lib/pm-utils/sleep.d/40inputattach hibernate hibernate: success.

Running hook /usr/lib/pm-utils/sleep.d/50unload_alx hibernate hibernate:
/usr/lib/pm-utils/sleep.d/50unload_alx hibernate hibernate: success.

Running hook /usr/lib/pm-utils/sleep.d/60_wpa_supplicant hibernate hibernate:
Selected interface 'wlp8s0'
OK
/usr/lib/pm-utils/sleep.d/60_wpa_supplicant hibernate hibernate: success.

Running hook /usr/lib/pm-utils/sleep.d/75modules hibernate hibernate:
/usr/lib/pm-utils/sleep.d/75modules hibernate hibernate: not applicable.

Running hook /usr/lib/pm-utils/sleep.d/90clock hibernate hibernate:
/usr/lib/pm-utils/sleep.d/90clock hibernate hibernate: not applicable.

Running hook /usr/lib/pm-utils/sleep.d/94cpufreq hibernate hibernate:
/usr/lib/pm-utils/sleep.d/94cpufreq hibernate hibernate: success.

Running hook /usr/lib/pm-utils/sleep.d/95anacron hibernate hibernate:
/usr/lib/pm-utils/sleep.d/95anacron hibernate hibernate: success.

Running hook /usr/lib/pm-utils/sleep.d/95hdparm-apm hibernate hibernate:
/usr/lib/pm-utils/sleep.d/95hdparm-apm hibernate hibernate: not applicable.

Running hook /usr/lib/pm-utils/sleep.d/95led hibernate hibernate:
/usr/lib/pm-utils/sleep.d/95led hibernate hibernate: not applicable.

Running hook /usr/lib/pm-utils/sleep.d/98video-quirk-db-handler hibernate hibernate:
Kernel modesetting video driver detected, not using quirks.
/usr/lib/pm-utils/sleep.d/98video-quirk-db-handler hibernate hibernate: success.

Running hook /usr/lib/pm-utils/sleep.d/99video hibernate hibernate:
/usr/lib/pm-utils/sleep.d/99video hibernate hibernate: success.

Running hook /etc/pm/sleep.d/novatel_3g_suspend hibernate hibernate:
/etc/pm/sleep.d/novatel_3g_suspend hibernate hibernate: success.

нд дек  3 13:50:57 CET 2017: performing hibernate
sh: echo: I/O error
нд дек  3 13:51:04 CET 2017: Awake.
нд дек  3 13:51:04 CET 2017: Running hooks for thaw
Running hook /etc/pm/sleep.d/novatel_3g_suspend thaw hibernate:
/etc/pm/sleep.d/novatel_3g_suspend thaw hibernate: success.

Running hook /usr/lib/pm-utils/sleep.d/99video thaw hibernate:
/usr/lib/pm-utils/sleep.d/99video thaw hibernate: success.

Running hook /usr/lib/pm-utils/sleep.d/98video-quirk-db-handler thaw hibernate:
/usr/lib/pm-utils/sleep.d/98video-quirk-db-handler thaw hibernate: success.

Running hook /usr/lib/pm-utils/sleep.d/95led thaw hibernate:
/usr/lib/pm-utils/sleep.d/95led thaw hibernate: not applicable.

Running hook /usr/lib/pm-utils/sleep.d/95hdparm-apm thaw hibernate:

/dev/sda:
 setting Advanced Power Management level to 0xfe (254)
 APM_level	= 254
/usr/lib/pm-utils/sleep.d/95hdparm-apm thaw hibernate: success.

Running hook /usr/lib/pm-utils/sleep.d/95anacron thaw hibernate:
/usr/lib/pm-utils/sleep.d/95anacron thaw hibernate: success.

Running hook /usr/lib/pm-utils/sleep.d/94cpufreq thaw hibernate:
/usr/lib/pm-utils/sleep.d/94cpufreq thaw hibernate: success.

Running hook /usr/lib/pm-utils/sleep.d/90clock thaw hibernate:
/usr/lib/pm-utils/sleep.d/90clock thaw hibernate: not applicable.

Running hook /usr/lib/pm-utils/sleep.d/75modules thaw hibernate:
Reloaded unloaded modules.
/usr/lib/pm-utils/sleep.d/75modules thaw hibernate: success.

Running hook /usr/lib/pm-utils/sleep.d/60_wpa_supplicant thaw hibernate:
Selected interface 'wlp8s0'
OK
/usr/lib/pm-utils/sleep.d/60_wpa_supplicant thaw hibernate: success.

Running hook /usr/lib/pm-utils/sleep.d/50unload_alx thaw hibernate:
/usr/lib/pm-utils/sleep.d/50unload_alx thaw hibernate: success.

Running hook /usr/lib/pm-utils/sleep.d/40inputattach thaw hibernate:
/usr/lib/pm-utils/sleep.d/40inputattach thaw hibernate: success.

Running hook /usr/lib/pm-utils/sleep.d/20tuxonice thaw hibernate:
/usr/lib/pm-utils/sleep.d/20tuxonice thaw hibernate: not applicable.

Running hook /etc/pm/sleep.d/10_grub-common thaw hibernate:
/etc/pm/sleep.d/10_grub-common thaw hibernate: success.

Running hook /usr/lib/pm-utils/sleep.d/00powersave thaw hibernate:
/usr/lib/pm-utils/sleep.d/00powersave thaw hibernate: success.

Running hook /usr/lib/pm-utils/sleep.d/00logging thaw hibernate:
/usr/lib/pm-utils/sleep.d/00logging thaw hibernate: success.

Running hook /usr/lib/pm-utils/sleep.d/000kernel-change thaw hibernate:
/usr/lib/pm-utils/sleep.d/000kernel-change thaw hibernate: success.

нд дек  3 13:51:12 CET 2017: Finished.

rene
Level 8
Level 8
Posts: 2348
Joined: Sun Mar 27, 2016 6:58 pm

Re: Ridiculous hibernation problem

Post by rene » Sun Dec 03, 2017 9:30 am

This is from the looks of your kernel version string [edit: or from your original post, of course, ... ] Mint 18.x? You are, or Mint 18.x is, still using the 'pm-utils' but as far as I'm aware those are in fact obsolete these days. Do things work for you if you initiate hibernation from the command line with systemctl hibernate?

Even if they do: I expect you'd probably have commented on things if you had manually installed and set up the 'pm-utils'; that this setup is generic Mint 18.x and that I will as such need to bow out, being still on 17.3 myself. You'd need someone running 18.x to confirm/deny 'pm-utils' still being a standard part of the OS in the first place, and to try/test things in the second. Certainly that I/O error you get at the point of actual hibernate doesn't look good; as far as I'm able to google up it's the actual echoing (of "disk") into /sys/power/state that fails... but investigating why requires someone with an actual 18.x install to look at.

emil_pavlov
Level 2
Level 2
Posts: 70
Joined: Sun Feb 03, 2008 11:06 am

Re: Ridiculous hibernation problem

Post by emil_pavlov » Sun Dec 03, 2017 10:07 am

I think it does not use pm-utils by default. I am just too old and did not know any other way to find the error log, so I issued pm-hibernate manually.

systemctl hibernate does not work either, same reason.

The errors I get on console which appears are

Code: Select all

[some numbers] mei_me 0000:00:16.0: less data available than length=00000002.
whereas the last digit varies between 2, 3 and 5

rene
Level 8
Level 8
Posts: 2348
Joined: Sun Mar 27, 2016 6:58 pm

Re: Ridiculous hibernation problem

Post by rene » Sun Dec 03, 2017 10:53 am

emil_pavlov wrote:systemctl hibernate does not work either, same reason.
You should probably take that to mean that we're looking at something fundamental here; not at any "caching" of your previous 4G swap space. I'd try updating my kernel to the newest series and version thereof available.

The "mei_me" message points at the Intel Management Environment and that is given the 4G to 8G step actually sort of interesting. The Intel ME is basically an in your chipset embedded operating system (Tanenbaum's MINIX for halfway modern versions) which is undoubtedly 32-bit; has a 4G address space. If you are the type of Russian (?) with stuff to hide I'd think about unplugging that system from the net lest MINIX were faulting trying to ship a bit of memory from above 4G to the American NSA, say...

Just kidding.

One thing you can test additionally is echo disk | sudo tee /proc/sys/state as a "most manual" form of hibernation but I don't expect there's going to be a difference wrt. systemctl hibernate. If indeed there isn't I believe we're definitively down to this being a kernel issue, and given the error message, perhaps more specifically the Intel ME driver. I.e., try a different kernel. Or, by the way, try and see if you can set anything regarding ME/AMT in your BIOS. Or through the Windows driver. Or...

[EDIT] Crap, sorry; echo disk | sudo tee /sys/power/state I mean.

emil_pavlov
Level 2
Level 2
Posts: 70
Joined: Sun Feb 03, 2008 11:06 am

Re: Ridiculous hibernation problem

Post by emil_pavlov » Sun Dec 03, 2017 4:34 pm

I figured out that the MEI error comes from the intel microcode drivers. So I just disabled them, and this fixed it. The error I mean, not the hibernation.

I tried with the latest available kernel 4.13.0-17--same problem.

echo disk | sudo tee /sys/power/state says it cannot allocate memory (rough translation)

rene
Level 8
Level 8
Posts: 2348
Joined: Sun Mar 27, 2016 6:58 pm

Re: Ridiculous hibernation problem

Post by rene » Sun Dec 03, 2017 5:09 pm

No spy novel fun to be had; figures. Yes, the microcode link seems to make sense; will try to remember that.

Yet another attempt: what happens if you enter echo $((1 * 1024**3)) | sudo tee /sys/power/image_size before attempting to hibernate (in the echo disk | sudo tee /sys/power/state manner or "normally")? I can't myself reproduce an issue with any setting of the image_size parameter but did find an old kernel bug regarding this. If it does in fact help: are you perhaps using for example RAID of encryption for your swap partition? For any partition?

Thing is: your free output confirms 8G RAM and 8G swap, you have updated /etc/initramfs-tools/conf.d/resume with the correct swap UUID, and even if you didn't already do so manually, the installation of the new kernel has certainly both (re)generated the initrd and run update-grub... which is to say that there really seems very little opportunity left for trouble, even potentially. Being unable to reproduce also doesn't help. Rather expect I'll be out of ideas after this ;(

emil_pavlov
Level 2
Level 2
Posts: 70
Joined: Sun Feb 03, 2008 11:06 am

Re: Ridiculous hibernation problem

Post by emil_pavlov » Mon Dec 04, 2017 8:31 am

Sorry, no spies.

echo $((1 * 1024**3)) | sudo tee /sys/power/image_size did not help.

uswsusp works regardless of the ram load, but it's not a practical solution for me, because it's much slower

tuxonice works also. however, I cannot install a kernel newer than 4.4, although they have patches for 4.13, which discourages me from using it. If you could help me install the latest kernel patch, this might be solution for me.

I expanded my swap to 16 gig, to see if this would help, but to no avail. I noticed however that the system hibernates (with <4gig ram) and resumes without problems, even though I did not update fstab or initramfs. The swap was recognized out of the box as 16 gig. I guessing the kernel uses a very special way for calculating free swap space.

Anyway, if I don't manage to install the latest tuxonice patched kernel, I will just do a fresh install.

rene
Level 8
Level 8
Posts: 2348
Joined: Sun Mar 27, 2016 6:58 pm

Re: Ridiculous hibernation problem

Post by rene » Mon Dec 04, 2017 8:52 am

emil_pavlov wrote:tuxonice works also. however, I cannot install a kernel newer than 4.4, although they have patches for 4.13, which discourages me from using it. If you could help me install the latest kernel patch, this might be solution for me.
Not sure why you { 're saying that you } cannot install a kernel newer than 4.4 but there's a tuxonice PPA available at https://launchpad.net/~tuxonice/+archive/ubuntu/ppa. You'd use it as

Code: Select all

sudo add-apt-repository ppa:tuxonice/ppa
sudo apt-get update
sudo apt-get install linux-generic-tuxonice tuxonice-userui
I expanded my swap to 16 gig, to see if this would help, but to no avail. I noticed however that the system hibernates (with <4gig ram) and resumes without problems, even though I did not update fstab or initramfs. The swap was recognized out of the box as 16 gig. I guessing the kernel uses a very special way for calculating free swap space.
I'm really quite fully out of ideas as to the nature of your problem...

emil_pavlov
Level 2
Level 2
Posts: 70
Joined: Sun Feb 03, 2008 11:06 am

Re: Ridiculous hibernation problem

Post by emil_pavlov » Mon Dec 04, 2017 9:13 am

Not sure why you { 're saying that you } cannot install a kernel newer than 4.4 but there's a tuxonice PPA available at https://launchpad.net/~tuxonice/+archive/ubuntu/ppa. You'd use it as
this what I do, but the response is just

Code: Select all

The following additional packages will be installed:
  linux-headers-4.4.0-101-generic-tuxonice linux-headers-generic-tuxonice
  linux-image-4.4.0-101-generic-tuxonice
  linux-image-extra-4.4.0-101-generic-tuxonice linux-image-generic-tuxonice
I'm really quite fully out of ideas as to the nature of your problem...
Thank you trying nevertheless

rene
Level 8
Level 8
Posts: 2348
Joined: Sun Mar 27, 2016 6:58 pm

Re: Ridiculous hibernation problem

Post by rene » Mon Dec 04, 2017 9:58 am

Oh, right, that PPA indeed only publishes a 4.4 kernel for "xenial", i.e., Ubuntu 16.04, the base of Mint 18.x. You could elect to use it if you don't need a newer kernel for anything else but personally I wouldn't either.

Compiling a kernel with tuxonice manually is also not something I'd suggest, and especially not since I don't in fact think it would've been a great idea to install a custom kernel in the first place. Given the PPA it would've at least been a quick fix but reinstalling Mint is likely to be quite a bit quicker if you don't have a lot of stuff to backup first. I have no idea what's happening there; can't reproduce any sort of issue, so, bit lame, but yes, if a reinstall isn't too much trouble, that's what I would advise.

Post Reply

Return to “Installation & Boot”