On Wed, Jun 22, 2022 at 12:00 PM Ranjan Maitra <[email protected]> wrote:
> On Wed Jun22'22 11:40:10AM, George N. White III wrote: > > From: "George N. White III" <[email protected]> > > Date: Wed, 22 Jun 2022 11:40:10 -0300 > > To: Community support for Fedora users <[email protected]> > > Reply-To: Community support for Fedora users < > [email protected]> > > Subject: Re: fully updated F36 Dell XPS 13 no longer comes back from > > hibernate (post Thursday updates) > > > > On Wed, Jun 22, 2022 at 8:43 AM Ranjan Maitra <[email protected]> wrote: > > > > > 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. 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. > 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. -- George N. White III
_______________________________________________ users mailing list -- [email protected] To unsubscribe send an email to [email protected] 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/[email protected] Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
