Dual efi entries

[edpil02]

systemd version the issue has been seen with

254

Used distribution

Rawhide

Linux kernel version used

6.5.0-0.rc3.23.fc39.x86_64

CPU architectures issue was seen on

x86_64

Component

systemd-boot

Expected behaviour you didn't see

No response

Unexpected behaviour you saw

To avoid this issue : https://bugzilla.redhat.com/show_bug.cgi?id=2226908 ,
I tried this pull : #28511.

I have no boot issue now but dual efi entries remain on /efi and /boot/efi.

~$ mount | grep /efi
systemd-1 on /efi type autofs (rw,relatime,fd=47,pgrp=1,timeout=120,minproto=5,maxproto=5,direct,pipe_ino=18020)
/dev/nvme0n1p1 on /boot/efi type vfat (rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=winnt,errors=remount-ro)

Steps to reproduce the problem

No response

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

No response

[YHNdnzj]

gpt-auto-generator only makes use of /boot/ or /efi/ for ESP. It shall not be responsible for custom mounts at other places. Please consider disabling gpt-auto logic if you don't need it.

[edpil02]

My esp is mounted by the anaconda installer which offers /boot and /boot/efi.
Booctl install also uses /boot/efi.

Does that mean I shouldn't choose /boot/efi in anaconda.
I didn't have this problem with -253

[YHNdnzj]

Booctl install also uses /boot/efi.

We retain compatibility for that when using bootctl, but it's no longer actively used elsewhere in our code.

Does that mean I shouldn't choose /boot/efi in anaconda.

Downstream distros should migrate to /boot/ or /efi/ gradually in the future I believe. But before that, you can choose /boot/ manually or disable gpt-auto-generator as a workaround.

[edpil02]

I sent a bug report to the installer team because anaconda crashes when ESP is on /boot.
However after some troubles, I managed to make a install on /boot and everything is ok now.

Thanks.

[keszybz]

It sounds like there's still something to fix on our side. The generator should not mount the partition if there's already a mount point configured for it in a different place. We have some code to do this, but if the reports about the generator doing a duplicate mount are correct, then it's not working correctly.

Disabling the generator should be a solution of the last resort. The setup described in this issue is very common, so we need to support it gracefully, esp. if it already worked before.

[YHNdnzj]

We have some code to do this, but if the reports about the generator doing a duplicate mount are correct, then it's not working correctly.

Currently only mountpoints used by us are checked, namely /boot/ and /efi/. Do we want to specialize /boot/efi/ too or just match any mounts with the same device?

[keszybz]

Currently only mountpoints used by us are checked, namely /boot/ and /efi/. Do we want to specialize /boot/efi/ too or just match any mounts with the same device?

I think it'd be neat to not specialize, i.e. check anything in /etc/fstab.