After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 784560 - Gnome Shell 3.24 installed on btrfs locks up and changes logon settings
Gnome Shell 3.24 installed on btrfs locks up and changes logon settings
Status: RESOLVED NOTGNOME
Product: gnome-shell
Classification: Core
Component: extensions
3.2.x
Other Linux
: Normal critical
: ---
Assigned To: gnome-shell-maint
gnome-shell-maint
Depends on:
Blocks:
 
 
Reported: 2017-07-05 18:01 UTC by Leslie Satenstein
Modified: 2017-11-10 07:36 UTC
See Also:
GNOME target: ---
GNOME version: 3.23/3.24


Attachments
The extension causing the problem (165.76 KB, application/octet-stream)
2017-07-20 01:09 UTC, Leslie Satenstein
Details

Description Leslie Satenstein 2017-07-05 18:01:14 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.
Comment 1 Leslie Satenstein 2017-07-05 18:04:09 UTC
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.
Comment 2 Leslie Satenstein 2017-07-20 01:09:14 UTC
Created attachment 355991 [details]
The extension causing the problem

This attachment pulled from GIT
Comment 3 Leslie Satenstein 2017-08-08 04:15:03 UTC
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
Comment 4 Bastien Nocera 2017-08-10 20:38:35 UTC
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.
Comment 5 Leslie Satenstein 2017-08-14 00:48:48 UTC
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.
Comment 6 Bastien Nocera 2017-08-14 01:09:19 UTC
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.
Comment 7 Leslie Satenstein 2017-08-14 17:08:25 UTC
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?
Comment 8 André Klapper 2017-08-14 19:53:14 UTC
Yes, until the extension author finds a defect in gnome-shell. See comment 6.
Please do not change the status of this ticket.
Comment 9 Leslie Satenstein 2017-08-14 22:04:46 UTC
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é.
Comment 10 André Klapper 2017-08-15 07:19:52 UTC
(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.
Comment 11 Adam Williamson 2017-11-09 20:26:08 UTC
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.
Comment 12 Debarshi Ray 2017-11-10 07:36:27 UTC
(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.