1
0
mirror of https://github.com/systemd/systemd.git synced 2024-12-26 03:22:00 +03:00
systemd/units/initrd-parse-etc.service.in

34 lines
1.1 KiB
SYSTEMD
Raw Normal View History

# SPDX-License-Identifier: LGPL-2.1-or-later
2017-11-18 19:35:03 +03:00
#
# This file is part of systemd.
#
# systemd is free software; you can redistribute it and/or modify it
# under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2.1 of the License, or
# (at your option) any later version.
[Unit]
units/initrd-parse-etc.service: only start units that are required This makes use of the option switch that was added in the previous commit. We used a pretty big hammer on a relatively small nail: we would do daemon-reload and (in principle) allow any configuration to be changed. But in fact we only made use of this in systemd-fstab-generator. systemd-fstab-generator filters out all mountpoints except /usr and those marked with x-initrd.mount, i.e. on a big majority of systems it wouldn't do anything. Also, since systemd-fstab-generator first parses /proc/cmdline, and then initrd's /etc/fstab, and only then /sysroot/etc/fstab, configuration in the host would only matter if it the same mountpoint wasn't configured "earlier". So the config in the host could be used for new mountpoints, but it couldn't be used to amend configuration for existing mountpoints. And we wouldn't actually remount anything, so mountpoints that were already mounted wouldn't be affected, even if did change some config. In the new scheme, we will parse /sysroot/etc/fstab and explicitly start sysroot-usr.mount and other units that we just wrote. In most cases (as written above), this will actually result in no units being created or started. If the generator is invoked on a system with /sysroot/etc/fstab present, behaviour is not changed and we'll create units as before. This is needed so that if daemon-reload is later at some points, we don't "lose" those units. There's a minor bugfix here: we honour x-initrd.mount for swaps, but we wouldn't restart swap.target, i.e. the new swaps wouldn't necessarilly be pulled in immediately.
2022-07-14 19:05:55 +03:00
Description=Mountpoints Configured in the Real Root
AssertPathExists=/etc/initrd-release
DefaultDependencies=no
Requires=initrd-root-fs.target
After=initrd-root-fs.target
units/initrd-parse-etc.service: only start units that are required This makes use of the option switch that was added in the previous commit. We used a pretty big hammer on a relatively small nail: we would do daemon-reload and (in principle) allow any configuration to be changed. But in fact we only made use of this in systemd-fstab-generator. systemd-fstab-generator filters out all mountpoints except /usr and those marked with x-initrd.mount, i.e. on a big majority of systems it wouldn't do anything. Also, since systemd-fstab-generator first parses /proc/cmdline, and then initrd's /etc/fstab, and only then /sysroot/etc/fstab, configuration in the host would only matter if it the same mountpoint wasn't configured "earlier". So the config in the host could be used for new mountpoints, but it couldn't be used to amend configuration for existing mountpoints. And we wouldn't actually remount anything, so mountpoints that were already mounted wouldn't be affected, even if did change some config. In the new scheme, we will parse /sysroot/etc/fstab and explicitly start sysroot-usr.mount and other units that we just wrote. In most cases (as written above), this will actually result in no units being created or started. If the generator is invoked on a system with /sysroot/etc/fstab present, behaviour is not changed and we'll create units as before. This is needed so that if daemon-reload is later at some points, we don't "lose" those units. There's a minor bugfix here: we honour x-initrd.mount for swaps, but we wouldn't restart swap.target, i.e. the new swaps wouldn't necessarilly be pulled in immediately.
2022-07-14 19:05:55 +03:00
Conflicts=emergency.target
OnFailure=emergency.target
OnFailureJobMode=replace-irreversibly
[Service]
Type=oneshot
units/initrd-parse-etc.service: only start units that are required This makes use of the option switch that was added in the previous commit. We used a pretty big hammer on a relatively small nail: we would do daemon-reload and (in principle) allow any configuration to be changed. But in fact we only made use of this in systemd-fstab-generator. systemd-fstab-generator filters out all mountpoints except /usr and those marked with x-initrd.mount, i.e. on a big majority of systems it wouldn't do anything. Also, since systemd-fstab-generator first parses /proc/cmdline, and then initrd's /etc/fstab, and only then /sysroot/etc/fstab, configuration in the host would only matter if it the same mountpoint wasn't configured "earlier". So the config in the host could be used for new mountpoints, but it couldn't be used to amend configuration for existing mountpoints. And we wouldn't actually remount anything, so mountpoints that were already mounted wouldn't be affected, even if did change some config. In the new scheme, we will parse /sysroot/etc/fstab and explicitly start sysroot-usr.mount and other units that we just wrote. In most cases (as written above), this will actually result in no units being created or started. If the generator is invoked on a system with /sysroot/etc/fstab present, behaviour is not changed and we'll create units as before. This is needed so that if daemon-reload is later at some points, we don't "lose" those units. There's a minor bugfix here: we honour x-initrd.mount for swaps, but we wouldn't restart swap.target, i.e. the new swaps wouldn't necessarilly be pulled in immediately.
2022-07-14 19:05:55 +03:00
ExecStart={{LIBEXECDIR}}/systemd-sysroot-fstab-check
units/initrd-parse-etc.service: only start units that are required This makes use of the option switch that was added in the previous commit. We used a pretty big hammer on a relatively small nail: we would do daemon-reload and (in principle) allow any configuration to be changed. But in fact we only made use of this in systemd-fstab-generator. systemd-fstab-generator filters out all mountpoints except /usr and those marked with x-initrd.mount, i.e. on a big majority of systems it wouldn't do anything. Also, since systemd-fstab-generator first parses /proc/cmdline, and then initrd's /etc/fstab, and only then /sysroot/etc/fstab, configuration in the host would only matter if it the same mountpoint wasn't configured "earlier". So the config in the host could be used for new mountpoints, but it couldn't be used to amend configuration for existing mountpoints. And we wouldn't actually remount anything, so mountpoints that were already mounted wouldn't be affected, even if did change some config. In the new scheme, we will parse /sysroot/etc/fstab and explicitly start sysroot-usr.mount and other units that we just wrote. In most cases (as written above), this will actually result in no units being created or started. If the generator is invoked on a system with /sysroot/etc/fstab present, behaviour is not changed and we'll create units as before. This is needed so that if daemon-reload is later at some points, we don't "lose" those units. There's a minor bugfix here: we honour x-initrd.mount for swaps, but we wouldn't restart swap.target, i.e. the new swaps wouldn't necessarilly be pulled in immediately.
2022-07-14 19:05:55 +03:00
# We want to enqueue initrd-cleanup.service/start after we finished the part
# above. It can't be part of the initial transaction, because non-oneshot units
# use Conflicts=initrd-cleanup.service to be terminated before we switch root.
# Effectively, initrd-parse-etc.service acts as a synchronization point after
# which cleanup of the initrd processes starts.
ExecStart=systemctl --no-block start initrd-cleanup.service