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