bootctl, systemd-logind: Failed to open '/boot//loader/entries': Remote address changed

[bam80]

systemd version the issue has been seen with

systemd 256 (256.8-1.fc41)

Used distribution

Fedora Linux 41.20241119.0 (Silverblue)

Linux kernel version used

6.11.8-300.fc41.x86_64

CPU architectures issue was seen on

x86_64

Component

bootctl

Expected behaviour you didn't see

$ bootctl list
           Boot Loader Entries:
                    type: Boot Loader Specification Type #1 (.conf)
                   title: Fedora Linux 36 (Workstation Edition) (default) (selected)
                      id: ...
                  source: /boot/efi/loader/entries/entry-token-kernel-version.conf
                 version: kernel-version
              machine-id: ...
                   linux: /entry-token/kernel-version/linux
                  initrd: /entry-token/kernel-version/initrd
                 options: root=...

                    type: Boot Loader Specification Type #2 (.efi)
...

Unexpected behaviour you saw

$ bootctl list 
Failed to open '/boot//loader/entries': Remote address changed

$ bootctl
Failed to open '/boot//loader/entries': Remote address changed
...

The same error from systemd-logind, see below.

Steps to reproduce the problem

transitioning to a separate /boot partition, run the bootctl command:
ostreedev/ostree#1719 (comment)

Other report on Silverblue:
https://unix.stackexchange.com/questions/785355/persistent-systemd-logind-error-in-fedora-silverblue-failed-to-open-boot-loa

Additional program output to the terminal or log subsystem illustrating the issue

# unrelated to the bootctl run

$ journalctl -b -u systemd-logind.service
...
ноя 19 21:04:02 host systemd-logind[918]: Failed to open '/boot//loader/entries': Remote address changed
ноя 19 21:14:09 host systemd-logind[918]: Failed to open '/boot//loader/entries': Remote address change
...

[yuwata]

The error code suggests that the path /boot//loader/entries contains symlink(s). Is it true?

[yuwata]

Not familiar with ostree or silverblue, but judging from ostreedev/ostree#1719 (comment), ostree configures /boot/loader as a symlink. systemd-boot does not accept that.

[bam80]

Well, we have to invent common solution, then :)

[bam80]

systemd-boot does not accept that

Please note the system boots though, so maybe systemd-boot itself does actually accept that, but other user-mode utils (
bootctl, systemd-logind) don't?

[yuwata]

Yeah, more accurately, (at least currently,) systemd-boot may work but we do not support such setup, and other tools like bootctl or so refuses such.

[cgwalters]

Yes, work remains on the ostree side to match the current BLS type1 spec. The tracker is ostreedev/ostree#1951

[TriMoon]

See also: #31179

[bam80]

While using symlinks might be a problem per se, this particular issue is different.

Please note the circumstances when the issue first happened:

After transitioning to a separate /boot partition I started to see this error:

If I return to my previous /boot placement (on btrfs subvolume), I see no such error.

ostreedev/ostree#1719 (comment)

So there is no issue if / and /boot/ are on the same partition, even with the symlinks.

Having that, should we reopen this issue? @cgwalters