http://bugzilla.opensuse.org/show_bug.cgi?id=935086
http://bugzilla.opensuse.org/show_bug.cgi?id=935086#c32
--- Comment #32 from Uwe Geuder
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. -- You are receiving this mail because: You are on the CC list for the bug.