shaba/ostree
1
0
Fork 0
mirror of https://github.com/ostreedev/ostree.git synced 2024-12-22 17:35:55 +03:00
Code Issues Projects Releases Wiki Activity
fa720d1540
ostree/Makefile-boot.am

80 lines
2.8 KiB
Plaintext
Raw Normal View History

Introducing ostree-grub-generator ostree-grub-generator can be used to customize the generated grub.cfg file. Compile time decision ostree-grub-generator vs grub2-mkconfig can be overwritten with the OSTREE_GRUB2_EXEC envvar - useful for auto tests and OS installers. Why this alternative approach: 1) The current approach is less flexible than using a custom 'ostree-grub-generator' script. Each system can adjust this script for its needs, instead of using the hardcoded values from ostree-bootloader-grub2.c. 2) Too much overhead on embedded to generate grub.cfg via /etc/grub.d/ configuration files. It is still possible to do so, even with this patch applied. No need to install grub2 package on a target device. 3) The grub2-mkconfig code path has other issues: https://bugzilla.gnome.org/show_bug.cgi?id=761180 Task: https://bugzilla.gnome.org/show_bug.cgi?id=762220 Closes: #228 Approved by: cgwalters
2016-04-01 14:51:18 +03:00
# Makefile for boot module
Add --with-dracut This installs a Dracut module which parses the ostree= kernel command line argument, and if given, sets up the OS/ at /sysroot, which systemd's switch-root then moves into. This only works if dracut is configured to use systemd itself.
2013-06-03 22:12:40 +04:00
#
# Copyright (C) 2013 Colin Walters <walters@verbum.org>
#
Add SPDX-License-Identifier to source files SPDX License List is a list of (common) open source licenses that can be referred to by a “short identifier”. It has several advantages compared to the common "license header texts" usually found in source files. Some of the advantages: * It is precise; there is no ambiguity due to variations in license header text * It is language neutral * It is easy to machine process * It is concise * It is simple and can be used without much cost in interpreted environments like java Script, etc. * An SPDX license identifier is immutable. * It provides simple guidance for developers who want to make sure the license for their code is respected See http://spdx.org for further reading. Signed-off-by: Marcus Folkesson <marcus.folkesson@gmail.com> Closes: #1439 Approved by: cgwalters
2018-01-30 22:26:26 +03:00
# SPDX-License-Identifier: LGPL-2.0+
#
Add --with-dracut This installs a Dracut module which parses the ostree= kernel command line argument, and if given, sets up the OS/ at /sysroot, which systemd's switch-root then moves into. This only works if dracut is configured to use systemd itself.
2013-06-03 22:12:40 +04:00
# This library 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 of the License, or (at your option) any later version.
#
# This library is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
# Lesser General Public License for more details.
#
# You should have received a copy of the GNU Lesser General Public
Update FSF license notices to use URL instead of address
2021-12-07 04:20:55 +03:00
# License along with this library. If not, see <https://www.gnu.org/licenses/>.
Add --with-dracut This installs a Dracut module which parses the ostree= kernel command line argument, and if given, sets up the OS/ at /sysroot, which systemd's switch-root then moves into. This only works if dracut is configured to use systemd itself.
2013-06-03 22:12:40 +04:00
if BUILDOPT_DRACUT
# Not using $(libdir) here is intentional, dracut modules go in prefix/lib
dracutmoddir = $(prefix)/lib/dracut/modules.d/98ostree
Add support for mkinitcpio https://bugzilla.gnome.org/show_bug.cgi?id=710682
2013-10-23 00:04:32 +04:00
dracutmod_SCRIPTS = src/boot/dracut/module-setup.sh
build: Introduce --with-dracut=yesbutnoconf It's actually just easier for build systems (e.g. rpm-ostree) using dracut to use `--add ostree` rather than indirecting through the conf file. This makes it easier for yum-managed systems to install ostree without side effects. Closes: #279 Approved by: gatispaeglis
2016-04-28 18:34:27 +03:00
endif
if BUILDOPT_DRACUT_CONF
Add --with-dracut This installs a Dracut module which parses the ostree= kernel command line argument, and if given, sets up the OS/ at /sysroot, which systemd's switch-root then moves into. This only works if dracut is configured to use systemd itself.
2013-06-03 22:12:40 +04:00
dracutconfdir = $(sysconfdir)/dracut.conf.d
Add support for mkinitcpio https://bugzilla.gnome.org/show_bug.cgi?id=710682
2013-10-23 00:04:32 +04:00
dracutconf_DATA = src/boot/dracut/ostree.conf
endif
if BUILDOPT_MKINITCPIO
mkinitcpioinstalldir = $(prefix)/lib/initcpio/install
mkinitcpioinstall_SCRIPTS = src/boot/mkinitcpio/ostree
mkinitcpioconfdir = $(sysconfdir)
mkinitcpioconf_DATA = src/boot/mkinitcpio/ostree-mkinitcpio.conf
endif
if BUILDOPT_SYSTEMD
systemdsystemunit_DATA = src/boot/ostree-prepare-root.service \
boot: Add ostree-finalize-staged.path Rather than manually starting the `ostree-finalize-staged.service` unit, we can leverage systemd's path units for this. It fits quite nicely too, given that we already have a path we drop iif we have a staged deployment. To give some time for the preset to make it to systems, we don't yet drop the explicit call to `systemctl start`. Though we do make it conditional based on a DEBUG env var so that we can actually test it in CI for now. Once we're sure this has propagated, we can drop the `systemctl start` path and the env var together. Closes: #1740 Approved by: cgwalters
2018-09-28 21:30:38 +03:00
src/boot/ostree-remount.service \
Add an `ostree-boot-complete.service` to propagate staging failures Quite a while ago we added staged deployments, which solved a bunch of issues around the `/etc` merge. However...a persistent problem since then is that any failures in that process that happened in the *previous* boot are not very visible. We ship custom code in `rpm-ostree status` to query the previous journal. But that has a few problems - one is that on systems that have been up a while, that failure message may even get rotated out. And second, some systems may not even have a persistent journal at all. A general thing we do in e.g. Fedora CoreOS testing is to check for systemd unit failures. We do that both in our automated tests, and we even ship code that displays them on ssh logins. And beyond that obviously a lot of other projects do the same; it's easy via `systemctl --failed`. So to make failures more visible, change our `ostree-finalize-staged.service` to have an internal wrapper around the process that "catches" any errors, and copies the error message into a file in `/boot/ostree`. Then, a new `ostree-boot-complete.service` looks for this file on startup and re-emits the error message, and fails. It also deletes the file. The rationale is to avoid *continually* warning. For example we need to handle the case when an upgrade process creates a new staged deployment. Now, we could change the ostree core code to delete the warning file when that happens instead, but this is trying to be a conservative change. This should make failures here much more visible as is.
2022-04-23 01:46:28 +03:00
src/boot/ostree-boot-complete.service \
boot: Add ostree-finalize-staged.path Rather than manually starting the `ostree-finalize-staged.service` unit, we can leverage systemd's path units for this. It fits quite nicely too, given that we already have a path we drop iif we have a staged deployment. To give some time for the preset to make it to systems, we don't yet drop the explicit call to `systemctl start`. Though we do make it conditional based on a DEBUG env var so that we can actually test it in CI for now. Once we're sure this has propagated, we can drop the `systemctl start` path and the env var together. Closes: #1740 Approved by: cgwalters
2018-09-28 21:30:38 +03:00
src/boot/ostree-finalize-staged.service \
src/boot/ostree-finalize-staged.path \
finalize-staged: Ensure /boot automount doesn't expire If `/boot` is an automount, then the unit will be stopped as soon as the automount expires. That's would defeat the purpose of using systemd to delay finalizing the deployment until shutdown. This is not uncommon as `systemd-gpt-auto-generator` will create an automount unit for `/boot` when it's the EFI System Partition and there's no fstab entry. To ensure that systemd doesn't stop the service early when the `/boot` automount expires, introduce a new unit that holds `/boot` open until it's sent `SIGTERM`. This uses a new `--hold` option for `finalize-staged` that loads but doesn't lock the sysroot. A separate unit is used since we want the process to remain active throughout the finalization run in `ExecStop`. That wouldn't work if it was specified in `ExecStart` in the same unit since it would be killed before the `ExecStop` action was run. Fixes: #2543
2022-02-17 01:58:58 +03:00
src/boot/ostree-finalize-staged-hold.service \
Add concept of state overlays In the OSTree model, executables go in `/usr`, state in `/var` and configuration in `/etc`. Software that lives in `/opt` however messes this up because it often mixes code *and* state, making it harder to manage. More generally, it's sometimes useful to have the OSTree commit contain code under a certain path, but still allow that path to be writable by software and the sysadmin at runtime (`/usr/local` is another instance). Add the concept of state overlays. A state overlay is an overlayfs mount whose upper directory, which contains unmanaged state, is carried forward on top of a lower directory, containing OSTree-managed files. In the example of `/usr/local`, OSTree commits can ship content there, all while allowing users to e.g. add scripts in `/usr/local/bin` when booted into that commit. Some reconciliation logic is executed whenever the base is updated so that newer files in the base are never shadowed by a copied up version in the upper directory. This matches RPM semantics when upgrading packages whose files may have been modified. For ease of integration, this is exposed as a systemd template unit which any downstream distro/user can enable. The instance name is the mountpath in escaped systemd path notation (e.g. `ostree-state-overlay@usr-local.service`). See discussions in https://github.com/ostreedev/ostree/issues/3113 for more details.
2023-12-15 00:46:14 +03:00
src/boot/ostree-state-overlay@.service \
boot: Add ostree-finalize-staged.path Rather than manually starting the `ostree-finalize-staged.service` unit, we can leverage systemd's path units for this. It fits quite nicely too, given that we already have a path we drop iif we have a staged deployment. To give some time for the preset to make it to systems, we don't yet drop the explicit call to `systemctl start`. Though we do make it conditional based on a DEBUG env var so that we can actually test it in CI for now. Once we're sure this has propagated, we can drop the `systemctl start` path and the env var together. Closes: #1740 Approved by: cgwalters
2018-09-28 21:30:38 +03:00
$(NULL)
boot: Add a tmpfiles.d snippet to clean up /var/tmp/ostree-ovl.XXX This is simplest for now. Compare with similar logic from `/usr/lib/tmpfiles.d/tmp.conf`: ``` R! /tmp/systemd-private-* ``` Closes: https://github.com/ostreedev/ostree/issues/393 Closes: #1090 Approved by: jlebon
2017-08-17 21:00:08 +03:00
systemdtmpfilesdir = $(prefix)/lib/tmpfiles.d
build: Ensure ostree-tmpfiles.conf is distributed Signed-off-by: Philip Withnall <withnall@endlessm.com> Closes: #1103 Approved by: cgwalters
2017-08-22 20:33:57 +03:00
dist_systemdtmpfiles_DATA = src/boot/ostree-tmpfiles.conf
build: Override systemd unit directory for distcheck distcheck tests that all the files are installed under $prefix. That doesn't work with the systemd unit directory since the path comes from pkg-config. Override the setting to be under $prefix in that case. Closes: #372 Approved by: cgwalters
2016-06-27 23:06:23 +03:00
# Allow the distcheck install under $prefix test to pass
AM_DISTCHECK_CONFIGURE_FLAGS += --with-systemdsystemunitdir='$${libdir}/systemd/system'
Add --with-dracut This installs a Dracut module which parses the ostree= kernel command line argument, and if given, sets up the OS/ at /sysroot, which systemd's switch-root then moves into. This only works if dracut is configured to use systemd itself.
2013-06-03 22:12:40 +04:00
endif
Introducing ostree-grub-generator ostree-grub-generator can be used to customize the generated grub.cfg file. Compile time decision ostree-grub-generator vs grub2-mkconfig can be overwritten with the OSTREE_GRUB2_EXEC envvar - useful for auto tests and OS installers. Why this alternative approach: 1) The current approach is less flexible than using a custom 'ostree-grub-generator' script. Each system can adjust this script for its needs, instead of using the hardcoded values from ostree-bootloader-grub2.c. 2) Too much overhead on embedded to generate grub.cfg via /etc/grub.d/ configuration files. It is still possible to do so, even with this patch applied. No need to install grub2 package on a target device. 3) The grub2-mkconfig code path has other issues: https://bugzilla.gnome.org/show_bug.cgi?id=761180 Task: https://bugzilla.gnome.org/show_bug.cgi?id=762220 Closes: #228 Approved by: cgwalters
2016-04-01 14:51:18 +03:00
if !BUILDOPT_BUILTIN_GRUB2_MKCONFIG
# We're using the system grub2-mkconfig generator
build: Move grub2-15_ostree back to pkglibexecdir It's not quite namespaced enough to have `/usr/libexec/grub2-15_ostree`, and the Fedora spec file expects things in `/usr/libexec/ostree`. Changing the spec file would be annoying as we'd need conditionals. Closes: #249 Approved by: gatispaeglis
2016-04-08 17:28:17 +03:00
pkglibexec_SCRIPTS += src/boot/grub2/grub2-15_ostree
libostree: Add initial GRUB2 support In this approach, we drop a /etc/grub.d/15_ostree file which is a hybrid of shell/C that picks up bits from the GRUB2 library (e.g. the block device script generation), and then calls into libostree's GRUB2 code which knows about the BLS entries. This is admittedly ugly. There exists another approach for GRUB2 to learn the BLS specification. However, the spec has a few issues: https://www.redhat.com/archives/anaconda-devel-list/2014-July/msg00002.html This approach also gives a bit more control to the admin via the naming of the 15_ostree symlink; they can easily disable it: Or reorder the ostree entries ahead of 10_linux: Also, this approach doesn't require patches for grub2, which is an issue with the pressure to backport (rpm-)OSTree to EL7.
2014-10-11 16:59:06 +04:00
install-grub2-config-hook:
mkdir -p $(DESTDIR)$(grub2configdir)
build: Move grub2-15_ostree back to pkglibexecdir It's not quite namespaced enough to have `/usr/libexec/grub2-15_ostree`, and the Fedora spec file expects things in `/usr/libexec/ostree`. Changing the spec file would be annoying as we'd need conditionals. Closes: #249 Approved by: gatispaeglis
2016-04-08 17:28:17 +03:00
ln -sf $(pkglibexecdir)/grub2-15_ostree $(DESTDIR)$(grub2configdir)/15_ostree
libostree: Add initial GRUB2 support In this approach, we drop a /etc/grub.d/15_ostree file which is a hybrid of shell/C that picks up bits from the GRUB2 library (e.g. the block device script generation), and then calls into libostree's GRUB2 code which knows about the BLS entries. This is admittedly ugly. There exists another approach for GRUB2 to learn the BLS specification. However, the spec has a few issues: https://www.redhat.com/archives/anaconda-devel-list/2014-July/msg00002.html This approach also gives a bit more control to the admin via the naming of the 15_ostree symlink; they can easily disable it: Or reorder the ostree entries ahead of 10_linux: Also, this approach doesn't require patches for grub2, which is an issue with the pressure to backport (rpm-)OSTree to EL7.
2014-10-11 16:59:06 +04:00
grub2configdir = $(sysconfdir)/grub.d
INSTALL_DATA_HOOKS += install-grub2-config-hook
Introducing ostree-grub-generator ostree-grub-generator can be used to customize the generated grub.cfg file. Compile time decision ostree-grub-generator vs grub2-mkconfig can be overwritten with the OSTREE_GRUB2_EXEC envvar - useful for auto tests and OS installers. Why this alternative approach: 1) The current approach is less flexible than using a custom 'ostree-grub-generator' script. Each system can adjust this script for its needs, instead of using the hardcoded values from ostree-bootloader-grub2.c. 2) Too much overhead on embedded to generate grub.cfg via /etc/grub.d/ configuration files. It is still possible to do so, even with this patch applied. No need to install grub2 package on a target device. 3) The grub2-mkconfig code path has other issues: https://bugzilla.gnome.org/show_bug.cgi?id=761180 Task: https://bugzilla.gnome.org/show_bug.cgi?id=762220 Closes: #228 Approved by: cgwalters
2016-04-01 14:51:18 +03:00
else
# We're using our internal generator
Makefile: declare ostree_boot_SCRIPTS and append values ostree_boot_SCRIPTS was being set on both Makefile-boot.am and Makefile-switchroot.am, causing the first one to be replaced by the other at the final Makefile, so declare as empty and append on both places instead. Signed-off-by: Ricardo Salveti <ricardo@foundries.io>
2019-11-06 03:16:07 +03:00
ostree_boot_SCRIPTS += src/boot/grub2/ostree-grub-generator
libostree: Add initial GRUB2 support In this approach, we drop a /etc/grub.d/15_ostree file which is a hybrid of shell/C that picks up bits from the GRUB2 library (e.g. the block device script generation), and then calls into libostree's GRUB2 code which knows about the BLS entries. This is admittedly ugly. There exists another approach for GRUB2 to learn the BLS specification. However, the spec has a few issues: https://www.redhat.com/archives/anaconda-devel-list/2014-July/msg00002.html This approach also gives a bit more control to the admin via the naming of the 15_ostree symlink; they can easily disable it: Or reorder the ostree entries ahead of 10_linux: Also, this approach doesn't require patches for grub2, which is an issue with the pressure to backport (rpm-)OSTree to EL7.
2014-10-11 16:59:06 +04:00
endif
Add support for mkinitcpio https://bugzilla.gnome.org/show_bug.cgi?id=710682
2013-10-23 00:04:32 +04:00
EXTRA_DIST += src/boot/dracut/module-setup.sh \
src/boot/dracut/ostree.conf \
build-sys: Include all mkinitcpio bits It's still so tempting to switch to `git archive` to ship sources. Closes: https://github.com/ostreedev/ostree/issues/2312
2021-04-06 00:00:07 +03:00
src/boot/mkinitcpio \
Add an `ostree-boot-complete.service` to propagate staging failures Quite a while ago we added staged deployments, which solved a bunch of issues around the `/etc` merge. However...a persistent problem since then is that any failures in that process that happened in the *previous* boot are not very visible. We ship custom code in `rpm-ostree status` to query the previous journal. But that has a few problems - one is that on systems that have been up a while, that failure message may even get rotated out. And second, some systems may not even have a persistent journal at all. A general thing we do in e.g. Fedora CoreOS testing is to check for systemd unit failures. We do that both in our automated tests, and we even ship code that displays them on ssh logins. And beyond that obviously a lot of other projects do the same; it's easy via `systemctl --failed`. So to make failures more visible, change our `ostree-finalize-staged.service` to have an internal wrapper around the process that "catches" any errors, and copies the error message into a file in `/boot/ostree`. Then, a new `ostree-boot-complete.service` looks for this file on startup and re-emits the error message, and fails. It also deletes the file. The rationale is to avoid *continually* warning. For example we need to handle the case when an upgrade process creates a new staged deployment. Now, we could change the ostree core code to delete the warning file when that happens instead, but this is trying to be a conservative change. This should make failures here much more visible as is.
2022-04-23 01:46:28 +03:00
src/boot/ostree-boot-complete.service \
Add support for mkinitcpio https://bugzilla.gnome.org/show_bug.cgi?id=710682
2013-10-23 00:04:32 +04:00
src/boot/ostree-prepare-root.service \
build-sys: Dist ostree-finalize-staged.path Otherwise the tarball doesn't work. Closes: #1766 Approved by: jlebon
2018-10-25 18:15:04 +03:00
src/boot/ostree-finalize-staged.path \
Add support for mkinitcpio https://bugzilla.gnome.org/show_bug.cgi?id=710682
2013-10-23 00:04:32 +04:00
src/boot/ostree-remount.service \
Add concept of "staged" deployment Add API to write a deployment state to `/run/ostree/staged-deployment`, along with a systemd service which runs at shutdown time. This is a big change to the ostree model for hosts, but it closes a longstanding set of bugs; many, many people have hit the "losing changes in /etc" problem. It also avoids the other problem of racing with programs that modify `/etc` such as LVM backups: https://bugzilla.redhat.com/show_bug.cgi?id=1365297 We need this in particular to go to a full-on model for automatically updated host systems where (like a dual-partition model) everything is fully prepared and the reboot can be taken asynchronously. Closes: https://github.com/ostreedev/ostree/issues/545 Closes: #1503 Approved by: jlebon
2018-02-22 23:27:59 +03:00
src/boot/ostree-finalize-staged.service \
finalize-staged: Ensure /boot automount doesn't expire If `/boot` is an automount, then the unit will be stopped as soon as the automount expires. That's would defeat the purpose of using systemd to delay finalizing the deployment until shutdown. This is not uncommon as `systemd-gpt-auto-generator` will create an automount unit for `/boot` when it's the EFI System Partition and there's no fstab entry. To ensure that systemd doesn't stop the service early when the `/boot` automount expires, introduce a new unit that holds `/boot` open until it's sent `SIGTERM`. This uses a new `--hold` option for `finalize-staged` that loads but doesn't lock the sysroot. A separate unit is used since we want the process to remain active throughout the finalization run in `ExecStop`. That wouldn't work if it was specified in `ExecStart` in the same unit since it would be killed before the `ExecStop` action was run. Fixes: #2543
2022-02-17 01:58:58 +03:00
src/boot/ostree-finalize-staged-hold.service \
Add concept of state overlays In the OSTree model, executables go in `/usr`, state in `/var` and configuration in `/etc`. Software that lives in `/opt` however messes this up because it often mixes code *and* state, making it harder to manage. More generally, it's sometimes useful to have the OSTree commit contain code under a certain path, but still allow that path to be writable by software and the sysadmin at runtime (`/usr/local` is another instance). Add the concept of state overlays. A state overlay is an overlayfs mount whose upper directory, which contains unmanaged state, is carried forward on top of a lower directory, containing OSTree-managed files. In the example of `/usr/local`, OSTree commits can ship content there, all while allowing users to e.g. add scripts in `/usr/local/bin` when booted into that commit. Some reconciliation logic is executed whenever the base is updated so that newer files in the base are never shadowed by a copied up version in the upper directory. This matches RPM semantics when upgrading packages whose files may have been modified. For ease of integration, this is exposed as a systemd template unit which any downstream distro/user can enable. The instance name is the mountpath in escaped systemd path notation (e.g. `ostree-state-overlay@usr-local.service`). See discussions in https://github.com/ostreedev/ostree/issues/3113 for more details.
2023-12-15 00:46:14 +03:00
src/boot/ostree-state-overlay@.service \
Introducing ostree-grub-generator ostree-grub-generator can be used to customize the generated grub.cfg file. Compile time decision ostree-grub-generator vs grub2-mkconfig can be overwritten with the OSTREE_GRUB2_EXEC envvar - useful for auto tests and OS installers. Why this alternative approach: 1) The current approach is less flexible than using a custom 'ostree-grub-generator' script. Each system can adjust this script for its needs, instead of using the hardcoded values from ostree-bootloader-grub2.c. 2) Too much overhead on embedded to generate grub.cfg via /etc/grub.d/ configuration files. It is still possible to do so, even with this patch applied. No need to install grub2 package on a target device. 3) The grub2-mkconfig code path has other issues: https://bugzilla.gnome.org/show_bug.cgi?id=761180 Task: https://bugzilla.gnome.org/show_bug.cgi?id=762220 Closes: #228 Approved by: cgwalters
2016-04-01 14:51:18 +03:00
src/boot/grub2/grub2-15_ostree \
src/boot/grub2/ostree-grub-generator \
Add a few more bits to EXTRA_DIST
2013-07-08 05:35:15 +04:00
$(NULL)
Reference in New Issue Copy Permalink