New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

logind assumes hibernation is not possible #10613

Closed
nl6720 opened this Issue Nov 1, 2018 · 28 comments

Comments

@nl6720
Copy link

nl6720 commented Nov 1, 2018

systemd version the issue has been seen with

239.300-1

Used distribution

Arch Linux

Expected behaviour you didn't see

system should hibernate

Unexpected behaviour you saw

system didn't hibernate

$ systemctl hibernate
Failed to hibernate system via logind: Resume not configured, can't hibernate

journal shows:

kernel: Kernel command line: \\vmlinuz-linux root=/dev/ArchLinux/root rw add_efi_memmap resume=/dev/ArchLinux/swap apparmor=1 security=apparmor systemd.log_level=debug initrd=/intel-ucode.img initrd=/initramfs-linux.img
...
systemd-logind[911]: Enough swap for hibernation, Active(anon)=61960 kB, size=16777212 kB, used=0 kB, threshold=98%
systemd-logind[911]: Failed to open "/boot/loader/loader.conf": No such file or directory
systemd-logind[911]: Failed to read boot config from "/boot/loader/loader.conf": No such file or directory
systemd-logind[911]: Failed to load bootspec config from "/boot/loader": No such file or directory
systemd-logind[911]: Cannot read boot configuration from ESP, assuming hibernation is not possible.

ESP is mounted to /boot; the bootloader is not systemd-boot so the /boot/loader/loader.conf file doesn't exist.

Steps to reproduce the problem

  1. install Arch Linux and use a bootloader other than systemd-boot
  2. enable testing repositories (systemd 239.300-1 is currently in testing)
  3. systemctl hibernate

Downstream bug report: FS#60650.

@loqs

This comment has been minimized.

Copy link

loqs commented Nov 1, 2018

systemd 239.300-1 is systemd-stable 25d1ba1 with 300 being commit count since the 239 tag.
Issue has been traced to 5fdf2d5 which is backported as systemd/systemd-stable@6789dca.
In systemd master the code does not reach that point failing at edda446.

@maitra

This comment has been minimized.

Copy link

maitra commented Nov 4, 2018

I have the same problem on Fedora 29 running the stable systemd-239-6.git9f3aed1.fc29.x86_64.Here is some output from sudo journalctl -fa when I do systemcrl hibernate.


Nov 04 07:19:29 machine.name polkitd[800]: Registered Authentication Agent for unix-process:2334:95259 (system bus name :1.175 [/usr/bin/pkttyagent --notify-fd 5 --fallback], object path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale en_US.UTF-8)
Nov 04 07:19:29 machine.name audit[827]: AVC avc:  denied  { read } for  pid=827 comm="systemd-logind" name="nvme0n1p1" dev="devtmpfs" ino=17625 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 07:19:29 machine.name audit[827]: SYSCALL arch=c000003e syscall=257 success=no exit=-13 a0=ffffff9c a1=7ffe3533e050 a2=80000 a3=0 items=0 ppid=1 pid=827 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 07:19:29 machine.name audit: PROCTITLE proctitle="/usr/lib/systemd/systemd-logind"
Nov 04 07:19:29 machine.name systemd-logind[827]: Failed to open file system "/boot/efi": Permission denied
Nov 04 07:19:29 machine.name polkitd[800]: Unregistered Authentication Agent for unix-process:2334:95259 (system bus name :1.175, object path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale en_US.UTF-8) (disconnected from bus)
Nov 04 07:19:29 machine.name kernel: audit: type=1400 audit(1541337569.994:258): avc:  denied  { read } for  pid=827 comm="systemd-logind" name="nvme0n1p1" dev="devtmpfs" ino=17625 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 07:19:29 machine.name kernel: audit: type=1300 audit(1541337569.994:258): arch=c000003e syscall=257 success=no exit=-13 a0=ffffff9c a1=7ffe3533e050 a2=80000 a3=0 items=0 ppid=1 pid=827 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 07:19:29 machine.name kernel: audit: type=1327 audit(1541337569.994:258): proctitle="/usr/lib/systemd/systemd-logind"

systemctl hibernate works flawlessly with Fedora 28 (where systemd is at 238-9).

My laptop giving problems is on EFI-boot. I have no issues with two other laptiops that Legacy boot enabled.

@chrisob666

This comment has been minimized.

Copy link

chrisob666 commented Nov 7, 2018

