Re: [systemd-devel] systemd prerelease 256-rc1
On Fr, 26.04.24 09:49, Neal Gompa (ngomp...@gmail.com) wrote: > > Well, people moved off split-usr quite successfully, which is a bigger > > feat than cleaning up the /boot/efi/ mess I'd say. > > > > Fedora is currently merging /usr/bin/ and /usr/sbin/, which I am pretty > > sure is a bigger change too. > > Neither of those involved screwing with mountpoints and changing code > around bootloaders. > > >From a distribution perspective, UsrMerge and the bin+sbin merge are > significantly simpler things. Well, believe what you want. But even in Fedora it's probably <= 15 packages that care about the EFI mount point. the sbin/bin merge and the usr merge otoh touched pretty much *every* package in the repo. I think the reproducible build stuff currently being in fedora is also going to be a harder thing to do. But anyway, we can certainly agree that we have different concepts/metrics of "hard" or "easy" tasks. Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] systemd prerelease 256-rc1
On Fr, 26.04.24 09:47, Neal Gompa (ngomp...@gmail.com) wrote: > > > > * 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. > > > > Uh, we mark outdated concepts as obsolete all the time. You might > > disagree with that, but that doesn't change the fact that from our PoV > > /boot/efi/ is obsolete, just like split /usr/, or cgroupv1. > > > > Nesting /efi/ in /boot/ is bad for plenty reasons, as has been widely > > discussed, so I am not going to repeat this here. And this has been > > communicated for multiple years now, and all the automatisms in > > systemd do not work for such a setup, hence I think saying that this > > setup is obsolete by now is not an understatement. > > > > I know that Fedora is sadly behind on boot loader topics, but that's > > no reason for changing our stance from systemd upstream on these > > things. > > There are fewer distros using /efi than /boot/efi, and no major > distributions that use /boot/efi. > > Complaining about it being a Fedora thing (which I guess I need to > remind this audience that I am involved in more than Fedora, and every > distribution I work on does use /boot/efi instead of /efi) is weird > since it's not just Fedora. It's pretty much everyone. Yeah, as the NEWS entry says, /boot/efi/ is commonly found. So? Doesn't change the fact it's a bad idea and from systemd's PoV an obsolete concept. Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] systemd prerelease 256-rc1
On Fri, Apr 26, 2024 at 9:46 AM Lennart Poettering wrote: > > On Fr, 26.04.24 10:39, Dan Nicholson (d...@endlessos.org) wrote: > > > On Fri, Apr 26, 2024 at 10:11 AM Adrian Vovk wrote: > > > > > > Perhaps Fedora can be adjusted to follow the BLS's recommended mount > > > points? > > > > The problem with all of these type of "we've realized a better way and > > the old way is obsolete" is that it's left as someone else's issue to > > actually change existing users from the obsolete way. I've written > > code to migrate away from some old setup several times at Endless and > > it's always scary that you're going to screw a whole class of users > > and the only way out of that will be manual intervention. That's > > doubly so for something like this where it's touching critical boot > > files. Doing something wrong there may make someone's system unusable. > > > > So, while I do agree with the sentiment that /boot/efi is a bad idea > > and should not be done anymore, I have a lot of sympathy for Fedora > > continuing to use it. > > Well, people moved off split-usr quite successfully, which is a bigger > feat than cleaning up the /boot/efi/ mess I'd say. > > Fedora is currently merging /usr/bin/ and /usr/sbin/, which I am pretty > sure is a bigger change too. > Neither of those involved screwing with mountpoints and changing code around bootloaders. >From a distribution perspective, UsrMerge and the bin+sbin merge are significantly simpler things. -- 真実はいつも一つ！/ Always, there's only one truth!
Re: [systemd-devel] systemd prerelease 256-rc1
On Fri, Apr 26, 2024 at 9:41 AM Lennart Poettering wrote: > > On Do, 25.04.24 18:52, Neal Gompa (ngomp...@gmail.com) wrote: > > > > * 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. > > Uh, we mark outdated concepts as obsolete all the time. You might > disagree with that, but that doesn't change the fact that from our PoV > /boot/efi/ is obsolete, just like split /usr/, or cgroupv1. > > Nesting /efi/ in /boot/ is bad for plenty reasons, as has been widely > discussed, so I am not going to repeat this here. And this has been > communicated for multiple years now, and all the automatisms in > systemd do not work for such a setup, hence I think saying that this > setup is obsolete by now is not an understatement. > > I know that Fedora is sadly behind on boot loader topics, but that's > no reason for changing our stance from systemd upstream on these > things. > There are fewer distros using /efi than /boot/efi, and no major distributions that use /boot/efi. Complaining about it being a Fedora thing (which I guess I need to remind this audience that I am involved in more than Fedora, and every distribution I work on does use /boot/efi instead of /efi) is weird since it's not just Fedora. It's pretty much everyone. -- 真実はいつも一つ！/ Always, there's only one truth!
Re: [systemd-devel] systemd prerelease 256-rc1
On Fr, 26.04.24 10:39, Dan Nicholson (d...@endlessos.org) wrote: > On Fri, Apr 26, 2024 at 10:11 AM Adrian Vovk wrote: > > > > Perhaps Fedora can be adjusted to follow the BLS's recommended mount points? > > The problem with all of these type of "we've realized a better way and > the old way is obsolete" is that it's left as someone else's issue to > actually change existing users from the obsolete way. I've written > code to migrate away from some old setup several times at Endless and > it's always scary that you're going to screw a whole class of users > and the only way out of that will be manual intervention. That's > doubly so for something like this where it's touching critical boot > files. Doing something wrong there may make someone's system unusable. > > So, while I do agree with the sentiment that /boot/efi is a bad idea > and should not be done anymore, I have a lot of sympathy for Fedora > continuing to use it. Well, people moved off split-usr quite successfully, which is a bigger feat than cleaning up the /boot/efi/ mess I'd say. Fedora is currently merging /usr/bin/ and /usr/sbin/, which I am pretty sure is a bigger change too. Noone here has any illusions, this is not going to be fixed from today to tomorrow, just like the usr-merge wasn't done in a day or the sbin-merge doesn't happen in a single day either. But I am very sure we shouldn't let the Linux platform stagnate like this. I think it really should be time to clean up /boot/efi/, we don't want that people get bored after the sbin-merge is complete, after all! Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] systemd prerelease 256-rc1
On Do, 25.04.24 18:52, Neal Gompa (ngomp...@gmail.com) wrote: > > * 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. Uh, we mark outdated concepts as obsolete all the time. You might disagree with that, but that doesn't change the fact that from our PoV /boot/efi/ is obsolete, just like split /usr/, or cgroupv1. Nesting /efi/ in /boot/ is bad for plenty reasons, as has been widely discussed, so I am not going to repeat this here. And this has been communicated for multiple years now, and all the automatisms in systemd do not work for such a setup, hence I think saying that this setup is obsolete by now is not an understatement. I know that Fedora is sadly behind on boot loader topics, but that's no reason for changing our stance from systemd upstream on these things. Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] systemd prerelease 256-rc1
On Fri, Apr 26, 2024 at 10:11 AM Adrian Vovk wrote: > > Perhaps Fedora can be adjusted to follow the BLS's recommended mount points? The problem with all of these type of "we've realized a better way and the old way is obsolete" is that it's left as someone else's issue to actually change existing users from the obsolete way. I've written code to migrate away from some old setup several times at Endless and it's always scary that you're going to screw a whole class of users and the only way out of that will be manual intervention. That's doubly so for something like this where it's touching critical boot files. Doing something wrong there may make someone's system unusable. So, while I do agree with the sentiment that /boot/efi is a bad idea and should not be done anymore, I have a lot of sympathy for Fedora continuing to use it. -- Dan Nicholson | Endless OS Foundation
Re: [systemd-devel] systemd prerelease 256-rc1
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 wrote:
> On Thu, Apr 25, 2024 at 6:15 PM systemd tag bot
> 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!
>
>
Re: [systemd-devel] systemd prerelease 256-rc1
On Thu, Apr 25, 2024 at 6:15 PM systemd tag bot
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!
[systemd-devel] systemd prerelease 256-rc1
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).
* The behavior of systemd-sleep and systemd-homed has been updated to
freeze user sessions when entering the various sleep modes or when
locking a homed-managed home area. This is known to cause issues with
the proprietary NVIDIA drivers. Packagers of the NVIDIA proprietary
drivers may want to add drop-in configuration files that set
SYSTEMD_SLEEP_FREEZE_USER_SESSION=false for systemd-suspend.service
and related services, and SYSTEMD_HOME_LOCK_FREEZE_SESSION=false for
systemd-homed.service.
* systemd-tmpfiles and systemd-sysusers, when given a relative
configuration file path (with at least one directory separator '/'),
will open the file directly, instead of searching for the given
partial path in the standard locations. The old mode wasn't useful
because tmpfiles.d/ and sysusers.d/ configuration has a flat
structure with no subdirectories under the standard locations and
this change makes it easier to work with local files with those
tools.
* systemd-tmpfiles now properly applies nested configuration to 'R' and
'D' stanzas. For example, with the combination of 'R /foo' and 'x
/foo/bar', /foo/bar will now be excluded from removal.
General Changes and New Features:
* Various programs will now attempt to load the main configuration file
from locations below /usr/lib/, /usr/local/lib/, and /run/, not just
below /etc/. For example, systemd-logind will look for
/etc/systemd/logind.conf, /run/systemd/logind.conf,
/usr/local/lib/systemd/logind.conf, and /usr/lib/systemd/logind.conf,
and use the first file that is found. This means that the search
logic for the main config file and for drop-ins is now the same.
Similarly, kernel-install will look for the config files in
/usr/lib/kernel/ and the other search locations, and now also
supports drop-ins.
systemd-udevd now supports drop-ins for udev.conf.
* A new 'systemd-vpick' binary has been added. It implements the new
vpick protocol, where a "*.v/" directory may contain multiple files
which have versions (following the UAPI version format specification)
embedded in the file name. The files are ordered by version and
the newest one is selected.
systemd-nspawn --image=/--directory=, systemd-dissect,
systemd-portabled, and the RootDirectory=, RootImage=,
ExtensionImages=, and ExtensionDirectories= settings for units now
support the vpick protocol and allow the latest version to be
selected automatically if a "*.v/" directory is specified as the
source.
* Encrypted service credentials can now be made accessible to
unprivileged users. systemd-creds gained new options --user/--uid=
for encrypting/decrypting a credential for a specific user.
* New
