0
How it looks like: laptop goes suspend, but when awoken, boots from scratch.
OS: Linux Mint 17.3 x64 Cinnamon
Laptop: ASUS UX32LN, EFI boot
How it happened: I was switching to SSD. Removed old HDD, put it into USB box and booted from it. While doing so, I accidentally suspended, and laptop didn't resume properly - it just booted. I didn't give much attention to it and installed SSD, then partitioned it (EFI, GRUB, swap, root, home) and copied my data there via cp -af
from recovery mode. After putting partition IDs in order I booted successfully, but suspend-to-ram was also broken. Putting old HDD back didn't have any effect - seems it already had broken suspend.
syslog
and pm-suspend.log
look "cut" at the point of suspend, i.e. syslog
shows just normal startup sequence at some point, and pm-suspend.log
doesn't have "Awake" sequence.
After some investigation I found out that swap partition on SSD is misconfigured and isn't used, so I reformatted it as unencrypted swap and enabled, but it didn't give any effect. Also, attempt to purge and then install pm-utils
from scratch gave no result.
So the question is, where can I look to fix suspend-to-ram? I can of course reinstall from scratch, but it just doesn't feel right to me.
UPD: Backed up my home partition and installed fresh Linux Mint 17.3. And it doesn't resume properly as well. The further I get, the stranger problem becomes.
UPDATE
I've conducted experiment with backing my whole SSD and then installing Windows 10 on it. Result: issue persists, so it apparently requires contact with service desk.
Apparently you did not update the kernel command line(s) in your bootloader conf (for the changes of the UUID of the swap partition; you might want to use PARTUUID instead btw) – Tom Yan – 2016-04-11T09:51:12.277
Then it's a very big question why old HDD also stopped to suspend. Because it still has cryptswap, bound to named mapper device. Also, AFAIK, suspend shouldn't care about swap partition. But thanks for a clue, I'll check it. – Target-san – 2016-04-11T10:12:36.403
You haven't been really clear whether it is suspend-to-ram or suspend-to-disk (a.k.a hibernate)...if you meant suspend-to-ram, the disk (instead of just the swap partition) shouldn't matter – Tom Yan – 2016-04-11T10:15:38.840
It's suspend-to-ram. Edited subject to make it more clear – Target-san – 2016-04-11T11:01:47.207
I think you should re-write the whole question to avoid the many more confusions. It's pretty obvious the problem has nothing to do with
moved to SSD
(especially when judging from your "step" 2). It's more likely because of the version bump (17.2 -> 17.3) or maybe even a "minor" update. It's not "disabled", but just "broken". Moreover, I don't know why you mentioned or even tried "step" 8 when you saidAlso, AFAIK, suspend shouldn't care about swap partition.
yourself. I'd downvote for now. – Tom Yan – 2016-04-11T12:34:07.323I tried to give details I thought would be necessary to understand the case. Because I first moved to SSD, and only after I noticed 'suspend' broken, I tried 'old' HDD which showed clearly that neither SSD nor transition is the case. Though I'll try to rewrite question to be more clear. – Target-san – 2016-04-11T16:45:04.647