Thanks! > > > > Dear friends, > > > > > > > > I have a fully updated F36 Dell XPS 13 that has been updated nightly > > (and > > > > upgraded when appropriate) using dnf on a cron job for the past few > > years. > > > > Sadly, after last Thursday's updates, the machine goes down fine (with > > the > > > > usual systemctl hibernate), but does not come back up. I am a little > > > > confused what changed last Thursday, but I was wondering if anyone had > > any > > > > suggestions as to how I may diagnose and fix this problem. > > > > > > > > > > Is this a dual boot with Windows? Did you recently get firmware updates > > > from Dell? Have you > > > looked at messages using journalctl? > > > > My apologies for overlooking such obvious necessary information. To answer > > your questions: > > > > > Is this a dual boot with Windows? > > > > No, only runs Fedora since I bought it. I believe I wiped out all > > partitions when it came and put up Fedora (in 2018). > > > > > Did you recently get firmware updates from Dell? > > > > No, sorry. I did not even check. > > > > > Have you looked at messages using journalctl? > > > > So, I don't really know what to look for, but I tried: > > > > journalctl | grep hibernate > > > > and got: > > > > Jun 22 06:06:49 localhost.localdomain systemd[1]: Created slice > > system-systemd\x2dhibernate\x2dresume.slice - Slice > > /system/systemd-hibernate-resume. > > Jun 22 06:06:50 localhost.localdomain systemd[1]: Starting > > systemd-hibernate-resume@dev-disk-by\x2duuid-a83ac239\x2dcc10\x2d43a6\x2dbe54\x2dde4ce7050605.service > > - Resume from hibernation using device > > /dev/disk/by-uuid/a83ac239-cc10-43a6-be54-de4ce7050605... > > Jun 22 06:06:50 localhost.localdomain systemd-hibernate-resume[390]: > > Could not resume from > > '/dev/disk/by-uuid/a83ac239-cc10-43a6-be54-de4ce7050605' (259:4). > > > > Next chance, make > > Searching for "systemd-hibernate-resume Could not resume from > 'dev/disk/by-uuid" in the past year may give you some ideas. > Interesting hit was https://www.suse.com/support/kb/doc/?id=000020264, > which says: > > Specifying to attempt resuming from a hibernation image should not normally > result in a failure to boot. I don't know what this means, but I do boot in, but not to the hibernated state, but a new one. > SUSE Support has observed cases in which it > does. These include: > > Security hardened systems > Systems in which the swap device, root filesystem or /boot partition > was not specified by UUID > Otherwise improperly configured GRUB, such as duplicate resume= > parameters > Cases where the swap device was unreachable. > I have changed nothing for months, if not years. In any case, I am pretty certain the first three points are not true for me, and I have no idea as to how to see if the swap device is reachable or not. Btw, I have noticed something, that the grub menu now has an entry for the kernel with debug as well as the kernel itself (which is what it boots into, and does not resume). Before last week (at least), there were not two entries: one for the kernel with debug and the other for the kernel only. I am not sure if this is relevant. My /etc/default/grub is as follows: GRUB_TIMEOUT=5 GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)" GRUB_DEFAULT=saved GRUB_DISABLE_SUBMENU=true GRUB_TERMINAL_OUTPUT="console" GRUB_CMDLINE_LINUX="resume=UUID=a83ac239-cc10-43a6-be54-de4ce7050605 rhgb quiet" GRUB_DISABLE_RECOVERY="true" GRUB_ENABLE_BLSCFG=true It was last updated on May 5, 2019. > > > Jun 22 06:06:50 localhost.localdomain systemd[1]: > > systemd-hibernate-resume@dev-disk-by\x2duuid-a83ac239\x2dcc10\x2d43a6\x2dbe54\x2dde4ce7050605.service: > > Deactivated successfully. > > > > Why is ASCII "minus/dash" (-) is shown as hex "\x2d"? I see similar > entries on my Fedora 35 system. > Don't know, sorry. Thanks again for your help and your suggestions, Ranjan _______________________________________________ users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
