11ce3ea2f2
This reworks the how machine ID used by the boot loader spec snippet generation logic. Instead of persisting it automatically to /etc/ we'll append it via systemd.machined_id= to the kernel command line, and thus persist it in the generated boot loader spec snippets instead. This has nice benefits: 1. We do not collide with read-only root 2. The machine ID remains stable across factory reset, so that we can safely recognize the path in $BOOT we drop our kernel images in again, i.e. kernel updates will work correctly and safely across kernel factory resets. 3. Previously regular systems had different machine IDs while in initrd and after booting into the host system. With this change they will now have the same. This then drops implicit persisting of KERNEL_INSTALL_MACHINE_ID, as its unnecessary then. The field is still honoured though, for compat reasons. This also drops the "Default" fallback previously used, as it actually is without effect, the randomized ID generation already took precedence in all cases. This means $MACHNE_ID/KERNEL_INSTALL_MACHINE_ID are now guaranteed to look like a proper machine ID, which is useful for us, given you need it that way to be able to pass it to the systemd.machine_id= kernel command line option. |
||
---|---|---|
.clusterfuzzlite | ||
.github | ||
.lgtm/cpp-queries | ||
.semaphore | ||
catalog | ||
coccinelle | ||
docs | ||
factory | ||
hwdb.d | ||
LICENSES | ||
man | ||
mkosi.default.d | ||
modprobe.d | ||
network | ||
po | ||
presets | ||
rules.d | ||
shell-completion | ||
src | ||
sysctl.d | ||
sysusers.d | ||
test | ||
tmpfiles.d | ||
tools | ||
units | ||
xorg | ||
.clang-format | ||
.ctags | ||
.dir-locals.el | ||
.editorconfig | ||
.gitattributes | ||
.gitignore | ||
.lgtm.yml | ||
.mailmap | ||
.packit.yml | ||
.vimrc | ||
.ycm_extra_conf.py | ||
configure | ||
LICENSE.GPL2 | ||
LICENSE.LGPL2.1 | ||
Makefile | ||
meson_options.txt | ||
meson.build | ||
mkosi.build | ||
mkosi.postinst | ||
NEWS | ||
README | ||
README.md | ||
TODO |
System and Service Manager
Details
Most documentation is available on systemd's web site.
Assorted, older, general information about systemd can be found in the systemd Wiki.
Information about build requirements is provided in the README file.
Consult our NEWS file for information about what's new in the most recent systemd versions.
Please see the Code Map for information about this repository's layout and content.
Please see the Hacking guide for information on how to hack on systemd and test your modifications.
Please see our Contribution Guidelines for more information about filing GitHub Issues and posting GitHub Pull Requests.
When preparing patches for systemd, please follow our Coding Style Guidelines.
If you are looking for support, please contact our mailing list or join our IRC channel.
Stable branches with backported patches are available in the stable repo.