Bug 486889

Summary:	Screen Locker Black Screen of Death Resulting in Nasty Data Corruption
Product:	[Plasma] plasmashell	Reporter:	bugreporting
Component:	Screen locking	Assignee:	Plasma Bugs List <plasma-bugs>
Status:	RESOLVED DUPLICATE
Severity:	major	CC:	me
Priority:	NOR
Version First Reported In:	6.2.4
Target Milestone:	1.0
Platform:	Arch Linux
OS:	Linux
Latest Commit:		Version Fixed In:
Sentry Crash Report:

Description bugreporting 2024-05-11 15:05:22 UTC

SUMMARY
***
Screen locker gives black screen of death.
***

STEPS TO REPRODUCE:
1. With default KDE settings (screen locking, power plan, nothing changed from the default) wait for screen to start locking.
2. Move mouse (just like you were doing in KDE 5).

OBSERVED RESULTS:
Black screen of death. Nothing visible, system runs.

End game: user must hard reset the computer and hence destroy HDD/SSD (errors on the file system/data corruption plust lost work and corrupted/broken files; I understand that modern file systems are somewhat "resilient", but KDE should not force user to hard reset). To properly scan ext4 its takes about an hour from external drive.

EXPECTED RESULT:
Reverting the changes to the KDE 5, working state.

SOFTWARE/OS VERSIONS
KDE Plasma Version: 6.0.4
KDE Frameworks Version: 6.1.0
Qt Version: 6.7.0
Graphics Platform: X11
Graphics Processor: Mesa Intel HD

Comment 1 bugreporting 2024-05-11 15:12:27 UTC

I meant: it takes an hour from external live system to properly the drive:
The following commands have to be run separetely (so you have to stare at the screen to run the next, they cannot be run together, e2fsck does not allow it. Yes I know "&&");
$ e2fsck -f -p -c -v
$ e2fsck -f -v -E discard
$ e2fsck -f -v -E optimize_extents
$ e2fsck -f -v -D

for each "/" and "/home" as I have them separately. Users should not be force to do this just becasue they just tried to unlock the screen.

Comment 2 ratijas 2024-12-18 20:51:49 UTC


*** This bug has been marked as a duplicate of bug 483094 ***