Bug 1795000 - gnome-session is crashing, desktop intermittently is never reached
Summary: gnome-session is crashing, desktop intermittently is never reached
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: gnome-session
Version: 32
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Ray Strode [halfline]
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: AcceptedBlocker
Depends On:
Blocks: F32BetaBlocker
TreeView+ depends on / blocked
 
Reported: 2020-01-26 09:27 UTC by lnie
Modified: 2020-02-18 04:12 UTC (History)
24 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-02-18 04:12:34 UTC
Type: Bug


Attachments (Terms of Use)
video1 (1.32 MB, video/webm)
2020-01-26 09:27 UTC, lnie
no flags Details
video2 (1.61 MB, video/webm)
2020-01-26 09:27 UTC, lnie
no flags Details
screenshot (55.75 KB, image/png)
2020-02-02 02:27 UTC, lnie
no flags Details
journal (428.09 KB, text/plain)
2020-02-03 05:07 UTC, Chris Murphy
no flags Details

Description lnie 2020-01-26 09:27:12 UTC
Created attachment 1655365 [details]
video1

Description of problem:
Boot the installer with virt-manager,the installation failed with screen blinks,
please see the attached video for more information,thanks.
FYI: I'm able to switch to other terminals 
Version-Release number of selected component (if applicable):
Fedora-Workstation-Live-x86_64-Rawhide-20200122.n.1.iso

How reproducible:
always

Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Comment 1 lnie 2020-01-26 09:27:48 UTC
Created attachment 1655366 [details]
video2

Comment 2 lnie 2020-02-02 02:25:51 UTC
With Fedora-Workstation-Live-x86_64-Rawhide-20200122.n.1.iso,
I'm able to finish the installation without use virt-install or virt-manager:
qemu-system-x86_64 -m 1024 -enable-kvm -display sdl -vga qxl -hda /var/lib/libvirt/images/test.qcow2 -cdrom /home/lnie/Fedora-Workstation-Live-x86_64-Rawhide-20200122.n.1.iso -boot d -net nic,model=e1000 -net user -spice port=5900

But with Fedora-Workstation-Live-x86_64-Rawhide-20200131.n.0.iso,the installation stuck as shown in the sreenshot.

Comment 3 lnie 2020-02-02 02:27:22 UTC
Created attachment 1657062 [details]
screenshot

Comment 4 Fedora Blocker Bugs Application 2020-02-02 09:35:35 UTC
Proposed as a Blocker for 32-beta by Fedora user lnie using the blocker tracking app because:

 It seems to affects:
Release-blocking live images must boot to the expected boot menu, and then to a desktop or to a login prompt where it is clear how to log in to a desktop.

Comment 5 Chris Murphy 2020-02-03 05:02:07 UTC
I'm not sure if this is Anaconda. I'm seeing crashes with a clean installation of Fedora-Workstation-Live-x86_64-Rawhide-20200125.n.0.iso, and it's a bunch of crashes in gnome-session


[   14.792143] gnome-session-b[913]: segfault at 0 ip 00007f412993f68e sp 00007ffecb696568 error 4 in libc-2.30.9000.so[7f41298cc000+150000]
[   18.792489] gnome-session-b[1211]: segfault at 0 ip 00007f5d3115868e sp 00007ffe0e518bc8 error 4 in libc-2.30.9000.so[7f5d310e5000+150000]


Sometimes it happens 4-5 times.

Comment 6 Chris Murphy 2020-02-03 05:05:56 UTC
gnome-session-3.35.3-1.fc32.x86_64
gnome-shell-3.35.3-2.fc32.x86_64
mutter-3.35.3-2.fc32.x86_64

Comment 7 Chris Murphy 2020-02-03 05:07:40 UTC
Created attachment 1657250 [details]
journal

Comment 8 Chris Murphy 2020-02-03 05:11:45 UTC
Hmm..coredumpctl lists quite a few issues, but none of them have usable coredumps.

Sun 2020-02-02 21:59:58 MST     961    42    42   5 error     /usr/bin/ibus-daemon
Sun 2020-02-02 21:59:59 MST     989    42    42   5 error     /usr/bin/ibus-daemon
Sun 2020-02-02 22:00:00 MST     913    42    42  11 error     /usr/libexec/gnome-session-binary
Sun 2020-02-02 22:00:03 MST    1232    42    42   5 error     /usr/bin/ibus-daemon
Sun 2020-02-02 22:00:04 MST    1250    42    42   5 error     /usr/bin/ibus-daemon
Sun 2020-02-02 22:00:04 MST    1211    42    42  11 error     /usr/libexec/gnome-session-binary
Sun 2020-02-02 22:00:05 MST    1407    42    42   5 error     /usr/bin/ibus-daemon
Sun 2020-02-02 22:00:07 MST    1493    42    42   5 error     /usr/bin/ibus-daemon
Sun 2020-02-02 22:00:08 MST    1511    42    42   5 error     /usr/bin/ibus-daemon

