Copying the reply from Bug 35460, moving discussion here:

(In reply to Giuseppe Ghibò from Bug 35460 comment #6)
> Is this a new issue that doesn't happen when you switch back to the previous
> kernel?
> 
> Usually, GRUB defaults to the entry in /etc/default/grub, specifically the
> line:
> 
> GRUB_DEFAULT=saved
> 
> This boots generally to the value pointed to by the content of the file
> /boot/grub2/grubenv.

I may test later on another system.
I do not want to cause to much wear and risk on that T43 production machine
(the alternate boot Win XP is important for work, old machines servicing)

Please experiment on a faster Mga9 system with backport and normal kernels, and maybe also select between different versions and flavours of 6.6 kernels.

Thinking, I and maybe others may have been experiencing this problem earlier but thought it was other bugs in restoring.

Assignee: bugsquad => kernel
Severity: normal => major

After being a bit more tested, should be noted in
 https://wiki.mageia.org/en/Kernel_flavours
and then linked to from errata 9
 (and errata 10 later if valid)

Flags: (none) => affects_mga9+, in_wiki?

"Is it pure luck whether restoring works when booting another kernel than the one in use when hibernated?"
I think so.
It looks to me that changing kernels when resuming from Hibernate is asking too much. It is not restoring the Hibernated session.
And should Grub be involved at all when resuming after Hibernate? I cannot see why.
It would be normal to re-boot to change kernels.

Re comment 2, again I am unsure where the actual fault is - it there is one.

CC: (none) => lewyssmith

I got something!

First excuse me for forgetting exact kernel flavour:
In Comment 0 the backport kernel "desktop" 6.18.26-1 is really the desktop586 version!

There is no log saved from the booting crashing kernel. After grub, the screen is just black maybe three seconds, then i see the black hue changes and it reboot.


Continued testing:

It also fail the other way around: hibernating desktop586 6.18, then booting linus 6.6.137 reboots.

Also hibernating linus 6.6.137, booting desktop586 6.6.137 fail. (same version, different flavour)

BUT hibernating desktop586 6.6.137, booting desktop586 6.18 works: session restored and uname-a report desktop586 6.6.137.


So the "guaranteed?" incompatibility seem to be the "586" part in flavour.

Are other flavours compatible?  desktop <-> server <-> linus ?
All 6.6x with each other of same flavour?
6.6 <-> 6.18 ?
All above provided non or all is desktop586?

Flags: (none) => in_errata10?

(In reply to Lewis Smith from comment #3)
> "Is it pure luck whether restoring works when booting another kernel than
> the one in use when hibernated?"
> I think so.
> It looks to me that changing kernels when resuming from Hibernate is asking
> too much. It is not restoring the Hibernated session.

Interestingly, it use to work.
Including loading the hibernated kernel.
Which implies kernel is stored in image.

So the only task of the booting kernel is to load the image?
-overwriting itself?
That seem reliable until thinking they are different size in RAM which is much probable...

The "586" - "no 586" incompatibility seem only to do with RAM management?

Anyway, if we can make the same kernel be loaded, we do not need to think about compatibility.


> And should Grub be involved at all when resuming after Hibernate? I cannot
> see why.

I think it is the kernel that detect if system is hibernated.

And grub do not check for that.

Optimally grub should check that itself and unconditionally and with no delay load sam kernel as last booted.

(provided there is a way for user to get out of a boot loop and select another kernel if it somehow fail)

If grub cannot be made to be hibernation aware, something should reconfigure it when going into hibernation so it next boot with no timeout boot same kernel as the running one.
- and when restored, reset grub setting to normal.

(In reply to Morgan Leijström from comment #5)

> (In reply to Lewis Smith from comment #3)
> > "Is it pure luck whether restoring works when booting another kernel than
> > the one in use when hibernated?"
> > I think so.
> > It looks to me that changing kernels when resuming from Hibernate is asking
> > too much. It is not restoring the Hibernated session.
> 
> Interestingly, it use to work.
> Including loading the hibernated kernel.
> Which implies kernel is stored in image.

the kernel saves the image, which contains the status of the memory. at next boot it checks the kernel checksums/signatures, if the booting kernel is the same and checksum matches, it restores, if it's different, then restore is aborted. Never tried to boot from a removable external hard disk, hibernate to the external disk, and restore on a different computer, in theory it should fail (i.e. not crashing due to incompatible hardware, but skip restoring).

CC: (none) => ghibomgx

(In reply to Giuseppe Ghibò from comment #6)
> (In reply to Morgan Leijström from comment #5)
> 
> at next
> boot it checks the kernel checksums/signatures, if the booting kernel is the
> same and checksum matches, it restores, if it's different, then restore is
> aborted.

Then we must fix so grub select the correct kernel.

But in reality, for example booting desktop586 6.18.26 restores successfully a hibernated desktop586 6.6.137

(In reply to Morgan Leijström from comment #7)

> (In reply to Giuseppe Ghibò from comment #6)
> > (In reply to Morgan Leijström from comment #5)
> > 
> > at next
> > boot it checks the kernel checksums/signatures, if the booting kernel is the
> > same and checksum matches, it restores, if it's different, then restore is
> > aborted.
> 
> Then we must fix so grub select the correct kernel.
> 
> But in reality, for example booting desktop586 6.18.26 restores successfully
> a hibernated desktop586 6.6.137

So it doesn't correctly restore its own image, but it successfully restores another... ;-)

(In reply to Giuseppe Ghibò from comment #8)
> So it doesn't correctly restore its own image, but it successfully restores
> another... ;-)

AFAIK, all kernels successfully restores an image with themselves in it.

And the only incompatibility i *know* is for the 32 bit kernels; desktop586 can not restore an image made by desktop or linus, and vice versa.

I have never seen incompatibility between different flavours in other ways, even between version - even a 6.18 can restore image of 6.6 and vice versa - maybe just luck.

I think *to be safe* we must somehow make grub boot same kernel as the hibernated one.

(In reply to Morgan Leijström from comment #9)
> I think *to be safe* we must somehow make grub boot same kernel as the
> hibernated one.
A1gree entirely. It just seems to me automatic that the restored system (hence its kernel) is exactly what was hibernated.
I still do not see where Grub comes into it. I need to play on a laptop when I can.

Entered: https://wiki.mageia.org/en/Kernel_flavours#Hibernation

Probably we have had this problem always, but I have only noted it when switching between desktop586 and other flavours, so only on 32 bit systems.
And desktop586 is no more from mga10 and on.

However, as said we can not guarantee there is no problem between other kernel favours when one is hibernated and another boots.

It should get fixed in the future, (boot same kernel as the one hibernated) so I set this bug to Cauldron.

Version: 9 => Cauldron
Status comment: (none) => Same kernel as in hibernation should boot.
Flags: in_errata10?, in_wiki? => in_errata10-, in_wiki+
Summary: restore from hibernation reboots, session lost, when grub default to wrong kernel (backport/normal) => Restore from hibernation reboots, session lost, when grub default to wrong kernel