[kscreenlocker] [Bug 403255] Screenlock prevented by kdialog on read-only filesystem
https://bugs.kde.org/show_bug.cgi?id=403255 Kai Uwe Broulik changed: What|Removed |Added Resolution|--- |FIXED Status|CONFIRMED |RESOLVED Latest Commit||https://commits.kde.org/ksc ||reenlocker/30e61b4aa4e73b0c ||c87cf26d78eb39d8eab8ce3d --- Comment #6 from Kai Uwe Broulik --- Git commit 30e61b4aa4e73b0cc87cf26d78eb39d8eab8ce3d by Kai Uwe Broulik. Committed on 16/01/2019 at 14:10. Pushed by broulik into branch 'master'. [Greeter] Ignore unwritable configuration files When opening a non-writable config file, a kdialog process is spawned and the application waits for it to quit. However, since in case of the lock screen, the input and everything is already blocked, the user cannot dismiss the warning generated by the greeter, effectively locking the user out. Differential Revision: https://phabricator.kde.org/D18291 M +4-0greeter/main.cpp https://commits.kde.org/kscreenlocker/30e61b4aa4e73b0cc87cf26d78eb39d8eab8ce3d -- You are receiving this mail because: You are watching all bug changes.
[kscreenlocker] [Bug 403255] Screenlock prevented by kdialog on read-only filesystem
https://bugs.kde.org/show_bug.cgi?id=403255 --- Comment #5 from Leonard Lausen --- Thanks Kai. Sorry if I misunderstood your previous comment as requiring the env variable. -- You are receiving this mail because: You are watching all bug changes.
[kscreenlocker] [Bug 403255] Screenlock prevented by kdialog on read-only filesystem
https://bugs.kde.org/show_bug.cgi?id=403255 --- Comment #4 from Kai Uwe Broulik --- I see. I agree at least the lock screen definitely shouldn't lock the user out because of this, which is what my patch is for. Other than that I think it needs to be decided on a case-by-case basis how to address this. -- You are receiving this mail because: You are watching all bug changes.
[kscreenlocker] [Bug 403255] Screenlock prevented by kdialog on read-only filesystem
https://bugs.kde.org/show_bug.cgi?id=403255 --- Comment #3 from Leonard Lausen --- Thanks Kai. I would argue that KDE_HOME_READONLY should not be required to avoid this freeze. Requiring KDE_HOME_READONLY means that a user must consciously want to run on a read-only system, which I guess is not very useful / common. But read-only remount due to kernel bug or cosmic ray is somewhat common, so KDE should still support users investigate and fix the root-cause if that happens. If KDE locks up the X Session, this makes debugging harder and may encourage users to force reboot their system, which in turn would make documenting and recovering from the kernel issue / bit-flip data corruption issue harder. -- You are receiving this mail because: You are watching all bug changes.
[kscreenlocker] [Bug 403255] Screenlock prevented by kdialog on read-only filesystem
https://bugs.kde.org/show_bug.cgi?id=403255 --- Comment #2 from Kai Uwe Broulik --- Also, you may want to set KDE_HOME_READONLY in your environment if you use a read-only home, as I don't think this is a supported usecase. -- You are receiving this mail because: You are watching all bug changes.
[kscreenlocker] [Bug 403255] Screenlock prevented by kdialog on read-only filesystem
https://bugs.kde.org/show_bug.cgi?id=403255 Kai Uwe Broulik changed: What|Removed |Added CC||k...@privat.broulik.de Ever confirmed|0 |1 Status|REPORTED|CONFIRMED --- Comment #1 from Kai Uwe Broulik --- https://phabricator.kde.org/D18291 -- You are receiving this mail because: You are watching all bug changes.
