On Mon, 2016-09-26 at 12:28 -0600, Chris Murphy wrote:
I don't see how GRUB_DISABLE_RECOVERY="false" is
related. All that
does when true is create extra "(recovery mode)'" menu entries for
each kernel that includes one additional boot parameter: single
OK, well now I now where those extra lines came from.
Saying "it doesn't work" and "it used to work and
now it doesn't" is
not at all helpful. You need to provide logs, specifically the entire
output of 'journalctl -b -o short-monotonic > journal_notworking.log'
and then one for the working case, and look through them both to find
out what the differences are between them.
Fair enough.
There's a 50/50 chance you could just compare dmesg with a
working
case and non-working case. I'm willing to bet that the kernel is
either not finding where the hibernation image is stored, or it
doesn't like what it found. The logic for finding the hibernation
image is apparently non-trivial, there's no udev or anything available
yet so I think it's dracut that has to convert whatever notation you
use into major:minor which is what the kernel needs to use to get the
image.
Given that the working and non-working kernels are identical, it's not
clear what differences there can be, but if it has to do with device
numbering then I guess there could be a timing issue.
poc