shaba/systemd
1
0
Fork 0
mirror of https://github.com/systemd/systemd.git synced 2025-02-21 05:57:34 +03:00
Code
systemd/units/initrd-parse-etc.service.in

34 lines
1.1 KiB
SYSTEMD
Raw Normal View History

license: LGPL-2.1+ -> LGPL-2.1-or-later
2020-11-09 13:23:58 +09:00
# SPDX-License-Identifier: LGPL-2.1-or-later
Add SPDX license headers to unit files
2017-11-18 17:35:03 +01:00
#
initrd: add unit files needed for basic systemd-in-initrd support This will: * mount all configured filesystems (typically the rootfs on /sysroot) * reload the configuration to pick up anything from the mounted fs (typically /sysroot/etc/fstab) * mount any newly configured filesystems (typically /usr on /sysroot/usr, if applicable) * shut-down and clean-up any daemons running in the initramfs (typically udevd) * switch-root to /sysroot and start the real init For an example of what files should be included in an initramfs based on this see <https://mailman.archlinux.org/pipermail/arch-projects/2013-February/003628.html>. Cc: Harald Hoyer <harald.hoyer@gmail.com> Cc: Dave Reisner <d@falconindy.com>
2013-02-24 17:40:36 +01: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 18:05:55 +02:00
Description=Mountpoints Configured in the Real Root
AssertPathExists=/etc/initrd-release
initrd: add unit files needed for basic systemd-in-initrd support This will: * mount all configured filesystems (typically the rootfs on /sysroot) * reload the configuration to pick up anything from the mounted fs (typically /sysroot/etc/fstab) * mount any newly configured filesystems (typically /usr on /sysroot/usr, if applicable) * shut-down and clean-up any daemons running in the initramfs (typically udevd) * switch-root to /sysroot and start the real init For an example of what files should be included in an initramfs based on this see <https://mailman.archlinux.org/pipermail/arch-projects/2013-February/003628.html>. Cc: Harald Hoyer <harald.hoyer@gmail.com> Cc: Dave Reisner <d@falconindy.com>
2013-02-24 17:40:36 +01:00
DefaultDependencies=no
Make initrd.target the default target in the initrd First, rename root-fs.target to initrd-root-fs.target to clarify its usage. Mount units with "x-initrd-rootfs.mount" are now ordered before initrd-root-fs.target. As we sometimes construct /sysroot mounts in /etc/fstab in the initrd, we want these to be mounted before the initrd-root-fs.target is active. initrd.target can be the default target in the initrd. (normal startup) : : v basic.target | ______________________/| / | | sysroot.mount | | | v | initrd-root-fs.target | | | v | initrd-parse-etc.service (custom initrd services) | | v | (sysroot-usr.mount and | various mounts marked | with fstab option | x-initrd.mount) | | | v | initrd-fs.target | | \______________________ | \| v initrd.target | v initrd-cleanup.service isolates to initrd-switch-root.target | v ______________________/| / | | initrd-udevadm-cleanup-db.service | | (custom initrd services) | | | \______________________ | \| v initrd-switch-root.target | v initrd-switch-root.service | v switch-root
2013-03-14 13:12:10 +01:00
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 18:05:55 +02:00
units/initrd-parse-etc.service: Conflict with emergency.target If emergency.target is started while initrd-parse-etc.service/start is queued, the initrd-parse-etc job did not get canceled. In parallel to the emergency units, it eventually runs the service, which starts initrd-cleanup.service, which in turn isolates initrd-switch-root.target. This stops the emergency units and effectively starts the initrd boot process again, which likely fails again like the initial attempt. The system is thus stuck in an endless loop, never really reaching emergency.target. With this conflict added, starting emergency.target automatically cancels initrd-parse-etc.service/start, avoiding the loop.
2023-08-08 12:52:53 +02:00
Conflicts=emergency.target
initrd: add unit files needed for basic systemd-in-initrd support This will: * mount all configured filesystems (typically the rootfs on /sysroot) * reload the configuration to pick up anything from the mounted fs (typically /sysroot/etc/fstab) * mount any newly configured filesystems (typically /usr on /sysroot/usr, if applicable) * shut-down and clean-up any daemons running in the initramfs (typically udevd) * switch-root to /sysroot and start the real init For an example of what files should be included in an initramfs based on this see <https://mailman.archlinux.org/pipermail/arch-projects/2013-February/003628.html>. Cc: Harald Hoyer <harald.hoyer@gmail.com> Cc: Dave Reisner <d@falconindy.com>
2013-02-24 17:40:36 +01:00
OnFailure=emergency.target
core: replace OnFailureIsolate= setting by a more generic OnFailureJobMode= setting and make use of it where applicable
2013-11-26 01:39:53 +01:00
OnFailureJobMode=replace-irreversibly
initrd: add unit files needed for basic systemd-in-initrd support This will: * mount all configured filesystems (typically the rootfs on /sysroot) * reload the configuration to pick up anything from the mounted fs (typically /sysroot/etc/fstab) * mount any newly configured filesystems (typically /usr on /sysroot/usr, if applicable) * shut-down and clean-up any daemons running in the initramfs (typically udevd) * switch-root to /sysroot and start the real init For an example of what files should be included in an initramfs based on this see <https://mailman.archlinux.org/pipermail/arch-projects/2013-February/003628.html>. Cc: Harald Hoyer <harald.hoyer@gmail.com> Cc: Dave Reisner <d@falconindy.com>
2013-02-24 17:40:36 +01:00
[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 18:05:55 +02:00
Revert "initrd-parse-etc: override argv[0] to avoid dracut issue" This reverts commit db5276215ae496074c163fca4014baf1bcd05984. dracut is patched since https://github.com/dracutdevs/dracut/commit/23684e4a, and this commit is included in the latest dracut-059 release.
2023-12-07 08:29:40 +01: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 18:05:55 +02: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.
units: drop full paths for utilities in $PATH This makes things a bit simpler and the build a bit faster, because we don't have to rewrite files to do the trivial substitution. @rootbindir@ is always in our internal $PATH that we use for non-absolute paths, so there should be no functional change.
2019-12-18 09:14:57 +01:00
ExecStart=systemctl --no-block start initrd-cleanup.service
Copy Permalink