On Wed, Jul 6, 2022 at 2:14 PM Ben Cotton <bcotton@xxxxxxxxxx> wrote: > > https://fedoraproject.org/wiki/Changes/Preset_All_Systemd_Units_on_First_Boot > > This document represents a proposed Change. As part of the Changes > process, proposals are publicly announced in order to receive > community feedback. This proposal will only be implemented if approved > by the Fedora Engineering Steering Committee. > > == Summary == > Systemd will execute the equivalent of '''systemctl preset-all''' when > an unconfigured system is booted > ([https://www.freedesktop.org/software/systemd/man/machine-id.html#First%20Boot%20Semantics > "First Boot"] condition). This means that units will be enabled or > disabled according to the preset configuration. We currently do the > equivalent of '''systemctl preset-all --preset-mode=enable-only''', > and this will be extended to also disable units, i.e. '''systemctl > preset-all --preset-mode=full'''. Any units which are manually > symlinked but presets say they shouldn't (which is against the > packaging guidelines for packaged units) will be disabled. > > Note that this applies to "first boot" only, i.e. to boot from an > image without ''/etc'' fully populated. In does not apply to systems > that were installed using Anaconda. > > == Owner == > * Name: [[User:jlebon| Jonathan Lebon]] > * Name: [[User:Zbyszek| Zbigniew Jędrzejewski-Szmek]] > * Email: zbyszek at in.waw.pl, jlebon at redhat.com > > > == Detailed Description == > Our [https://docs.fedoraproject.org/en-US/packaging-guidelines/Scriptlets/#_systemd > guidelines] say that units that are packaged in rpms must be enabled > through macros (''%systemd_post'') and the preset system. Almost all > packages conform to this, so effectively their enablement state > follows the preset config. When the system is installed, or more > precisely when ''systemd.rpm'' is installed, we do ''preset-all''. But > for historical reasons, when booting an unconfigured system ("first > boot") we only 'enable' units in this fashion. In Fedora and RHEL > CoreOS, some symlinks are created in the golden image, but should be > disabled in the local image after local preset configuration has been > inserted. To make this work, the call in systemd will be changed to > execute the equivalent of ''preset-all --preset-mode=full'', making > enablement during "first boot" more like enablement during an Anaconda > installation. > > > == Benefit to Fedora == > * CoreOS can insert local preset configuration through Ignition and > this configuration will be applied on the first boot. > * Users can do something similar with local preset configuration on > distributed images. > * The system is made a bit simpler and easier to understand, because > we can say that "units are enabled/disabled after installation as > specified by the preset system". > * Users can call ''systemctl preset-all'' at any time to apply > preset-configuration. If no local changes to configuration have been > made, ''preset-all'' would make no changes to unit state. If units > have been enabled or disabled, ''preset-all'' would return unit > enablement to the pristine state after installation. > > == Scope == > * Proposal owners: > ** implement patch for systemd to configure preset-all mode on first > boot (https://github.com/systemd/systemd/pull/15205) > ** build systemd with this mode changed to ''--preset-mode=full'' > ** provide pull requests for two packages which have been identified > to not use the preset system for enablement to conform to the > packaging guidelines > (https://bugzilla.redhat.com/show_bug.cgi?id=2070862, > https://bugzilla.redhat.com/show_bug.cgi?id=2070726) > > * Other developers: review and merge the pull requests > * Release engineering: N/A > * Policies and guidelines: none, this change is about following the > guidelines more closely > * Trademark approval: N/A (not needed for this Change) > * Alignment with Objectives: > > == Upgrade/compatibility impact == > None. > > == How To Test == > * On a newly installed system, with arbitrary set of packages: call > ''systemctl preset-all''. This should result in no changes. > * On a system which is booted from an unconfigured image (e.g. the new > Server VM image should qualify, see > [[Changes/Supplement-server-by-kvm-vm-image]]): before the first boot, > enable some units manually that are disabled in presets. After > booting, those units should be disabled again. > > == User Experience == > In general this change will be a noop for users, because it only > applies to "first boot", i.e. to the case when a system is booted from > a distributable image without local configuration and is configured > when initially booted. In case where Anaconda is used to install > images, /etc is populated before the first boot and the "first boot" > condition never applies, thus this change is irrelevant. On systems > installed from a "golden image" such as Fedora CoreOS, units will > follow the preset configuration more closely. Thanks to the fixes to > make packages conform to packaging guidelines, users can call > '''preset-all''' to return the system to defaults. > > == Dependencies == > > > == Contingency Plan == > * Contingency mechanism: (What to do? Who will do it?) Systemd > maintainers: flip back the default in systemd, rebuild. > * Contingency deadline: N/A (not a System Wide Change) This can be > done at any time up to the release. > * Blocks release? No. > > == Documentation == > N/A (not a System Wide Change) > This really feels like a system wide change. It totally changes how the system configures itself across the board, and changes how all images wind up being configured when building them. -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