Bypassing the selinux denials posted above, it looks like logind is looking for /boot/efi/loader/loader.conf, which doesn't exist:

Nov 07 10:20:47 notebook systemd-logind[1268]: Power key pressed.
Nov 07 10:20:47 notebook systemd-logind[1268]: Failed to open "/boot/efi/loader/loader.conf": No such file or directory
Nov 07 10:20:47 notebook systemd-logind[1268]: Failed to read boot config from "/boot/efi/loader/loader.conf": No such file or directory
Nov 07 10:20:47 notebook systemd-logind[1268]: Failed to load bootspec config from "/boot/efi/loader": No such file or directory

Edit:
Creating /boot/efi/loader/loader.conf manually results in:

No entry suitable as default, refusing to guess.
@maitra

This comment has been minimized.

Copy link

maitra commented Nov 7, 2018

With the debug logging enabled, it is clear that it's the failure to open /boot/efi that is causing it to not work. The swap is ok and there is a correct resume= parameter.


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.

@KJoke70

This comment has been minimized.

Copy link

KJoke70 commented Nov 8, 2018

Identical problem. (also on arch, though the package is now in the regular repo). Additionally I have

systemd-logind[1097]: Failed to open "/boot/loader/loader.conf": No such file or directory
systemd-logind[1097]: Failed to read boot config from "/boot/loader/loader.conf": No such file or directory
systemd-logind[1097]: Failed to load bootspec config from "/boot/loader": No such file or directory
systemd-logind[1097]: Failed to open "/boot/loader/loader.conf": No such file or directory
systemd-logind[1097]: Failed to read boot config from "/boot/loader/loader.conf": No such file or directory
systemd-logind[1097]: Failed to load bootspec config from "/boot/loader": No such file or directory

on every boot in my journal. Same messages when I run bootctl list.

@markusdd

This comment has been minimized.

Copy link

markusdd commented Nov 9, 2018

Can confirm problem on Fedora 29 with latest selinux policy update.

bootctl list
Failed to open "/boot/efi/loader/loader.conf": No such file or directory
Failed to read boot config from "/boot/efi/loader/loader.conf": No such file or directory
Failed to load bootspec config from "/boot/efi/loader": No such file or directory

Is there any known workaround yet? Non-working Hibernate is a deal-breaker for me.

@6wheels

This comment has been minimized.

Copy link

6wheels commented Nov 9, 2018

@markusdd under Archlinux, the only workaround I found is to downgrade to systemd 239.6-1.
Any other workaround with latest systemd release (239.300-1) would be appreciated.

@markusdd

This comment has been minimized.

Copy link

markusdd commented Nov 9, 2018

Thanks for that hint, I can confirm hibernate functionality is restored by downgrading systemd to fedora29 base version systemd-239-3.fc29
I had installed systemd-239-6.git9f3aed1.fc29, which contains the commit which breaks the hibernate functionality.

@KJoke70

This comment has been minimized.

Copy link

KJoke70 commented Nov 10, 2018

This comment on the arch bug tracker suggests creating a fake (but correct) systemd-boot entry. Seems to work for me

@davidegirardi

This comment has been minimized.

Copy link

davidegirardi commented Nov 10, 2018

This comment on the arch bug tracker suggests creating a fake (but correct) systemd-boot entry. Seems to work for me

Creating a fake file will not work in all the cases.

In my example, I run secure boot with systemd-boot, this means that my entry files do not have any useful information. They just contain a references to a single, signed, efi image.

There is no command line to parse there.

@KJoke70

This comment has been minimized.

Copy link

KJoke70 commented Nov 10, 2018

In my example, I run secure boot with systemd-boot, this means that my entry files do not have any useful information. They just contain a references to a single, signed, efi image.

Are you also affected by this problem, despite using systemd-boot? I was under the impression this only affects setups with other boot loaders.

electrickite added a commit to electrickite/systemd that referenced this issue Nov 11, 2018

@6wheels

This comment has been minimized.

Copy link

6wheels commented Nov 11, 2018

The workaround with the fake systemd-boot doesn't work for me.
jourmald shows this:

systemd-logind[513]: File system "/boot/efi" is not on a GPT partition table.

Which is true, my esp is a VFAT partition. Downgrading is this only option for me.

@davidegirardi

This comment has been minimized.

Copy link

davidegirardi commented Nov 11, 2018

In my example, I run secure boot with systemd-boot, this means that my entry files do not have any useful information. They just contain a references to a single, signed, efi image.

