2:35 p.m.
Hi,
Looks like today updates are trashing gnome almost completely.
gdm-x-session cannot setup XKB mapping. gnome-shell is core dumping ..
"journalctl -xe" output is in attachment.
kloczek
--
Tomasz Kłoczko | LinkedIn: *http://lnkd.in/FXPWxH <http://lnkd.in/FXPWxH>*
2:55 p.m.
Yeah I'm getting a bunch of clutter messages as well as many lines of
gnome shell desktop related stack traces. But there is nothing listed
by coredumpctl, or abrt.
Feb 02 13:51:31 f27h.localdomain org.gnome.Shell.desktop[1612]: ==
Stack trace for context 0x557b7ae9d000 ==
4:55 p.m.
Any news on the cause? I'm waiting to update until this is figured out...
Thanks,
Richard
6:53 p.m.
On 3 February 2018 at 22:55, Richard Shaw <hobbes1069(a)gmail.com> wrote:
Any news on the cause? I'm waiting to update until this is
figured out...
Still don't see any update about the issue.
It is really pain in the a*s that Linux still has no good support to handle
such cases like it is on for example on Solaris where is possible to
generate using zfs snapshots and cloning separated BEs (boot environments)
on each upgrade or even new package install which adds to grub menu new
boot entry which allows preserve 100% state from before any packages
operations.
Just checked a bit dnf documentation and seems that dnf supports rollback
operation. However as long as Fedora repo holds only latest versions of the
each package I'm only curious how it is handled as rpm no longer supports
repackage and rollback operations (?).
Can someone share some details how to use dnf rollback and/or is it now
supported by Fedora rawhide?
Issues like this one with crashing gnome may happen always an no one should
be bashing anyone for such faults as rawhide is devel by definition however
details about how system needs to be prepared to handle rollback using dnf
are quite important.
kloczek
--
Tomasz Kłoczko | LinkedIn: *http://lnkd.in/FXPWxH <http://lnkd.in/FXPWxH>*
7:51 p.m.
Tomasz Kłoczko writes:
On 3 February 2018 at 22:55, Richard Shaw
<<URL:mailto:hobbes1069@gmail.com>hobbes1069@gmail.com> wrote:
Any news on the cause? I'm waiting to update until this is figured out...
Still don't see any update about the issue.
It is really pain in the a*s that Linux still has no good support to handle
One option that's available to you is to switch to another desktop. No
issues here, whatsoever, on my XFCE desktop.
I replaced Gnome with XFCE on all my desktops a number of years ago, and
haven't looked back.
12:43 a.m.
On 4 February 2018 at 01:51, Sam Varshavchik <mrsam(a)courier-mta.com> wrote:
Tomasz Kłoczko writes:
On 3 February 2018 at 22:55, Richard Shaw <<URL:mailto:hobbes1069@gmail.
> com>hobbes1069(a)gmail.com> wrote:
>
> Any news on the cause? I'm waiting to update until this is figured
> out...
>
> Still don't see any update about the issue.
> It is really pain in the a*s that Linux still has no good support to
> handle
>
One option that's available to you is to switch to another desktop. No
issues here, whatsoever, on my XFCE desktop.
I replaced Gnome with XFCE on all my desktops a number of years ago, and
haven't looked back.
I gave the chance for xfce and here are some my conclusions:
- Pros:
-- much lower memory consumption. Difference is about 1.2GB less RAM. On
one of my laptops with only 8GB RAM it makes really big difference
- Cons:
-- after only 3-4h on m primary desktop I've been able to collect descent
number of core files
# ls -la /var/lib/systemd/coredump/*
-rw-r-----+ 1 root root 1628938240 Feb 6 03:28
/var/lib/systemd/coredump/core.chrome.1000.9b34b2ba89514d86a302484519bf2a53.14303.1517887637000000
-rw-r-----+ 1 root root 37933056 Feb 6 04:10
/var/lib/systemd/coredump/core.mission-control.1000.ad37f99486c24da58887b80804c84322.9243.1517890233000000
-rw-r-----+ 1 root root 28282880 Feb 6 03:34
/var/lib/systemd/coredump/core.xfce4-notifyd.1000.ad37f99486c24da58887b80804c84322.2398.1517888039000000
-rw-r-----+ 1 root root 32505856 Feb 6 04:27
/var/lib/systemd/coredump/core.xfce4-notifyd.1000.ad37f99486c24da58887b80804c84322.5645.1517891258000000
and only this does not look good :/
Chrome as usually is affected by memory leaks which are causing that on
some web pages suddenly some chrome process suddenly puffs and crashes by
passing max memory limit. Of course this issue has nothing to do with xfce.
Other cores may be caused by the same cause(s) which is(are) now affecting
Gnome desktop.
-- xfce needs a lot of work
--- base @Xfce kickstart group drags a lot of dependencies which are not
essential. It wold be IMO good to create something @Xfce-minimal group
--- I've installed xfce by choosing initially set of packages and I've anup
on desktop without window manage so it wold be good to add to one of the
core xfce package "Require: windowmanager" and add to all packages
"Provides: windowmanager" if xfce can be used without xfwm4 or add straight
Requires: xfwm4
My my minimal set of xfce packages:
libxfce4ui
libxfce4util
xfce4-appfinder
xfce4-notifyd
xfce4-panel
xfce4-power-manager
xfce4-screenshooter
xfce4-session
xfce4-session-engines
xfce4-settings
xfce4-taskmanager
xfce4-terminal
xfce4-xkb-plugin
xfce-polkit
xfconf
xfdesktop
xfwm4
I'm opened on any suggestions about what more could be added to such set :)
-- trying to launch any gnome application still is affected by already
discussed in this thread issues.
--- it is not possible to tart working wit xfce desktop because during
first time xfce start it is necessary to answer on few questions. I thing
that it is generally wrong strategy because everything should start with
some default settings. Whatever someone will like/dislike still is possible
to customize later.
--- I think that it wold be really good to prepare initial default desktop
layout to mimic default Gnome desktop. This wold make migration from Gnome
to xfce much smoother.
-- I thing that using xfce4 in many packages should be replaced by just
xfce This will make future transitions to next major version easier. I see
that already some number of xfce packages is not using this "4" in package
names.
- Other:
Looks like changing xkb keyboard layout which started with crashing
gnome-shell under gome is not caused by gnome-shell but by gdm issue. from
logs:
Feb 06 03:45:43 domek /usr/libexec/gdm-x-session[5448]: (**) Option
"xkb_layout" "pl,gb,us"
Feb 06 03:45:43 domek /usr/libexec/gdm-x-session[5448]: (**) Option
"xkb_variant" ",,"
Feb 06 03:45:43 domek /usr/libexec/gdm-x-session[5448]: syntax error: line
500 of pl
Feb 06 03:45:43 domek /usr/libexec/gdm-x-session[5448]: The XKEYBOARD
keymap compiler (xkbcomp) reports:
Feb 06 03:45:43 domek /usr/libexec/gdm-x-session[5448]: > Error:
Error interpreting include file "pl"
Feb 06 03:45:43 domek /usr/libexec/gdm-x-session[5448]: >
Exiting
Feb 06 03:45:43 domek /usr/libexec/gdm-x-session[5448]: >
Abandoning symbols file "default"
Feb 06 03:45:43 domek /usr/libexec/gdm-x-session[5448]: Errors from xkbcomp
are not fatal to the X server
Feb 06 03:45:43 domek /usr/libexec/gdm-x-session[5448]: (EE) Error loading
keymap /tmp/server-0.xkm
Feb 06 03:45:43 domek /usr/libexec/gdm-x-session[5448]: (EE) XKB: Failed to
load keymap. Loading default keymap instead.
Cannot find which one xkb map is used in above case. After uncompressing
/lib/kbd/keymaps/xkb/pl.map.gz I see that this file has only 199 lines so
this error message must be about some other (text?) file. So Still I cannot
change keyboard layout to pl :/
kloczek
--
Tomasz Kłoczko | LinkedIn: *http://lnkd.in/FXPWxH <http://lnkd.in/FXPWxH>*
5:48 a.m.
Tomasz Kłoczko writes:
-- after only 3-4h on m primary desktop I've been able to collect
descent
number of core files
# ls -la /var/lib/systemd/coredump/*
-rw-r-----+ 1 root root 1628938240 Feb 6 03:28
/var/lib/systemd/coredump/core.chrome.
1000.9b34b2ba89514d86a302484519bf2a53.14303.1517887637000000
-rw-r-----+ 1 root root 37933056 Feb 6 04:10
/var/lib/systemd/coredump/core.mission-control.
1000.ad37f99486c24da58887b80804c84322.9243.1517890233000000
-rw-r-----+ 1 root root 28282880 Feb 6 03:34
/var/lib/systemd/coredump/core.xfce4-notifyd.
1000.ad37f99486c24da58887b80804c84322.2398.1517888039000000
-rw-r-----+ 1 root root 32505856 Feb 6 04:27
/var/lib/systemd/coredump/core.xfce4-notifyd.
1000.ad37f99486c24da58887b80804c84322.5645.1517891258000000
Never had xfce4-notifyd crash on me. Not sure what mission-control is. I
have chrome running on my Ubuntu laptop, also XFCE desktop, never had it
crash either.
9:05 a.m.
On 6 February 2018 at 11:48, Sam Varshavchik <mrsam(a)courier-mta.com> wrote:
[..]
Never had xfce4-notifyd crash on me. Not sure what mission-control
is. I
have chrome running on my Ubuntu laptop, also XFCE desktop, never had it
crash either.
Thiis process is part of the telepathy-mission-control package. It crashed
when I've been trying to use polari Gnome IRC client under xfce.
Looks like this crach has nothing to do with xfce per se, however xfce4-notifyd
looks like it is part of of te xfce.
More details about this process crashes:
Feb 06 10:41:23 domek xfce4-notifyd[23486]: malloc_consolidate(): invalid
chunk size
Feb 06 10:41:29 domek systemd[1]: Started Process Core Dump (PID 30009/UID
0).
-- Subject: Unit systemd-coredump(a)4-30009-0.service has finished start-up
-- Defined-By: systemd
-- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit systemd-coredump(a)4-30009-0.service has finished starting up.
--
-- The start-up result is RESULT.
Feb 06 10:41:32 domek systemd[5399]: xfce4-notifyd.service: Main process
exited, code=dumped, status=6/ABRT
Feb 06 10:41:36 domek dbus-daemon[5457]: [session uid=1000 pid=5457]
Activating via systemd: service name='org.freedesktop.Notifications'
unit='xfce4-notifyd.service' requested by ':1.42' (uid=1000 pid=5534
comm="/usr/share/skypeforlinux/skypeforlinux --executed-")
Feb 06 10:41:32 domek systemd[5399]: xfce4-notifyd.service: Failed with
result 'core-dump'.
Feb 06 10:41:36 domek systemd[5399]: Starting XFCE notifications service...
-- Subject: Unit UNIT has begun start-up
-- Defined-By: systemd
-- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit UNIT has begun starting up.
And gdb stack back trace:
Core was generated by `/usr/lib64/xfce4/notifyd/xfce4-notifyd'.
Program terminated with signal SIGABRT, Aborted.
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
50 return ret;
[Current thread is 1 (Thread 0x7f1b8aa59a80 (LWP 23486))]
(gdb) bt
#0 0x00007f1b871f0f6b in __GI_raise (sig=sig@entry=6) at
../sysdeps/unix/sysv/linux/raise.c:50
#1 0x00007f1b871db591 in __GI_abort () at abort.c:79
#2 0x00007f1b87233cab in __libc_message (action=action@entry=do_abort,
fmt=fmt@entry=0x7f1b8733d95e "%s\n") at ../sysdeps/posix/libc_fatal.c:181
#3 0x00007f1b8723a1dc in malloc_printerr (str=str@entry=0x7f1b8733f208
"malloc_consolidate(): invalid chunk size") at malloc.c:5353
#4 0x00007f1b8723a4da in malloc_consolidate (av=av@entry=0x7f1b87573c40
<main_arena>) at malloc.c:4444
#5 0x00007f1b8723d0a0 in _int_malloc (av=av@entry=0x7f1b87573c40
<main_arena>, bytes=bytes@entry=1352) at malloc.c:3706
#6 0x00007f1b8723f5f2 in __libc_calloc (n=n@entry=1,
elem_size=elem_size@entry=1352) at malloc.c:3439
#7 0x00007f1b877e9511 in g_malloc0 (n_bytes=n_bytes@entry=1352) at
gmem.c:124
#8 0x00007f1b89844ea3 in _gtk_css_lookup_new (relevant=relevant@entry=0x0)
at gtkcsslookup.c:32
#9 0x00007f1b898596b3 in gtk_css_static_style_new_compute
(provider=0x7f1b6c00e900, matcher=matcher@entry=0x7fffcfbfff40,
parent=parent@entry=0x0)
at gtkcssstaticstyle.c:183
#10 0x00007f1b898475b4 in gtk_css_node_create_style (cssnode=0x5640f830aaa0
[GtkCssWidgetNode]) at gtkcssnode.c:371
#11 0x00007f1b898475b4 in gtk_css_node_real_update_style
(cssnode=0x5640f830aaa0 [GtkCssWidgetNode], change=135, timestamp=0,
style=0x5640f813a040 [GtkCssStaticStyle]) at gtkcssnode.c:425
#12 0x00007f1b898463a4 in gtk_css_node_ensure_style
(cssnode=cssnode@entry=0x5640f830aaa0
[GtkCssWidgetNode], current_time=0) at gtkcssnode.c:1007
#13 0x00007f1b898465b6 in gtk_css_node_ensure_style
(current_time=<optimized out>, cssnode=0x5640f830aaa0 [GtkCssWidgetNode])
at gtkcssnode.c:992
#14 0x00007f1b898465b6 in gtk_css_node_get_style (cssnode=0x5640f830aaa0
[GtkCssWidgetNode]) at gtkcssnode.c:1033
#15 0x00007f1b899a890b in gtk_style_context_lookup_style
(context=0x5640f8172f90 [GtkStyleContext]) at gtkstylecontext.c:493
#16 0x00007f1b899a890b in _gtk_style_context_peek_style_property
(context=context@entry=0x5640f8172f90 [GtkStyleContext],
widget_type=94837039369344, pspec=0x7f1b680041e0 [GParamDouble]) at
gtkstylecontext.c:1635
#17 0x00007f1b89a5320c in gtk_widget_style_get_valist
(widget=widget@entry=0x5640f81242f0
[XfceNotifyWindow],
first_property_name=first_property_name@entry=0x5640f674cd35
"padding", var_args=var_args@entry=0x7fffcfc00160) at gtkwidget.c:13248
#18 0x00007f1b89a53598 in gtk_widget_style_get (widget=0x5640f81242f0
[XfceNotifyWindow],
first_property_name=first_property_name@entry=0x5640f674cd35
"padding")
at gtkwidget.c:13286
#19 0x00005640f67493cd in xfce_notify_window_init (window=0x5640f81242f0
[XfceNotifyWindow]) at xfce4-notifyd/xfce-notify-window.c:227
#20 0x00007f1b87ae22c5 in g_type_create_instance (type=94837039369344) at
gtype.c:1866
#21 0x00007f1b87ac2518 in g_object_new_internal
(class=class@entry=0x5640f8112820,
params=params@entry=0x7fffcfc00570, n_params=n_params@entry=1) at
gobject.c:1797
#22 0x00007f1b87ac445e in g_object_new_valist (object_type=<optimized out>,
first_property_name=first_property_name@entry=0x5640f674c4b3 "type",
var_args=var_args@entry=0x7fffcfc006c0) at gobject.c:2120
#23 0x00007f1b87ac47d9 in g_object_new (object_type=<optimized out>,
first_property_name=first_property_name@entry=0x5640f674c4b3 "type") at
gobject.c:1640
#24 0x00005640f674b30c in xfce_notify_window_new_with_actions
(summary=summary@entry=0x5640f8230560 "tata", body=body@entry=0x5640f830a710
"tata: Missed call", icon_name=icon_name@entry=0x5640f8321af0 "",
expire_timeout=expire_timeout@entry=-1, actions=actions@entry=0x5640f827f100,
css_provider=0x5640f80b22e0 [GtkCssProvider]) at xfce4-notifyd/xfce-notify-
window.c:742
#25 0x00005640f6747ca4 in notify_notify (skeleton=0x5640f80c61d0,
invocation=0x7f1b6c012ab0 [GDBusMethodInvocation], app_name=<optimized
out>, replaces_id=0, app_icon=0x5640f8321af0 "", summary=0x5640f8230560
"tata", body=0x5640f830a710 "tata: Missed call",
actions=0x5640f827f100,
hints=0x7f1b68012390, expire_timeout=-1, xndaemon=0x5640f80c61d0
[XfceNotifyDaemon]) at xfce4-notifyd/xfce-notify-daemon.c:1288
#26 0x00007f1b8255103e in ffi_call_unix64 () at ../src/x86/unix64.S:76
#27 0x00007f1b825509ff in ffi_call (cif=<optimized out>, fn=<optimized
out>, rvalue=<optimized out>, avalue=<optimized out>) at
../src/x86/ffi64.c:525
---Type <return> to continue, or q <return> to quit---
#31 0x00007f1b87ad8423 in Python Exception <class 'gdb.error'> There is no
member named v_pointer.:
#32 0x00005640f67455ca in _xfce_notify_gbus_skeleton_handle_method_call
(connection=<optimized out>, sender=<optimized out>,
object_path=<optimized
out>, interface_name=0x5640f817d490 "org.freedesktop.Notifications",
method_name=0x7f1b6c00e7b0 "Notify", parameters=<optimized out>,
invocation=0x7f1b6c012ab0 [GDBusMethodInvocation],
user_data=0x5640f80c61d0) at xfce4-notifyd/xfce-notify-gbus.c:1734
#33 0x00007f1b87de0587 in g_dbus_interface_method_dispatch_helper
(interface=<optimized out>, method_call_func=0x5640f6745410
<_xfce_notify_gbus_skeleton_handle_method_call>, invocation=0x7f1b6c012ab0
[GDBusMethodInvocation]) at gdbusinterfaceskeleton.c:609
#34 0x00007f1b87dc8109 in call_in_idle_cb
(user_data=user_data@entry=0x7f1b6c012ab0)
at gdbusconnection.c:4851
#35 0x00007f1b877e05e7 in g_idle_dispatch (source=0x7f1b6c012000,
callback=0x7f1b87dc7fe0 <call_in_idle_cb>, user_data=0x7f1b6c012ab0) at
gmain.c:5535
#36 0x00007f1b877e3c17 in g_main_dispatch (context=0x5640f80678f0) at
gmain.c:3177
#37 0x00007f1b877e3c17 in g_main_context_dispatch
(context=context@entry=0x5640f80678f0)
at gmain.c:3830
#38 0x00007f1b877e3fc0 in g_main_context_iterate (context=0x5640f80678f0,
block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at
gmain.c:3903
#39 0x00007f1b877e42d2 in g_main_loop_run (loop=0x5640f80fe210) at
gmain.c:4099
#40 0x00007f1b898f60a5 in gtk_main () at gtkmain.c:1322
#41 0x00005640f6743819 in main (argc=<optimized out>, argv=<optimized out>)
at xfce4-notifyd/main.c:73
Will try kater to create the ticket with this.
kloczek
--
Tomasz Kłoczko | LinkedIn: *http://lnkd.in/FXPWxH <http://lnkd.in/FXPWxH>*
2:17 a.m.
On Sat, Feb 3, 2018 at 5:53 PM, Tomasz Kłoczko <kloczko.tomasz(a)gmail.com> wrote:
On 3 February 2018 at 22:55, Richard Shaw
<hobbes1069(a)gmail.com> wrote:
>
> Any news on the cause? I'm waiting to update until this is figured out...
Still don't see any update about the issue.
It is really pain in the a*s that Linux still has no good support to handle
such cases like it is on for example on Solaris where is possible to
generate using zfs snapshots and cloning separated BEs (boot environments)
on each upgrade or even new package install which adds to grub menu new boot
entry which allows preserve 100% state from before any packages operations.
It's not a Linux limitation, the infrastructure is there. SUSE has had
state preserving rollbacks for several years. Their Btrfs patches for
GRUB, which I think are now upstream so we might also have them,
discover Btrfs snapshots made by snapper before and after every
package change, and build menu entries for each snapshot. Pick one,
and you get a read only one time rollback to the chosen snapshot.
Fedora repo does have both snapper and a dnf snapper plugin that'll
take snapshots of rootfs before any dnf update, and it's possible to
use snapper to rollback - I've only ever done it with a Btrfs rootfs
but I think snapper also supports LVM thinly provisioned volumes and
snapshots. The gotcha compared to what SUSE folks are doing is, on
Fedora it's possible (likely) to get a disconnect between the kernels
located in /boot vs the modules installed on the rolledback rootfs,
because /boot is not snapshot along with rootfs on Fedora since
they're separate file systems. So that'll inevitably snare things
unless you manually 'cp -a --reflink' copy the latest modules dir from
a current tree into a rolledback tree. And the reason for this is the
Fedora installer enforces /boot being on a plain ext4 or XFS volume,
it can't be on Btrfs due to a now 6+ year old grubby bug that causes
grubby to not update grub.cfg if /boot is a Btrfs subvolume.
Just checked a bit dnf documentation and seems that dnf supports
rollback
operation. However as long as Fedora repo holds only latest versions of the
each package I'm only curious how it is handled as rpm no longer supports
repackage and rollback operations (?).
I've never tried doing rollbacks from dnf itself. If I need to
rollback, I just pick one I'm doing to rollback to, update the fstab
inside that snapshot to reflect the correct snapshot/subvolume name
used by the subvol= mount option, reboot, and then I manually edit the
boot entry's rootflags=subvol= parameter to reflect the name of the
snapshot I want to boot. Done, I've rolled back.
Of course you've just rolled back everything except home. So even your
journal log is rolledback on Fedora since it's located in the root
subvolume, whereas on SUSE they've got one of the longest fstabs
mankind has imagined, in order to carve out with a scalpel exactly
what is and is not subject to rollbacks.
Can someone share some details how to use dnf rollback and/or is it now
supported by Fedora rawhide?
Issues like this one with crashing gnome may happen always an no one should
be bashing anyone for such faults as rawhide is devel by definition however
details about how system needs to be prepared to handle rollback using dnf
are quite important.
I'm seeing it in Fedora 27.
--
Chris Murphy
1 a.m.
On 02/02/2018 12:55 PM, Chris Murphy wrote:
Yeah I'm getting a bunch of clutter messages as well as many
lines of
gnome shell desktop related stack traces. But there is nothing listed
by coredumpctl, or abrt.
Feb 02 13:51:31 f27h.localdomain org.gnome.Shell.desktop[1612]: ==
Stack trace for context 0x557b7ae9d000 ==
The gnome shell related stack traces have been going for a while.
They're really annoying, but not fatal. However, there is an issue with
the Places menu extension that cause gnome shell to crash when a USB
device is plugged in and also other situations.
https://bugzilla.redhat.com/show_bug.cgi?id=1538493
6:22 p.m.
On 4 February 2018 at 07:00, Samuel Sieb <samuel(a)sieb.net> wrote:
On 02/02/2018 12:55 PM, Chris Murphy wrote:
> Yeah I'm getting a bunch of clutter messages as well as many lines of
> gnome shell desktop related stack traces. But there is nothing listed
> by coredumpctl, or abrt.
>
>
> Feb 02 13:51:31 f27h.localdomain org.gnome.Shell.desktop[1612]: ==
> Stack trace for context 0x557b7ae9d000 ==
>
The gnome shell related stack traces have been going for a while. They're
really annoying, but not fatal. However, there is an issue with the Places
menu extension that cause gnome shell to crash when a USB device is plugged
in and also other situations.
https://bugzilla.redhat.com/show_bug.cgi?id=1538493
In my case it is not necessary to do anything around USB.
Actually they are fatal.
Setting keyboard mapping is not working at all (I'm using as primary Polish
programmer kbd mapping).
Polari IRC client is not able to communicate with shell and by this is
completely useless (after joining channels after |1 min everything
disconnects from iRC server).
Whole desktop initiates incredibly slow (about maybe even 10 times longer
than it was before).
Every 10-20 min shell is dying completely and until it will be not
restarted it is not possible to do anything.
Just started tracing files operations using "strace -fe trace=file -p
<pid>" and found that gnome-shell is trying to stat() directories which it
shouldn't be trying to stat()
[pid 25382] stat("/usr/share/pixmaps/gnome", 0x7ffe80cddd40) = -1 ENOENT
(No such file or directory)
[pid 25382] stat("/usr/local/share/pixmaps/gnome", 0x7ffe80cddd40) = -1
ENOENT (No such file or directory)
[pid 25382] stat("/usr/share/icons/gnome", {st_mode=S_IFDIR|0755,
st_size=140, ...}) = 0
[pid 25382] stat("/usr/local/share/icons/gnome", 0x7ffe80cddd40) = -1
ENOENT (No such file or directory)
[pid 25382] stat("/home/tkloczko/.icons/gnome", 0x7ffe80cddd40) = -1 ENOENT
(No such file or directory)
[pid 25382] stat("/home/tkloczko/.local/share/icons/gnome", 0x7ffe80cddd40)
= -1 ENOENT (No such file or directory)
[pid 25382] stat("/home/tkloczko/.local/share/icons/Adwaita",
0x7ffe80cddd40) = -1 ENOENT (No such file or directory)
[pid 25382] stat("/home/tkloczko/.icons/Adwaita", 0x7ffe80cddd40) = -1
ENOENT (No such file or directory)
[pid 25382] stat("/usr/local/share/icons/Adwaita", 0x7ffe80cddd40) = -1
ENOENT (No such file or directory)
[pid 25382] stat("/usr/share/icons/Adwaita", {st_mode=S_IFDIR|0755,
st_size=222, ...}) = 0
[pid 25382] stat("/usr/local/share/pixmaps/Adwaita", 0x7ffe80cddd40) = -1
ENOENT (No such file or directory)
[pid 25382] stat("/usr/share/pixmaps/Adwaita", 0x7ffe80cddd40) = -1 ENOENT
(No such file or directory)
[pid 25382] stat("/home/tkloczko/.local/share/icons/hicolor",
{st_mode=S_IFDIR|0700, st_size=58, ...}) = 0
[pid 25382] stat("/home/tkloczko/.icons/hicolor", 0x7ffe80cddd40) = -1
ENOENT (No such file or directory)
[pid 25382] stat("/usr/local/share/icons/hicolor", 0x7ffe80cddd40) = -1
ENOENT (No such file or directory)
[pid 25382] stat("/usr/share/icons/hicolor", {st_mode=S_IFDIR|0755,
st_size=270, ...}) = 0
[pid 25382] stat("/usr/local/share/pixmaps/hicolor", 0x7ffe80cddd40) = -1
ENOENT (No such file or directory)
[pid 25382] stat("/usr/share/pixmaps/hicolor", 0x7ffe80cddd40) = -1 ENOENT
(No such file or directory)
[pid 25382] stat("/home/tkloczko/.local/share/icons",
{st_mode=S_IFDIR|0700, st_size=14, ...}) = 0
[pid 25382] stat("/home/tkloczko/.icons", 0x7ffe80cddd40) = -1 ENOENT (No
such file or directory)
[pid 25382] stat("/usr/local/share/icons", 0x7ffe80cddd40) = -1 ENOENT (No
such file or directory)
[pid 25382] stat("/usr/share/icons", {st_mode=S_IFDIR|0755, st_size=120,
...}) = 0
[pid 25382] stat("/usr/local/share/pixmaps", 0x7ffe80cddd40) = -1 ENOENT
(No such file or directory)
[pid 25382] stat("/usr/share/pixmaps", {st_mode=S_IFDIR|0755, st_size=944,
...}) = 0
[pid 25382] openat(AT_FDCWD, "/proc/self/stat", O_RDONLY) = 25
[pid 25382] openat(AT_FDCWD, "/proc/self/stat", O_RDONLY) = 25
[pid 25382] stat("/home/tkloczko/.local/share/sounds",
{st_mode=S_IFDIR|0700, st_size=0, ...}) = 0
[pid 25382] stat("/usr/local/share/sounds", 0x7ffe80cde5e0) = -1 ENOENT (No
such file or directory)
[pid 25382] stat("/usr/share/sounds", {st_mode=S_IFDIR|0755, st_size=86,
...}) = 0
Of course above is not a cause of current crashes but it would be good to
patch gnome-shell or some gnome libraries which are trying to search cross
some of above directories. and
Looks like gnome-shell is doing sequence of those stats regularly (why?)
Just checked what has been changed on my system at 31 Jan and I found:
# rpm -qa --qf "%{INSTALLTIME:date} %{NAME}\n" | grep "31 Jan 2018" |
grep
-v debuginfo | sort -k 7 | grep g
Wed 31 Jan 2018 23:34:25 GMT compat-gdbm
Wed 31 Jan 2018 23:13:41 GMT dbus-glib
Wed 31 Jan 2018 23:28:13 GMT dbus-glib-devel
Wed 31 Jan 2018 23:15:20 GMT gdbm
Wed 31 Jan 2018 23:13:31 GMT gjs << here
Wed 31 Jan 2018 23:28:34 GMT gjs-devel << here
Wed 31 Jan 2018 23:01:42 GMT glibc
Wed 31 Jan 2018 23:34:45 GMT glibc-all-langpacks
Wed 31 Jan 2018 23:00:59 GMT glibc-common
Wed 31 Jan 2018 23:20:40 GMT glibc-devel
Wed 31 Jan 2018 23:18:41 GMT glibc-headers
Wed 31 Jan 2018 23:34:37 GMT glibc-langpack-en
Wed 31 Jan 2018 23:01:15 GMT glibc-langpack-pl
Wed 31 Jan 2018 23:26:21 GMT glibc-utils
Wed 31 Jan 2018 23:09:21 GMT gpgme
Wed 31 Jan 2018 23:31:50 GMT gpgmepp
Wed 31 Jan 2018 23:13:35 GMT gsoap
Wed 31 Jan 2018 23:28:25 GMT gsoap-devel
Wed 31 Jan 2018 04:37:56 GMT gstreamer-plugins-bad-free
Wed 31 Jan 2018 23:34:04 GMT libappstream-glib
Wed 31 Jan 2018 23:34:06 GMT libgltf
Wed 31 Jan 2018 23:34:51 GMT libgxps
Wed 31 Jan 2018 23:28:04 GMT libnice-gstreamer1
Wed 31 Jan 2018 23:33:20 GMT libodfgen
Wed 31 Jan 2018 23:33:22 GMT libpagemaker
Wed 31 Jan 2018 23:06:37 GMT librevenge
Wed 31 Jan 2018 04:39:59 GMT mariadb-config
Wed 31 Jan 2018 23:33:38 GMT php-gd
Wed 31 Jan 2018 23:33:36 GMT php-mbstring
Wed 31 Jan 2018 23:31:46 GMT python2-gpg
Wed 31 Jan 2018 23:31:40 GMT python3-gpg
Wed 31 Jan 2018 04:39:45 GMT python3-pyparsing
Wed 31 Jan 2018 23:09:11 GMT qt5-qtbase-gui
Wed 31 Jan 2018 23:34:15 GMT swig
Wed 31 Jan 2018 23:31:14 GMT uboot-images-armv7
Wed 31 Jan 2018 23:31:35 GMT uboot-images-armv8
Wed 31 Jan 2018 23:34:56 GMT xorg-x11-drv-wacom-devel
because in call traces is possible to see a lot of javascripts call traces
and gjs it is Javascript Bindings for GNOME I think that it must be
probably something around exactly this package.
# rpm -q gjs --changelog | head -n 10
* Sun Jan 28 2018 Kalev Lember <klember(a)redhat.com> - 1.50.4-1
- Update to 1.50.4
* Thu Jan 18 2018 Kalev Lember <klember(a)redhat.com> - 1.50.3-1
- Update to 1.50.3
* Wed Nov 01 2017 Kalev Lember <klember(a)redhat.com> - 1.50.2-1
- Update to 1.50.2
* Mon Oct 09 2017 Kalev Lember <klember(a)redhat.com> - 1.50.1-1
Will try to downgrade to 1.50.3 to see is it can cure anything.
kloczek
--
Tomasz Kłoczko | LinkedIn: *http://lnkd.in/FXPWxH <http://lnkd.in/FXPWxH>*
1:33 p.m.
On Fri, Feb 02, 2018 at 20:35:25 +0000,
Tomasz Kłoczko <kloczko.tomasz(a)gmail.com> wrote:
Hi,
Looks like today updates are trashing gnome almost completely.
gdm-x-session cannot setup XKB mapping. gnome-shell is core dumping ..
"journalctl -xe" output is in attachment.
If this is rawhide, you might try downgrading m17n-db* . On one machine
the latest version is causing lots of applications to crash. On other
machines it doesn't happen and I don't know what the difference is.
I'm hoping the gcc8 rebuild will fix things when it happens. Right now I
don't have much for the maintainer to go on to try to fix things.
6:42 p.m.
On 6 February 2018 at 19:33, Bruno Wolff III <bruno(a)wolff.to> wrote:
On Fri, Feb 02, 2018 at 20:35:25 +0000,
Tomasz Kłoczko <kloczko.tomasz(a)gmail.com> wrote:
> Hi,
>
> Looks like today updates are trashing gnome almost completely.
> gdm-x-session cannot setup XKB mapping. gnome-shell is core dumping ..
>
> "journalctl -xe" output is in attachment.
>
If this is rawhide, you might try downgrading m17n-db* . On one machine
the latest version is causing lots of applications to crash. On other
machines it doesn't happen and I don't know what the difference is. I'm
hoping the gcc8 rebuild will fix things when it happens. Right now I don't
have much for the maintainer to go on to try to fix things.
m17n-db has nothing to do with xkb.
I've done something different.
I found that m17n-db is only required by m17n-lib package and m17n-lib is
required only by ibus-m17n, and nothing requires ibus-m17n.
So I've removed all those three packages and after logout-> loging (under
gnome or Xfce; both under X11) still gdm has been failing with *exactly*
the same error messages.
xkb is about keyboard mappings withing working X11 server.
Nevertheless just found what is causing tose xkb errors.
I've installed xorg-x11-xkb-extras to have the access to setxkbmap command
and on executing:
[tkloczko@domek ~]$ setxkbmap -v pl
Warning! Multiple definitions of keyboard layout
Using command line, ignoring X server
Trying to build keymap using the following components:
keycodes: evdev+aliases(qwerty)
types: complete
compat: complete
symbols: pc+pl+inet(evdev)
geometry: pc(pc105)
Error loading new keyboard description
[tkloczko@domek ~]$ strace -e trace=file setxkbmap -v pl
execve("/usr/bin/setxkbmap", ["setxkbmap", "-v",
"pl"], 0x7ffcce6b2830 /*
46 vars */) = 0
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or
directory)
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib64/libxkbfile.so.1", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib64/libX11.so.6", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib64/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib64/libxcb.so.1", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib64/libdl.so.2", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib64/libXau.so.6", O_RDONLY|O_CLOEXEC) = 3
access("/run/user/1000/gdm/Xauthority", R_OK) = 0
openat(AT_FDCWD, "/run/user/1000/gdm/Xauthority", O_RDONLY) = 4
Warning! Multiple definitions of keyboard layout
Using command line, ignoring X server
openat(AT_FDCWD, "./rules/evdev-C.lst", O_RDONLY) = -1 ENOENT (No such file
or directory)
openat(AT_FDCWD, "./rules/evdev.lst", O_RDONLY) = -1 ENOENT (No such file
or directory)
openat(AT_FDCWD, "/usr/share/X11/xkb/rules/evdev-C.lst", O_RDONLY) = -1
ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/share/X11/xkb/rules/evdev.lst", O_RDONLY) = 4
openat(AT_FDCWD, "/usr/share/X11/xkb/rules/evdev-C", O_RDONLY) = -1 ENOENT
(No such file or directory)
openat(AT_FDCWD, "/usr/share/X11/xkb/rules/evdev", O_RDONLY) = 4
Next was rpm query:
[tkloczko@domek ~]$ rpm -qif /usr/share/X11/xkb/rules/evdev
Name : xkeyboard-config
Version : 2.23
Release : 1.fc28
Architecture: noarch
Install Date: Fri 02 Feb 2018 03:10:22 GMT
Group : Unspecified
Size : 5804719
License : MIT
Signature : RSA/SHA256, Wed 31 Jan 2018 09:07:03 GMT, Key ID
e08e7e629db62fb1
Source RPM : xkeyboard-config-2.23-1.fc28.src.rpm
Build Date : Wed 31 Jan 2018 09:06:48 GMT <<<< ****HERE****
>>>>
Build Host : buildvm-ppc64le-15.ppc.fedoraproject.org
Relocations : (not relocatable)
Packager : Fedora Project
Vendor : Fedora Project
URL : http://www.freedesktop.org/wiki/Software/XKeyboardConfig
Summary : X Keyboard Extension configuration data
Description :
This package contains configuration data used by the X Keyboard Extension
(XKB),
which allows selection of keyboard layouts when using a graphical interface.
As long as upgrade 2.23 has been done around the time when mine problems
with xkb started I've downloaded xkeyboard-config-2.22 from f27 and after
downgrade:
[tkloczko@domek ~]$ setxkbmap -v pl
Warning! Multiple definitions of keyboard layout
Using command line, ignoring X server
Trying to build keymap using the following components:
keycodes: evdev+aliases(qwerty)
types: complete
compat: complete
symbols: pc+pl+inet(evdev)
geometry: pc(pc105)
[tkloczko@domek ~]$ łóćźęśźż
So I'm able now to enter Polish characters :)
So looks like at least something is wrong with xkeyboard-config-2.23.
If no one will try to check what has been changed in 2.23 tomorrow will
continue investigation (at the moment have no time to raise ticket).
A .. BTW: looks like m17n-{db,lib} and ibus-m17n are not needed and
everything is working perfectly fine (doesn't matter am I using us, gb or
pl xkb mapping).
Another conclusion: I think that using xkbcomp compile text definition to
binary file and use those binary files is a bit over complication of
setting all xkb settings.
setxkbmap command can use text xkb definitions and using libxkbfile library
to set keyboard mapping is causing that this library lis dynamically linked
with few other binaries which are constantly in memory. Using this library
is not kind the RightUnixWay(tm) as setting keyboard mapping is done only
one time per GUI session or change xkb settings is not time critical using
external command is OK.
Additionally using fixed file name /tmp/server-0.xkm adds security risk. On
use setxkbmap nothing needs to be written to any temporary file.
it is nothing wrong with do fork() end execute some external command.
If whole desktop would be using setxkbmap instead xkbcomp and libxkbfile it
would be possible to change xkx setting from command line or do additional
diagnostics like I've done above.
$ dnf -C repoquery --whatrequires 'libxkbfile.so.1()(64bit)'
cinnamon-desktop-0:3.6.2-3.fc28.x86_64
deepin-mutter-0:3.20.26-1.fc28.x86_64
fcitx-libs-0:4.2.9.5-1.fc28.x86_64
freerdp-libs-2:2.0.0-37.20180115git8f52c7e.fc28.x86_64
freerdp1.2-0:1.2.0-9.fc27.x86_64
input-pad-0:1.0.99.20140916-8.fc27.x86_64
kcm-fcitx-0:0.5.5-1.fc28.x86_64
ktouch-0:17.12.1-1.fc28.x86_64
libxkbfile-devel-0:1.0.9-6.fc27.x86_64
libxklavier-0:5.4-9.fc27.x86_64
mutter-0:3.27.1-1.fc28.x86_64
mutter-tests-0:3.27.1-1.fc28.x86_64
onboard-0:1.4.1-8.fc28.x86_64
plasma-desktop-0:5.12.0-1.fc28.x86_64
python2-virtkey-0:0.63.0-5.fc27.x86_64
python3-virtkey-0:0.63.0-5.fc27.x86_64
qxkb-0:0.4.6-9.fc26.x86_64
remmina-plugins-nx-0:1.2.0-0.46.20180107.git.d70108c.fc28.x86_64
xkb-switch-0:1.5.0-3.20160925gitda4ef22.fc27.x86_64
xorg-x11-apps-0:7.7-18.fc27.x86_64
xorg-x11-xkb-extras-0:7.7-21.fc27.x86_64
xorg-x11-xkb-utils-0:7.7-21.fc27.x86_64
xpra-0:2.2.3-5.fc28.x86_64
Looks like already to many things with using libxkbfile library went a bit
to far.
kloczek
--
Tomasz Kłoczko | LinkedIn: *http://lnkd.in/FXPWxH <http://lnkd.in/FXPWxH>*
10:12 p.m.
On Wed, Feb 07, 2018 at 12:42:54AM +0000, Tomasz Kłoczko wrote:
On 6 February 2018 at 19:33, Bruno Wolff III <bruno(a)wolff.to>
wrote:
> On Fri, Feb 02, 2018 at 20:35:25 +0000,
> Tomasz Kłoczko <kloczko.tomasz(a)gmail.com> wrote:
>
>> Hi,
>>
>> Looks like today updates are trashing gnome almost completely.
>> gdm-x-session cannot setup XKB mapping. gnome-shell is core dumping ..
>>
>> "journalctl -xe" output is in attachment.
>>
>
> If this is rawhide, you might try downgrading m17n-db* . On one machine
> the latest version is causing lots of applications to crash. On other
> machines it doesn't happen and I don't know what the difference is. I'm
> hoping the gcc8 rebuild will fix things when it happens. Right now I don't
> have much for the maintainer to go on to try to fix things.
>
m17n-db has nothing to do with xkb.
I've done something different.
I found that m17n-db is only required by m17n-lib package and m17n-lib is
required only by ibus-m17n, and nothing requires ibus-m17n.
So I've removed all those three packages and after logout-> loging (under
gnome or Xfce; both under X11) still gdm has been failing with *exactly*
the same error messages.
xkb is about keyboard mappings withing working X11 server.
Nevertheless just found what is causing tose xkb errors.
I've installed xorg-x11-xkb-extras to have the access to setxkbmap command
and on executing:
[tkloczko@domek ~]$ setxkbmap -v pl
Warning! Multiple definitions of keyboard layout
Using command line, ignoring X server
Trying to build keymap using the following components:
keycodes: evdev+aliases(qwerty)
types: complete
compat: complete
symbols: pc+pl+inet(evdev)
geometry: pc(pc105)
Error loading new keyboard description
[tkloczko@domek ~]$ strace -e trace=file setxkbmap -v pl
execve("/usr/bin/setxkbmap", ["setxkbmap", "-v",
"pl"], 0x7ffcce6b2830 /*
46 vars */) = 0
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or
directory)
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib64/libxkbfile.so.1", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib64/libX11.so.6", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib64/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib64/libxcb.so.1", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib64/libdl.so.2", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib64/libXau.so.6", O_RDONLY|O_CLOEXEC) = 3
access("/run/user/1000/gdm/Xauthority", R_OK) = 0
openat(AT_FDCWD, "/run/user/1000/gdm/Xauthority", O_RDONLY) = 4
Warning! Multiple definitions of keyboard layout
Using command line, ignoring X server
openat(AT_FDCWD, "./rules/evdev-C.lst", O_RDONLY) = -1 ENOENT (No such file
or directory)
openat(AT_FDCWD, "./rules/evdev.lst", O_RDONLY) = -1 ENOENT (No such file
or directory)
openat(AT_FDCWD, "/usr/share/X11/xkb/rules/evdev-C.lst", O_RDONLY) = -1
ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/share/X11/xkb/rules/evdev.lst", O_RDONLY) = 4
openat(AT_FDCWD, "/usr/share/X11/xkb/rules/evdev-C", O_RDONLY) = -1 ENOENT
(No such file or directory)
openat(AT_FDCWD, "/usr/share/X11/xkb/rules/evdev", O_RDONLY) = 4
Next was rpm query:
[tkloczko@domek ~]$ rpm -qif /usr/share/X11/xkb/rules/evdev
Name : xkeyboard-config
Version : 2.23
Release : 1.fc28
Architecture: noarch
Install Date: Fri 02 Feb 2018 03:10:22 GMT
Group : Unspecified
Size : 5804719
License : MIT
Signature : RSA/SHA256, Wed 31 Jan 2018 09:07:03 GMT, Key ID
e08e7e629db62fb1
Source RPM : xkeyboard-config-2.23-1.fc28.src.rpm
Build Date : Wed 31 Jan 2018 09:06:48 GMT <<<< ****HERE****
>>>>
Build Host : buildvm-ppc64le-15.ppc.fedoraproject.org
Relocations : (not relocatable)
Packager : Fedora Project
Vendor : Fedora Project
URL : http://www.freedesktop.org/wiki/Software/XKeyboardConfig
Summary : X Keyboard Extension configuration data
Description :
This package contains configuration data used by the X Keyboard Extension
(XKB),
which allows selection of keyboard layouts when using a graphical interface..
As long as upgrade 2.23 has been done around the time when mine problems
with xkb started I've downloaded xkeyboard-config-2.22 from f27 and after
downgrade:
[tkloczko@domek ~]$ setxkbmap -v pl
Warning! Multiple definitions of keyboard layout
Using command line, ignoring X server
Trying to build keymap using the following components:
keycodes: evdev+aliases(qwerty)
types: complete
compat: complete
symbols: pc+pl+inet(evdev)
geometry: pc(pc105)
[tkloczko@domek ~]$ łóćźęśźż
So I'm able now to enter Polish characters :)
So looks like at least something is wrong with xkeyboard-config-2.23.
yep, thanks, there was a typo in the polish layout. Was fixed upstream, I
just don't use that layout very often ;)
xkeyboard-config-2.23.1-1.fc28 is building and seems to fix the issue
https://koji.fedoraproject.org/koji/taskinfo?taskID=24771380
Cheers,
Peter
10:48 p.m.
On Wed, Feb 07, 2018 at 02:12:52PM +1000, Peter Hutterer wrote:
xkeyboard-config-2.23.1-1.fc28 is building and seems to fix the
issue
https://koji.fedoraproject.org/koji/taskinfo?taskID=24771380
First build failed, successful one is:
https://koji.fedoraproject.org/koji/taskinfo?taskID=24772701
Cheers,
Peter
2307
days inactive
2312
days old
14 comments
7 participants
participants (7)
-
Bruno Wolff III -
Chris Murphy -
Peter Hutterer -
Richard Shaw -
Sam Varshavchik -
Samuel Sieb -
Tomasz Kłoczko