Created attachment 1860289 [details] journal Description of problem: the coredump file abrt generated is empty,as a result,non-kernel crash can not be reported by gnome-abrt(screenshot). I see a spice-vdagent crash after boot the newly installed system,but I'm not able to report it with gnome-abrt. I also checked with "sleep 500 & pkill -SEGV sleep" Version-Release number of selected component (if applicable): abrt-2.15.0-3.fc36 How reproducible: always Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
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.