$ coredumpctl info 961
           PID: 961 (ibus-daemon)
           UID: 42 (gdm)
           GID: 42 (gdm)
        Signal: 5 (TRAP)
     Timestamp: Sun 2020-02-02 21:59:57 MST (9min ago)
  Command Line: ibus-daemon --panel disable
    Executable: /usr/bin/ibus-daemon
 Control Group: /user.slice/user-42.slice/user@42.service/gnome-shell-wayland.service
          Unit: user@42.service
     User Unit: gnome-shell-wayland.service
         Slice: user-42.slice
     Owner UID: 42 (gdm)
       Boot ID: 93cd89b897654c44ad5f6fe30a0e43c9
    Machine ID: 8b494cd4aa744f9f83c3e0131f21929b
      Hostname: localhost.localdomain
       Storage: /var/lib/systemd/coredump/core.ibus-daemon.42.93cd89b897654c44ad5f6fe30a0e43c9.961.1580705997000000000000.lz4 (inaccessible)
       Message: Process 961 (ibus-daemon) of user 42 dumped core.
                
                Stack trace of thread 961:
                #0  0x00007f83ff249e05 _g_log_abort (libglib-2.0.so.0 + 0x57e05)
                #1  0x00007f83ff24ae89 g_log_default_handler (libglib-2.0.so.0 + 0x58e89)
                #2  0x00007f83ff24b0bb g_logv (libglib-2.0.so.0 + 0x590bb)
                #3  0x00007f83ff24b2a3 g_log (libglib-2.0.so.0 + 0x592a3)
                #4  0x000055bf1f8f6023 bus_server_init (ibus-daemon + 0x1e023)
                #5  0x000055bf1f8e15b5 main (ibus-daemon + 0x95b5)
                #6  0x00007f83ff02d042 __libc_start_main (libc.so.6 + 0x27042)
                #7  0x000055bf1f8e19fe _start (ibus-daemon + 0x99fe)
                
                Stack trace of thread 962:
                #0  0x00007f83ff107865 __clone (libc.so.6 + 0x101865)
                #1  0x0000000000000007 n/a (n/a + 0x0)
[hack@localhost ~]$ journalctl -b -o short-monotonic | grep AVC
[    6.420832] localhost.localdomain audit[571]: AVC avc:  denied  { search } for  pid=571 comm="systemd-journal" name="/" dev="efivarfs" ino=16434 scontext=system_u:system_r:syslogd_t:s0 tcontext=system_u:object_r:efivarfs_t:s0 tclass=dir permissive=1
[    7.006316] localhost.localdomain audit[650]: AVC avc:  denied  { setsched } for  pid=650 comm="ModemManager" scontext=system_u:system_r:modemmanager_t:s0 tcontext=system_u:system_r:modemmanager_t:s0 tclass=process permissive=1
[    8.208867] localhost.localdomain audit[746]: AVC avc:  denied  { sys_nice } for  pid=746 comm="accounts-daemon" capability=23  scontext=system_u:system_r:accountsd_t:s0 tcontext=system_u:system_r:accountsd_t:s0 tclass=capability permissive=1
[    8.208951] localhost.localdomain audit[746]: AVC avc:  denied  { setsched } for  pid=746 comm="accounts-daemon" scontext=system_u:system_r:accountsd_t:s0 tcontext=system_u:system_r:accountsd_t:s0 tclass=process permissive=1
[   13.773253] localhost.localdomain audit[977]: AVC avc:  denied  { setsched } for  pid=977 comm="geoclue" scontext=system_u:system_r:geoclue_t:s0 tcontext=system_u:system_r:geoclue_t:s0 tclass=process permissive=1
[   19.901338] localhost.localdomain audit[1387]: AVC avc:  denied  { setsched } for  pid=1387 comm="colord" scontext=system_u:system_r:colord_t:s0 tcontext=system_u:system_r:colord_t:s0 tclass=process permissive=1
[hack@localhost ~]$ 


While I'm also seeing AVC denials that result in failed boot in bug 1797414, I don't see that they're related to the ibus-daemon or gnome-session crashes, at least not directly.

Comment 9 Michael Catanzaro 2020-02-03 17:09:44 UTC
Even without a usable stacktrace, the journal core dump for gnome-session would be a lot better than nothing.

Comment 10 Michael Catanzaro 2020-02-03 17:10:15 UTC
Well I wrote that backwards. I meant: "Even without a usable core dump, the journal stacktrace for gnome-session would be a lot better than nothing."

Comment 11 Jonas Ådahl 2020-02-03 17:15:36 UTC
Crash seems to be in gnome-session, not gnome-shell, moving.

Comment 12 Adam Williamson 2020-02-03 17:27:50 UTC
does this also happen with enforcing=0?

Comment 13 lnie 2020-02-04 01:56:22 UTC
(In reply to Adam Williamson from comment #12)
> does this also happen with enforcing=0?

yes

Comment 14 Adam Williamson 2020-02-06 21:42:03 UTC
Discussed at 2020-02-03 blocker review meeting: https://meetbot-raw.fedoraproject.org/fedora-blocker-review/2020-02-03/f32-blocker-review.2020-02-03-17.13.html . Accepted as a Beta blocker as a violation of "A system installed with a release-blocking desktop must boot to a log in screen where it is possible to log in to a working desktop using a user account created during installation or a 'first boot' utility" - https://fedoraproject.org/wiki/Basic_Release_Criteria#Expected_installed_system_boot_behavior .

Comment 15 Jonathan Haas 2020-02-10 08:33:09 UTC
While trying to reproduce this, abrt detected the problem as https://retrace.fedoraproject.org/faf/reports/2824963/, but I failed to produce a full backtrace. Hope that helps anyway.

Also can't reproduce this anymore after installing the latest updates. (With enforcing=0 because of Bug 1795524).

Comment 16 Ben Cotton 2020-02-11 16:34:39 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 32 development cycle.
Changing version to 32.

Comment 17 Adam Williamson 2020-02-17 18:17:35 UTC
Lili, are you still hitting this specific bug with more recent F32 composes? Could it possibly be the same as https://bugzilla.redhat.com/show_bug.cgi?id=1801820 ? Thanks!

Comment 18 lnie 2020-02-18 04:12:34 UTC
Adam, I checked with Fedora-Workstation-Live-x86_64-32-2020021,the bug is gone,and #1801820 seems like a different one.


Note You need to log in before you can comment on or make changes to this bug.