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 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: [RFC] initoverlayfs - a scalable initial filesystem
On Mon, Dec 11, 2023 at 12:30 PM Demi Marie Obenour wrote: > > On Mon, Dec 11, 2023 at 10:57:58AM +0100, Lennart Poettering wrote: > > On Fr, 08.12.23 17:59, Eric Curtin (ecur...@redhat.com) wrote: > > > > > Here is the boot sequence with initoverlayfs integrated, the > > > mini-initramfs contains just enough to get storage drivers loaded and > > > storage devices initialized. storage-init is a process that is not > > > designed to replace init, it does just enough to initialize storage > > > (performs a targeted udev trigger on storage), switches to > > > initoverlayfs as root and then executes init. > > > > > > ``` > > > fw -> bootloader -> kernel -> mini-initramfs -> initoverlayfs -> rootfs > > > > > > fw -> bootloader -> kernel -> storage-init -> init -> > > > ``` > > > > I am not sure I follow what these chains are supposed to mean? Why are > > there two lines? > > > > So, I generally would agree that the current initrd scheme is not > > ideal, and we have been discussing better approaches. But I am not > > sure your approach really is useful on generic systems for two > > reasons: > > > > 1. no security model? you need to authenticate your initrd in > >2023. There's no execuse to not doing that anymore these days. Not > >in automotive, and not anywhere else really. > > > > 2. no way to deal with complex storage? i.e. people use FDE, want to > >unlock their root disks with TPM2 and similar things. People use > >RAID, LVM, and all that mess. > > > > Actually the above are kinda the same problem in a way: you need > > complex storage, but if you need that you kinda need udev, and > > services, and then also systemd and all that other stuff, and that's > > why the system works like the system works right now. > > > > Whenever you devise a system like yours by cutting corners, and > > declaring that you don't want TPM, you don't want signed initrds, you > > don't want to support weird storage, you just solve your problem in a > > very specific way, ignoring the big picture. Which is OK, *if* you can > > actually really work without all that and are willing to maintain the > > solution for your specific problem only. > > > > As I understand you are trying to solve multiple problems at once > > here, and I think one should start with figuring out clearly what > > those are before trying to address them, maybe without compromising on > > security. So my guess is you want to address the following: > > > > 1. You don't want the whole big initrd to be read off disk on every > >boot, but only the parts of it that are actually needed. > > > > 2. You don't want the whole big initrd to be fully decompressed on every > >boot, but only the parts of it that are actually needed. > > > > 3. You want to share data between root fs and initrd > > > > 4. You want to save some boot time by not bringing up an init system > >in the initrd once, then tearing it down again, and starting it > >again from the root fs. > > > > For the items listed above I think you can find different solutions > > which do not necessarily compromise security as much. > > > > So, in the list above you could address the latter three like this: > > > > 2. Use an erofs rather than a packed cpio as initrd. Make the boot > >loader load the erofs into contigous memory, then use memmap=X!Y on > >the kernel cmdline to synthesize a block device from that, which > >you then mount directly (without any initrd) via > >root=/dev/pmem0. This means yout boot loader will still load the > >whole image into memory, but only decompress the bits actually > >neeed. (It also has some other nice benefits I like, such as an > >immutable rootfs, which tmpfs-based initrds don't have.) > > > > 3. Simply never transition to the root fs, don't marke the initrds in > >systemd's eyes as an initrd (specifically: don't add an > >/etc/initrd-release file to it). Instead, just merge resources of > >the root fs into your initrd fs via overlayfs. systemd has > >infrastructure for this: "systemd-sysext". It takes immutable, > >authenticated erofs images (with verity, we call them "DDIs", > >i.e. "discoverable disk images") that it overlays into /usr/. [You > >could also very nicely combine this approach with systemd's > >portable services, and npsawn containers, which operate on the same > >authenticated images]. At MSFT we have a major product that works > >exactly like this: the OS runs off a rootfs that is loaded as an > >initrd, and everything that runs on top of this are just these > >verity disk images, using overlayfs and portable services. > > > > 4. The proposal in 3 also addresses goal 4. > > > > Which leaves item 1, which is a bit harder to address. We have been > > discussing this off an on internally too. A generic solution to this > > is hard. My current thinking for this could be something like this, > > covering the UEFI world: support sticking
Re: [systemd-devel] [PATCH 0/1] x86/kexec: UKI support
On Mon, Sep 11, 2023 at 7:15 PM Jarkko Sakkinen wrote: > > On Sat Sep 9, 2023 at 7:18 PM EEST, Jan Hendrik Farr wrote: > > Hello, > > > > this patch implements UKI support for kexec_file_load. It will require > > support > > in the kexec-tools userspace utility. For testing purposes the following > > can be used: > > https://github.com/Cydox/kexec-test/ > > > > There has been discussion on this topic in an issue on GitHub that is > > linked below > > for reference. > > > > > > Some links: > > - Related discussion: https://github.com/systemd/systemd/issues/28538 > > - Documentation of UKIs: > > https://uapi-group.org/specifications/specs/unified_kernel_image/ > > > > Jan Hendrik Farr (1): > > x86/kexec: UKI support > > > > arch/x86/include/asm/kexec-uki.h | 7 ++ > > arch/x86/include/asm/parse_pefile.h| 32 +++ > > arch/x86/kernel/Makefile | 2 + > > arch/x86/kernel/kexec-uki.c| 113 + > > arch/x86/kernel/machine_kexec_64.c | 2 + > > arch/x86/kernel/parse_pefile.c | 110 > > crypto/asymmetric_keys/mscode_parser.c | 2 +- > > crypto/asymmetric_keys/verify_pefile.c | 110 +++- > > crypto/asymmetric_keys/verify_pefile.h | 16 > > 9 files changed, 278 insertions(+), 116 deletions(-) > > create mode 100644 arch/x86/include/asm/kexec-uki.h > > create mode 100644 arch/x86/include/asm/parse_pefile.h > > create mode 100644 arch/x86/kernel/kexec-uki.c > > create mode 100644 arch/x86/kernel/parse_pefile.c > > > > -- > > 2.40.1 > > What the heck is UKI? Unified Kernel Images. More details available here: https://uapi-group.org/specifications/specs/unified_kernel_image/ It's a way of creating initramfs-style images as fully generic, reproducible images that can be built server-side. It is a requirement for creating locked down Linux devices for appliances that can be tamper-resistant too. -- 真実はいつも一つ！/ Always, there's only one truth!
Re: [systemd-devel] Dropping SysV init script support? (was: systemd prerelease 254-rc3)
On Mon, Jul 24, 2023 at 11:40 AM Luca Boccassi wrote: > > On Mon, 24 Jul 2023 at 16:30, Neal Gompa wrote: > > > > On Mon, Jul 24, 2023 at 9:00 AM systemd tag bot > > wrote: > > > > > > * Support for System V service scripts is now deprecated and will > > > be > > > removed in a future release. Please make sure to update your > > > software > > > *now* to include a native systemd unit file instead of a legacy > > > System V script to retain compatibility with future systemd > > > releases. > > > > > > > What's driving this change? Already distributions have to manage the > > code that integrates the sysv init script support into systemd (such > > as chkconfig(8) and debian's systemd-sysv-install for update-rc.d(8)). > > > > To the best of my knowledge, the sysv support code actually *in* > > systemd is mostly around the systemd-sysv-generator that creates > > transient units to express dependencies. There's also the small bits > > in systemctl(1) itself for triggering the generation of those units. > > > > Is this something that could be externalized into a separate project > > and framework like systemd-initctl was? Perhaps it could even be a > > pattern for others to implement translation for their own things to > > systemd (e.g. runit, et al). > > Why not just add a unit where it's missing? It's been a decade or so, > most things should be in place now Because I don't necessarily control what other people do. And there's still a very long tail of software out there that only ships a sysvinit script. There are still people upgrading from RHEL 5/6, SLE 11, or Ubuntu 14.04 too. The software they bring along that they can't change would still be using sysvinit scripts. -- 真実はいつも一つ！/ Always, there's only one truth!
[systemd-devel] Dropping SysV init script support? (was: systemd prerelease 254-rc3)
On Mon, Jul 24, 2023 at 9:00 AM systemd tag bot wrote: > > * Support for System V service scripts is now deprecated and will be > removed in a future release. Please make sure to update your > software > *now* to include a native systemd unit file instead of a legacy > System V script to retain compatibility with future systemd > releases. > What's driving this change? Already distributions have to manage the code that integrates the sysv init script support into systemd (such as chkconfig(8) and debian's systemd-sysv-install for update-rc.d(8)). To the best of my knowledge, the sysv support code actually *in* systemd is mostly around the systemd-sysv-generator that creates transient units to express dependencies. There's also the small bits in systemctl(1) itself for triggering the generation of those units. Is this something that could be externalized into a separate project and framework like systemd-initctl was? Perhaps it could even be a pattern for others to implement translation for their own things to systemd (e.g. runit, et al). -- 真実はいつも一つ！/ Always, there's only one truth!
Re: [systemd-devel] Feedback sought: can we drop cgroupv1 support soon?
On Wed, Jul 19, 2023 at 8:52 AM Luca Boccassi wrote: > > On Wed, 19 Jul 2023 at 13:45, Neal Gompa wrote: > > > > On Thu, Jul 21, 2022 at 6:15 AM Lennart Poettering > > wrote: > > > > > > Heya! > > > > > > It's currently a terrible mess having to support both cgroupsv1 and > > > cgroupsv2 in our codebase. > > > > > > cgroupsv2 first entered the kernel in 2014, i.e. *eight* years ago > > > (kernel 3.16). We soon intend to raise the baseline for systemd to > > > kernel 4.3 (because we want to be able to rely on the existance of > > > ambient capabilities), but that also means, that all kernels we intend > > > to support have a well-enough working cgroupv2 implementation. > > > > > > hence, i'd love to drop the cgroupv1 support from our tree entirely, > > > and simplify and modernize our codebase to go cgroupv2-only. Before we > > > do that I'd like to seek feedback on this though, given this is not > > > purely a thing between the kernel and systemd — this does leak into > > > some userspace, that operates on cgroups directly. > > > > > > Specifically, legacy container infra (i.e. docker/moby) for the > > > longest time was cgroupsv1-only. But as I understand it has since been > > > updated, to cgroupsv2 too. > > > > > > Hence my question: is there a strong community of people who insist on > > > using newest systemd while using legacy container infra? Anyone else > > > has a good reason to stick with cgroupsv1 but really wants newest > > > systemd? > > > > > > The time where we'll drop cgroupv1 support *will* come eventually > > > either way, but what's still up for discussion is to determine > > > precisely when. hence, please let us know! > > > > > > > The main concern I have about cgroup v1 removal is that some major > > Kubernetes distributions don't support cgroup v2 yet. Upstream > > Kubernetes only started fully supporting cgroup v2 with Kubernetes > > 1.25, as noted in their documentation: > > https://kubernetes.io/docs/concepts/architecture/cgroups/ > > > > OpenShift just added support in 4.13 (but didn't enable it by default > > yet): https://cloud.redhat.com/blog/cgroups-v2-goes-ga-in-openshift-4.13 > > > > AKS seems to only support cgroup v2 with Ubuntu 22.04: > > https://learn.microsoft.com/en-us/azure/aks/supported-kubernetes-versions?tabs=azure-cli#aks-components-breaking-changes-by-version > > > > (No mention of Azure Linux? I'm pretty sure CBL-Mariner is cgroup v2 only) > > > > It is unclear whether EKS supports cgroup v2 at all (I suspect not, > > since EKS doesn't yet run on Amazon Linux 2023): > > https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html > > > > It is similarly unclear with GKE: > > https://cloud.google.com/kubernetes-engine/docs/concepts/node-images > > > > (The version of Ubuntu is not mentioned in the documentation, if it's > > not new enough, it's still cgroup v1) > > > > DigitalOcean Kubernetes Service (DOKS) is still cgroup v1: > > https://docs.digitalocean.com/products/kubernetes/details/changelog/ > > > > Linode Kubernetes Engine (LKE) is still cgroup v1: > > https://www.linode.com/docs/products/compute/kubernetes/release-notes/ > > > > It is possible that systemd's deprecation will push things over the > > edge, but I wanted to make sure people are aware of this. > > Are you sure that in all those cases it's really not supported at all, > vs simply not being the default configuration that can be changed with > a toggle? If it's not mentioned, it's probably not supported. And especially with managed Kubernetes, it's pretty rare to allow such kind of configuration changes. -- 真実はいつも一つ！/ Always, there's only one truth!
Re: [systemd-devel] Feedback sought: can we drop cgroupv1 support soon?
On Thu, Jul 21, 2022 at 6:15 AM Lennart Poettering wrote: > > Heya! > > It's currently a terrible mess having to support both cgroupsv1 and > cgroupsv2 in our codebase. > > cgroupsv2 first entered the kernel in 2014, i.e. *eight* years ago > (kernel 3.16). We soon intend to raise the baseline for systemd to > kernel 4.3 (because we want to be able to rely on the existance of > ambient capabilities), but that also means, that all kernels we intend > to support have a well-enough working cgroupv2 implementation. > > hence, i'd love to drop the cgroupv1 support from our tree entirely, > and simplify and modernize our codebase to go cgroupv2-only. Before we > do that I'd like to seek feedback on this though, given this is not > purely a thing between the kernel and systemd — this does leak into > some userspace, that operates on cgroups directly. > > Specifically, legacy container infra (i.e. docker/moby) for the > longest time was cgroupsv1-only. But as I understand it has since been > updated, to cgroupsv2 too. > > Hence my question: is there a strong community of people who insist on > using newest systemd while using legacy container infra? Anyone else > has a good reason to stick with cgroupsv1 but really wants newest > systemd? > > The time where we'll drop cgroupv1 support *will* come eventually > either way, but what's still up for discussion is to determine > precisely when. hence, please let us know! > The main concern I have about cgroup v1 removal is that some major Kubernetes distributions don't support cgroup v2 yet. Upstream Kubernetes only started fully supporting cgroup v2 with Kubernetes 1.25, as noted in their documentation: https://kubernetes.io/docs/concepts/architecture/cgroups/ OpenShift just added support in 4.13 (but didn't enable it by default yet): https://cloud.redhat.com/blog/cgroups-v2-goes-ga-in-openshift-4.13 AKS seems to only support cgroup v2 with Ubuntu 22.04: https://learn.microsoft.com/en-us/azure/aks/supported-kubernetes-versions?tabs=azure-cli#aks-components-breaking-changes-by-version (No mention of Azure Linux? I'm pretty sure CBL-Mariner is cgroup v2 only) It is unclear whether EKS supports cgroup v2 at all (I suspect not, since EKS doesn't yet run on Amazon Linux 2023): https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html It is similarly unclear with GKE: https://cloud.google.com/kubernetes-engine/docs/concepts/node-images (The version of Ubuntu is not mentioned in the documentation, if it's not new enough, it's still cgroup v1) DigitalOcean Kubernetes Service (DOKS) is still cgroup v1: https://docs.digitalocean.com/products/kubernetes/details/changelog/ Linode Kubernetes Engine (LKE) is still cgroup v1: https://www.linode.com/docs/products/compute/kubernetes/release-notes/ It is possible that systemd's deprecation will push things over the edge, but I wanted to make sure people are aware of this. -- 真実はいつも一つ！/ Always, there's only one truth!
Re: [systemd-devel] Linking /lib64 to /usr/lib
On Sat, Feb 25, 2023 at 11:39 AM Adrian Vovk wrote: > > Well it would only link /lib64 to /usr/lib if both Debian-style and > Fedora-style multilib don't exist and the loader is in lib, unless I'm > mistaken? I'm pretty sure it should be harmless to Fedora and openSUSE. > > Maybe it'd be preferable for me to make a /usr/lib64->/usr/lib link, then let > systemd think this is Fedora-style multilib? Would there be any bad side > effects from that? > That's pretty much how Arch and a few others do it. It should be fine since you are explicitly not doing multilib in your system. > --- > > Maybe I should explain my reasoning: > > Part of the reason I didn't do the split is to be less surprising. My distro > has no package management, nor does it have multilib. The /usr/lib64 vs > /usr/lib split has always been surprising to me as a user of Fedora, and I'm > never quite sure if I'll find something in lib or in lib64 (lib/systemd or > lib64/systemd or both? lib/pkgconfig or lib64/pkgconfig or both? lib/locale > or lib64/locale? You get the idea). Because I have no multilib, this split > becomes unnecessary. Thus, I can resolve all the ambiguities above in favor > of lib, which makes life easier and (imo) less surprising. > This is less ambiguous than you'd think. Outside of systemd putting executables in /usr/lib/systemd (rather than /usr/libexec/systemd), pretty much everything goes into the /usr/lib64 hierarchy for x86_64 stuff. In ancient times, systemd needed to pick directories that existed in FHS on / and /usr, which led to unit files and executables being installed in /lib. There is no /share or /libexec directories, and no one (back then) was interested in adding them. Today, systemd basically expects /usr hierarchy, which has /usr/share and /usr/libexec. I don't know if this will ever get fixed (probably not), but it's basically an accident of history. > I'm not the only distro doing this. Arch Linux is as well. > > I go a little further and actually make binaries I produce look for the > loader in /usr/lib as well. This makes the system fully functional just with > /usr present (at least that's the goal; still trying to remove references to > /bin and friends). I don't actually need /lib64 at all but it should exist > for backwards compatibility with existing binaries (as much as I would love > to prevent people from running random binaries downloaded from the > internet...) > This is probably not a good idea. > Both of these changes are harmless because I'll never support multilib (it's > entirely unnecessary for the software I distribute) and nobody should expect > to be able to run a binary from distro A on distro B anyway. > "nobody should" != "nobody would". > Anyway that's beside the point. I've been set up like this for a while now. > Perhaps one day I'll switch back to a more proper layout, but that would be a > change that will probably break things across the distro (again, due to the > whole "what goes into lib vs lib64" confusion) > Well, it should be easy enough for you to just shift existing binaries and tweak your build stuff so things go into lib64 going forward. -- 真実はいつも一つ！/ Always, there's only one truth!
Re: [systemd-devel] Linking /lib64 to /usr/lib
On Sat, Feb 25, 2023 at 9:45 AM Lennart Poettering wrote: > > On Di, 21.02.23 16:00, Adrian Vovk (adrianv...@gmail.com) wrote: > > > Hello all, > > > > Would you accept a patch to shared/base-filesystem that makes /usr/lib > > a fallback link target for /lib64? On my distro I don't support > > multilib at all and so everything ends up in /usr/lib. > > > > So for example, for x86_64 I'd change the target from > > "usr/lib/"LIB_ARCH_TUPLE"\0" "usr/lib64\0" to > > "usr/lib/"LIB_ARCH_TUPLE"\0" "usr/lib64\0" "usr/lib\0", and ditto for > > all the other architectures. That way no matter what, /lib64 always > > exists when necessary. > > I guess that makes some sense on a pure /lib/ file system. Send a > patch. > > (I mean, honestly, I personally wouldn't bother, and just usr /lib64/ > as fedora does and no populate /lib/ with libraries. I mean, it's just > names, and the ABI is how the ABI is. But regardless, a patch using > /lib/ as final fallback we search for ld.so in sounds acceptable.) > > Submit via github. > I don't think that's a good idea. Aside from violating the FHS, it creates an unexpected problem where multilib or multi-arch *is* available. If Adrian wants to do that on his own distribution, that's fine. But as a generic patch in upstream systemd? No way. It would probably need to be reverted in Fedora and openSUSE (at the minimum) to prevent chaos. Adrian, my advice to you: don't do it. Violating the principle of least surprise is not a good idea. I would just recommend not having a /usr/lib at all in your system. -- 真実はいつも一つ！/ Always, there's only one truth!
Re: [systemd-devel] Any chance of a new stable v250 tag?
On Fri, Dec 2, 2022 at 4:16 PM Ian Pilcher wrote: > > https://github.com/systemd/systemd-stable/issues/233 > CentOS Stream 9 is being upgraded to systemd 252[1], so this will likely become unneeded soon. The systemd-extras package in EPEL will be upgraded to systemd 252 to go along with it eventually. [1]: https://gitlab.com/redhat/centos-stream/rpms/systemd/-/merge_requests/59 -- 真実はいつも一つ！/ Always, there's only one truth!
Re: [systemd-devel] Antw: [EXT] Re: [systemd‑devel] systemd‑nspawn container not starting on RHEL9.0
On Thu, Aug 11, 2022 at 3:15 AM Ulrich Windl wrote: > > >>> Lennart Poettering schrieb am 10.08.2022 um 22:09 > in > Nachricht : > > On Mi, 10.08.22 10:13, Thomas Archambault (t...@tparchambault.com) wrote: > > > >> Thank you again Lennart, and thx Kevin. > >> > >> That makes total sense, and accounts for the application's high level > >> start‑up delay which appears to be what we are stuck with if we are over > >> xfs. Unfortunately, it's difficult to dictate to the client to change > their > >> fs type, consequently we can't develop / ship a tool with that baseline > >> latency on our primary target platform (RHEL xx.) > >> > >> So the next obvious question would be, is XFS reflink support on the > >> systemd‑nspawn roadmap or actually, (and even better) has support been > >> incorporated already in the latest and greatest src and I'm just behind > the > >> curve working with the older version of nspawn as shipped in RHEL90? > >> > >> I'm asking because according to the RHEL 9 docs > > > (https://access.redhat.com/documentation/en‑us/red_hat_enterprise_linux/9/html‑ > > > > single/managing_file_systems/index#the‑xfs‑file‑system_assembly_overview‑of‑availa > > ble‑file‑systems) > >> it's the current default fs and is configured for "Reflink‑based file > >> copies." > > > > We issue copy_file_range() syscall, which should do reflinks on xfs, > > if it supports that. Question is if your kernel supports that too. I > > have no experience with xfs though, no idea how xfs hooked up reflink > > initially. And we never tested that really. I don't think outside RHEL > > many people use xfs. > > Not true: For SUSE /home is typically using XFS, and we use it with SLES for > (huge) database filesystems. > In openSUSE, this hasn't been the default behavior for a while. SLES will catch up here eventually. -- 真実はいつも一つ！/ Always, there's only one truth!
Re: [systemd-devel] systemd-nspawn container not starting on RHEL9.0
On Wed, Aug 10, 2022 at 11:16 AM Thomas Archambault wrote: > > Thank you again Lennart, and thx Kevin. > > That makes total sense, and accounts for the application's high level > start-up delay which appears to be what we are stuck with if we are over > xfs. Unfortunately, it's difficult to dictate to the client to change > their fs type, consequently we can't develop / ship a tool with that > baseline latency on our primary target platform (RHEL xx.) > > So the next obvious question would be, is XFS reflink support on the > systemd-nspawn roadmap or actually, (and even better) has support been > incorporated already in the latest and greatest src and I'm just behind > the curve working with the older version of nspawn as shipped in RHEL90? > > I'm asking because according to the RHEL 9 docs > (https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html-single/managing_file_systems/index#the-xfs-file-system_assembly_overview-of-available-file-systems) > it's the current default fs and is configured for "Reflink-based file > copies." > > I understand that the project supports many distros, but I'm also > assuming that RHEL would make the list of platforms that the tool should > run optimally on. So, Is this worth submitting an enhancement request? > It's certainly not a bug. > > We like the feature set of nspawn and want to keep banging on it; > Probably pushing it into spaces it was not intended for, but that's > another story, and our issue... > You could also ask Red Hat to consider adding Btrfs to RHEL and give them your use-case so that they could consider adding it. It's already used by default in Fedora and many other distributions, so bringing it back to RHEL at this point would be a matter of customers asking for it. -- 真実はいつも一つ！/ Always, there's only one truth!
Re: [systemd-devel] Splitting sd-boot from systemd/bootctl for enabling sd-boot in Fedora
On Mon, May 9, 2022 at 10:30 AM Lennart Poettering wrote: > > On Fr, 06.05.22 10:12, Wols Lists (antli...@youngman.org.uk) wrote: > > > On 27/04/2022 14:53, Lennart Poettering wrote: > > > I think we systematically disagree on one point here: I am pretty sure > > > picking a boot loader is genuinely someting a distro should be doing, > > > and not the admin really. I mean, yes, I personally of course switched > > > away from Fedora's default choice of grub to use sd-boot, and of > > > course I'd prefer if it wasn't such a mess to do so. But also: we > > > should not advertise this as something people should actually do and > > > should make easy to do. > > > > EXCEPT. The boot loader loads the distro. An OS has no say in the computer's > > choice of BIOS/EFI because that's what starts the distro. Same for boot > > loader. > > > > There's a whole bunch of comments on LWN at the moment comparing computers > > to "cattle or pet". For "cattle", yep if the distro chooses the boot loader > > who cares. > > > > But for "pet"s (like my computer), (a) I'm going to need more hand-holding > > because I'm not a professional sys-admin, and (b) my system is multi-boot - > > it's bad enough with distros squabbling over who has control of grub.cfg, > > without them also squabbling over whether it's grub, systemd-bootd, rEFInd, > > LILO, whatever whatever. > > I am pretty sure the answer to this is not to make choice of boot > loaders configurable, but making them adhere to a common definition > how boot menu entries are defined, so that it doesn't matter which > boot loader you are using, the menu items pop up correctly either way. > > i.e. if boot loaders would all implement > https://systemd.io/BOOT_LOADER_SPECIFICATION then there would be a > very clear way how without trampling on each other's feet multi-boot > would work... > Has there been a campaign to get them to do it? Any outreach? Posting a page on the internet doesn't exactly do anything to get people to adopt a spec. -- 真実はいつも一つ！/ Always, there's only one truth!
Re: [systemd-devel] Splitting sd-boot from systemd/bootctl for enabling sd-boot in Fedora
On Wed, Apr 27, 2022 at 1:07 PM Neal Gompa wrote: > > On Wed, Apr 27, 2022 at 12:19 PM Zbigniew Jędrzejewski-Szmek > wrote: > > > > On Wed, Apr 27, 2022 at 11:40:36AM -0400, Neal Gompa wrote: > > > On Wed, Apr 27, 2022 at 11:26 AM Dan Nicholson wrote: > > > > > > > > On Wed, Apr 27, 2022 at 9:10 AM Neal Gompa wrote: > > > > > > > > > > Note that it means Fedora CI, pull requests from contributors, and > > > > > releng auto-rebuilds will no longer work. Maintainers basically > > > > > sign-on to do all of those things manually and have to be responsive > > > > > for doing it. You will get FTBFS tickets every cycle because of it, > > > > > for example. > > > > > > > > Asking systemd folks to change their development process because of > > > > limitations in Fedora/Koji seems like a big ask, don't you think? > > > > > > Honestly, that never factors in for me, because then I'd never ask > > > anything of anyone. :) > > > > > > But no, it doesn't sound unreasonable to me, because I reasonably > > > expect the parts that make up the EFI boot manager code to be somewhat > > > separate from the rest of the codebase in the first place. It targets > > > a different build environment and has to be built differently from the > > > rest of systemd anyway. So to me, it's not a "big ask" as you put it. > > > > Once more (this has already been written *independently* by Lennart > > and me, but let's say it once again): THE USERSPACE AND EFI-SPACE > > PARTS SHARE CODE, the configuration system and the build system. So if > > we split them, we'd probably want to update them in tandem anyway, and > > it's just easier to do it, then to try to figure out if the sd-boot parts > > didn't change and we can skip the update. > > > > Yes, well he was asking me why I bothered to ask, and I answered. That > doesn't have a bearing on what reality turned out to be. > > > Since the signing is automatic once configured, I can't grok what > > savings people foresee by doing separate builds. > > > > That's the point: correct signing is *not* automatic. It's *manual* > and done by *you* doing the build. Automatic signing is independent of > who does it, this is not that. > Another option that preserves the single source tree thing and probably will make Lennart happy is splitting this process in two: 1. systemd keeps building systemd-boot, but it gets split out as a subpackage (systemd-boot-unsigned-%efi_arch as noarch) 2. A new systemd-boot-signed source package BRs all systemd-boot-unsigned-$EFIARCH packages and signs them. It then produces "systemd-boot-$EFIARCH" subpackages that are signed that people can use. That second package gets specifically marked to not get autobuilt, doesn't have a disttag, and basically goes through the entire exception path that shim uses today. I think this matches what Michael Biebl was talking about for Debian that died on the vine. -- 真実はいつも一つ！/ Always, there's only one truth!
Re: [systemd-devel] Splitting sd-boot from systemd/bootctl for enabling sd-boot in Fedora
On Wed, Apr 27, 2022 at 12:19 PM Zbigniew Jędrzejewski-Szmek wrote: > > On Wed, Apr 27, 2022 at 11:40:36AM -0400, Neal Gompa wrote: > > On Wed, Apr 27, 2022 at 11:26 AM Dan Nicholson wrote: > > > > > > On Wed, Apr 27, 2022 at 9:10 AM Neal Gompa wrote: > > > > > > > > Note that it means Fedora CI, pull requests from contributors, and > > > > releng auto-rebuilds will no longer work. Maintainers basically > > > > sign-on to do all of those things manually and have to be responsive > > > > for doing it. You will get FTBFS tickets every cycle because of it, > > > > for example. > > > > > > Asking systemd folks to change their development process because of > > > limitations in Fedora/Koji seems like a big ask, don't you think? > > > > Honestly, that never factors in for me, because then I'd never ask > > anything of anyone. :) > > > > But no, it doesn't sound unreasonable to me, because I reasonably > > expect the parts that make up the EFI boot manager code to be somewhat > > separate from the rest of the codebase in the first place. It targets > > a different build environment and has to be built differently from the > > rest of systemd anyway. So to me, it's not a "big ask" as you put it. > > Once more (this has already been written *independently* by Lennart > and me, but let's say it once again): THE USERSPACE AND EFI-SPACE > PARTS SHARE CODE, the configuration system and the build system. So if > we split them, we'd probably want to update them in tandem anyway, and > it's just easier to do it, then to try to figure out if the sd-boot parts > didn't change and we can skip the update. > Yes, well he was asking me why I bothered to ask, and I answered. That doesn't have a bearing on what reality turned out to be. > Since the signing is automatic once configured, I can't grok what > savings people foresee by doing separate builds. > That's the point: correct signing is *not* automatic. It's *manual* and done by *you* doing the build. Automatic signing is independent of who does it, this is not that. -- 真実はいつも一つ！/ Always, there's only one truth!
Re: [systemd-devel] Splitting sd-boot from systemd/bootctl for enabling sd-boot in Fedora
On Wed, Apr 27, 2022 at 11:59 AM Luca Boccassi wrote: > > On Wed, 2022-04-27 at 11:48 -0400, Neal Gompa wrote: > > On Wed, Apr 27, 2022 at 11:46 AM Luca Boccassi wrote: > > > > > > On Wed, 2022-04-27 at 11:26 -0400, Neal Gompa wrote: > > > > On Wed, Apr 27, 2022 at 11:13 AM Zbigniew Jędrzejewski-Szmek > > > > wrote: > > > > > > > > > > On Wed, Apr 27, 2022 at 09:31:10AM -0400, Neal Gompa wrote: > > > > > > On Wed, Apr 27, 2022 at 7:41 AM Lennart Poettering > > > > > > > > Realistically, I think if we want to make movement on making > > > > > > > > systemd-boot fully supported in Fedora, the systemd-boot boot > > > > > > > > manager > > > > > > > > code itself should be split out into its own repository with > > > > > > > > its own > > > > > > > > release cadence, while bootctl(1) and related infrastructure > > > > > > > > remains > > > > > > > > in the systemd source tree and evolves to be able to manage > > > > > > > > arbitrary > > > > > > > > BLS-conformant boot managers. > > > > > > > > > > > > > > Why though? I don't follow? as long as we provide you with a > > > > > > > tarball > > > > > > > you can build your stuff from it shouldn't really matter if > > > > > > > there's > > > > > > > more stuff in it you are not immediately interested in. > > > > > > > > > > > > > > I mean, if you like I could do a "cp systemd-251.tar.gz > > > > > > > systemd-boot-251.tar.gz" for you if you want two tarballs instead > > > > > > > of > > > > > > > one, but I don't see the point? > > > > > > > > > > > > > > > > > > > As I illustrated in another email[5], decoupling the lifecycle of > > > > > > the > > > > > > EFI boot manager code from the rest of systemd would be ideal to not > > > > > > make the constraints around building sd-boot with secure boot > > > > > > support > > > > > > painful. > > > > > > > > > > > > [5]: > > > > > > https://lists.freedesktop.org/archives/systemd-devel/2022-April/047801.html > > > > > > > > > > Apart from the constraint who can build official packages, is there > > > > > anything else? If it's just that, that doesn't seem onerous. > > > > > > > > It also means Fedora CI, pull requests from contributors, and > > > > releng auto-rebuilds will no longer work. Maintainers basically > > > > sign-on to do all of those things manually and have to be responsive > > > > for doing it. You will get FTBFS tickets every cycle because of it, > > > > for example. > > > > > > > > Koji doesn't conceptually know the difference because there is no > > > > namespacing for builders, only who is approved to build. > > > > > > > > (In contrast, in the Open Build Service like what Luca Boccassi was > > > > talking about, packagers don't control the builds at all, so OBS only > > > > has to trust itself to sign it, so everything works properly.) > > > > > > You could simply have a separate source RPM, no? That should be pretty > > > simple, and limit the impact on team maintenance of the main source > > > package? > > > > > > > Yep. I was hoping we could have the upstream sources split too, but if > > we can't, then that's definitely the preferred way to go. > > With this PR https://github.com/systemd/systemd/pull/23204 you'll be > able to do this, which takes a fraction of a second to complete, as > opposed to the full build: > > $ ninja src/boot/efi/linuxx64.efi.stub > [21/21] Generating src/boot/efi/linuxx64.efi.stub with a custom command > $ ninja src/boot/efi/systemd-bootx64.efi > [10/10] Generating src/boot/efi/systemd-bootx64.efi with a custom > command > $ DESTDIR=/tmp/foo meson install --tags sd-boot,sd-stub --no-rebuild > Installing src/boot/efi/systemd-bootx64.efi to > /tmp/foo/usr/lib/systemd/boot/efi > Installing src/boot/efi/linuxx64.elf.stub to > /tmp/foo/usr/lib/systemd/boot/efi > Installing src/boot/efi/linuxx64.efi.stub to > /tmp/foo/usr/lib/systemd/boot/efi > > It should make it easier and more manageable I hope? > Yup, for sure! Being able to avoid compiling all of systemd when just building sd-boot would be really useful! > > > (OBS is awesome :-) ) > > > > > > > Indeed. I run an OBS instance for my workplace, and I've contributed > > to OBS over the years. It has its warts, but I think it got more > > right than wrong in the philosophy of a build system. > > Same at $previous_job, and miss it dearly at $current_job. The way > they've integrated signing EFI binaries for packages is quite nice too > - I contributed some bits and pieces to enable EFI binary signing for > Debian builds too, as it was supported only for RPM before, PoC with > shim + grub + kernel = secure bootable Debian image: > https://build.opensuse.org/project/show/home:bluca:debian_secure_boot > Interesting, I'll have to look at it at some point... -- 真実はいつも一つ！/ Always, there's only one truth!
Re: [systemd-devel] Splitting sd-boot from systemd/bootctl for enabling sd-boot in Fedora
On Wed, Apr 27, 2022 at 11:49 AM Zbigniew Jędrzejewski-Szmek wrote: > > On Wed, Apr 27, 2022 at 11:26:14AM -0400, Neal Gompa wrote: > > On Wed, Apr 27, 2022 at 11:13 AM Zbigniew Jędrzejewski-Szmek > > wrote: > > > > > > On Wed, Apr 27, 2022 at 09:31:10AM -0400, Neal Gompa wrote: > > > > On Wed, Apr 27, 2022 at 7:41 AM Lennart Poettering > > > > wrote: > > > > It is not very friendly when you're in a failure scenario or have to > > > > deal with boot stuff. > > > > > > Well, if you have a boot failure, then a text-based interface is better > > > than a graphical one. I.e. while we might want to make it easier to > > > discover > > > disks and state from sd-boot, I doubt that adding support for icons and > > > themes would be of any help in failure scenarios. > > > > > > > I know it more or less looks like Fedora's GRUB > > > > is configured today, but Fedora is an outlier among Linux > > > > distributions in that it doesn't theme GRUB or provide more > > > > user-friendly boot configure out of the box. I don't like it and I'd > > > > like to change this someday. > > > > > > E.g. the biggest development in how the boot looks in recent years > > > in Fedora has been hiding on the boot menus and boot messages by > > > default. I.e. the _design_ is that you start with the logo of the > > > manufacturer which is seamlessly replaced by the gdm login screen. > > > How the boot menu looks never factors into any of this. > > > > > > > Hiding them by default doesn't mean making them scary and semi-useless > > when you access them. Most people don't access UEFI menus very often, > > if at all, and yet a huge amount of investment went into making that > > UX better than it was in the past. Is it spectacular? No. Is it less > > scary? Absolutely. > > > > Even with rEFInd, I'd probably want to do it that way because the > > point of rEFInd is to make the emergency cases and multiboot cases > > more approachable, not to present it all the time by default. > > > > > > Well, if you're installing and managing EFI binaries (as bootctl > > > > does), you can design a scheme to allow bootctl to know what to do in > > > > those circumstances. > > > > > > > > As a back of the napkin example, say you offer the user three EFI boot > > > > manager options: rEFInd, sd-boot, or GRUB. The distribution may prefer > > > > GRUB, sd-boot, or rEFInd, and define that as a config file for bootctl > > > > to read. But if the user wants to override this choice, they could > > > > pass --bootloader= to the install subcommand. That would write > > > > out a config file in /etc/systemd/boot declaring which bootloader the > > > > user chose as the "default" for future bootctl invocations and allow > > > > the commands to work. > > > > > > --bootloader= sounds like something we can do. OTOH, I agree > > > with what Lennart wrote elsewhere: we don't want to get into the > > > business of fiddling with special files that'd be specific so some > > > bootloader. > > > > > > Currently the update command only does the update if it find sd-boot. > > > We could enhance it to update other installations (if it find matching > > > files under /usr/lib somewhere. (I'd rather make it /usr/lib/boot/, > > > but I think we can talk about directory names later.) > > > > > > > That's more or less what I want. I don't really want bootctl being > > *too* smart. Even for sd-boot, it doesn't do that much, and I'd rather > > keep it that limited. If you need to do fancier bootloader specific > > things, use the appropriate tools. > > > > > > The bootloaders themselves could be stored in > > > > /usr/lib/systemd/boot/efi//, where is the bootloader name > > > > passed to bootctl. It would then know to copy all the files from that > > > > directory into the ESP. > > > > > > > > > > The second problem is because having sd-boot in the systemd source > > > > > > tree means that in order for Fedora to sign the boot manager EFI > > > > > > binaries, we have to lock down the systemd source package to the > > > > > > secure boot Koji build channel. This is unequivocally unacceptable > > > > > > from my point of view, as the restrictions around the secure boot > > > > > > channel make it reali
Re: [systemd-devel] Splitting sd-boot from systemd/bootctl for enabling sd-boot in Fedora
On Wed, Apr 27, 2022 at 11:46 AM Luca Boccassi wrote: > > On Wed, 2022-04-27 at 11:26 -0400, Neal Gompa wrote: > > On Wed, Apr 27, 2022 at 11:13 AM Zbigniew Jędrzejewski-Szmek > > wrote: > > > > > > On Wed, Apr 27, 2022 at 09:31:10AM -0400, Neal Gompa wrote: > > > > On Wed, Apr 27, 2022 at 7:41 AM Lennart Poettering > > > > > > Realistically, I think if we want to make movement on making > > > > > > systemd-boot fully supported in Fedora, the systemd-boot boot > > > > > > manager > > > > > > code itself should be split out into its own repository with its own > > > > > > release cadence, while bootctl(1) and related infrastructure remains > > > > > > in the systemd source tree and evolves to be able to manage > > > > > > arbitrary > > > > > > BLS-conformant boot managers. > > > > > > > > > > Why though? I don't follow? as long as we provide you with a tarball > > > > > you can build your stuff from it shouldn't really matter if there's > > > > > more stuff in it you are not immediately interested in. > > > > > > > > > > I mean, if you like I could do a "cp systemd-251.tar.gz > > > > > systemd-boot-251.tar.gz" for you if you want two tarballs instead of > > > > > one, but I don't see the point? > > > > > > > > > > > > > As I illustrated in another email[5], decoupling the lifecycle of the > > > > EFI boot manager code from the rest of systemd would be ideal to not > > > > make the constraints around building sd-boot with secure boot support > > > > painful. > > > > > > > > [5]: > > > > https://lists.freedesktop.org/archives/systemd-devel/2022-April/047801.html > > > > > > Apart from the constraint who can build official packages, is there > > > anything else? If it's just that, that doesn't seem onerous. > > > > It also means Fedora CI, pull requests from contributors, and > > releng auto-rebuilds will no longer work. Maintainers basically > > sign-on to do all of those things manually and have to be responsive > > for doing it. You will get FTBFS tickets every cycle because of it, > > for example. > > > > Koji doesn't conceptually know the difference because there is no > > namespacing for builders, only who is approved to build. > > > > (In contrast, in the Open Build Service like what Luca Boccassi was > > talking about, packagers don't control the builds at all, so OBS only > > has to trust itself to sign it, so everything works properly.) > > You could simply have a separate source RPM, no? That should be pretty > simple, and limit the impact on team maintenance of the main source > package? > Yep. I was hoping we could have the upstream sources split too, but if we can't, then that's definitely the preferred way to go. > (OBS is awesome :-) ) > Indeed. I run an OBS instance for my workplace, and I've contributed to OBS over the years. It has its warts, but I think it got more right than wrong in the philosophy of a build system. -- 真実はいつも一つ！/ Always, there's only one truth!
Re: [systemd-devel] Splitting sd-boot from systemd/bootctl for enabling sd-boot in Fedora
On Wed, Apr 27, 2022 at 11:26 AM Dan Nicholson wrote: > > On Wed, Apr 27, 2022 at 9:10 AM Neal Gompa wrote: > > > > Note that it means Fedora CI, pull requests from contributors, and > > releng auto-rebuilds will no longer work. Maintainers basically > > sign-on to do all of those things manually and have to be responsive > > for doing it. You will get FTBFS tickets every cycle because of it, > > for example. > > Asking systemd folks to change their development process because of > limitations in Fedora/Koji seems like a big ask, don't you think? Honestly, that never factors in for me, because then I'd never ask anything of anyone. :) But no, it doesn't sound unreasonable to me, because I reasonably expect the parts that make up the EFI boot manager code to be somewhat separate from the rest of the codebase in the first place. It targets a different build environment and has to be built differently from the rest of systemd anyway. So to me, it's not a "big ask" as you put it. But I'm also not demanding anything. I'm *asking*. If you don't want to do it, then that's fine. I only very occasionally help out with systemd in Fedora, and mostly deal with systemd in other distributions (CentOS Stream, etc.). I used to help with dracut and systemd maintenance in Mageia, so I'm familiar with the source structures. And I've contributed to systemd before, as well. I don't help more with systemd in Fedora because the packaging is pretty difficult for me to understand. If I did, I'd probably help out more. > Having implemented UEFI secure boot signing for Endless, I can concur > it is a PITA. However, there are certainly ways to make it work that > have no effect on upstream. Our Endless system is pretty hacky, but > Debian's is pretty well thought out. What both have in common is that > the signer generates a separate package so that the normal build flow > isn't affected. In the case of systemd, there would be both an > unsigned and signed version of the sd-boot EFI program in separate > packages. > > I'm sure it would require work to fix, but this seems like more of a > Koji problem than a systemd problem. I also feel like Lennart's > suggestion that sd-boot get split out as a separate source package but > using the same tarball is completely reasonable if your signing system > is too onerous to use. > It's definitely problems with both. I agree that a chunk of this is Koji's problem. I spent two years doing research on this topic because I was working on kernel, kmod, and bootloader builds and discovered how terrible it is and how nobody wants to improve it. My saltiness about the whole affair is pretty evident in the Fedora discussion about discontinuing BIOS support (and was even in an LWN article, apparently!). The Open Build Service is the only build system I know of that avoids this problem by totally removing the packager's ability to control builds *entirely*. They don't get to choose how the Release field works, they don't get to choose when builds are made, and they don't get to choose when builds are released. That's all entirely under the control of the build system, which does its own decision-making by constantly tracking the repoclosure state of the repository. Since no humans are involved, everyone is equally happy and unhappy. :) But I also strongly believe that it was a mistake to merge gummiboot into the systemd source tree because it creates all kinds of problems for distro maintenance, as I've already said earlier. It also discourages making the sd-boot code tighter and simpler since your primary focus is reuse across the tree rather than strictly separating the functional domains. -- 真実はいつも一つ！/ Always, there's only one truth!
Re: [systemd-devel] Splitting sd-boot from systemd/bootctl for enabling sd-boot in Fedora
On Wed, Apr 27, 2022 at 11:13 AM Zbigniew Jędrzejewski-Szmek wrote: > > On Wed, Apr 27, 2022 at 09:31:10AM -0400, Neal Gompa wrote: > > On Wed, Apr 27, 2022 at 7:41 AM Lennart Poettering > > wrote: > > It is not very friendly when you're in a failure scenario or have to > > deal with boot stuff. > > Well, if you have a boot failure, then a text-based interface is better > than a graphical one. I.e. while we might want to make it easier to discover > disks and state from sd-boot, I doubt that adding support for icons and > themes would be of any help in failure scenarios. > > > I know it more or less looks like Fedora's GRUB > > is configured today, but Fedora is an outlier among Linux > > distributions in that it doesn't theme GRUB or provide more > > user-friendly boot configure out of the box. I don't like it and I'd > > like to change this someday. > > E.g. the biggest development in how the boot looks in recent years > in Fedora has been hiding on the boot menus and boot messages by > default. I.e. the _design_ is that you start with the logo of the > manufacturer which is seamlessly replaced by the gdm login screen. > How the boot menu looks never factors into any of this. > Hiding them by default doesn't mean making them scary and semi-useless when you access them. Most people don't access UEFI menus very often, if at all, and yet a huge amount of investment went into making that UX better than it was in the past. Is it spectacular? No. Is it less scary? Absolutely. Even with rEFInd, I'd probably want to do it that way because the point of rEFInd is to make the emergency cases and multiboot cases more approachable, not to present it all the time by default. > > Well, if you're installing and managing EFI binaries (as bootctl > > does), you can design a scheme to allow bootctl to know what to do in > > those circumstances. > > > > As a back of the napkin example, say you offer the user three EFI boot > > manager options: rEFInd, sd-boot, or GRUB. The distribution may prefer > > GRUB, sd-boot, or rEFInd, and define that as a config file for bootctl > > to read. But if the user wants to override this choice, they could > > pass --bootloader= to the install subcommand. That would write > > out a config file in /etc/systemd/boot declaring which bootloader the > > user chose as the "default" for future bootctl invocations and allow > > the commands to work. > > --bootloader= sounds like something we can do. OTOH, I agree > with what Lennart wrote elsewhere: we don't want to get into the > business of fiddling with special files that'd be specific so some > bootloader. > > Currently the update command only does the update if it find sd-boot. > We could enhance it to update other installations (if it find matching > files under /usr/lib somewhere. (I'd rather make it /usr/lib/boot/, > but I think we can talk about directory names later.) > That's more or less what I want. I don't really want bootctl being *too* smart. Even for sd-boot, it doesn't do that much, and I'd rather keep it that limited. If you need to do fancier bootloader specific things, use the appropriate tools. > > The bootloaders themselves could be stored in > > /usr/lib/systemd/boot/efi//, where is the bootloader name > > passed to bootctl. It would then know to copy all the files from that > > directory into the ESP. > > > > > > The second problem is because having sd-boot in the systemd source > > > > tree means that in order for Fedora to sign the boot manager EFI > > > > binaries, we have to lock down the systemd source package to the > > > > secure boot Koji build channel. This is unequivocally unacceptable > > > > from my point of view, as the restrictions around the secure boot > > > > channel make it realistically impossible for community contribution > > > > and maintenance of the package. > > > > > > I don't follow. Where's the problem using the same source package for > > > two independently built RPM packages? > > > > > > If Fedora wants to build systemd userspace packages one way, and > > > systemd-boot another way, that's entirely fine actually. they can just > > > do that… > > > > > > > Realistically, I think if we want to make movement on making > > > > systemd-boot fully supported in Fedora, the systemd-boot boot manager > > > > code itself should be split out into its own repository with its own > > > > release cadence, while bootctl(1) and related infrastructure remains > > > > in the systemd source tree and evolves to be able to manage arbitrary > &
Re: [systemd-devel] Splitting sd-boot from systemd/bootctl for enabling sd-boot in Fedora
On Wed, Apr 27, 2022 at 10:13 AM Zbigniew Jędrzejewski-Szmek
wrote:
>
> On Wed, Apr 27, 2022 at 08:55:55AM -0400, Neal Gompa wrote:
> > On Wed, Apr 27, 2022 at 6:47 AM Zbigniew Jędrzejewski-Szmek
> > wrote:
> > >
> > > On Tue, Apr 26, 2022 at 07:12:02PM -0400, Neal Gompa wrote:
> > > > Hey all,
> > >
> > > Hi Neal,
> > >
> > > thank you for starting the discussion. I think it'd be good to figure
> > > out what are the high-level options we have as a community…
> > >
> > > > Some of you might know about the recent discussion in Fedora about
> > > > dropping BIOS support[1][2]. While the end result for now is that
> > > > we're not dropping it[3], several side discussions involved enabling
> > > > systemd-boot as an option in Fedora in the future.
> > > >
> > > > While I *personally* am not a huge fan of systemd-boot itself
> > >
> > > You mentioned that a few times, and we (at least Lennnart and I) have
> > > asked for details. If there's something important missing from sd-boot,
> > > we would like to know.
> > >
> >
> > I think this is probably a distraction from this discussion, but sure
> > I guess I can answer: I fundamentally dislike systemd-boot because I
> > feel it's not a very user-friendly boot manager because of its
> > absolutely spartan interface. I'm much more of a fan of rEFInd[1],
> > which provides a feature-rich and user-friendly EFI boot manager[2].
>
> Ah, icons and graphics ;) Yeah, we don't provide that, and I don't think
> there are any plans to work on this. Instead of trying to make the menu
> better, we can follow the example of windows: integrate the boot menu
> directly in the graphical environment. We already have command-line access
> to this: bootctl reboot-to-firmware, bootctl set-oneshot,
> systemctl reboot --boot-loader-entry=. With a little bit of integration
> users should be able to select the system / kernel to boot directly
> from the reboot dialogue.
>
Windows also provides a functioning graphical boot manager since at
least Windows 10.
> Rebooting from the DE has advantages: nice UI without much work, l10n,
> accessibility, help, integration with normal auth mechanisms (e.g. polkit
> auth for non-default boot entries or firmware setup), no need to
> fiddle with pressing keys at the exactly right time.
>
It also has a major downside that in the event the OS doesn't boot,
you don't have a friendly way to do recovery. Nowadays both Windows
and macOS provide graphical boot managers and graphical
tools/environments for recovery. These are both things I want in
Fedora as well.
> > Essentially, the Koji build channel for secure boot is made up of three
> > things:
>
> [snip]
>
> Thanks for the description. If the limitation that only RH folks can
> build the official package is true, it'd be annoying, but not such a big
> issue. In the recent times, I made the most builds, with Adam Williamson
> and Yu Watanabe also doing an occasional build, i.e. all RH employees. It
> is important that people can do pull requests for dist-git, but limiting the
> offical builds to a few people wouldn't be a big issue. (Don't get me wrong:
> I would prefer to keep the current state where a bunch of maintainer *and*
> any proven packager or relengee can build systemd, but in practice it doesn't
> happen much.)
>
> > For sd-boot, it'd be making sure the package is "ExclusiveArch:
> > %{efi}", then in %install, you'd do:
> >
> > pushd %{buildroot}%{_prefix}/lib/systemd/boot/efi
> > %pesign -s -i systemd-boot%{efi_arch}.efi -o
> > systemd-boot%{efi_arch}.efi.signed
> > popd
>
> https://src.fedoraproject.org/rpms/systemd/pull-request/77
> does the deed. PTAL. (Though it just conditionalized the build on
> %ifarch %efi, instead of limiting where the package is built. In mock
> this produces an additional .signed thingy that 'bootctl update'
> should pick up automatically.)
>
Note that it means Fedora CI, pull requests from contributors, and
releng auto-rebuilds will no longer work. Maintainers basically
sign-on to do all of those things manually and have to be responsive
for doing it. You will get FTBFS tickets every cycle because of it,
for example.
--
真実はいつも一つ！/ Always, there's only one truth!
Re: [systemd-devel] Splitting sd-boot from systemd/bootctl for enabling sd-boot in Fedora
On Wed, Apr 27, 2022 at 9:31 AM Lennart Poettering wrote: > > On Mi, 27.04.22 08:55, Neal Gompa (ngomp...@gmail.com) wrote: > > > > You mentioned that a few times, and we (at least Lennnart and I) have > > > asked for details. If there's something important missing from sd-boot, > > > we would like to know. > > > > I think this is probably a distraction from this discussion, but sure > > I guess I can answer: I fundamentally dislike systemd-boot because I > > feel it's not a very user-friendly boot manager because of its > > absolutely spartan interface. I'm much more of a fan of rEFInd[1], > > which provides a feature-rich and user-friendly EFI boot manager[2]. > > Dunno. sd-boot UI was originally based on GNOME designers > ideas. It's a simple UI doing exactly what is needed, that's how > designs really should be I believe. Minimal, effective, and given this > is low-level nerd stuff that people should normally never see I think > that's already way above what is actually needed. > > I personally find the refind UI (judging by the screenshots) > stylistically problematic, but I'll certainly accept that other people > have other tastes on that... > > So, ignoring how precisely it looks, what exactly is the > "feature-rich" stuff that you prefer you appear to indicate that > exists? > > To be frank, it seems to not actually bring much to the table that > might be interesting from a modern Linux userspace perspective, > i.e. doesn't implement boot laoder spec or boot loader interface, no > boot counting, no random seed stuff, no certificate enrolling, no tpm > measurement stuff, no devicetree loading, and so on. Functionalitywise > it appears to be quite a step back from both sd-boot and in fact > grub. I'd really prefer if we'd not complicate the boot loader > question further, by throwing even more half-baked options into the > mix. I mean, it's fine if this is an option, but more? > Can anything actually *use* that stuff today? Like those are all nice things to have, but as you've mentioned on the Fedora mailing lists before, most of those things don't work or provide anything in the OS because no enablement has been done there. But this is pretty much why I didn't want to talk about this, because it diverts from the point I was trying to make around enabling sd-boot as an option. > > > > The first problem is mostly because I think bootctl(1) is a fantastic > > > > interface to manage *any* Bootloader Spec[4] (BLS) conformant boot > > > > manager, and I would love for that tool to be useful for doing so. > > > > Being able to do things like install/upgrade/swap GRUB 2, > > > > systemd-boot, or any other registered BLS-enabled boot manager would > > > > make it tremendously useful and valuable as a "building block" tool. I > > > > feel it would make sense to offer some kind of configuration to teach > > > > bootctl(1) about these boot managers so that it can work for them, and > > > > not just systemd-boot. > > > > > > bootctl could be taught to install other EFI stuff. It'd probably be a > > > matter of specifying a different glob when looking for files to copy. > > > I'm not sure if we want to get into the business of installing non-EFI > > > stuff… What exactly do you have in mind? > > > > I'm purely talking about EFI boot managers. I would like bootctl(1) to > > be able to lifecycle any BLS-conformant EFI boot manager. > > I think this is unrealistic to be frank. Ignoring this refind thing > (which I have not much clue about), for grub installation is a lot more > complex than just dropping a bunch of files+dirs into the ESP. They > have stages, partitions, boot scripts that need to be generated. I > think the complexities this involves is a major problem, and certainly > not something we should make *our* problem. > At least in Fedora's grub2 (which is BLS-enabled), this doesn't apply. All of that is static and we just use BLS snippets. My understanding is that it *will* be upstreamed, but getting it upstreamed is slow since the Red Hat grub2 patch set is *huge* and there's not enough reviewers to go through and get patches into the tree. And that means there are already two implementations. And there could be more in the future. -- 真実はいつも一つ！/ Always, there's only one truth!
Re: [systemd-devel] Splitting sd-boot from systemd/bootctl for enabling sd-boot in Fedora
On Wed, Apr 27, 2022 at 7:41 AM Lennart Poettering
wrote:
>
> On Di, 26.04.22 19:12, Neal Gompa (ngomp...@gmail.com) wrote:
>
> > Hey all,
> >
> > Some of you might know about the recent discussion in Fedora about
> > dropping BIOS support[1][2]. While the end result for now is that
> > we're not dropping it[3], several side discussions involved enabling
> > systemd-boot as an option in Fedora in the future.
> >
> > While I *personally* am not a huge fan of systemd-boot itself, I
> > *am*
>
> I asked this elsewhere already, without getting a reply: why aren't
> you though? Can you elaborate on what crucial thing you are missing?
>
It is not very friendly when you're in a failure scenario or have to
deal with boot stuff. I know it more or less looks like Fedora's GRUB
is configured today, but Fedora is an outlier among Linux
distributions in that it doesn't theme GRUB or provide more
user-friendly boot configure out of the box. I don't like it and I'd
like to change this someday.
Eventually, I'd like to have a comparable experience to Windows or
macOS on Fedora, and I just don't see that happening with systemd-boot
as it stands today.
I'm a fan of rEFInd[1], which provides a feature-rich and
user-friendly EFI boot manager[2] that I feel can offer that
experience. It even supports the Discoverable Partitions Spec[3], and
I hope that they'll support the Boot Loader Spec[4] eventually.
[1]: https://www.rodsbooks.com/refind/
[2]: https://www.rodsbooks.com/refind/features.html
[3]: https://systemd.io/DISCOVERABLE_PARTITIONS/
[4]: https://systemd.io/BOOT_LOADER_SPECIFICATION/
> > * bootctl(1) appears to be tightly coupled to sd-boot
>
> Well, kinda. But also not. So if you type "bootctl --help" then you'll
> see three sections of commands. The last section "systemd-boot
> Commands" shows commands that only really make sense for systemd-boot
> as they install/remove/update the boot loader itself. They are the
> only things inherently tied to sd-boot.
>
> The other two sections are useful outside of sd-boot: the first
> section ("Generic EFI Firmware/Boot Loader Commands") is useful on any
> kind of UEFI section, the second section ("Boot Loader Specification
> Commands") on all boot loaders that implement the (upstream) boot loader
> spec/boot loader interface, as documented.
>
> Note though that at this point grub does not implement either of the
> specs properly, or has any upstream work in that area to my
> knowledge.
>
> > The first problem is mostly because I think bootctl(1) is a fantastic
> > interface to manage *any* Bootloader Spec[4] (BLS) conformant boot
> > manager, and I would love for that tool to be useful for doing so.
> > Being able to do things like install/upgrade/swap GRUB 2,
> > systemd-boot, or any other registered BLS-enabled boot manager would
> > make it tremendously useful and valuable as a "building block" tool.
>
> As mentioned the commands in the first two sections of the --help
> blurb should work just fine with other loaders, and the reason the
> sections exist in the --help text is to help making this clear.
>
> > I feel it would make sense to offer some kind of configuration to
> > teach bootctl(1) about these boot managers so that it can work for
> > them, and not just systemd-boot.
>
> So the commands in the first two sections already should work with any
> boot loader implementing these specs. I am pretty sure that bootctl
> should not be adjusted to specific boot loaders needleslly, instead
> the bootloaders should just implement the specs...
>
> Implementing the specs after all is not something that just is
> relevant for bootctl only. After all there's a lot of hookup to the
> two specs in logind too (for example, reboot into Windows, reboot into
> boot loader entry xyz, and so on), or in the kexec-based reboot
> functionality. And a lot of other stuff as well…
>
> So we kept these things reasonably generic via making this specs so
> that any other boot loader can be plugged in there. But I think real
> interest in adding support for the specs in those other boot loaders
> appears to be minimal unfortunately.
>
> Note that the commands in the last section of the "bootctl --help"
> text are something we never can make generic really. They are
> specifically about installing sd-boot in the ESP, I see no avenue
> about making this a grub installer, sorry...
>
Well, if you're installing and managing EFI binaries (as bootctl
does), you can design a scheme to allow bootctl to know what to do in
those circumstances.
As a back of the napkin example, say you offer the user three EFI boot
manager options: rEFInd, sd-boot, or GRUB. The distribution m
Re: [systemd-devel] Splitting sd-boot from systemd/bootctl for enabling sd-boot in Fedora
On Wed, Apr 27, 2022 at 8:55 AM Neal Gompa wrote: > > On Wed, Apr 27, 2022 at 6:47 AM Zbigniew Jędrzejewski-Szmek > wrote: > > > > On Tue, Apr 26, 2022 at 07:12:02PM -0400, Neal Gompa wrote: > > > Hey all, > > > > Hi Neal, > > > > thank you for starting the discussion. I think it'd be good to figure > > out what are the high-level options we have as a community… > > > > > Some of you might know about the recent discussion in Fedora about > > > dropping BIOS support[1][2]. While the end result for now is that > > > we're not dropping it[3], several side discussions involved enabling > > > systemd-boot as an option in Fedora in the future. > > > > > > While I *personally* am not a huge fan of systemd-boot itself > > > > You mentioned that a few times, and we (at least Lennnart and I) have > > asked for details. If there's something important missing from sd-boot, > > we would like to know. > > > > I think this is probably a distraction from this discussion, but sure > I guess I can answer: I fundamentally dislike systemd-boot because I > feel it's not a very user-friendly boot manager because of its > absolutely spartan interface. I'm much more of a fan of rEFInd[1], > which provides a feature-rich and user-friendly EFI boot manager[2]. > > While I get the idea that people shouldn't spend a lot of time at the > boot menu, it's very clear that other platforms (Windows and macOS) > spend a great deal of time making their boot environments friendly and > useful so that when they have to be there, it's not a bad place. I > like having the same for my Linux environments too. > > I use rEFInd on my MacBooks running Fedora Linux and I really like it. > A couple of other Linux distributions have also adopted rEFInd as an > option (notably Mageia did). One of the things I'd like to have as a > positive outcome from this would be to have the infrastructure in > place to make it appealing for rEFInd to support the Bootloader > Spec[3] in addition to the Discoverable Partition Spec[4] it already > supports today. > > [1]: https://www.rodsbooks.com/refind > [2]: https://www.rodsbooks.com/refind/features.html > [3]: https://systemd.io/BOOT_LOADER_SPECIFICATION/ > [4]: https://systemd.io/DISCOVERABLE_PARTITIONS/ > > > > I *am* a fan of a lot of the mechanisms around it, and I think it > > > would be valuable for us to adopt more of that in Fedora. To that > > > end, that means making it easier for people to fully adopt > > > systemd-boot on their systems in Fedora with minimal effort (ideally > > > just a kickstart or Anaconda flag if desired). > > > > Yeah. While I don't think we're ready to propose it as the default, > > we definitely would like it to be trivial to switch to it if somebody > > wants to. > > > > > From my point of view as someone working on several Fedora variants > > > and would like to provide more optionality around this, there are a > > > couple of issues: > > > > > > * bootctl(1) appears to be tightly coupled to sd-boot > > > > This is a misunderstanding of the our development goals of systemd > > (the project) and sd-boot. As far as possible, generic interfaces are used. > > > > Starting from the bottom: the boot loader specification is designed > > to be completely generic and independent of the boot loader and independent > > of the userspace tools used to configure the boot loader. Similarly, > > most bootctl commands are implemented using generic functionality > > (either EFI or any bootloader implementing the boot loader specification). > > And stuff like 'bootctl status' and 'systemd-analyze blame' use interfaces > > that are completely generic and any bootload can provide the appropriate > > information to the operating system (see > > https://systemd.io/BOOT_LOADER_INTERFACE/). > > So bootctl is NOT coupled to sd-boot, except for some specific parts > > explicitly documented to be about sd-boot, currently the > > install/update/uninstall verbs and random-seed support. > > > > > * sd-boot is part of the systemd source tree > > > > > > The first problem is mostly because I think bootctl(1) is a fantastic > > > interface to manage *any* Bootloader Spec[4] (BLS) conformant boot > > > manager, and I would love for that tool to be useful for doing so. > > > Being able to do things like install/upgrade/swap GRUB 2, > > > systemd-boot, or any other registered BLS-enabled boot manager would > > > make it tremendously useful and valuable as a "building block" tool.
Re: [systemd-devel] Splitting sd-boot from systemd/bootctl for enabling sd-boot in Fedora
On Wed, Apr 27, 2022 at 6:47 AM Zbigniew Jędrzejewski-Szmek wrote: > > On Tue, Apr 26, 2022 at 07:12:02PM -0400, Neal Gompa wrote: > > Hey all, > > Hi Neal, > > thank you for starting the discussion. I think it'd be good to figure > out what are the high-level options we have as a community… > > > Some of you might know about the recent discussion in Fedora about > > dropping BIOS support[1][2]. While the end result for now is that > > we're not dropping it[3], several side discussions involved enabling > > systemd-boot as an option in Fedora in the future. > > > > While I *personally* am not a huge fan of systemd-boot itself > > You mentioned that a few times, and we (at least Lennnart and I) have > asked for details. If there's something important missing from sd-boot, > we would like to know. > I think this is probably a distraction from this discussion, but sure I guess I can answer: I fundamentally dislike systemd-boot because I feel it's not a very user-friendly boot manager because of its absolutely spartan interface. I'm much more of a fan of rEFInd[1], which provides a feature-rich and user-friendly EFI boot manager[2]. While I get the idea that people shouldn't spend a lot of time at the boot menu, it's very clear that other platforms (Windows and macOS) spend a great deal of time making their boot environments friendly and useful so that when they have to be there, it's not a bad place. I like having the same for my Linux environments too. I use rEFInd on my MacBooks running Fedora Linux and I really like it. A couple of other Linux distributions have also adopted rEFInd as an option (notably Mageia did). One of the things I'd like to have as a positive outcome from this would be to have the infrastructure in place to make it appealing for rEFInd to support the Bootloader Spec[3] in addition to the Discoverable Partition Spec[4] it already supports today. [1]: https://www.rodsbooks.com/refind [2]: https://www.rodsbooks.com/refind/features.html [3]: https://systemd.io/BOOT_LOADER_SPECIFICATION/ [4]: https://systemd.io/DISCOVERABLE_PARTITIONS/ > > I *am* a fan of a lot of the mechanisms around it, and I think it > > would be valuable for us to adopt more of that in Fedora. To that > > end, that means making it easier for people to fully adopt > > systemd-boot on their systems in Fedora with minimal effort (ideally > > just a kickstart or Anaconda flag if desired). > > Yeah. While I don't think we're ready to propose it as the default, > we definitely would like it to be trivial to switch to it if somebody > wants to. > > > From my point of view as someone working on several Fedora variants > > and would like to provide more optionality around this, there are a > > couple of issues: > > > > * bootctl(1) appears to be tightly coupled to sd-boot > > This is a misunderstanding of the our development goals of systemd > (the project) and sd-boot. As far as possible, generic interfaces are used. > > Starting from the bottom: the boot loader specification is designed > to be completely generic and independent of the boot loader and independent > of the userspace tools used to configure the boot loader. Similarly, > most bootctl commands are implemented using generic functionality > (either EFI or any bootloader implementing the boot loader specification). > And stuff like 'bootctl status' and 'systemd-analyze blame' use interfaces > that are completely generic and any bootload can provide the appropriate > information to the operating system (see > https://systemd.io/BOOT_LOADER_INTERFACE/). > So bootctl is NOT coupled to sd-boot, except for some specific parts > explicitly documented to be about sd-boot, currently the > install/update/uninstall verbs and random-seed support. > > > * sd-boot is part of the systemd source tree > > > > The first problem is mostly because I think bootctl(1) is a fantastic > > interface to manage *any* Bootloader Spec[4] (BLS) conformant boot > > manager, and I would love for that tool to be useful for doing so. > > Being able to do things like install/upgrade/swap GRUB 2, > > systemd-boot, or any other registered BLS-enabled boot manager would > > make it tremendously useful and valuable as a "building block" tool. I > > feel it would make sense to offer some kind of configuration to teach > > bootctl(1) about these boot managers so that it can work for them, and > > not just systemd-boot. > > bootctl could be taught to install other EFI stuff. It'd probably be a > matter of specifying a different glob when looking for files to copy. > I'm not sure if we want to get into the business of installing non-EFI > stuff… What exactly do you have in mind? > I'm purely talk
[systemd-devel] Splitting sd-boot from systemd/bootctl for enabling sd-boot in Fedora
Hey all, Some of you might know about the recent discussion in Fedora about dropping BIOS support[1][2]. While the end result for now is that we're not dropping it[3], several side discussions involved enabling systemd-boot as an option in Fedora in the future. While I *personally* am not a huge fan of systemd-boot itself, I *am* a fan of a lot of the mechanisms around it, and I think it would be valuable for us to adopt more of that in Fedora. To that end, that means making it easier for people to fully adopt systemd-boot on their systems in Fedora with minimal effort (ideally just a kickstart or Anaconda flag if desired). >From my point of view as someone working on several Fedora variants and would like to provide more optionality around this, there are a couple of issues: * bootctl(1) appears to be tightly coupled to sd-boot * sd-boot is part of the systemd source tree The first problem is mostly because I think bootctl(1) is a fantastic interface to manage *any* Bootloader Spec[4] (BLS) conformant boot manager, and I would love for that tool to be useful for doing so. Being able to do things like install/upgrade/swap GRUB 2, systemd-boot, or any other registered BLS-enabled boot manager would make it tremendously useful and valuable as a "building block" tool. I feel it would make sense to offer some kind of configuration to teach bootctl(1) about these boot managers so that it can work for them, and not just systemd-boot. The second problem is because having sd-boot in the systemd source tree means that in order for Fedora to sign the boot manager EFI binaries, we have to lock down the systemd source package to the secure boot Koji build channel. This is unequivocally unacceptable from my point of view, as the restrictions around the secure boot channel make it realistically impossible for community contribution and maintenance of the package. Realistically, I think if we want to make movement on making systemd-boot fully supported in Fedora, the systemd-boot boot manager code itself should be split out into its own repository with its own release cadence, while bootctl(1) and related infrastructure remains in the systemd source tree and evolves to be able to manage arbitrary BLS-conformant boot managers. This would also (hopefully) encourage other boot managers to support the Bootloader Spec configuration model, making it succeed as a semi-universal abstraction for boot manager configuration. We could then teach our tooling in Fedora to interact with bootctl(1) to do bootloader things, rather than having to create multiple tools and scripts to deal with this. The alternative, of course, is to build sd-boot by having a second source package of the systemd code and setting it up to only build the boot stuff. This is painful for a variety of reasons: it guarantees we need to have some kind of synchronization point to ensure fixes and improvements are carried between the two. It is more work from a maintenance perspective (especially around security stuff), and it doesn't really help with pushing the adoption of the Bootloader Spec as a whole. What do you all think? Best regards, Neal [1]: https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/thread/K5YKCQU3YVCTMSBHLP4AOQWIE3AHWCKC/ [2]: https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/thread/JUJV6BEJAXK5LATTSWGRFZDIAVM7KN4J/ [3]: https://pagure.io/fesco/issue/2780#comment-794311 [4]: https://systemd.io/BOOT_LOADER_SPECIFICATION/ -- 真実はいつも一つ！/ Always, there's only one truth!
Re: [systemd-devel] Antw: Re: Antw: [EXT] Dropping split-usr/unmerged-usr support
On Thu, Apr 7, 2022 at 3:45 AM Ulrich Windl
wrote:
>
> >>> Wols Lists schrieb am 06.04.2022 um 21:41 in
> Nachricht :
> > On 06/04/2022 10:34, Luca Boccassi wrote:
> >>> Symlinking /sbin or /usr/sbin binaries to /usr is also a bad concept
> >>> IMHO.
> >>>
> >>> It seems systemd is the new Microsoft ("We know what is good for you;
> >>> just accept it!");-)
> >
> > Well, I saw a link to WHY we have /bin, /usr/bin, /sbin etc. Interesting
> > read ...
> >
> > / was disk0. /usr was apparently originally short for /user, on disk1.
> > Then the system disk ran out of space, so they created /usr/bin to have
> > more space. So when they got a 3rd disk, they called it /home and moved
> > all the user directories across ...
>
> However space is not the only reason: Back in the times of non-journaling
> filesystems (and slow disks where a fsck could take 40 minutes or more) it
> was highly desirable to have a small root filesystem that could be checked
> quickly, to root had the chance to become active.
> Even today when something bad happens, one would probably prefer to have
> multiple smaller filesystems to repair rather than one "huge pot". MHO.
> Agreed Windows users who only know C: never wasted much thoughts on
> structure; see the mess in C:\Windows. But I thought UNIX was highly
> structured...
>
On the contrary, Windows has been much more organized than UNIX has
been. In the C:\ hierarchy, the "Windows" directory contains all the
resources to run Windows itself. System-wide applications are all in
"Program Files", and user data is in "Users". Those three directories
form the core of the Windows experience. There are obviously more
directories, but those three are essential for Windows itself. And if
you don't need any applications (just the base Windows OS), then you
can get away with just C:\Windows.
UNIX, meanwhile, didn't have an opportunity to be thoughtful
about how the hierarchy worked. Things got stuffed in where they could
based on the size of diskettes and what could be held in memory. The
fact that /usr doesn't actually represent where user data is proves
it. "Unix System Resources" is a backronym to attempt to deal with the
mistake of not renaming the directory when it evolved away from
holding user data. The Unix hierarchy is *full* of mistakes and
post-rationalizations ideally would be fixed someday but probably
won't be.
--
真実はいつも一つ！/ Always, there's only one truth!
Re: [systemd-devel] Antw: [EXT] Dropping split-usr/unmerged-usr support
On Wed, Apr 6, 2022 at 8:07 AM Luca Boccassi wrote:
>
> On Wed, 2022-04-06 at 06:51 -0400, Neal Gompa wrote:
> > On Wed, Apr 6, 2022 at 6:45 AM Luca Boccassi
> > wrote:
> > >
> > > On Wed, 2022-04-06 at 08:05 +0200, Ulrich Windl wrote:
> > > > > > > Luca Boccassi schrieb am 05.04.2022
> > > > > > > um 22:07 in
> > > > Nachricht <05cf10d04274dcbff07fed88e98dca2eebb24b7d.ca...@gmail.com>:
> > > > > Hi,
> > > > >
> > > > > As part of our spring cleaning effort, we are considering when to
> > > > > drop
> > > > > support for split/unmerged-usr filesystem layouts.
> > > > >
> > > > > A build-time warning was added last year:
> > > > >
> > > > > https://github.com/systemd/systemd/commit/9afd5e7b975e8051c011ff9c07c95e80bd
> > > > > 954469
> > > >
> > > > Honestly to me the requirement that /usr be part of the root
> > > > filesystem never had a reasonable argument.
> > > > Instead I think systemd quit the concept of a simple scaled-down
> > > > subset to bring up the system.
> > > > Also with initrd/dracut the concept is even more odd, because the
> > > > /usr found there is just some arbitrary subset of the real /usr
> > > > (similar for other filesystems).
> > > > So why couldn't that work with a really scaled-down /sbin?
> > > >
> > > > >
> > > > > We are now adding a runtime taint as well.
> > > > >
> > > > > Which distributions are left running with systemd on a
> > > > > split/unmerged-
> > > > > usr system?
> > > > >
> > > > > (reminder: we refer to a system that boots without a populated /usr
> > > > > as
> > > > > split-usr, and a system where bin, sbin and lib* are not symlinks
> > > > > to
> > > > > their counterparts under /usr as unmerged-usr)
> > > >
> > > > Symlinking /sbin or /usr/sbin binaries to /usr is also a bad concept
> > > > IMHO.
> > > >
> > > > It seems systemd is the new Microsoft ("We know what is good for you;
> > > > just accept it!") ;-)
> > > >
> > > > Regards,
> > > > Ulrich
> > >
> > > Sorry, but you are about ~10 years late to this debate :-) The question
> > > today is not whether it's good or bad, but who's left to do the switch.
> > >
> > > We know Fedora/RHEL/CentOS/SUSE/Arch/Ubuntu have done the switch, and
> > > presumably any of their derivatives.
> > >
> > > We know Debian is, er, working on it, as per the most recent article on
> > > LWN.
> > >
> >
> > Debian is expected to complete this with Debian 12, I believe.
>
> Yeah it's, uhm, complicated :-) Working on it...
>
> > > What about other distros that are not derivatives of the aboves and
> > > that use systemd? Does anybody have any insight?
> > >
> >
> > OpenMandriva and Yocto both haven't done the switch yet, as far as I'm
> > aware. Might be worth reaching out to them and finding out when
> > they're going to do it.
>
> Thanks, I'm not familiar with OpenMandriva at all, is anyone here? Any
> pointers on where to reach out to?
>
You could try filing an issue here:
https://github.com/OpenMandrivaAssociation/distribution
Alternatively, I believe Bernhard Rosenkraenzer (berolinux on GitHub)
is someone to reach out to. He does a lot of OpenMandriva
architectural work.
--
真実はいつも一つ！/ Always, there's only one truth!
Re: [systemd-devel] Antw: [EXT] Dropping split-usr/unmerged-usr support
On Wed, Apr 6, 2022 at 6:45 AM Luca Boccassi wrote:
>
> On Wed, 2022-04-06 at 08:05 +0200, Ulrich Windl wrote:
> > > > > Luca Boccassi schrieb am 05.04.2022
> > > > > um 22:07 in
> > Nachricht <05cf10d04274dcbff07fed88e98dca2eebb24b7d.ca...@gmail.com>:
> > > Hi,
> > >
> > > As part of our spring cleaning effort, we are considering when to
> > > drop
> > > support for split/unmerged-usr filesystem layouts.
> > >
> > > A build-time warning was added last year:
> > >
> > > https://github.com/systemd/systemd/commit/9afd5e7b975e8051c011ff9c07c95e80bd
> > > 954469
> >
> > Honestly to me the requirement that /usr be part of the root
> > filesystem never had a reasonable argument.
> > Instead I think systemd quit the concept of a simple scaled-down
> > subset to bring up the system.
> > Also with initrd/dracut the concept is even more odd, because the
> > /usr found there is just some arbitrary subset of the real /usr
> > (similar for other filesystems).
> > So why couldn't that work with a really scaled-down /sbin?
> >
> > >
> > > We are now adding a runtime taint as well.
> > >
> > > Which distributions are left running with systemd on a
> > > split/unmerged-
> > > usr system?
> > >
> > > (reminder: we refer to a system that boots without a populated /usr
> > > as
> > > split-usr, and a system where bin, sbin and lib* are not symlinks
> > > to
> > > their counterparts under /usr as unmerged-usr)
> >
> > Symlinking /sbin or /usr/sbin binaries to /usr is also a bad concept
> > IMHO.
> >
> > It seems systemd is the new Microsoft ("We know what is good for you;
> > just accept it!") ;-)
> >
> > Regards,
> > Ulrich
>
> Sorry, but you are about ~10 years late to this debate :-) The question
> today is not whether it's good or bad, but who's left to do the switch.
>
> We know Fedora/RHEL/CentOS/SUSE/Arch/Ubuntu have done the switch, and
> presumably any of their derivatives.
>
> We know Debian is, er, working on it, as per the most recent article on
> LWN.
>
Debian is expected to complete this with Debian 12, I believe.
> What about other distros that are not derivatives of the aboves and
> that use systemd? Does anybody have any insight?
>
OpenMandriva and Yocto both haven't done the switch yet, as far as I'm
aware. Might be worth reaching out to them and finding out when
they're going to do it.
--
真実はいつも一つ！/ Always, there's only one truth!
Re: [systemd-devel] Antw: [EXT] Re: [systemd‑devel] version bump of minimal kernel version supported by systemd?
On Thu, Mar 24, 2022 at 8:15 AM Greg Kroah-Hartman wrote: > > On Thu, Mar 24, 2022 at 10:23:21AM +, Luca Boccassi wrote: > > On Thu, 2022-03-24 at 09:45 +0100, Greg Kroah-Hartman wrote: > > > On Thu, Mar 24, 2022 at 09:33:50AM +0100, Ulrich Windl wrote: > > > > > > > Greg KH schrieb am 24.03.2022 um > > > > > > > 08:12 in > > > > Nachricht : > > > > > On Wed, Mar 23, 2022 at 10:34:00PM +, Dave Howorth wrote: > > > > > > FWIW, I think Greg was a bit too outspoken calling long maintenance > > > > > > attempts 'crazy'; that may have intimidated some. I'm thinking of > > > > > > moving distro to one that provides longer term maintenance than my > > > > > > present one. Although CIP is a completely different ball game; I > > > > > > hope > > > > > > they succeed. > > > > > > > > > > It is not "crazy" it is "well documented". As someone who has been > > > > > doing this work for 20+ years now and sees all of the stable kernel > > > > > patches flow by, it's obvious that a distro that does not keep up with > > > > > them is insecure by design. > > > > > > > > If "newer is better" I'd agree. Sometimes "newer is actually worse". > > > > Some new features intended to improve things sometimes actually make > > > > things worse. > > > > > > That's not the issue here. > > > > > > Do you want to run a kernel with known security problems, or one with > > > "unknown potential problems." The latter is always the case, so please > > > don't pick the known-insecure one, that's just foolish. > > > > "security problems" are a dime a dozen, as they say. Speaking as a > > (thankfully former) downstream integrator, you'd have much more success > > if you stopped breaking backward compatibility with userspace all the > > damn time. Upgrading major kernel version is like rolling a dice, you > > never know what kind of extremely expensive and time consuming rabbit > > hole you'll be dragged into because the kernel plays fast and loose > > with its userspace interfaces, and each and every time there's a chance > > one might end up having to do major reworks to deal with it. > > We should never be breaking working userspace programs when upgrading > the kernel. If so, please report it to the regressions mailing list. > > Of course there's always some corner cases, but for the most part, this > should never happen. > > > So really it shouldn't be that surprising that users are averse to > > following the "latest is greatest" mantra from kernel.org, given how > > risky and expensive it is, and how little one gains in return. Rather > > than changing the world, what about changing your own processes first? > > A great starting point would be reverting backward incompatible changes > > regardless of who's affected, instead of doing that only if they affect > > the personal computer of a handful of maintainers (mainly Linus'), and > > shrugging reports away with "deal with it" in other cases. > > We should never be "shrugging" away reports like this. If you have > specific incidents that you wish to discuss, I will be glad to do so on > the regressions kernel mailing list. Otherwise this is way off-topic > for systemd-devel. > >From a systemd-relevant angle, this has happened before. Recently even: https://github.com/systemd/systemd/blob/8c70e8024ba8ff42c23f1a35b9e8fafddd5caa8d/NEWS#L2355-L2437 That means that from a reasonable systemd user perspective, we need to depend on Linux kernel 4.14 or higher to cross over that breakage. While it is true that the syscall interface is kept reasonably stable, almost everything else gets monkeyed with a lot, because a lot of kernel developers only consider the syscall interface a program interface. This is a problem because a *lot* of things are only accessible through other means (procfs, sysfs, uevents, etc.). Unfortunately, that means that in practice, the kernel interfaces that userspace *must* depend on break far more than anyone likes. -- 真実はいつも一つ！/ Always, there's only one truth!
Re: [systemd-devel] version bump of minimal kernel version supported by systemd?
On Thu, Mar 24, 2022 at 4:30 PM Michael Biebl wrote: > > As far as Debian is concerned, we do have > > 4.9.x in old old stable aka stretch > 4.19.x in old stable aka buster > 5.10.x in stable aka bullseye > 5.16.x in unstable/bookworm > > We do provide backports of current systemd versions for bullseye. I > also do care that users upgrading from bullseye to bookworm can > continue to use the old stable kernel, which would be 5.10.x > So all in all, not an issue from the Debian side, as this would mean > the baseline would be 5.10.x > > Obviously I can't speak for all our downstreams (like raspbian) or > individual users with their self-compiled kernels. > Which I guess is more common among Debian then e.g. Fedora users. > It's not *super-common* for Fedora users, but it *is* common in CentOS. There's an active backport of the latest systemd to CentOS Stream 8, which is a 4.18 kernel with backports of stuff across the board. So I would personally like for the latest systemd to work on CentOS/RHEL 8 still. -- 真実はいつも一つ！/ Always, there's only one truth!
Re: [systemd-devel] Antw: [EXT] Re: version bump of minimal kernel version supported by systemd?
On Thu, Mar 24, 2022 at 4:30 AM Ulrich Windl wrote: > > I wonder: > > Why not providing some test suite instead: If the test suite succeeds, systemd > might work; if it doesn't, manual steps are needed. > My guess is that most people will quit trying once manual steps are needed. > In addition the configure procedure could include a "support window" (oldest > kernel supported, latest kernel supported). > And f the kernel is outside, print a warning at least that the configuration > is not supported. > Still I guess the kernel version is not the only dependency... > Because the point of doing this is to simplify the code in systemd itself and to give guidance to developers and distributors what systemd requires. Even if such a test suite exists (which I think it already does?), we *still* need the human guidance of the minimum Linux kernel version and what features we need enabled to make it work. Otherwise, it's a very unpleasant experience to port and ship it. -- 真実はいつも一つ！/ Always, there's only one truth!
Re: [systemd-devel] No space left errors on shutdown with systemd-homed /home dir
On Tue, Feb 1, 2022 at 2:02 PM Colin Guthrie wrote: > > Goffredo Baroncelli wrote on 30/01/2022 09:27: > > On 29/01/2022 19.01, Chris Murphy wrote: > >> On Sat, Jan 29, 2022 at 2:53 AM Goffredo Baroncelli > >> wrote: > >>> > >>> I think that for the systemd uses cases (singled device FS), a simpler > >>> approach would be: > >>> > >>> fstatfs(fd, ) > >>> needed = sfs.f_blocks - sfs.f_bavail; > >>> needed *= sfs.f_bsize > >>> > >>> needed = roundup_64(needed, 3*(1024*1024*1024)) > >>> > >>> Comparing the original systemd-homed code, I made the following changes > >>> - 1) f_bfree is replaced by f_bavail (which seem to be more > >>> consistent to the disk usage; to me it seems to consider also the > >>> metadata chunk allocation) > >>> - 2) the needing value is rounded up of 3GB in order to consider a > >>> further 1 data chunk and 2 metadata chunk (DUP)) > >>> > >>> Comments ? > >> > >> I'm still wondering if such a significant shrink is even indicated, in > >> lieu of trim. Isn't it sufficient to just trim on logout, thus > >> returning unused blocks to the underlying filesystem? > > > > I agree with you. In Fedora 35, and the default is ext4+luks+trim > > which provides the same results. However I remember that in the past the > > default > > was btrfs+luks+shrunk. I think that something is changed i. > > > > However, I want to provide do the systemd folks a suggestion ho change > > the code. > > Even a warning like: "it doesn't work that because this, please drop it" > > would be sufficient. > > > Out of curiosity (see other thread on the systemd list about this), what > it the current recommendation (by systemd/btrfs folks rather then Fedora > defaults) for homed machine partitioning? > I'd probably recommend Btrfs with the /home subvolume set with nodatacow if you're going to use loops of LUKS backed Btrfs homedir images. The individual Btrfs loops will have their own COW anyway. Otherwise, the Fedora defaults for Btrfs should be sufficient. -- 真実はいつも一つ！/ Always, there's only one truth!
