Bug#892321: attempts to suspend failing after crash
On Mon, 18 Jun 2018 10:38:20 +0200 Daniel Pocock 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. -- 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
Bug#892321: attempts to suspend failing after crash
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
Bug#892321: attempts to suspend failing after crash
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? -- 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
Bug#892321: attempts to suspend failing after crash
On 17/03/18 03:07, Michael Biebl wrote: > On Thu, 8 Mar 2018 10:02:32 + Daniel Pocock wrote: >> 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? > > It's unclear to me what exactly your specific problem is/how and how > systemd should detect that. > 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
Bug#892321: attempts to suspend failing after crash
On Sat, 17 Mar 2018 03:07:45 +0100 Michael Biebl wrote: > On Thu, 8 Mar 2018 10:02:32 + Daniel Pocock wrote: > > 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? > > It's unclear to me what exactly your specific problem is/how and how > systemd should detect that. Ping How is your suspend partition relevant for suspend to ram? Are you actually using hibernate (suspend-to-disk) where a properly setup swap partition is important? 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
Bug#892321: attempts to suspend failing after crash
On Thu, 8 Mar 2018 10:02:32 + Daniel Pocockwrote: > 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? It's unclear to me what exactly your specific problem is/how and how systemd should detect that. -- 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
Bug#892321: attempts to suspend failing after crash
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?