Are you also affected by this problem, despite using systemd-boot? I was under the impression this only affects setups with other boot loaders.

My main entry file looks like this:

title Arch Linux (Secure Boot Enabled)
efi /linux-signed.img

I think systemd should parse /proc/cmdline, which does not only solve my case but takes care of someone who booted with a temporary resume device from the command line.

@887

This comment has been minimized.

Copy link

887 commented Nov 11, 2018

Another thing: logind seems to now require that the /boot partition type has to be EFI:

systemd-logind[984]: File system "/boot" has wrong type for an EFI System Partition (ESP).

Switched the partition type to EFI using 'cfdisk'.
'bootctl list' shows a working entry with 'resume='.
Logind seems happy now and hibernate works again.

Background:
My system has bootctl installed in EFI but uses syslinux installed in the MBR.
Gnome-disks now shows:
Partition Type: EFI System (Legacy BIOS Bootable)
Contents: FAT (32-bit version) — Mounted at /boot

I installed the machine with EFI+bootctl, but switched bootloaders to syslinux and set the legacy bios option in BIOS. If i remember correctly this was du to EFI messing up hibernate and not resuming correctly.
Funny thing is now i can boot via bootctl if i use EFI and syslinux if i use legacy bios.

@myasn1k

This comment has been minimized.

Copy link

myasn1k commented Nov 14, 2018

systemd 239.300-1 is systemd-stable 25d1ba1 with 300 being commit count since the 239 tag.
Issue has been traced to 5fdf2d5 which is backported as systemd/systemd-stable@6789dca.
In systemd master the code does not reach that point failing at edda446.

Will they correct this?

@creshal

This comment has been minimized.

Copy link

creshal commented Nov 15, 2018

They better do. You can't just go and break all bootloaders except systemd-boot with no warning.

@markusdd

This comment has been minimized.

Copy link

markusdd commented Nov 16, 2018

This issue has a PR now, when can we expect this to be merged and available to the Downstream Maintainers? I currently have halted all updates to fedora machines at our site, but I do not want to keep it this that way for weeks. F29 is still very young and they have other fixes coming in as well, so I would like to be able to update our machines again...

@skidnik

This comment has been minimized.

Copy link

skidnik commented Nov 16, 2018

This issue has a PR now, when can we expect this to be merged and available to the Downstream Maintainers? I currently have halted all updates to fedora machines at our site, but I do not want to keep it this that way for weeks. F29 is still very young and they have other fixes coming in as well, so I would like to be able to update our machines again...

As people said here, you may create those files with info needed, that should do as a temporary fix. A script should work on Fedora and Arch. Or a howto at Arch wiki. This works if you boot in efi mode, and esp is not encrypted.

@KJoke70

This comment has been minimized.

Copy link

KJoke70 commented Nov 16, 2018

Or you could ask your maintainers to temporarily revert sleep related changes to fix this until the PR is merged. On arch this has been done in systemd 239.300-2.

@soul9

This comment has been minimized.

Copy link

soul9 commented Nov 19, 2018

I was hoping to be able to set up hibernation on my laptop in more than two weeks but no, the gods are not on my side. After managing to activate hibernate support on my system, I am now hitting this brick wall.
Furthermore, creating the directory with dummy files doesn't help because I now get

Nov 19 00:59:15 x audit[5530]: AVC avc:  denied  { read } for  pid=5530 comm="systemd-logind" name="loader.conf" dev="nvme0n1p1" ino=130 scontext=system_u:system_r:systemd_logind_t:s0 tcontext=system_u:object_r:dosfs_t:s0 tclass=file permissive=0
Nov 19 00:59:15 x systemd-logind[5530]: Failed to open "/boot/efi/loader/loader.conf": Permission denied
Nov 19 00:59:15 x systemd-logind[5530]: Failed to read boot config from "/boot/efi/loader/loader.conf": Permission denied
Nov 19 00:59:15 x systemd-logind[5530]: Failed to load bootspec config from "/boot/efi/loader": Permission denied

on fedora 29.

EDIT: downgrading to systemd-239-3.fc29 worked. Thank god they left the original version in the repos!

@ssieb

This comment has been minimized.

Copy link

ssieb commented Nov 19, 2018

I used the script to create the loader files, but still had to put selinux in permissive mode. I can use hybrid-sleep again now. I will probably do the downgrade as well if the fix doesn't get pushed to F29 soon.

