2020-11-09 12:23:58 +08:00
|
|
|
# SPDX-License-Identifier: LGPL-2.1-or-later
|
2017-11-19 00:35:03 +08:00
|
|
|
#
|
2013-02-25 00:40:36 +08: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-15 00:05:55 +08:00
|
|
|
Description=Mountpoints Configured in the Real Root
|
|
|
|
|
AssertPathExists=/etc/initrd-release
|
|
|
|
|
|
2013-02-25 00:40:36 +08:00
|
|
|
DefaultDependencies=no
|
2013-03-14 20:12:10 +08: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-15 00:05:55 +08:00
|
|
|
|
2013-02-25 00:40:36 +08:00
|
|
|
OnFailure=emergency.target
|
2013-11-26 08:39:53 +08:00
|
|
|
OnFailureJobMode=replace-irreversibly
|
2013-02-25 00:40:36 +08: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-15 00:05:55 +08:00
|
|
|
|
2022-08-13 21:51:14 +08:00
|
|
|
# FIXME: once dracut is patched to install the symlink, change to:
|
|
|
|
|
# ExecStart={{ROOTLIBEXECDIR}}/systemd-sysroot-fstab-check
|
|
|
|
|
ExecStart=@{{SYSTEM_GENERATOR_DIR}}/systemd-fstab-generator 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-15 00:05:55 +08: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.
|
2019-12-18 16:14:57 +08:00
|
|
|
ExecStart=systemctl --no-block start initrd-cleanup.service
|
