Bug 2052872

Created attachment 1860290 [details]
ccpp tar

Created attachment 1860291 [details]
screenshot

Proposed as a Blocker for 36-final by Fedora user lnie using the blocker tracking app because:

 This is a violation of the criteria:
All applications that can be launched using the standard graphical mechanism after a default installation of Fedora Workstation on the x86_64 architecture must start successfully and withstand a basic functionality test

coredump is generated if you downgrade abrt to abrt-2.14.6-9.fc36,but you will see #2052914,as a result,gnome-abrt will not able to report non-kernel crash

I can confirm this is indeed reproducible on Fedora 36.

@Michal: This might have something to do with the recent coredump-related changes in abrt.
Do you think you could double-check for any flukes?

We discussed this briefly yesterday. The problem is very likely related to the abrt+coredumpctl optimization change. I will test it.

Discussed during the 2022-02-14 blocker review meeting: [0]

The decision to classify this bug as an "AcceptedBlocker (Final)" was made as it violates the following criterion:

"All applications that can be launched using the standard graphical mechanism after a default installation of Fedora Workstation on the x86_64 architecture must start successfully and withstand a basic functionality test".

[0] https://meetbot.fedoraproject.org/fedora-blocker-review/2022-02-14/f36-blocker-review.2022-02-14-17.01.txt

This is a duplicate of bug #2050693

Michal Fabik found out that SELinux prevents abrt+coredumpctl to open+read the coredump file. I tried disabling SELinux just to test that this is indeed what's happening here and Michal was right:


######################################################################################################################

SELinux is preventing coredumpctl from read access on the file core.sleep.1000.178156ed5a304ee599f4634ca48e8c95.4246.1646221121000000.zst.

*****  Plugin catchall (100. confidence) suggests   **************************

If you believe that coredumpctl should be allowed read access on the core.sleep.1000.178156ed5a304ee599f4634ca48e8c95.4246.1646221121000000.zst file by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# ausearch -c 'coredumpctl' --raw | audit2allow -M my-coredumpctl
# semodule -X 300 -i my-coredumpctl.pp

Additional Information:
Source Context                system_u:system_r:abrt_t:s0-s0:c0.c1023
Target Context                system_u:object_r:systemd_coredump_var_lib_t:s0
Target Objects                core.sleep.1000.178156ed5a304ee599f4634ca48e8c95.4
                              246.1646221121000000.zst [ file ]
Source                        coredumpctl
Source Path                   coredumpctl
Port                          <Unknown>
Host                          localhost-live
Source RPM Packages           
Target RPM Packages           
SELinux Policy RPM            selinux-policy-targeted-36.3-1.fc36.noarch
Local Policy RPM              selinux-policy-targeted-36.3-1.fc36.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     localhost-live
Platform                      Linux localhost-live 5.17.0-0.rc5.102.fc36.x86_64
                              #1 SMP PREEMPT Mon Feb 21 19:16:16 UTC 2022 x86_64
                              x86_64
Alert Count                   3
First Seen                    2022-03-02 12:25:17 CET
Last Seen                     2022-03-02 12:38:42 CET
Local ID                      f1e93def-ce03-4c0c-b91f-8a6d369961fa

Raw Audit Messages
type=AVC msg=audit(1646221122.16:441): avc:  denied  { read } for  pid=4288 comm="coredumpctl" name="core.sleep.1000.178156ed5a304ee599f4634ca48e8c95.4246.1646221121000000.zst" dev="vda2" ino=187869 scontext=system_u:system_r:abrt_t:s0-s0:c0.c1023 tcontext=system_u:object_r:systemd_coredump_var_lib_t:s0 tclass=file permissive=0


Hash: coredumpctl,abrt_t,systemd_coredump_var_lib_t,file,read

######################################################################################################################


However, the fact that coredump is being copied from coredumpctl to abrt problem directory immediately after the crash happens kind of beats the purpose of the optimization patch in abrt. Even if we fix the SELinux issue, we still end up in a situation when there are multiple copies of the same coredump on the filesystem, and not just when abrt needs the copy.

*** Bug 2050693 has been marked as a duplicate of this bug. ***

FEDORA-2022-6d711f0d87 has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2022-6d711f0d87

This bug seems fixed,but I'm still not able to report bug using gnome-abrt,due to #2052914

FEDORA-2022-6d711f0d87 has been pushed to the Fedora 36 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2022-6d711f0d87`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-6d711f0d87

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Also proposing this as Beta FE, we should fix this for Beta if we can so people can report crashes during live sessions and first boots.

+6 Beta FE in https://pagure.io/fedora-qa/blocker-review/issue/604 , marking accepted.

FEDORA-2022-6d711f0d87 has been pushed to the Fedora 36 stable repository.
If problem still persists, please make note of it in this bug report.