Your message dated Wed, 18 Jul 2018 16:25:57 +0200
with message-id <[email protected]>
and subject line Re: Bug#892321: attempts to suspend failing after crash
has caused the Debian Bug report #892321,
regarding attempts to suspend failing after crash
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
892321: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=892321
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: systemd
Version: 232-25+deb9u1
Severity: important
Laptop was connected to a Thunderbolt dock, lid closed, using desktop
monitor and keyboard, everything connected through the dock. It is a
laptop with encrypted LVM and swap on LVM.
Laptop's thunderbolt cable was bumped very slightly without coming out
completely and then pushed back in. As the lid was down, it appears the
laptop tried to suspend
It didn't really suspend though, it became frozen with a blank screen.
After a hard reboot, every subsequent attempt to close the lid or undock
also failed, the screen would go blank and it wouldn't come back.
journalctl and /var/log/messages provided no clues.
Guessing it was a problem with the swap partition, tried the following:
swapoff /dev/mapper/vg00--vg-swap_1
mkswap /dev/mapper/vg00--vg-swap_1
mkswap: /dev/mapper/vg00--vg-swap_1: warning: wiping old swap signature.
Setting up swapspace version 1, size = 23.8 GiB (25513947136 bytes)
no label, UUID=
swapon /dev/mapper/vg00--vg-swap_1
In this case, the swap partition is named in /etc/fstab, not the UUID.
For somebody with the UUID in fstab it would be necessary to update
there too and also run update-initramfs
This is not hard for an experienced user to resolve but very annoying as
you only discover you have a problem after the second attempt to sleep.
Can systemd or whatever else is involved in the suspend/sleep mechanism
be improved to detect problems like this, give some kind of error to the
user and maybe even help them automatically correct it?
--- End Message ---
--- Begin Message ---
On Wed, 27 Jun 2018 22:06:06 +0200 Michael Biebl <[email protected]> wrote:
> On Mon, 18 Jun 2018 10:38:20 +0200 Daniel Pocock <[email protected]> wrote:
> >
> >
> > On 18/06/18 09:51, Michael Biebl wrote:
> > > Am 18.06.2018 um 09:26 schrieb Daniel Pocock:
> > >
> > >> The problem: a corrupted swap partition
> > >>
> > >> Before deciding how systemd should detect that, it may first be
> > >> necessary to decide if it is the job of systemd or some other process to
> > >> detect the problem
> > >
> > > How is a swap partition relevant for suspend?
> > >
> >
> >
> > I don't know, but suspend would not work until I manually resolved the
> > corruption issue
>
> Please try to find out why it failed or if this was actually a red herring.
Since we don't know what actually happened, it's not clear what the
Debian systemd package is supposed to do here.
Thus closing this bug report.
Michael
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
signature.asc
Description: OpenPGP digital signature
--- End Message ---
