smartmontools-7.2-10.fc33 seems to fare better for me on F33. No more setroubleshooter notifications on systemctl restart smartd

BZ#1990463 SELinux is preventing smartd from getattr access on the chr_file /dev/nvme1.

Update including smartmontools-selinux does not fix the bug on Fedora 33. $ rpm -qa smartmontools* smartmontools-7.2-9.fc33.x86_64 smartmontools-selinux-7.2-9.fc33.noarch

$ systemctl restart smartd ... open se troubleshooter:

Additional Information: Source Context system_u:system_r:fsdaemon_t:s0 Target Context system_u:object_r:nvme_device_t:s0 Target Objects /dev/nvme0 [ chr_file ] Source smartd Source Path smartd Port <Unbekannt> Host (removed) Source RPM Packages
Target RPM Packages
SELinux Policy RPM selinux-policy-targeted-3.14.6-39.fc33.noarch Local Policy RPM smartmontools-selinux-7.2-9.fc33.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name (removed) Platform Linux (removed) 5.13.9-100.fc33.x86_64 #1 SMP Mon Aug 9 12:04:50 UTC 2021 x86_64 x86_64 Alert Count 5 First Seen 2021-08-18 18:21:40 CEST Last Seen 2021-08-19 12:38:12 CEST Local ID 017c8780-b33a-44e1-a91a-f3796dff268f

Raw Audit Messages type=AVC msg=audit(1629369492.549:154347): avc: denied { open } for pid=576249 comm="smartd" path="/dev/nvme0" dev="devtmpfs" ino=328 scontext=system_u:system_r:fsdaemon_t:s0 tcontext=system_u:object_r:nvme_device_t:s0 tclass=chr_file permissive=0

BZ#1990463 SELinux is preventing smartd from getattr access on the chr_file /dev/nvme1.

works for me WRT BZ#1939930, basic functionality for unprivileged user is there, crontab running from terminal without command line arguments prints usage, and with file as input or dash as argument installs the crontab per replace, as expected. Thank you!

BZ#1939930 git maintenance fails to install crontab

Looks good to me WRT the tlp "execute_no_trans" issue, which is gone after this upgrade (with my local my-tlp.pp removed first, confirming the bug is back, and then updating, confirming the bug is gone).

BZ#1844755 SELinux is preventing tlp from 'execute_no_trans' accesses on the Datei /usr/sbin/tlp.

Not a complete fix. A suspend-to-RAM (closing laptop lid) and resume sequence still triggers similar issues, see

BZ#1806123 SELinux is preventing tlp from 'write' accesses on the file lock_tlp.

Not a complete fix. A suspend-to-RAM (closing laptop lid) and resume sequence still triggers similar issues, see (I've closed it as duplicate, but it's still relevant for 1806123)

BZ#1818508 [abrt] blivet-gui-runtime: __getattr__(): swap has no attribute relabels

kernel-core-5.2.6-200.fc30.x86_64 seems to work for me, apparently survives two suspend/resume cycles without ill effect.

BZ#1737046 [bisected] 5.1.20-300.fc30 regression: no wakeup from suspend to RAM (also present in 5.2.5-200.fc30 testing and vanilla 5.3-rc2)

Fedora f30 has an overlay available through fedpkg where the Git log suggests that Fedora reverted that patch, however the exploded Git tree seems behind (which is what I was checking). Will try the 5.2.6 update.

No, they did not revert that patch.

In order to fix this, revert 5817d78eba34f6c86f5462ae2c5212f80a013357 (relative to upstream Linux stable/linux-5.2.y)

Regression (already in 5.2.5 and 5.1.20): Contains the same suspend/resume regression as 5.2.5 and 5.1.20, turning the system unable to do I/O or network after resume, on AMD X370 main board with Ryzen 7 1700.

Note that upstream has chosen to revert the offending patch, see

Obtaining a vanilla v5.2.5 from stable/linux-5.2.y upstream and running git revert 5817d78eba34f6c86f5462ae2c5212f80a013357 then installing things including nvidia 430.40 driver (fedora-multimedia) through dkms gives me a working kernel that survives 2 suspend/resume cycles with S3 (STR) sleep.

commit 5817d78eba34f6c86f5462ae2c5212f80a013357
Author: Mika Westerberg <>
Date:   Wed Jun 12 13:57:38 2019 +0300

    PCI: Add missing link delays required by the PCIe spec

    [ Upstream commit c2bf1fc212f7e6f25ace1af8f0b3ac061ea48ba5 ]

    Currently Linux does not follow PCIe spec regarding the required delays
    after reset. A concrete example is a Thunderbolt add-in-card that
    consists of a PCIe switch and two PCIe endpoints:

      +-1b.0-[01-6b]----00.0-[02-6b]--+-00.0-[03]----00.0 TBT controller
                                      +-01.0-[04-36]-- DS hotplug port
                                      +-02.0-[37]----00.0 xHCI controller
                                      \-04.0-[38-6b]-- DS hotplug port

    The root port (1b.0) and the PCIe switch downstream ports are all PCIe
    gen3 so they support 8GT/s link speeds.


PM: hash matches drivers/base/power/main.c:1021

regression on suspend-to-RAM, fails to wake up properly, disk I/O blinks, but no console wake up, no network, same thing without nvidia drivers. Last working version 5.1.19

suspend to RAM fails and spams the log with pcieconf receiving Spurious native PME interrupts (last working in 5.1.19-300.fc30; 5.1.20-300.fc30 also regressed, but in a different way)