Valid.. Currently it's even worse in Cauldron.

Version: 1 => Cauldron

Yes... I too have LVM - for everything (including swap), except /boot

But no encryption anywhere, 

At boot it seem to have forgotten it saved anything, and ends at login.

CC: (none) => fri

I suspect this is very similar to, or a duplicate of bug 4537
where lvm volume groups are not being activated, or at least
not activated soon enough.

CC: (none) => davidwhodgins

Strange thing: grub had wrong swap name in kernel parameter 
it said resume=/dev/vg-mga/swap
but that partition name really is swap1, (not swap)
(Probably an effect of complicated problems partitioning with the installer (during which i had to rename that partition) ; bug 4442, bug 4449  )

Fixing it did not help however :/

But you may want to check if your resume= parameter is correct.

Looking at disk activity i believe it saves session.
But looking at the boot i see no attempt to restore.
What and where should i be looking for in the logs about save and restore events?

Still valid with latest updates ?

CC: (none) => ennael1

Full update no change.
Setup: IBM Thinkpad T40, cauldron i586, KDE, KDM
If someone want logs etc, tell me how to make it.

(In reply to comment #5)
> Still valid with latest updates ?

Currently standard shutting down is broken too. https://bugs.mageia.org/show_bug.cgi?id=5184 so after fixing #5184 I will test it.

This might actually be fixed with the latest installs and dracut (I did have this issue in mind as being a problem, but never knew this bug existed until now). I also think I've added appropriate migration in dracut post-install scripts too.

Can you check the contents of the file:

/etc/dracut.conf.d/51-mageia-resume.conf

?

CC: (none) => mageia

Did full update now, reboot and hibernation trials:

machine 1, Thinkpad T42: the result seem perfect -with the quirk that i spotted a line during boot saying something like resume file does not exist or could not be read.  This system have /swap and / on unencrypted LVM, and user on encrypted LVM.

machine 2, Desktop: resumes correctly except Ethernet NIC failed. Disk: "everything" in encrypted LVM.

( The Thinkpad T40 in comment 4 & 6 is unavailable right now )

(In reply to comment #7)
> (In reply to comment #5)
> > Still valid with latest updates ?
> 
> Currently standard shutting down is broken too.
> https://bugs.mageia.org/show_bug.cgi?id=5184 so after fixing #5184 I will test
> it.

Can you try?
It seems to be fixed

Thanks

CC: (none) => pterjan

(In reply to comment #10)
> Can you try?
> It seems to be fixed
> 
> Thanks

Tomorrow, I will reinstall from boot.iso.

(In reply to comment #10)
> Can you try?
> It seems to be fixed
> 
> Thanks

Fresh installation.


as minimal as possible system, tty:
pm-hibernate: leeds to:
>>
Looking for splash system... could not open renderer /dev/fb
could not initialize plymouth : error 0 
none
(after some time)
s2disk: Snapshotting system
(after waiting a while I decided to do a hard reset...)
<<<

Next try, next installation, with minimal system+slim+terminator+windowmaker

pm-suspend seems fine, but long!
pm-hibernate hibernated, but it cannot stand up, after waking it's asking for a passphrase against encrypted partition (LVM with / over btrfs and swap) and then I can see 'snowing' like from old TV without a signal.. system isn't usable, logging into TTY not possible.

hard reset

Additional info:
sda1 /boot ext4
sda2 LVM encrypted
- root /
- swap swap

OK, but the key point here is that it does now actually find the partition to do the resume? That's the bug I fixed! If resume/hibernation itself is busted, I know nothing about that :p

I think it's finding the partitions correctly, but the rest seems boosted. I suspect fglrx issues.

OK, so I just tried this on my test VMs and all is well, both on a regular swap and on a swap kept on encrypted LVM.

I only tested running pm-hibernate from a console login (no X) but the basic underlying bits of hibernation are apparently working (aside from error 0 from plymouth...)

Perhaps this is an ATI issue?

(In reply to comment #16)
> Perhaps this is an ATI issue?

Yes.

And system is really resuming (but ATI is breaking the final) so closing this bug.

Status: NEW => RESOLVED
Resolution: (none) => FIXED