Ridiculous hibernation problem
Forum rules
Before you post read how to get help. Topics in this forum are automatically closed 6 months after creation.
Before you post read how to get help. Topics in this forum are automatically closed 6 months after creation.
Ridiculous hibernation problem
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.
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.
Last edited by LockBot on Wed Dec 28, 2022 7:16 am, edited 1 time in total.
Reason: Topic automatically closed 6 months after creation. New replies are no longer allowed.
Reason: Topic automatically closed 6 months after creation. New replies are no longer allowed.
Re: Ridiculous hibernation problem
Is swap-partitions
UUID
correct in the /etc/fstab
file? Compare sudo blkid
output UUID
s with cat /etc/fstab
outputs.Re: Ridiculous hibernation problem
yes
this is from
this is
this is
this is from
Code: Select all
blkid
Code: Select all
/dev/sda6: UUID="a3d68e82-84c5-4a6f-b9f2-edb776b4c3c2" TYPE="swap" PARTUUID="c3ffc3ff-06"
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
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
Re: Ridiculous hibernation problem
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
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
Re: Ridiculous hibernation problem
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
Re: Ridiculous hibernation problem
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
GRUB_CMDLINE_LINUX="resume=UUID=a3d68e82-84c5-4a6f-b9f2-edb776b4c3c2"
...then do an
update-grub
to rebuild the /boot/grub/grub.cfg file.Re: Ridiculous hibernation problem
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 spaceCode: Select all
sudo swapoff -a
sudo mkswap /dev/sda6
sudo blkid /dev/sda6
<update the UUID in /etc/fstab>
sudo swapon -a
Re: Ridiculous hibernation problem
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
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
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.
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.
Re: Ridiculous hibernation problem
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
UPDATE
here is
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.
Re: Ridiculous hibernation problem
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
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.
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.
Re: Ridiculous hibernation problem
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
The errors I get on console which appears are
whereas the last digit varies between 2, 3 and 5
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.
Re: Ridiculous hibernation problem
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.emil_pavlov wrote:systemctl hibernate
does not work either, same reason.
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.Re: Ridiculous hibernation problem
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.
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)Re: Ridiculous hibernation problem
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
Thing is: your
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 ;(Re: Ridiculous hibernation problem
Sorry, no spies.
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
Anyway, if I don't manage to install the latest tuxonice patched kernel, I will just do a fresh install.
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 slowertuxonice
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.
Re: Ridiculous hibernation problem
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 asemil_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.
Code: Select all
sudo add-apt-repository ppa:tuxonice/ppa
sudo apt-get update
sudo apt-get install linux-generic-tuxonice tuxonice-userui
I'm really quite fully out of ideas as to the nature of your problem...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 updatefstab
orinitramfs
. 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.
Re: Ridiculous hibernation problem
this what I do, but the response is justNot 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
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
Thank you trying neverthelessI'm really quite fully out of ideas as to the nature of your problem...
Re: Ridiculous hibernation problem
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.
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.