On Sun, 4 Nov 2018 18:46:28 -0800 Samuel Sieb <samuel@xxxxxxxx> 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
_______________________________________________
users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/users@xxxxxxxxxxxxxxxxxxxxxxx
