This message might be slightly off topic.
This message is about Gnome 3.22 and 3.24 and later versions.   

I am using Fedora 25 and Fedora 26 Linux.For specific reasons, (SSD 
installations) the underlying file system is btrfs. (minimized writes to the 
The good news1) With lvm, ext4, xfs Gnome behaves ideally --I have not 
experienced any problems
2) With btrfs  -- half the time when logging to the system, the session will 
not start. Looking at it with /root, I see 
gnome-session running at 99%.  Its in a tight loop.   

2.1) After killing the loop, if I am lucky, one chance in 5, I can get the 
session to load.     If zero extensions, that is, not one extension is loaded 
within /usr/share/gnome-shell/extensions, or with 
$HOME/.local/share-gnome-extensions/extensiions,  I can run the session, log 
out and log in frequently, and the action is as it is for the EXT4 

3) If I move $HOME to a new partition, out from /btrfs,  extensions placed in 
$HOME/local/share/extensions   will function correctly, and things work out OK, 
as they do for the EXT4 situation.
If I move $HOME, as above, but there are extensions residing within 
/usr/share/gnome-shell/extensions,  I may be lucky, after a fresh boot, to log 
in and things are fine.  But if I log out and I try to log back in, I will not 
be able to return. It is as mentioned in 2)
So, what is my "gripe" to Q/A people?         Test with btrfs.  For a typical 
function that causes problems, 
take a copy of TaskBar by zyper as the single extension (I can provide others, 
but one extension is enough to do Q/A) and resolve this issue since Gnome 3.22 
(or before).
Desktop users are purchasing SSD's and not rotating disks.   SSD users are 
advised to install Linux using btrfs to prolong the life of the SSD. 
This is why: 
      Ext4 = write_data+meta_data+journal+(atime update) = 4 updates.  
      Btrfs = (copy on write) = 1 meta_data +1 data = 2 writes       

For your QA people. 
Test with ssd and nossd parameter 
UUID=28615a60-5669-4be2-8546-93985254af07  /          btrfs   
subvol=root,noatime,ssd 0  0     /dev/sdc4   fedora_f26c
UUID=28615a60-5669-4be2-8546-93985254af07  /          btrfs   
subvol=root,noatime,nossd 0  0     /dev/sdc4   fedora_f26c
This bug is more than 1 year old. Last year hard disks outsold SSD's. Today it 
is not so.  Its time to fix up gnome-shell.
I did raise a bug report. But who takes action if there is only one individual 
raising the bug?  
 Leslie Satenstein, retired software engineer.
Montréal Québec, Canada
55+ years in IT as software engineer. 

      From: "" <>
 To: Arun Raghavan <> 
Cc: desktop-devel-list <>
 Sent: Monday, July 31, 2017 8:14 AM
 Subject: Re: Too many broken modules
On Mon, Jul 31, 2017 at 12:36 PM, Arun Raghavan <> wrote:

Is there some place we can look at logs of the current build? I don'thave a 
jhbuild-y setup here, but I'd be happy to look at the gst-*failures.

Nope, got to ask Javier if he remembers why it failed. Sorry. We know we need 
way better release infrastructure. Alternatively you could download the 3.25.4 
modulesets from the release announcement and try building that.
In the past, I had to change GStreamer to build from Autotools instead of meson 
because the tarballs did not contain That's the first thing I 
would check.
desktop-devel-list mailing list

desktop-devel-list mailing list

Reply via email to