On Sun, 4 Nov 2018 18:46:28 -0800 Samuel Sieb <samuel(a)sieb.net> wrote:
On 11/4/18 5:21 PM, Ranjan Maitra wrote:
> Nov 04 19:12:41 machine.name systemd-logind[805]: Enough swap for hibernation,
Active(anon)=234032 kB, size=20967420 kB, used=0 kB, threshold=98%
Your swap is fine.
> Nov 04 19:12:41 machine.name audit[805]: AVC avc: denied { read } for pid=805
comm="systemd-logind" name="nvme0n1p1" dev="devtmpfs"
ino=17833 scontext=system_u:system_r:systemd_logind_t:s0
tcontext=system_u:object_r:nvme_device_t:s0 tclass=blk_file permissive=0
> Nov 04 19:12:41 machine.name audit[805]: SYSCALL arch=c000003e syscall=257
success=no exit=-13 a0=ffffff9c a1=7fffb9486130 a2=80000 a3=0 items=0 ppid=1 pid=805
auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none)
ses=4294967295 comm="systemd-logind"
exe="/usr/lib/systemd/systemd-logind" subj=system_u:system_r:systemd_logind_t:s0
key=(null)
> Nov 04 19:12:41 machine.name audit: PROCTITLE
proctitle="/usr/lib/systemd/systemd-logind"
> Nov 04 19:12:41 machine.name systemd-logind[805]: Failed to open file system
"/boot/efi": Permission denied
> Nov 04 19:12:41 machine.name systemd-logind[805]: Cannot read boot configuration
from ESP, assuming hibernation is not possible.
This is clearly the problem. I don't have any idea why it can't open
the file system. And from the code, my understanding is that it should
fall back to reading /proc/cmdline anyway.
I see. I filed earlier this morning on bugzilla as well as on github. But no one has asked
for any information yet. I guess that I should add this info in case someone looks into.
The important thing to note is that it worked in F28 (with systemd 238-9) and not in F29
(with systemd 239-6). And it was not a fresh install but an upgrade to F29 from F28.
> Nov 04 19:12:41 machine.name kernel: audit: type=1400
audit(1541380361.892:226): avc: denied { read } for pid=805
comm="systemd-logind" name="nvme0n1p1" dev="devtmpfs"
ino=17833 scontext=system_u:system_r:systemd_logind_t:s0
tcontext=system_u:object_r:nvme_device_t:s0 tclass=blk_file permissive=0
> Nov 04 19:12:41 machine.name kernel: audit: type=1300 audit(1541380361.892:226):
arch=c000003e syscall=257 success=no exit=-13 a0=ffffff9c a1=7fffb9486130 a2=80000 a3=0
items=0 ppid=1 pid=805 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0
fsgid=0 tty=(none) ses=4294967295 comm="systemd-logind"
exe="/usr/lib/systemd/systemd-logind" subj=system_u:system_r:systemd_logind_t:s0
key=(null)
There are a couple of these and it appears that it is the disk device
that it is trying to open. Run "ls -li /dev/nvme0n1*" to verify that.
17666 brw-rw----. 1 root disk 259, 0 Nov 4 19:43 /dev/nvme0n1
17667 brw-rw----. 1 root disk 259, 1 Nov 4 19:43 /dev/nvme0n1p1
17668 brw-rw----. 1 root disk 259, 2 Nov 4 19:43 /dev/nvme0n1p2
17669 brw-rw----. 1 root disk 259, 3 Nov 4 19:44 /dev/nvme0n1p3
17670 brw-rw----. 1 root disk 259, 4 Nov 4 19:43 /dev/nvme0n1p4
17671 brw-rw----. 1 root disk 259, 5 Nov 4 19:43 /dev/nvme0n1p5
17672 brw-rw----. 1 root disk 259, 6 Nov 4 19:43 /dev/nvme0n1p6
> Sorry, it works, and flawlessly. I am wondering if I should just upgrade the source
rpm and then forget about this mess of systemd.
You don't need to update it. It works fine as it is and it won't go away.
The only irritating thing is that it requires a password. And can not be mapped to a
button, therefore: I am an openbox user.
> I see. I am using a text console.
Oh, that's surprising.
Thanks again!
Ranjan