<div dir="auto"><div dir="auto">systemd has been recommending against an arrangement like that for a long time now. These partitions are often fragile (read from bootloader code, or worse firmware! VFAT has no data integrity), and they really have no reason to be mounted unless they're about to be accessed. Stacking the mount points like that requires /boot to be mounted to mount /efi, which is just unnecessary<br></div><div dir="auto"><br></div><div dir="auto">So systemd & the Boot Loader Standard (<a href="https://uapi-group.org/specifications/specs/boot_loader_specification/#mount-points">https://uapi-group.org/specifications/specs/boot_loader_specification/#mount-points</a>) document separate /efi and /boot mount points, and recommend against /boot/efi. In all of systemd's code, /boot/efi is treated as a fallback of last resort, as a special case in the partition lookup logic, kept around for backwards compatibility with distros that haven't changed their layout to the recommended way. It's not even all that well supported/tested - it's been broken in gpt-auto-generator and warranted a breaking change to fix it. And systemd, left to its own devices, will never create such a mount layout (i.e. w/ gpt-auto-generator and root=tmpfs)</div><div dir="auto"><br></div><div dir="auto">So yes, in systemd /boot/efi is treated and thought of as obsolete. Distros not following systemd's recommendations doesn't make the layout any less deprecated from systemd's perspective.</div><div dir="auto"><br></div><div dir="auto">Perhaps Fedora can be adjusted to follow the BLS's recommended mount points?</div><div dir="auto"><br></div><div dir="auto">Best,</div><div dir="auto">Adrian </div><br><div class="gmail_quote" dir="auto"><div dir="ltr" class="gmail_attr">On Thu, Apr 25, 2024, 21:53 Neal Gompa <<a href="mailto:ngompa13@gmail.com" target="_blank" rel="noreferrer">ngompa13@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Thu, Apr 25, 2024 at 6:15 PM systemd tag bot<br>
<<a href="mailto:donotreply-systemd-tag@refi64.com" rel="noreferrer noreferrer" target="_blank">donotreply-systemd-tag@refi64.com</a>> wrote:<br>
><br>
> A new systemd ☠️ pre-release ☠️ has just been tagged. Please download the tarball here:<br>
><br>
> <a href="https://github.com/systemd/systemd/archive/v256-rc1.tar.gz" rel="noreferrer noreferrer noreferrer" target="_blank">https://github.com/systemd/systemd/archive/v256-rc1.tar.gz</a><br>
><br>
> NOTE: This is ☠️ pre-release ☠️ software. Do not run this on production<br>
> systems, but please test this and report any issues you find to GitHub:<br>
><br>
> <a href="https://github.com/systemd/systemd/issues/new?template=Bug_report.md" rel="noreferrer noreferrer noreferrer" target="_blank">https://github.com/systemd/systemd/issues/new?template=Bug_report.md</a><br>
><br>
> Changes since the previous release:<br>
><br>
> Announcements of Future Feature Removals and Incompatible Changes:<br>
><br>
> * Support for automatic flushing of the nscd user/group database caches<br>
> will be dropped in a future release.<br>
><br>
> * Support for cgroup v1 ('legacy' and 'hybrid' hierarchies) is now<br>
> considered obsolete and systemd by default will refuse to boot under<br>
> it. To forcibly reenable cgroup v1 support,<br>
> SYSTEMD_CGROUP_ENABLE_LEGACY_FORCE=1 must be set on kernel command<br>
> line. The meson option 'default-hierarchy=' is also deprecated, i.e.<br>
> only cgroup v2 ('unified' hierarchy) can be selected as build-time<br>
> default.<br>
><br>
> * Previously, systemd-networkd did not explicitly remove any bridge<br>
> VLAN IDs assigned on bridge master and ports. Since version 256, if a<br>
> .network file for an interface has at least one valid setting in the<br>
> [BridgeVLAN] section, then all assigned VLAN IDs on the interface<br>
> that are not configured in the .network file are removed.<br>
><br>
> * systemd-gpt-auto-generator will stop generating units for ESP or<br>
> XBOOTLDR partitions if it finds mount entries for or below the /boot/<br>
> or /efi/ hierarchies in /etc/fstab. This is to prevent the generator<br>
> from interfering with systems where the ESP is explicitly configured<br>
> to be mounted at some path, for example /boot/efi/ (this type of<br>
> setup is obsolete, but still commonly found).<br>
><br>
<br>
This is not obsolete. Please do not say it is when it is not true.<br>
<br>
<br>
<br>
<br>
<br>
--<br>
真実はいつも一つ！/ Always, there's only one truth!<br><br>
</blockquote></div>
</div>