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
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!
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).
Not a complete fix. A suspend-to-RAM (closing laptop lid) and resume sequence still triggers similar issues, see https://bugzilla.redhat.com/show_bug.cgi?id=1844755.
Not a complete fix. A suspend-to-RAM (closing laptop lid) and resume sequence still triggers similar issues, see https://bugzilla.redhat.com/show_bug.cgi?id=1844755 (I've closed it as duplicate, but it's still relevant for 1806123)
kernel-core-5.2.6-200.fc30.x86_64 seems to work for me, apparently survives two suspend/resume cycles without ill effect.
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 https://bugzilla.kernel.org/show_bug.cgi?id=204413#c12
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 <mika.westerberg@linux.intel.com>
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)
smartmontools-7.2-10.fc33 seems to fare better for me on F33. No more setroubleshooter notifications on systemctl restart smartd