On Fri, 2012-12-14 at 14:54 -0500, Adam Tauno Williams wrote: > Quoting Adam Tauno Williams <[email protected]>: > > > Quoting Adam Tauno Williams <[email protected]>: > > > >> On Tue, 2012-11-27 at 14:47 +0100, Dominique Leuenberger a.k.a DimStar > >> wrote: > >>> Quoting Adam Tauno Williams <[email protected]>: > >>>> After upgrading two boxes to the current GNOME3.6 both land at a > >>>> spinning-pizza-of-death on a black background. > >>>> Messages in dmesg like - > >>>> [ 39.715139] eth0: no IPv6 routers present > >>>> [ 60.071102] show_signal_msg: 66 callbacks suppressed > >>>> [ 60.071105] gnome-shell[1618]: segfault at 30 ip 00007f79f3e37116 sp > >>>> 00007fff88a3a590 error 4 in libgdk-3.so.0.400.4[7f79f3de4000+a4000] > >>>> [ 63.594961] EXT4-fs (sda2): re-mounted. Opts: acl,user_xattr,commit=0 > >>>> [ 63.621990] EXT4-fs (sda3): re-mounted. Opts: acl,user_xattr,commit=0 > >>> That does not sound good... > >>> First, make sure you have ALL updates from GS35: > >>> zypper lu -a -r GS36 (if GS36 is the name you gave the repo) > >> One one workstations I just had to zypper dup back to the mainline GNOME > >> to get it working right away - so I don't know about that one. > >> On my test box [ where I can break things :) ] the "zypper lu -a -r > >> GS36" and a reboot *DID* resolve the problem. I suspect the repository > >> priorities were not adjusted and somehow mainline GTK packages got mixed > >> in with the packages from GS36. > >> Both boxes were showing segfaults from either libgdk or libgtk. > >>> Also: can you manage to get a backtrace? > >>> An easy way is to setup your system to create coredumps in /cores for > >>> you; as starting stuff in gdb is typically running after it and not > >>> being able to reproduce. > >>> How to setup the system: > >>> in /etc/security/limits.conf add a line > >>> * soft core unlimited > >>> in /etc/sysctl.conf add a line > >>> kernel.core_pattern = /cores/%e-%u-%t.core > >>> create a folder /cores > >>> mkdir /cores > >>> chmod 777 /cores > >>> -> warning! This is NOT for production! But it can help a great deal > >>> in debugging... > >>> Later on, using gdb, you can load the coredumps (and redo a bt as > >>> often as you need, even installing debuginfo packages afterwards is > >>> still possible). > >> I'll do this on my test box in any case, for future breakage reporting. > >>> With this, we should be able to track this down... > >>> (Please also create a bug report about this... to have it tracked). > > Now it appears to have happened to my primary laptop; boot-up > > starts X and leaves it at a spinning-pizza-of-death. Cores are > > enabled but nothing is being dropped in "/cores". > > Argh!!! So I'm dupp'ing again to see if that fixes it. > > I had an oddity this morning. > > I did a zypper refresh, and then tried to install GVFS debuginfo > > packages. It said none matching my versions (from GS36) were > > available. I have the priority of the GS36 repo at 80, higher than > > the openSUSE repo-oss (at 99). So I thought it was odd, I changed > > the priority back to 99 on GS36, so they were all the same. And > > then the debuginfo packages were found. But now after reboot things > > seem out-of-whack. > > It seems odd. I was at GVFS 1.14 like in the GS36 repor, but then > > "zypper lu -a -r GS36" showed older packages installed for other > > stuff. Scratches head... > > We'll see if dup'ing fixes me. > Yes, the "zypper dup --from GS36" restored the laptop to working. > Scratches head again (I might be balding).
FYI, GNOME 3.6 has been stable on my laptop and both workstations ever since this issue. And I did a fresh from DVD install and subsequent dup to GNOME 3.6 on a test laptop yesterday [2013-02-25]... and it is working perfectly. -- Adam Tauno Williams GPG D95ED383 Systems Administrator, Python Developer, LPI / NCLA -- To unsubscribe, e-mail: [email protected] To contact the owner, e-mail: [email protected]
