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 _______________________________________________ users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
