The problem was first noticed when the system was given a clean installation of Debian Trixie some months ago whilst Trixie was then under development. As an issue it occurred almost 100% of the time when hibernation was engaged. Under Bookworm there was no problem at all with the same hardware configuration.

The system configuration uses a swap partition which is stored on Sata SSD.

The system’s motherboard was replaced due to unrelated issues and trixie reinstalled from scratch but the locking problem has continued. After much difficulty as the system usually had to be reset after resuming it was discovered that the issue is not with the hibernation/resume but with the action of locking the system at the completion of the resume operation. At this point the locking would result in the system freezing instead. With the requirement to lock the computer after waking from sleep disabled, the use of hibernation/resume immediately regained its normal level of reliability.

A second Trixie installed system has displayed the same issue although it does not freeze all the time when resuming, only occasionally. It has different hardware from the computer which is the subject of this bug report.

It was thought initially the issue was the use of the hibernation option on the Lock Screen to hibernate the computer but has been now shown to be any use of hibernation in the system although the second mentioned computer seems more likely to freeze on resume if the Lock Screen hibernation function is engaged, as compared with selecting hibernation while unlocked.