GNOME Bugzilla – Bug 784560
Gnome Shell 3.24 installed on btrfs locks up and changes logon settings
Last modified: 2017-11-10 07:36:27 UTC
Testing Fedora26 -- golive candidate. Its installed on btrfs formatted system. 3 test installations. I also have s second disk with the same Fedora candidate and based in ext4 When installing some extensions, there is a lockup during installation or a lockup after trying to establish settings Typical extensions causing the problems are: caffeine Gno-Menu Taskbar (zpydr version) Other extensions with settings. The ext4 versions if Gnome 3.24 present no problems. So, I am really discussing Gnome 3.24 installed onto btrfs file system. Why am I using btrfs The architect of ext4 recommended installing Fedora on SSDs by using btrfs, so as to prolong the life of SSD's. Gnome 3.24 (btrfs versions) When the system locks up, alt-f2+r does not restore the session. I can sometimes log in as root in terminal mode, and remove the extensions from ~/.local/share/gnome-sessions/extensions. This action is usually sufficient to recover the logon id, but one cannot use one or more of the extension(s). For a while I thought that the author of the extension was at fault, but I am not sure now as all the extensions that I use, work just fine with Gnome 3.22 I am testing with the following isos (particularly the live version) https://kojipkgs.fedoraproject.org/compose/26/latest-Fedora-26/compose/Workstation/x86_64/iso/ Fedora24 wants to go live this coming week. I think this is a serious bug. The test versions are on x64 system 4 core cpu and 8gigs ram. Disks are Sata based. And to note again, Gnome 3.22 (previous version) does not experience problems.
When the system locks up and I have to reboot, the logon screen gear shows that the system is note on Gnome Wayland or Gnome Org There is a list of interfaces, and the gear option shows AWEsome as the system to boot, unless I manually reset the system to Wayland.
Created attachment 355991 [details] The extension causing the problem This attachment pulled from GIT
Has anyone looked into why gnome-shell crashes if it has extensions and /home is also on btrfs? I have two btrfs systems. With /home on btrfs and some extensions, gnome-shell will enter a 100% cpu loop until killed by root. Then root issues a killuser -u userid The second attempt may or may not start gnome -shell for that user BTRFS is used because the host platform is an SSD. BTRFS is recommended for Desktop use with SSD's as the file system to extend an SSD's life span. I have provided an extension that runs without problems on LVM ext4 xfs but crashes gnome-shell if the /home/userid is on a btrfs system Want to see a daily list of crashes, visit fedora 26 bugzilla. I submit a daily 50 meg dump. abrt 6 abrt 11, and more... If there is no attempt to fixing, then one should recommend that gnome not be installed onto a btrfs system
Problems with an extension should be reported to the developer of said extension. It's at https://github.com/zpydr/gnome-shell-extension-taskbar in your case. In fact, you already did so: https://github.com/zpydr/gnome-shell-extension-taskbar/issues/156 so I'll close this bug which we cannot fix. You might want to provide the extension developer with a backtrace of the crash, otherwise there's probably not much that she/he can do.
Bastien. Since this extension follows the rules completely and it has worked and does work if the file system is ext4 or xfs, I would like this bug to remain open. I have recompiled the schema, I have checked every enum, though I am not an JS developer Is there a tool that I can install as an extension, that has the capabilities to start an extension located in a different location from the extension directory? For example, provide the name of the extension that I keep in the ../extension directory). That debugging tool will load the extension to be traced or the other faulty extensions that I detected as having problems with gnome under the btrfs file system. Looking glass does not appear the tool to use. If said tool does not exist, is there a statement that I can add to each function that pops up a function name and asks for a confirmation to continue? Debug statements for the javascript code is what I am after.
That's not how things work. If the extension makes gnome-shell crash, then that's where the bug needs to be root-caused. You're not going to get any help with third-party extensions from gnome-shell developers. If the extension author has found a defect, then it'll get reported back here. In the meantime, I'm afraid you get to keep both pieces.
Please read: I made a change to my logon as follows; I moved the ~.config/dconf from under btrfs to an ext4 file system. dconf -> /homeext4/leslie/.config/dconf/ All extensions remain on the btrfs file system. All other user files are on the btrfs file system. The dconf/user file is owned and managed by Gnome, It is never written to by the extension. The extension calls gnome-shell. The shell should not crash Gnome or even under other situations, disable the keyboard and mouse. I am not the author of the extension(s) in problem. I am the end-user. I have examined, line by line, the schemas of many failing extensions. They are clean. So what I did was move the ~/.config/dconf/user from btrfs to ext4. the ./config file on the ext4 file system allows all extensions to work as GNOME APIs are documented, subject to GNOME's rules for the API. An extension that I separated out from the others for your testing works, using the above trick and the api's and the range checks prescribed in the schema of that extension. Is this still an extension code issue?
Yes, until the extension author finds a defect in gnome-shell. See comment 6. Please do not change the status of this ticket.
Hi André, Bastien, I resolved the issue by abandoning btrfs. I removed all the extensions that were in /usr/share/gnome-shell/extensions and moved them to ~/.local/share/gnome/shell/extensions, and I moved /home to a /ext4 file system. As I stated, with / and /home under ext4, Gnome does not crash. It works from first logon after powerup to multiple login/logouts to shutdown at end of day. Je suis très déçu que ce problème ne sera pas corrigé.
(In reply to Leslie Satenstein from comment #9) > Je suis très déçu que ce problème ne sera pas corrigé. Leslie: If you do not report problems to the right folks after having been informed twice who the right folks are, this problem likely will not get fixed, indeed. Up to you whether to continue ignoring such feedback or not.
Note, downstream bug https://bugzilla.redhat.com/show_bug.cgi?id=1469129 has a lot more folks affected by something that looks similar. We don't have details for all reporters but it looks a bit like some combination of btrfs+extensions may be involved in at least some cases.
(In reply to Adam Williamson from comment #11) > Note, downstream bug https://bugzilla.redhat.com/show_bug.cgi?id=1469129 has > a lot more folks affected by something that looks similar. We don't have > details for all reporters but it looks a bit like some combination of > btrfs+extensions may be involved in at least some cases. I think that's bug 788931.