Bug 1795000

Created attachment 1655366 [details]
video2

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.

Created attachment 1657062 [details]
screenshot

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.

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.

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

Created attachment 1657250 [details]
journal

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/gnome-shell-wayland.service
          Unit: user
     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.

Even without a usable stacktrace, the journal core dump for gnome-session would be a lot better than nothing.

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."

Crash seems to be in gnome-session, not gnome-shell, moving.

does this also happen with enforcing=0?

(In reply to Adam Williamson from comment #12)
> does this also happen with enforcing=0?

yes

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 .

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).

This bug appears to have been reported against 'rawhide' during the Fedora 32 development cycle.
Changing version to 32.

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!

Adam, I checked with Fedora-Workstation-Live-x86_64-32-2020021,the bug is gone,and #1801820 seems like a different one.