@soul9

This comment has been minimized.

Copy link

soul9 commented Nov 19, 2018

just downgrade systemd for now:

  dnf install systemd-239-3.fc29
@skidnik

This comment has been minimized.

Copy link

skidnik commented Nov 19, 2018

Yeah, right, selinux. For those on F29 the following may help:

 semanage fcontext -a -t systemd_logind_sessions_t "/boot/efi/loader(/.*)?"

this should allow logind to access those files, have no way to test if this works though

@soul9

This comment has been minimized.

Copy link

soul9 commented Nov 19, 2018

are you aware that fat doesn't support selinux?

@skidnik

This comment has been minimized.

Copy link

skidnik commented Nov 19, 2018

well,

 ls -lZa
 total 16
 drwx------. 3 root root system_u:object_r:dosfs_t:s0 4096 Nov 16 14:55 .
 drwx------. 5 root root system_u:object_r:dosfs_t:s0 4096 Jan  1  1970 ..
 drwx------. 2 root root system_u:object_r:dosfs_t:s0 4096 Nov 16 14:55 entries
 -rwx------. 1 root root system_u:object_r:dosfs_t:s0   14 Nov 16 14:55 loader.conf

seeing this I assumed it does. nevermind me then, just read the manual and thought it be worth trying.

keszybz added a commit to keszybz/systemd that referenced this issue Nov 21, 2018

Revert 5fdf2d5
This reverts 5fdf2d5, except for one improved
log message.

Fixes systemd#10613.

Checking if resume= is configured is a good idea, but it turns out we cannot do
it reliably:
- the code only supported boot options with sd-boot, and it's not very widely
  used. This means that for most systemd we could only check the current
  commandline, not the next one.
- Various systems resume without, e.g. Debian has
  /etc/initramfs-tools/conf.d/resume in the initramfs.

Making those checks better would be possible with enough effort, but there'll
be always new systems that boot in a slightly different way and we would need
to keep adding new cases. Longer term, we want to rely on autodetecting the
resume partition, and then checks like this will not be necessary at all. It is
quite clear from the number of bug reports that the number of poeple impacted
by this is quite high now, so let's just drop this.

poettering added a commit that referenced this issue Nov 21, 2018

Revert 5fdf2d5
This reverts 5fdf2d5, except for one improved
log message.

Fixes #10613.

Checking if resume= is configured is a good idea, but it turns out we cannot do
it reliably:
- the code only supported boot options with sd-boot, and it's not very widely
  used. This means that for most systemd we could only check the current
  commandline, not the next one.
- Various systems resume without, e.g. Debian has
  /etc/initramfs-tools/conf.d/resume in the initramfs.

Making those checks better would be possible with enough effort, but there'll
be always new systems that boot in a slightly different way and we would need
to keep adding new cases. Longer term, we want to rely on autodetecting the
resume partition, and then checks like this will not be necessary at all. It is
quite clear from the number of bug reports that the number of poeple impacted
by this is quite high now, so let's just drop this.

eworm-de added a commit to eworm-de/systemd that referenced this issue Nov 26, 2018

Revert 5fdf2d5
This reverts 5fdf2d5, except for one improved
log message.

Fixes systemd#10613.

Checking if resume= is configured is a good idea, but it turns out we cannot do
it reliably:
- the code only supported boot options with sd-boot, and it's not very widely
  used. This means that for most systemd we could only check the current
  commandline, not the next one.
- Various systems resume without, e.g. Debian has
  /etc/initramfs-tools/conf.d/resume in the initramfs.

Making those checks better would be possible with enough effort, but there'll
be always new systems that boot in a slightly different way and we would need
to keep adding new cases. Longer term, we want to rely on autodetecting the
resume partition, and then checks like this will not be necessary at all. It is
quite clear from the number of bug reports that the number of poeple impacted
by this is quite high now, so let's just drop this.

(cherry picked from commit 6d17652)
@wrabcak

This comment has been minimized.

Copy link

wrabcak commented Dec 12, 2018

Hi @poettering,
Do we still need some fixes in SELinux policy for fedora after 5fdf2d5 revert?

Thanks,
Lukas.

@poettering

This comment has been minimized.

Copy link
Member

poettering commented Dec 12, 2018

@wrabcak on don't think we do, for now at least.

@wrabcak

This comment has been minimized.

Copy link

wrabcak commented Dec 12, 2018

@poettering. Thanks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment