[systemd-devel] systemd prerelease 256-rc1

[Adrian Vovk]

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

So systemd & the Boot Loader Standard (
https://uapi-group.org/specifications/specs/boot_loader_specification/#mount-points)
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)

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.

Perhaps Fedora can be adjusted to follow the BLS's recommended mount points?

Best,
Adrian

On Thu, Apr 25, 2024, 21:53 Neal Gompa <ngompa13 at gmail.com> wrote:

> On Thu, Apr 25, 2024 at 6:15 PM systemd tag bot
> <donotreply-systemd-tag at refi64.com> wrote:
> >
> > A new systemd ☠️ pre-release ☠️ has just been tagged. Please download
> the tarball here:
> >
> >         https://github.com/systemd/systemd/archive/v256-rc1.tar.gz
> >
> > NOTE: This is ☠️ pre-release ☠️ software. Do not run this on production
> > systems, but please test this and report any issues you find to GitHub:
> >
> >
> https://github.com/systemd/systemd/issues/new?template=Bug_report.md
> >
> > Changes since the previous release:
> >
> >         Announcements of Future Feature Removals and Incompatible
> Changes:
> >
> >         * Support for automatic flushing of the nscd user/group database
> caches
> >           will be dropped in a future release.
> >
> >         * Support for cgroup v1 ('legacy' and 'hybrid' hierarchies) is
> now
> >           considered obsolete and systemd by default will refuse to boot
> under
> >           it. To forcibly reenable cgroup v1 support,
> >           SYSTEMD_CGROUP_ENABLE_LEGACY_FORCE=1 must be set on kernel
> command
> >           line. The meson option 'default-hierarchy=' is also
> deprecated, i.e.
> >           only cgroup v2 ('unified' hierarchy) can be selected as
> build-time
> >           default.
> >
> >         * Previously, systemd-networkd did not explicitly remove any
> bridge
> >           VLAN IDs assigned on bridge master and ports. Since version
> 256, if a
> >           .network file for an interface has at least one valid setting
> in the
> >           [BridgeVLAN] section, then all assigned VLAN IDs on the
> interface
> >           that are not configured in the .network file are removed.
> >
> >         * systemd-gpt-auto-generator will stop generating units for ESP
> or
> >           XBOOTLDR partitions if it finds mount entries for or below the
> /boot/
> >           or /efi/ hierarchies in /etc/fstab. This is to prevent the
> generator
> >           from interfering with systems where the ESP is explicitly
> configured
> >           to be mounted at some path, for example /boot/efi/ (this type
> of
> >           setup is obsolete, but still commonly found).
> >
>
> This is not obsolete. Please do not say it is when it is not true.
>
>
>
>
>
> --
> 真実はいつも一つ！/ Always, there's only one truth!
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20240426/86a50891/attachment.htm>