Broken suspend-to-ram mode

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.

Target-san

Posted 2016-04-11T08:49:23.277

Reputation: 11

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 said Also, AFAIK, suspend shouldn't care about swap partition. yourself. I'd downvote for now. – Tom Yan – 2016-04-11T12:34:07.323

I 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

No answers