Comment # 32 on bug 935086 from Uwe Geuder

(In reply to Takashi Iwai from comment #25)
> BTW, while looking at the dmesg output on my machine, I noticed that the
> system triggers hibernate-resume twice: once the kernel itself and once by
> dracut.
> 
> Could you add "noresume" boot option (while keeping "resume=xxx" option) and
> retest for a few times whether you still get the unexpected reboot with
> SLEEP_METHOD="kernel"?
> 
> Also does this have any influence with SLEEP_METHOD="uswsusp"?

Ah I did not even know that the kernel can obviously resume directly from
its command line without any help from initramfs. Well, I have used disk
encryption longer than hibernate, so this does not apply to me.

Yes, the first resume failure has always been in the kernel log. I never
understood where it comes from. That's also the place where resumedelay=10
takes effect. But of course with LUKS encryption and LVM that resume has never
succeeded for me and never will.

I don't think the failed attempt should confuse the kernel, the device just
does not exist. It got confused there and misfunction latet, that would be a
bad bug.

Anyway I tried the "nosuspend" parameter (only with uswsusp so far). It looks
like dracut also respects this parameter and skips the whole resume script.

So not at good idea, at least not with uswsusp. It will boot with filesystem
mounts after hibernate, which can always mean data loss.

Not sure about kernel mode. One resume action is in the same 95suspend script.
If that is the only one, it will not resume either. But need to test.