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
265b7f9ecc
ostree/tests/admin-test.sh

405 lines
19 KiB
Bash
Raw Normal View History

Sourced test snippets: remove shebang and make non-executable They are installed non-executable, which makes Debian's Lintian packaging consistency check complain that #! is only useful in executable scripts. But in fact they are not useful to execute directly (they rely on setup being done in the script that sources them), so just chmod them -x. Closes: #652 Approved by: cgwalters
2017-01-19 14:23:30 +03:00
# This file is to be sourced, not executed
Unify uboot and syslinux test cases The test-admin-deploy-1 was copied into -uboot at some point. But really they should be testing exactly the same thing, except for the bootloader backend. Unify these tests by extracting a common test core.
2014-01-15 18:48:04 +04:00
# Copyright (C) 2011,2014 Colin Walters <walters@verbum.org>
[INCOMPATIBLE CHANGE] Implement new deployment model See https://wiki.gnome.org/OSTree/DeploymentModel2 This is a major rework of the on-disk filesystem layout, and the boot process. OSTree now explicitly supports upgrading kernels, and these upgrades are also atomic. The core concept of the new model is the "deployment list", which is an ordered list of bootable operating system trees. The deployment list is reflected in the bootloader configuration; which has a kernel argument that tells the initramfs (dracut) which operating system root to use. Invidiual notable changes that come along with this: 1) Operating systems should now come with their etc in usr/etc; OSTree will perform a 3-way merge at deployment time, and place etc in the actual root. This avoids the need for a bind mount, and is just a lot cleaner. 2) OSTree no longer bind mounts /root, /home, and /tmp. It is expected that the the OS/ has these as symbolic links into /var. At the moment, OSTree only supports managing syslinux; other bootloader backends will follow.
2013-06-29 19:45:53 +04:00
#
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+
#
[INCOMPATIBLE CHANGE] Implement new deployment model See https://wiki.gnome.org/OSTree/DeploymentModel2 This is a major rework of the on-disk filesystem layout, and the boot process. OSTree now explicitly supports upgrading kernels, and these upgrades are also atomic. The core concept of the new model is the "deployment list", which is an ordered list of bootable operating system trees. The deployment list is reflected in the bootloader configuration; which has a kernel argument that tells the initramfs (dracut) which operating system root to use. Invidiual notable changes that come along with this: 1) Operating systems should now come with their etc in usr/etc; OSTree will perform a 3-way merge at deployment time, and place etc in the actual root. This avoids the need for a bind mount, and is just a lot cleaner. 2) OSTree no longer bind mounts /root, /home, and /tmp. It is expected that the the OS/ has these as symbolic links into /var. At the moment, OSTree only supports managing syslinux; other bootloader backends will follow.
2013-06-29 19:45:53 +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/>.
[INCOMPATIBLE CHANGE] Implement new deployment model See https://wiki.gnome.org/OSTree/DeploymentModel2 This is a major rework of the on-disk filesystem layout, and the boot process. OSTree now explicitly supports upgrading kernels, and these upgrades are also atomic. The core concept of the new model is the "deployment list", which is an ordered list of bootable operating system trees. The deployment list is reflected in the bootloader configuration; which has a kernel argument that tells the initramfs (dracut) which operating system root to use. Invidiual notable changes that come along with this: 1) Operating systems should now come with their etc in usr/etc; OSTree will perform a 3-way merge at deployment time, and place etc in the actual root. This avoids the need for a bind mount, and is just a lot cleaner. 2) OSTree no longer bind mounts /root, /home, and /tmp. It is expected that the the OS/ has these as symbolic links into /var. At the moment, OSTree only supports managing syslinux; other bootloader backends will follow.
2013-06-29 19:45:53 +04:00
tests: Use "bash strict mode" I noticed in the static deltas tests, there were some tests that should have been under `-o pipefail` to ensure we properly propagate errors. There were a few places where we were referencing undefined variables. Overall, this is clearly a good idea IMO.
2016-01-27 19:44:10 +03:00
set -euo pipefail
[INCOMPATIBLE CHANGE] Implement new deployment model See https://wiki.gnome.org/OSTree/DeploymentModel2 This is a major rework of the on-disk filesystem layout, and the boot process. OSTree now explicitly supports upgrading kernels, and these upgrades are also atomic. The core concept of the new model is the "deployment list", which is an ordered list of bootable operating system trees. The deployment list is reflected in the bootloader configuration; which has a kernel argument that tells the initramfs (dracut) which operating system root to use. Invidiual notable changes that come along with this: 1) Operating systems should now come with their etc in usr/etc; OSTree will perform a 3-way merge at deployment time, and place etc in the actual root. This avoids the need for a bind mount, and is just a lot cleaner. 2) OSTree no longer bind mounts /root, /home, and /tmp. It is expected that the the OS/ has these as symbolic links into /var. At the moment, OSTree only supports managing syslinux; other bootloader backends will follow.
2013-06-29 19:45:53 +04:00
deploy: Improve error message for nonexistent stateroot Came up on an internal chat; previously we were only erroring out when trying to do the SELinux labeling for `/var` which was really misleading. Add some other error prefixing while we have the patient open.
2023-10-12 20:22:00 +03:00
echo "1..$((30 + ${extra_admin_tests:-0}))"
admin/init-fs: Add a --modern switch This skips creating the default stuff in the physical sysroot. I don't recall why I did that to be honest; it originated with the first commit of this file. It might not have ever been necessary. In any case, it's not necessary now with Fedora CoreOS, so prune it and let's have a clean `/`. Keep the old behavior by default though to avoid breaking anyone. Closes: #1894 Approved by: ajeddeloh
2019-08-06 04:59:38 +03:00
mkdir sysrootmin
${CMD_PREFIX} ostree admin init-fs --modern sysrootmin
assert_has_dir sysrootmin/boot
assert_has_dir sysrootmin/ostree/repo
assert_not_has_dir sysrootmin/home
rm sysrootmin -rf
echo "ok init-fs --modern"
ostree-sysroot: make simple_write_deployment smarter This is a follow-up to https://github.com/ostreedev/ostree/pull/1097. We make simple_write_deployment smart enough so that it can be used for rpm-ostree's purposes. This is mostly an upstreaming of logic that already existed there. Notably we correctly append NOT_DEFAULT deployments *after* the booted deployment and we now support RETAIN_PENDING and RETAIN_ROLLBACK flags to have more granularity on deployment pruning. Expose these new flags on the CLI using new options (as well as expose the previously existing NOT_DEFAULT flag as --not-as-default). I couldn't add tests for --retain-pending because the merge deployment is always the topmost one. Though I did check that it worked in a VM. Closes: #1110 Approved by: cgwalters
2017-08-23 19:15:46 +03:00
tests: Add a crosscheck for syslinux bootloader config generation And actually wire this one up in admin-test.sh.
2015-05-28 03:08:44 +03:00
function validate_bootloader() {
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
cd ${test_tmpdir};
bootloader=""
if test -f sysroot/boot/syslinux/syslinux.cfg; then
bootloader="syslinux"
elif test -f sysroot/boot/grub2/grub.cfg; then
bootloader="grub2"
fi
if test -n "${bootloader}"; then
$(dirname $0)/bootloader-entries-crosscheck.py sysroot ${bootloader}
fi
cd -
tests: Add a crosscheck for syslinux bootloader config generation And actually wire this one up in admin-test.sh.
2015-05-28 03:08:44 +03:00
}
lib: Add a private helper to abort txns, use in sysroot cleanup Steal some code from flatpak for this, which allows porting a few more things to new style. I started on a public API version of this but was trying to roll some other things into it and it snowballed. Let's do this version since it's easy for now. While here I changed things so that `generate_deployment_refs()` now just uses `_set_ref_immediate()` rather than requring a txn. Also, AFAICS there was no test coverage of `generate_deployment_refs()`; I tried commenting it out and at least `admin-test.sh` passed. Add some coverage of this - I verified that with this commenting out bits of that function cause the test to fail. Closes: #1132 Approved by: jlebon
2017-09-05 22:43:04 +03:00
# Test generate_deployment_refs()
assert_ostree_deployment_refs() {
${CMD_PREFIX} ostree --repo=sysroot/ostree/repo refs ostree | sort > ostree-refs.txt
(for v in "$@"; do echo $v; done) | sort > ostree-refs-expected.txt
diff -u ostree-refs{-expected,}.txt
}
deploy: Bump the mtime on ostree/deploy after deployments finish This allows other processes (e.g. rpm-ostreed) to monitor for external changes (e.g. if someone does `ostree admin undeploy`) in a relatively sane fashion. Specifically, I'm trying to fix: https://github.com/projectatomic/rpm-ostree/issues/220
2016-03-03 00:26:09 +03:00
orig_mtime=$(stat -c '%.Y' sysroot/ostree/deploy)
*: rename master to main in tests & examples
2021-05-07 17:42:37 +03:00
${CMD_PREFIX} ostree --repo=sysroot/ostree/repo pull-local --remote=testos testos-repo testos/buildmain/x86_64-runtime
rev=$(${CMD_PREFIX} ostree --repo=sysroot/ostree/repo rev-parse testos/buildmain/x86_64-runtime)
[INCOMPATIBLE CHANGE] Implement new deployment model See https://wiki.gnome.org/OSTree/DeploymentModel2 This is a major rework of the on-disk filesystem layout, and the boot process. OSTree now explicitly supports upgrading kernels, and these upgrades are also atomic. The core concept of the new model is the "deployment list", which is an ordered list of bootable operating system trees. The deployment list is reflected in the bootloader configuration; which has a kernel argument that tells the initramfs (dracut) which operating system root to use. Invidiual notable changes that come along with this: 1) Operating systems should now come with their etc in usr/etc; OSTree will perform a 3-way merge at deployment time, and place etc in the actual root. This avoids the need for a bind mount, and is just a lot cleaner. 2) OSTree no longer bind mounts /root, /home, and /tmp. It is expected that the the OS/ has these as symbolic links into /var. At the moment, OSTree only supports managing syslinux; other bootloader backends will follow.
2013-06-29 19:45:53 +04:00
export rev
admin/init-fs: Add a --modern switch This skips creating the default stuff in the physical sysroot. I don't recall why I did that to be honest; it originated with the first commit of this file. It might not have ever been necessary. In any case, it's not necessary now with Fedora CoreOS, so prune it and let's have a clean `/`. Keep the old behavior by default though to avoid breaking anyone. Closes: #1894 Approved by: ajeddeloh
2019-08-06 04:59:38 +03:00
# This initial deployment gets kicked off with some kernel arguments
*: rename master to main in tests & examples
2021-05-07 17:42:37 +03:00
${CMD_PREFIX} ostree admin deploy --karg=root=LABEL=MOO --karg=quiet --os=testos testos:testos/buildmain/x86_64-runtime
deploy: Bump the mtime on ostree/deploy after deployments finish This allows other processes (e.g. rpm-ostreed) to monitor for external changes (e.g. if someone does `ostree admin undeploy`) in a relatively sane fashion. Specifically, I'm trying to fix: https://github.com/projectatomic/rpm-ostree/issues/220
2016-03-03 00:26:09 +03:00
new_mtime=$(stat -c '%.Y' sysroot/ostree/deploy)
assert_not_streq "${orig_mtime}" "${new_mtime}"
tests: Export OSTREE_SYSROOT in setup_os_repository Eliminates the need for constantly passing --sysroot=sysroot, but also makes ostree place remote configs for sysroot/ostree/repo in sysroot/etc/ostree/remotes.d where they should have been all along.
2015-07-14 20:30:05 +03:00
${CMD_PREFIX} ostree admin status | tee status.txt
lib/sysroot: Add API to get pending/rollback for given stateroot This imports a function that is used in rpm-ostree, and it's also intended for use by https://github.com/advancedtelematic/aktualizr to display what deployment we're going to boot next after the reboot. Updated-by: Colin Walters <walters@verbum.org> Closes: #897 Approved by: OYTIS
2017-06-01 13:43:50 +03:00
assert_not_file_has_content status.txt "pending"
assert_not_file_has_content status.txt "rollback"
tests: Add a crosscheck for syslinux bootloader config generation And actually wire this one up in admin-test.sh.
2015-05-28 03:08:44 +03:00
validate_bootloader
[INCOMPATIBLE CHANGE] Implement new deployment model See https://wiki.gnome.org/OSTree/DeploymentModel2 This is a major rework of the on-disk filesystem layout, and the boot process. OSTree now explicitly supports upgrading kernels, and these upgrades are also atomic. The core concept of the new model is the "deployment list", which is an ordered list of bootable operating system trees. The deployment list is reflected in the bootloader configuration; which has a kernel argument that tells the initramfs (dracut) which operating system root to use. Invidiual notable changes that come along with this: 1) Operating systems should now come with their etc in usr/etc; OSTree will perform a 3-way merge at deployment time, and place etc in the actual root. This avoids the need for a bind mount, and is just a lot cleaner. 2) OSTree no longer bind mounts /root, /home, and /tmp. It is expected that the the OS/ has these as symbolic links into /var. At the moment, OSTree only supports managing syslinux; other bootloader backends will follow.
2013-06-29 19:45:53 +04:00
Add an API+CLI to inject metadata for bootable OSTree commits I was doing some rpm-ostree work and I wanted to compare two OSTree commits to see if the kernel has changed. I think this should be a lot more natural. Add `ostree commit --bootable` which calls into a new generic library API `ostree_commit_metadata_for_bootable()` that discovers the kernel version and injects it as an `ostree.linux` metadata key. And for extra clarity, add an `ostree.bootable` key. It's interesting because the "core" OSTree layer is all about generic files, but this is adding special APIs around bootable OSTree commits (as opposed to e.g. flatpak as well as things like rpm-ostree's pkgcache refs). Eventually, I'd like to ensure everyone is using this and hard require this metadata key for the `ostree admin deploy` flow - mainly to prevent accidents.
2021-03-11 04:36:13 +03:00
# Test the bootable and linux keys
*: rename master to main in tests & examples
2021-05-07 17:42:37 +03:00
${CMD_PREFIX} ostree --repo=sysroot/ostree/repo --print-metadata-key=ostree.linux show testos:testos/buildmain/x86_64-runtime >out.txt
Add an API+CLI to inject metadata for bootable OSTree commits I was doing some rpm-ostree work and I wanted to compare two OSTree commits to see if the kernel has changed. I think this should be a lot more natural. Add `ostree commit --bootable` which calls into a new generic library API `ostree_commit_metadata_for_bootable()` that discovers the kernel version and injects it as an `ostree.linux` metadata key. And for extra clarity, add an `ostree.bootable` key. It's interesting because the "core" OSTree layer is all about generic files, but this is adding special APIs around bootable OSTree commits (as opposed to e.g. flatpak as well as things like rpm-ostree's pkgcache refs). Eventually, I'd like to ensure everyone is using this and hard require this metadata key for the `ostree admin deploy` flow - mainly to prevent accidents.
2021-03-11 04:36:13 +03:00
assert_file_has_content_literal out.txt 3.6.0
*: rename master to main in tests & examples
2021-05-07 17:42:37 +03:00
${CMD_PREFIX} ostree --repo=sysroot/ostree/repo --print-metadata-key=ostree.bootable show testos:testos/buildmain/x86_64-runtime >out.txt
Add an API+CLI to inject metadata for bootable OSTree commits I was doing some rpm-ostree work and I wanted to compare two OSTree commits to see if the kernel has changed. I think this should be a lot more natural. Add `ostree commit --bootable` which calls into a new generic library API `ostree_commit_metadata_for_bootable()` that discovers the kernel version and injects it as an `ostree.linux` metadata key. And for extra clarity, add an `ostree.bootable` key. It's interesting because the "core" OSTree layer is all about generic files, but this is adding special APIs around bootable OSTree commits (as opposed to e.g. flatpak as well as things like rpm-ostree's pkgcache refs). Eventually, I'd like to ensure everyone is using this and hard require this metadata key for the `ostree admin deploy` flow - mainly to prevent accidents.
2021-03-11 04:36:13 +03:00
assert_file_has_content_literal out.txt true
[INCOMPATIBLE CHANGE] Implement new deployment model See https://wiki.gnome.org/OSTree/DeploymentModel2 This is a major rework of the on-disk filesystem layout, and the boot process. OSTree now explicitly supports upgrading kernels, and these upgrades are also atomic. The core concept of the new model is the "deployment list", which is an ordered list of bootable operating system trees. The deployment list is reflected in the bootloader configuration; which has a kernel argument that tells the initramfs (dracut) which operating system root to use. Invidiual notable changes that come along with this: 1) Operating systems should now come with their etc in usr/etc; OSTree will perform a 3-way merge at deployment time, and place etc in the actual root. This avoids the need for a bind mount, and is just a lot cleaner. 2) OSTree no longer bind mounts /root, /home, and /tmp. It is expected that the the OS/ has these as symbolic links into /var. At the moment, OSTree only supports managing syslinux; other bootloader backends will follow.
2013-06-29 19:45:53 +04:00
echo "ok deploy command"
tests: Export OSTREE_SYSROOT in setup_os_repository Eliminates the need for constantly passing --sysroot=sysroot, but also makes ostree place remote configs for sysroot/ostree/repo in sysroot/etc/ostree/remotes.d where they should have been all along.
2015-07-14 20:30:05 +03:00
${CMD_PREFIX} ostree admin --print-current-dir > curdir
tests: Escape periods when appropriate Don't match any character in a regular expression when we only want to match a period. Closes: #1834 Approved by: rfairley
2019-04-02 05:01:49 +03:00
assert_file_has_content curdir ^`pwd`/sysroot/ostree/deploy/testos/deploy/${rev}\.0$
Test 'ostree admin --print-current-dir' Add a test for the --print-current-dir option https://bugzilla.gnome.org/show_bug.cgi?id=731051
2014-09-26 19:54:04 +04:00
echo "ok --print-current-dir"
deploy: Improve error message for nonexistent stateroot Came up on an internal chat; previously we were only erroring out when trying to do the SELinux labeling for `/var` which was really misleading. Add some other error prefixing while we have the patient open.
2023-10-12 20:22:00 +03:00
if ${CMD_PREFIX} ostree admin deploy --stateroot=nosuchroot testos:testos/buildmain/x86_64-runtime 2>err.txt; then
fatal "deployed to nonexistent root"
fi
assert_file_has_content err.txt "error:.*No such stateroot: nosuchroot"
echo "ok nice error for deploy with no stateroot"
lib: Add a private helper to abort txns, use in sysroot cleanup Steal some code from flatpak for this, which allows porting a few more things to new style. I started on a public API version of this but was trying to roll some other things into it and it snowballed. Let's do this version since it's easy for now. While here I changed things so that `generate_deployment_refs()` now just uses `_set_ref_immediate()` rather than requring a txn. Also, AFAICS there was no test coverage of `generate_deployment_refs()`; I tried commenting it out and at least `admin-test.sh` passed. Add some coverage of this - I verified that with this commenting out bits of that function cause the test to fail. Closes: #1132 Approved by: jlebon
2017-09-05 22:43:04 +03:00
# Test layout of bootloader config and refs
[INCOMPATIBLE CHANGE] Implement new deployment model See https://wiki.gnome.org/OSTree/DeploymentModel2 This is a major rework of the on-disk filesystem layout, and the boot process. OSTree now explicitly supports upgrading kernels, and these upgrades are also atomic. The core concept of the new model is the "deployment list", which is an ordered list of bootable operating system trees. The deployment list is reflected in the bootloader configuration; which has a kernel argument that tells the initramfs (dracut) which operating system root to use. Invidiual notable changes that come along with this: 1) Operating systems should now come with their etc in usr/etc; OSTree will perform a 3-way merge at deployment time, and place etc in the actual root. This avoids the need for a bind mount, and is just a lot cleaner. 2) OSTree no longer bind mounts /root, /home, and /tmp. It is expected that the the OS/ has these as symbolic links into /var. At the moment, OSTree only supports managing syslinux; other bootloader backends will follow.
2013-06-29 19:45:53 +04:00
assert_not_has_dir sysroot/boot/loader.0
assert_has_dir sysroot/boot/loader.1
assert_has_dir sysroot/ostree/boot.1.1
deploy: Change BootLoaderSpec filenames so they can be used for sorting Currently the BLS snippets are named ostree-$ID-$VARIANT_ID-$index.conf, but the BLS config files are actually sorted by using the version field which is the inverse of the index. In most places, _ostree_sysroot_read_boot_loader_configs() is used to get the BLS files and this function already returns them sorted by the version field. The only place where the index trailing number is used is in the ostree-grub-generator script that lists the BLS files to populate the grub config file. But for some bootloaders the BLS filename is the criteria for sorting by taking the filename as a string version. So on these bootloaders the BLS entries will be listed in the reverse order. To avoid that, change the BLS snippets filename to have the version field instead of the index and also to have the version before deployment name. Make the filenames to be of the form ostree-$version-$ID-$VARIANT_ID.conf so the version is before the deployment name. Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Closes: #1654 Approved by: cgwalters
2018-06-27 17:45:43 +03:00
assert_has_file sysroot/boot/loader/entries/ostree-1-testos.conf
assert_file_has_content sysroot/boot/loader/entries/ostree-1-testos.conf 'options.* root=LABEL=MOO'
assert_file_has_content sysroot/boot/loader/entries/ostree-1-testos.conf 'options.* quiet'
[INCOMPATIBLE CHANGE] Implement new deployment model See https://wiki.gnome.org/OSTree/DeploymentModel2 This is a major rework of the on-disk filesystem layout, and the boot process. OSTree now explicitly supports upgrading kernels, and these upgrades are also atomic. The core concept of the new model is the "deployment list", which is an ordered list of bootable operating system trees. The deployment list is reflected in the bootloader configuration; which has a kernel argument that tells the initramfs (dracut) which operating system root to use. Invidiual notable changes that come along with this: 1) Operating systems should now come with their etc in usr/etc; OSTree will perform a 3-way merge at deployment time, and place etc in the actual root. This avoids the need for a bind mount, and is just a lot cleaner. 2) OSTree no longer bind mounts /root, /home, and /tmp. It is expected that the the OS/ has these as symbolic links into /var. At the moment, OSTree only supports managing syslinux; other bootloader backends will follow.
2013-06-29 19:45:53 +04:00
assert_file_has_content sysroot/boot/ostree/testos-${bootcsum}/vmlinuz-3.6.0 'a kernel'
assert_file_has_content sysroot/ostree/deploy/testos/deploy/${rev}.0/etc/os-release 'NAME=TestOS'
assert_file_has_content sysroot/ostree/boot.1/testos/${bootcsum}/0/etc/os-release 'NAME=TestOS'
lib: Add a private helper to abort txns, use in sysroot cleanup Steal some code from flatpak for this, which allows porting a few more things to new style. I started on a public API version of this but was trying to roll some other things into it and it snowballed. Let's do this version since it's easy for now. While here I changed things so that `generate_deployment_refs()` now just uses `_set_ref_immediate()` rather than requring a txn. Also, AFAICS there was no test coverage of `generate_deployment_refs()`; I tried commenting it out and at least `admin-test.sh` passed. Add some coverage of this - I verified that with this commenting out bits of that function cause the test to fail. Closes: #1132 Approved by: jlebon
2017-09-05 22:43:04 +03:00
assert_ostree_deployment_refs 1/1/0
tests: Export OSTREE_SYSROOT in setup_os_repository Eliminates the need for constantly passing --sysroot=sysroot, but also makes ostree place remote configs for sysroot/ostree/repo in sysroot/etc/ostree/remotes.d where they should have been all along.
2015-07-14 20:30:05 +03:00
${CMD_PREFIX} ostree admin status
[INCOMPATIBLE CHANGE] Implement new deployment model See https://wiki.gnome.org/OSTree/DeploymentModel2 This is a major rework of the on-disk filesystem layout, and the boot process. OSTree now explicitly supports upgrading kernels, and these upgrades are also atomic. The core concept of the new model is the "deployment list", which is an ordered list of bootable operating system trees. The deployment list is reflected in the bootloader configuration; which has a kernel argument that tells the initramfs (dracut) which operating system root to use. Invidiual notable changes that come along with this: 1) Operating systems should now come with their etc in usr/etc; OSTree will perform a 3-way merge at deployment time, and place etc in the actual root. This avoids the need for a bind mount, and is just a lot cleaner. 2) OSTree no longer bind mounts /root, /home, and /tmp. It is expected that the the OS/ has these as symbolic links into /var. At the moment, OSTree only supports managing syslinux; other bootloader backends will follow.
2013-06-29 19:45:53 +04:00
echo "ok layout"
*: rename master to main in tests & examples
2021-05-07 17:42:37 +03:00
if ${CMD_PREFIX} ostree admin deploy --stage --os=testos testos:testos/buildmain/x86_64-runtime 2>err.txt; then
lib/deploy: Throw an error if trying to stage when not ostree-booted There's no reason to do this. I didn't actually hit this problem, but it's a corner case that just occurred to me while working on the code. I think callers should be adapted to skip trying to use staging if there's no booted deployment. Closes: #1568 Approved by: jlebon
2018-05-01 23:36:03 +03:00
fatal "staged when not booted"
fi
sysroot: Add _require_booted_deployment() API This is a common pattern that is replicated both in our code and in rpm-ostree a lot. Let's add a canonical API.
2021-03-17 17:03:49 +03:00
assert_file_has_content_literal err.txt "Cannot stage deployment: Not currently booted into an OSTree system"
lib/deploy: Throw an error if trying to stage when not ostree-booted There's no reason to do this. I didn't actually hit this problem, but it's a corner case that just occurred to me while working on the code. I think callers should be adapted to skip trying to use staging if there's no booted deployment. Closes: #1568 Approved by: jlebon
2018-05-01 23:36:03 +03:00
echo "ok staging does not work when not booted"
deploy: Bump the mtime on ostree/deploy after deployments finish This allows other processes (e.g. rpm-ostreed) to monitor for external changes (e.g. if someone does `ostree admin undeploy`) in a relatively sane fashion. Specifically, I'm trying to fix: https://github.com/projectatomic/rpm-ostree/issues/220
2016-03-03 00:26:09 +03:00
orig_mtime=$(stat -c '%.Y' sysroot/ostree/deploy)
admin-deploy: Add `--stateroot` as alias for `--os` To further help deprecate the confusing "osname" terminology.
2023-08-17 23:48:05 +03:00
${CMD_PREFIX} ostree admin deploy --stateroot=testos testos:testos/buildmain/x86_64-runtime
deploy: Bump the mtime on ostree/deploy after deployments finish This allows other processes (e.g. rpm-ostreed) to monitor for external changes (e.g. if someone does `ostree admin undeploy`) in a relatively sane fashion. Specifically, I'm trying to fix: https://github.com/projectatomic/rpm-ostree/issues/220
2016-03-03 00:26:09 +03:00
new_mtime=$(stat -c '%.Y' sysroot/ostree/deploy)
assert_not_streq "${orig_mtime}" "${new_mtime}"
[INCOMPATIBLE CHANGE] Implement new deployment model See https://wiki.gnome.org/OSTree/DeploymentModel2 This is a major rework of the on-disk filesystem layout, and the boot process. OSTree now explicitly supports upgrading kernels, and these upgrades are also atomic. The core concept of the new model is the "deployment list", which is an ordered list of bootable operating system trees. The deployment list is reflected in the bootloader configuration; which has a kernel argument that tells the initramfs (dracut) which operating system root to use. Invidiual notable changes that come along with this: 1) Operating systems should now come with their etc in usr/etc; OSTree will perform a 3-way merge at deployment time, and place etc in the actual root. This avoids the need for a bind mount, and is just a lot cleaner. 2) OSTree no longer bind mounts /root, /home, and /tmp. It is expected that the the OS/ has these as symbolic links into /var. At the moment, OSTree only supports managing syslinux; other bootloader backends will follow.
2013-06-29 19:45:53 +04:00
# Need a new bootversion, sine we now have two deployments
assert_has_dir sysroot/boot/loader.0
assert_not_has_dir sysroot/boot/loader.1
assert_has_dir sysroot/ostree/boot.0.1
assert_not_has_dir sysroot/ostree/boot.0.0
assert_not_has_dir sysroot/ostree/boot.1.0
assert_not_has_dir sysroot/ostree/boot.1.1
# Ensure we propagated kernel arguments from previous deployment
deploy: Change BootLoaderSpec filenames so they can be used for sorting Currently the BLS snippets are named ostree-$ID-$VARIANT_ID-$index.conf, but the BLS config files are actually sorted by using the version field which is the inverse of the index. In most places, _ostree_sysroot_read_boot_loader_configs() is used to get the BLS files and this function already returns them sorted by the version field. The only place where the index trailing number is used is in the ostree-grub-generator script that lists the BLS files to populate the grub config file. But for some bootloaders the BLS filename is the criteria for sorting by taking the filename as a string version. So on these bootloaders the BLS entries will be listed in the reverse order. To avoid that, change the BLS snippets filename to have the version field instead of the index and also to have the version before deployment name. Make the filenames to be of the form ostree-$version-$ID-$VARIANT_ID.conf so the version is before the deployment name. Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Closes: #1654 Approved by: cgwalters
2018-06-27 17:45:43 +03:00
assert_file_has_content sysroot/boot/loader/entries/ostree-2-testos.conf 'options.* root=LABEL=MOO'
[INCOMPATIBLE CHANGE] Implement new deployment model See https://wiki.gnome.org/OSTree/DeploymentModel2 This is a major rework of the on-disk filesystem layout, and the boot process. OSTree now explicitly supports upgrading kernels, and these upgrades are also atomic. The core concept of the new model is the "deployment list", which is an ordered list of bootable operating system trees. The deployment list is reflected in the bootloader configuration; which has a kernel argument that tells the initramfs (dracut) which operating system root to use. Invidiual notable changes that come along with this: 1) Operating systems should now come with their etc in usr/etc; OSTree will perform a 3-way merge at deployment time, and place etc in the actual root. This avoids the need for a bind mount, and is just a lot cleaner. 2) OSTree no longer bind mounts /root, /home, and /tmp. It is expected that the the OS/ has these as symbolic links into /var. At the moment, OSTree only supports managing syslinux; other bootloader backends will follow.
2013-06-29 19:45:53 +04:00
assert_file_has_content sysroot/ostree/deploy/testos/deploy/${rev}.1/etc/os-release 'NAME=TestOS'
assert_file_has_content sysroot/ostree/boot.0/testos/${bootcsum}/0/etc/os-release 'NAME=TestOS'
lib: Add a private helper to abort txns, use in sysroot cleanup Steal some code from flatpak for this, which allows porting a few more things to new style. I started on a public API version of this but was trying to roll some other things into it and it snowballed. Let's do this version since it's easy for now. While here I changed things so that `generate_deployment_refs()` now just uses `_set_ref_immediate()` rather than requring a txn. Also, AFAICS there was no test coverage of `generate_deployment_refs()`; I tried commenting it out and at least `admin-test.sh` passed. Add some coverage of this - I verified that with this commenting out bits of that function cause the test to fail. Closes: #1132 Approved by: jlebon
2017-09-05 22:43:04 +03:00
assert_ostree_deployment_refs 0/1/{0,1}
tests: Export OSTREE_SYSROOT in setup_os_repository Eliminates the need for constantly passing --sysroot=sysroot, but also makes ostree place remote configs for sysroot/ostree/repo in sysroot/etc/ostree/remotes.d where they should have been all along.
2015-07-14 20:30:05 +03:00
${CMD_PREFIX} ostree admin status
tests: Add a crosscheck for syslinux bootloader config generation And actually wire this one up in admin-test.sh.
2015-05-28 03:08:44 +03:00
validate_bootloader
admin: Write out correct version fields in boot/loader/entries files Before, we were writing the "bootversion", which is either 0 or 1, for all entries. This is completely wrong; the idea of the "version" field is to compare between entries. Fix this by writing out the inverted index - internally, index 0 is the *first* boot entry, so we give it the highest version number, and index N is the last, so give it version 0. Then fix the deployment sorting code to correctly reverse the version number comparison, so we read back the right order. In practice before this bug didn't matter because "normally" you only have at most two deployments. https://bugzilla.gnome.org/show_bug.cgi?id=706546
2013-08-22 02:48:00 +04:00
[INCOMPATIBLE CHANGE] Implement new deployment model See https://wiki.gnome.org/OSTree/DeploymentModel2 This is a major rework of the on-disk filesystem layout, and the boot process. OSTree now explicitly supports upgrading kernels, and these upgrades are also atomic. The core concept of the new model is the "deployment list", which is an ordered list of bootable operating system trees. The deployment list is reflected in the bootloader configuration; which has a kernel argument that tells the initramfs (dracut) which operating system root to use. Invidiual notable changes that come along with this: 1) Operating systems should now come with their etc in usr/etc; OSTree will perform a 3-way merge at deployment time, and place etc in the actual root. This avoids the need for a bind mount, and is just a lot cleaner. 2) OSTree no longer bind mounts /root, /home, and /tmp. It is expected that the the OS/ has these as symbolic links into /var. At the moment, OSTree only supports managing syslinux; other bootloader backends will follow.
2013-06-29 19:45:53 +04:00
echo "ok second deploy"
*: rename master to main in tests & examples
2021-05-07 17:42:37 +03:00
${CMD_PREFIX} ostree admin deploy --os=testos testos:testos/buildmain/x86_64-runtime
[INCOMPATIBLE CHANGE] Implement new deployment model See https://wiki.gnome.org/OSTree/DeploymentModel2 This is a major rework of the on-disk filesystem layout, and the boot process. OSTree now explicitly supports upgrading kernels, and these upgrades are also atomic. The core concept of the new model is the "deployment list", which is an ordered list of bootable operating system trees. The deployment list is reflected in the bootloader configuration; which has a kernel argument that tells the initramfs (dracut) which operating system root to use. Invidiual notable changes that come along with this: 1) Operating systems should now come with their etc in usr/etc; OSTree will perform a 3-way merge at deployment time, and place etc in the actual root. This avoids the need for a bind mount, and is just a lot cleaner. 2) OSTree no longer bind mounts /root, /home, and /tmp. It is expected that the the OS/ has these as symbolic links into /var. At the moment, OSTree only supports managing syslinux; other bootloader backends will follow.
2013-06-29 19:45:53 +04:00
# Keep the same bootversion
assert_has_dir sysroot/boot/loader.0
assert_not_has_dir sysroot/boot/loader.1
# But swap subbootversion
assert_has_dir sysroot/ostree/boot.0.0
assert_not_has_dir sysroot/ostree/boot.0.1
lib: Add a private helper to abort txns, use in sysroot cleanup Steal some code from flatpak for this, which allows porting a few more things to new style. I started on a public API version of this but was trying to roll some other things into it and it snowballed. Let's do this version since it's easy for now. While here I changed things so that `generate_deployment_refs()` now just uses `_set_ref_immediate()` rather than requring a txn. Also, AFAICS there was no test coverage of `generate_deployment_refs()`; I tried commenting it out and at least `admin-test.sh` passed. Add some coverage of this - I verified that with this commenting out bits of that function cause the test to fail. Closes: #1132 Approved by: jlebon
2017-09-05 22:43:04 +03:00
assert_ostree_deployment_refs 0/0/{0,1}
tests: Export OSTREE_SYSROOT in setup_os_repository Eliminates the need for constantly passing --sysroot=sysroot, but also makes ostree place remote configs for sysroot/ostree/repo in sysroot/etc/ostree/remotes.d where they should have been all along.
2015-07-14 20:30:05 +03:00
${CMD_PREFIX} ostree admin status
tests: Add a crosscheck for syslinux bootloader config generation And actually wire this one up in admin-test.sh.
2015-05-28 03:08:44 +03:00
validate_bootloader
[INCOMPATIBLE CHANGE] Implement new deployment model See https://wiki.gnome.org/OSTree/DeploymentModel2 This is a major rework of the on-disk filesystem layout, and the boot process. OSTree now explicitly supports upgrading kernels, and these upgrades are also atomic. The core concept of the new model is the "deployment list", which is an ordered list of bootable operating system trees. The deployment list is reflected in the bootloader configuration; which has a kernel argument that tells the initramfs (dracut) which operating system root to use. Invidiual notable changes that come along with this: 1) Operating systems should now come with their etc in usr/etc; OSTree will perform a 3-way merge at deployment time, and place etc in the actual root. This avoids the need for a bind mount, and is just a lot cleaner. 2) OSTree no longer bind mounts /root, /home, and /tmp. It is expected that the the OS/ has these as symbolic links into /var. At the moment, OSTree only supports managing syslinux; other bootloader backends will follow.
2013-06-29 19:45:53 +04:00
echo "ok third deploy (swap)"
tests: Export OSTREE_SYSROOT in setup_os_repository Eliminates the need for constantly passing --sysroot=sysroot, but also makes ostree place remote configs for sysroot/ostree/repo in sysroot/etc/ostree/remotes.d where they should have been all along.
2015-07-14 20:30:05 +03:00
${CMD_PREFIX} ostree admin os-init otheros
sysroot: Error out on deploy --os=<unknown> which has not been initialized We should hard require "ostree admin os-init foo" before letting deployments go there; it's too easy to typo the argument.
2014-01-09 03:29:05 +04:00
*: rename master to main in tests & examples
2021-05-07 17:42:37 +03:00
${CMD_PREFIX} ostree admin deploy --os=otheros testos/buildmain/x86_64-runtime
[INCOMPATIBLE CHANGE] Implement new deployment model See https://wiki.gnome.org/OSTree/DeploymentModel2 This is a major rework of the on-disk filesystem layout, and the boot process. OSTree now explicitly supports upgrading kernels, and these upgrades are also atomic. The core concept of the new model is the "deployment list", which is an ordered list of bootable operating system trees. The deployment list is reflected in the bootloader configuration; which has a kernel argument that tells the initramfs (dracut) which operating system root to use. Invidiual notable changes that come along with this: 1) Operating systems should now come with their etc in usr/etc; OSTree will perform a 3-way merge at deployment time, and place etc in the actual root. This avoids the need for a bind mount, and is just a lot cleaner. 2) OSTree no longer bind mounts /root, /home, and /tmp. It is expected that the the OS/ has these as symbolic links into /var. At the moment, OSTree only supports managing syslinux; other bootloader backends will follow.
2013-06-29 19:45:53 +04:00
assert_not_has_dir sysroot/boot/loader.0
assert_has_dir sysroot/boot/loader.1
deploy: Change BootLoaderSpec filenames so they can be used for sorting Currently the BLS snippets are named ostree-$ID-$VARIANT_ID-$index.conf, but the BLS config files are actually sorted by using the version field which is the inverse of the index. In most places, _ostree_sysroot_read_boot_loader_configs() is used to get the BLS files and this function already returns them sorted by the version field. The only place where the index trailing number is used is in the ostree-grub-generator script that lists the BLS files to populate the grub config file. But for some bootloaders the BLS filename is the criteria for sorting by taking the filename as a string version. So on these bootloaders the BLS entries will be listed in the reverse order. To avoid that, change the BLS snippets filename to have the version field instead of the index and also to have the version before deployment name. Make the filenames to be of the form ostree-$version-$ID-$VARIANT_ID.conf so the version is before the deployment name. Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Closes: #1654 Approved by: cgwalters
2018-06-27 17:45:43 +03:00
assert_has_file sysroot/boot/loader/entries/ostree-2-testos.conf
assert_has_file sysroot/boot/loader/entries/ostree-3-otheros.conf
[INCOMPATIBLE CHANGE] Implement new deployment model See https://wiki.gnome.org/OSTree/DeploymentModel2 This is a major rework of the on-disk filesystem layout, and the boot process. OSTree now explicitly supports upgrading kernels, and these upgrades are also atomic. The core concept of the new model is the "deployment list", which is an ordered list of bootable operating system trees. The deployment list is reflected in the bootloader configuration; which has a kernel argument that tells the initramfs (dracut) which operating system root to use. Invidiual notable changes that come along with this: 1) Operating systems should now come with their etc in usr/etc; OSTree will perform a 3-way merge at deployment time, and place etc in the actual root. This avoids the need for a bind mount, and is just a lot cleaner. 2) OSTree no longer bind mounts /root, /home, and /tmp. It is expected that the the OS/ has these as symbolic links into /var. At the moment, OSTree only supports managing syslinux; other bootloader backends will follow.
2013-06-29 19:45:53 +04:00
assert_file_has_content sysroot/ostree/deploy/testos/deploy/${rev}.1/etc/os-release 'NAME=TestOS'
assert_file_has_content sysroot/ostree/deploy/otheros/deploy/${rev}.0/etc/os-release 'NAME=TestOS'
lib: Add a private helper to abort txns, use in sysroot cleanup Steal some code from flatpak for this, which allows porting a few more things to new style. I started on a public API version of this but was trying to roll some other things into it and it snowballed. Let's do this version since it's easy for now. While here I changed things so that `generate_deployment_refs()` now just uses `_set_ref_immediate()` rather than requring a txn. Also, AFAICS there was no test coverage of `generate_deployment_refs()`; I tried commenting it out and at least `admin-test.sh` passed. Add some coverage of this - I verified that with this commenting out bits of that function cause the test to fail. Closes: #1132 Approved by: jlebon
2017-09-05 22:43:04 +03:00
assert_ostree_deployment_refs 1/1/{0,1,2}
tests: Export OSTREE_SYSROOT in setup_os_repository Eliminates the need for constantly passing --sysroot=sysroot, but also makes ostree place remote configs for sysroot/ostree/repo in sysroot/etc/ostree/remotes.d where they should have been all along.
2015-07-14 20:30:05 +03:00
${CMD_PREFIX} ostree admin status
tests: Add a crosscheck for syslinux bootloader config generation And actually wire this one up in admin-test.sh.
2015-05-28 03:08:44 +03:00
validate_bootloader
[INCOMPATIBLE CHANGE] Implement new deployment model See https://wiki.gnome.org/OSTree/DeploymentModel2 This is a major rework of the on-disk filesystem layout, and the boot process. OSTree now explicitly supports upgrading kernels, and these upgrades are also atomic. The core concept of the new model is the "deployment list", which is an ordered list of bootable operating system trees. The deployment list is reflected in the bootloader configuration; which has a kernel argument that tells the initramfs (dracut) which operating system root to use. Invidiual notable changes that come along with this: 1) Operating systems should now come with their etc in usr/etc; OSTree will perform a 3-way merge at deployment time, and place etc in the actual root. This avoids the need for a bind mount, and is just a lot cleaner. 2) OSTree no longer bind mounts /root, /home, and /tmp. It is expected that the the OS/ has these as symbolic links into /var. At the moment, OSTree only supports managing syslinux; other bootloader backends will follow.
2013-06-29 19:45:53 +04:00
echo "ok independent deploy"
*: rename master to main in tests & examples
2021-05-07 17:42:37 +03:00
${CMD_PREFIX} ostree admin deploy --retain --os=testos testos:testos/buildmain/x86_64-runtime
[INCOMPATIBLE CHANGE] Implement new deployment model See https://wiki.gnome.org/OSTree/DeploymentModel2 This is a major rework of the on-disk filesystem layout, and the boot process. OSTree now explicitly supports upgrading kernels, and these upgrades are also atomic. The core concept of the new model is the "deployment list", which is an ordered list of bootable operating system trees. The deployment list is reflected in the bootloader configuration; which has a kernel argument that tells the initramfs (dracut) which operating system root to use. Invidiual notable changes that come along with this: 1) Operating systems should now come with their etc in usr/etc; OSTree will perform a 3-way merge at deployment time, and place etc in the actual root. This avoids the need for a bind mount, and is just a lot cleaner. 2) OSTree no longer bind mounts /root, /home, and /tmp. It is expected that the the OS/ has these as symbolic links into /var. At the moment, OSTree only supports managing syslinux; other bootloader backends will follow.
2013-06-29 19:45:53 +04:00
assert_has_dir sysroot/boot/loader.0
assert_not_has_dir sysroot/boot/loader.1
deploy: Change BootLoaderSpec filenames so they can be used for sorting Currently the BLS snippets are named ostree-$ID-$VARIANT_ID-$index.conf, but the BLS config files are actually sorted by using the version field which is the inverse of the index. In most places, _ostree_sysroot_read_boot_loader_configs() is used to get the BLS files and this function already returns them sorted by the version field. The only place where the index trailing number is used is in the ostree-grub-generator script that lists the BLS files to populate the grub config file. But for some bootloaders the BLS filename is the criteria for sorting by taking the filename as a string version. So on these bootloaders the BLS entries will be listed in the reverse order. To avoid that, change the BLS snippets filename to have the version field instead of the index and also to have the version before deployment name. Make the filenames to be of the form ostree-$version-$ID-$VARIANT_ID.conf so the version is before the deployment name. Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Closes: #1654 Approved by: cgwalters
2018-06-27 17:45:43 +03:00
assert_has_file sysroot/boot/loader/entries/ostree-4-testos.conf
[INCOMPATIBLE CHANGE] Implement new deployment model See https://wiki.gnome.org/OSTree/DeploymentModel2 This is a major rework of the on-disk filesystem layout, and the boot process. OSTree now explicitly supports upgrading kernels, and these upgrades are also atomic. The core concept of the new model is the "deployment list", which is an ordered list of bootable operating system trees. The deployment list is reflected in the bootloader configuration; which has a kernel argument that tells the initramfs (dracut) which operating system root to use. Invidiual notable changes that come along with this: 1) Operating systems should now come with their etc in usr/etc; OSTree will perform a 3-way merge at deployment time, and place etc in the actual root. This avoids the need for a bind mount, and is just a lot cleaner. 2) OSTree no longer bind mounts /root, /home, and /tmp. It is expected that the the OS/ has these as symbolic links into /var. At the moment, OSTree only supports managing syslinux; other bootloader backends will follow.
2013-06-29 19:45:53 +04:00
assert_file_has_content sysroot/ostree/deploy/testos/deploy/${rev}.2/etc/os-release 'NAME=TestOS'
deploy: Change BootLoaderSpec filenames so they can be used for sorting Currently the BLS snippets are named ostree-$ID-$VARIANT_ID-$index.conf, but the BLS config files are actually sorted by using the version field which is the inverse of the index. In most places, _ostree_sysroot_read_boot_loader_configs() is used to get the BLS files and this function already returns them sorted by the version field. The only place where the index trailing number is used is in the ostree-grub-generator script that lists the BLS files to populate the grub config file. But for some bootloaders the BLS filename is the criteria for sorting by taking the filename as a string version. So on these bootloaders the BLS entries will be listed in the reverse order. To avoid that, change the BLS snippets filename to have the version field instead of the index and also to have the version before deployment name. Make the filenames to be of the form ostree-$version-$ID-$VARIANT_ID.conf so the version is before the deployment name. Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Closes: #1654 Approved by: cgwalters
2018-06-27 17:45:43 +03:00
assert_has_file sysroot/boot/loader/entries/ostree-2-testos.conf
[INCOMPATIBLE CHANGE] Implement new deployment model See https://wiki.gnome.org/OSTree/DeploymentModel2 This is a major rework of the on-disk filesystem layout, and the boot process. OSTree now explicitly supports upgrading kernels, and these upgrades are also atomic. The core concept of the new model is the "deployment list", which is an ordered list of bootable operating system trees. The deployment list is reflected in the bootloader configuration; which has a kernel argument that tells the initramfs (dracut) which operating system root to use. Invidiual notable changes that come along with this: 1) Operating systems should now come with their etc in usr/etc; OSTree will perform a 3-way merge at deployment time, and place etc in the actual root. This avoids the need for a bind mount, and is just a lot cleaner. 2) OSTree no longer bind mounts /root, /home, and /tmp. It is expected that the the OS/ has these as symbolic links into /var. At the moment, OSTree only supports managing syslinux; other bootloader backends will follow.
2013-06-29 19:45:53 +04:00
assert_file_has_content sysroot/ostree/deploy/testos/deploy/${rev}.3/etc/os-release 'NAME=TestOS'
tests: Export OSTREE_SYSROOT in setup_os_repository Eliminates the need for constantly passing --sysroot=sysroot, but also makes ostree place remote configs for sysroot/ostree/repo in sysroot/etc/ostree/remotes.d where they should have been all along.
2015-07-14 20:30:05 +03:00
${CMD_PREFIX} ostree admin status
lib: Add a private helper to abort txns, use in sysroot cleanup Steal some code from flatpak for this, which allows porting a few more things to new style. I started on a public API version of this but was trying to roll some other things into it and it snowballed. Let's do this version since it's easy for now. While here I changed things so that `generate_deployment_refs()` now just uses `_set_ref_immediate()` rather than requring a txn. Also, AFAICS there was no test coverage of `generate_deployment_refs()`; I tried commenting it out and at least `admin-test.sh` passed. Add some coverage of this - I verified that with this commenting out bits of that function cause the test to fail. Closes: #1132 Approved by: jlebon
2017-09-05 22:43:04 +03:00
assert_ostree_deployment_refs 0/1/{0,1,2,3}
tests: Add a crosscheck for syslinux bootloader config generation And actually wire this one up in admin-test.sh.
2015-05-28 03:08:44 +03:00
validate_bootloader
[INCOMPATIBLE CHANGE] Implement new deployment model See https://wiki.gnome.org/OSTree/DeploymentModel2 This is a major rework of the on-disk filesystem layout, and the boot process. OSTree now explicitly supports upgrading kernels, and these upgrades are also atomic. The core concept of the new model is the "deployment list", which is an ordered list of bootable operating system trees. The deployment list is reflected in the bootloader configuration; which has a kernel argument that tells the initramfs (dracut) which operating system root to use. Invidiual notable changes that come along with this: 1) Operating systems should now come with their etc in usr/etc; OSTree will perform a 3-way merge at deployment time, and place etc in the actual root. This avoids the need for a bind mount, and is just a lot cleaner. 2) OSTree no longer bind mounts /root, /home, and /tmp. It is expected that the the OS/ has these as symbolic links into /var. At the moment, OSTree only supports managing syslinux; other bootloader backends will follow.
2013-06-29 19:45:53 +04:00
echo "ok fourth deploy (retain)"
echo "a new local config file" > sysroot/ostree/deploy/testos/deploy/${rev}.3/etc/a-new-config-file
sysroot: Handle deleting directories in /etc We need to use the full shutil_rm_rf() in order to actually delete complete directories. Test suite code based on a patch from Sjoerd Simons <sjored@luon.net> https://bugzilla.gnome.org/show_bug.cgi?id=710097
2013-10-15 22:11:43 +04:00
rm -r sysroot/ostree/deploy/testos/deploy/${rev}.3/etc/testdirectory
[INCOMPATIBLE CHANGE] Implement new deployment model See https://wiki.gnome.org/OSTree/DeploymentModel2 This is a major rework of the on-disk filesystem layout, and the boot process. OSTree now explicitly supports upgrading kernels, and these upgrades are also atomic. The core concept of the new model is the "deployment list", which is an ordered list of bootable operating system trees. The deployment list is reflected in the bootloader configuration; which has a kernel argument that tells the initramfs (dracut) which operating system root to use. Invidiual notable changes that come along with this: 1) Operating systems should now come with their etc in usr/etc; OSTree will perform a 3-way merge at deployment time, and place etc in the actual root. This avoids the need for a bind mount, and is just a lot cleaner. 2) OSTree no longer bind mounts /root, /home, and /tmp. It is expected that the the OS/ has these as symbolic links into /var. At the moment, OSTree only supports managing syslinux; other bootloader backends will follow.
2013-06-29 19:45:53 +04:00
rm sysroot/ostree/deploy/testos/deploy/${rev}.3/etc/aconfigfile
ln -s /ENOENT sysroot/ostree/deploy/testos/deploy/${rev}.3/etc/a-new-broken-symlink
*: rename master to main in tests & examples
2021-05-07 17:42:37 +03:00
${CMD_PREFIX} ostree admin deploy --retain --os=testos testos:testos/buildmain/x86_64-runtime
ostree-sysroot: make simple_write_deployment smarter This is a follow-up to https://github.com/ostreedev/ostree/pull/1097. We make simple_write_deployment smart enough so that it can be used for rpm-ostree's purposes. This is mostly an upstreaming of logic that already existed there. Notably we correctly append NOT_DEFAULT deployments *after* the booted deployment and we now support RETAIN_PENDING and RETAIN_ROLLBACK flags to have more granularity on deployment pruning. Expose these new flags on the CLI using new options (as well as expose the previously existing NOT_DEFAULT flag as --not-as-default). I couldn't add tests for --retain-pending because the merge deployment is always the topmost one. Though I did check that it worked in a VM. Closes: #1110 Approved by: cgwalters
2017-08-23 19:15:46 +03:00
assert_not_has_dir sysroot/boot/loader.0
assert_has_dir sysroot/boot/loader.1
tests: Better error message if target is not a symlink I broke the code for this and ended up adding this to debug it. Closes: #1535 Approved by: jlebon
2018-04-11 20:31:18 +03:00
link=sysroot/ostree/deploy/testos/deploy/${rev}.4/etc/a-new-broken-symlink
if ! test -L ${link}; then
ls -al ${link}
fatal "Not a symlink: ${link}"
fi
linktarget=$(readlink ${link})
assert_streq "${linktarget}" /ENOENT
[INCOMPATIBLE CHANGE] Implement new deployment model See https://wiki.gnome.org/OSTree/DeploymentModel2 This is a major rework of the on-disk filesystem layout, and the boot process. OSTree now explicitly supports upgrading kernels, and these upgrades are also atomic. The core concept of the new model is the "deployment list", which is an ordered list of bootable operating system trees. The deployment list is reflected in the bootloader configuration; which has a kernel argument that tells the initramfs (dracut) which operating system root to use. Invidiual notable changes that come along with this: 1) Operating systems should now come with their etc in usr/etc; OSTree will perform a 3-way merge at deployment time, and place etc in the actual root. This avoids the need for a bind mount, and is just a lot cleaner. 2) OSTree no longer bind mounts /root, /home, and /tmp. It is expected that the the OS/ has these as symbolic links into /var. At the moment, OSTree only supports managing syslinux; other bootloader backends will follow.
2013-06-29 19:45:53 +04:00
assert_file_has_content sysroot/ostree/deploy/testos/deploy/${rev}.3/etc/os-release 'NAME=TestOS'
assert_file_has_content sysroot/ostree/deploy/testos/deploy/${rev}.4/etc/os-release 'NAME=TestOS'
assert_file_has_content sysroot/ostree/deploy/testos/deploy/${rev}.4/etc/a-new-config-file 'a new local config file'
assert_not_has_file sysroot/ostree/deploy/testos/deploy/${rev}.4/etc/aconfigfile
tests: Export OSTREE_SYSROOT in setup_os_repository Eliminates the need for constantly passing --sysroot=sysroot, but also makes ostree place remote configs for sysroot/ostree/repo in sysroot/etc/ostree/remotes.d where they should have been all along.
2015-07-14 20:30:05 +03:00
${CMD_PREFIX} ostree admin status
tests: Add a crosscheck for syslinux bootloader config generation And actually wire this one up in admin-test.sh.
2015-05-28 03:08:44 +03:00
validate_bootloader
[INCOMPATIBLE CHANGE] Implement new deployment model See https://wiki.gnome.org/OSTree/DeploymentModel2 This is a major rework of the on-disk filesystem layout, and the boot process. OSTree now explicitly supports upgrading kernels, and these upgrades are also atomic. The core concept of the new model is the "deployment list", which is an ordered list of bootable operating system trees. The deployment list is reflected in the bootloader configuration; which has a kernel argument that tells the initramfs (dracut) which operating system root to use. Invidiual notable changes that come along with this: 1) Operating systems should now come with their etc in usr/etc; OSTree will perform a 3-way merge at deployment time, and place etc in the actual root. This avoids the need for a bind mount, and is just a lot cleaner. 2) OSTree no longer bind mounts /root, /home, and /tmp. It is expected that the the OS/ has these as symbolic links into /var. At the moment, OSTree only supports managing syslinux; other bootloader backends will follow.
2013-06-29 19:45:53 +04:00
echo "ok deploy with modified /etc"
ostree-sysroot: make simple_write_deployment smarter This is a follow-up to https://github.com/ostreedev/ostree/pull/1097. We make simple_write_deployment smart enough so that it can be used for rpm-ostree's purposes. This is mostly an upstreaming of logic that already existed there. Notably we correctly append NOT_DEFAULT deployments *after* the booted deployment and we now support RETAIN_PENDING and RETAIN_ROLLBACK flags to have more granularity on deployment pruning. Expose these new flags on the CLI using new options (as well as expose the previously existing NOT_DEFAULT flag as --not-as-default). I couldn't add tests for --retain-pending because the merge deployment is always the topmost one. Though I did check that it worked in a VM. Closes: #1110 Approved by: cgwalters
2017-08-23 19:15:46 +03:00
# we now have 5 deployments, let's bring that back down to 1
for i in $(seq 4); do
${CMD_PREFIX} ostree admin undeploy 0
done
deploy: Change BootLoaderSpec filenames so they can be used for sorting Currently the BLS snippets are named ostree-$ID-$VARIANT_ID-$index.conf, but the BLS config files are actually sorted by using the version field which is the inverse of the index. In most places, _ostree_sysroot_read_boot_loader_configs() is used to get the BLS files and this function already returns them sorted by the version field. The only place where the index trailing number is used is in the ostree-grub-generator script that lists the BLS files to populate the grub config file. But for some bootloaders the BLS filename is the criteria for sorting by taking the filename as a string version. So on these bootloaders the BLS entries will be listed in the reverse order. To avoid that, change the BLS snippets filename to have the version field instead of the index and also to have the version before deployment name. Make the filenames to be of the form ostree-$version-$ID-$VARIANT_ID.conf so the version is before the deployment name. Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Closes: #1654 Approved by: cgwalters
2018-06-27 17:45:43 +03:00
assert_has_file sysroot/boot/loader/entries/ostree-1-testos.conf
assert_not_has_file sysroot/boot/loader/entries/ostree-2-testos.conf
assert_not_has_file sysroot/boot/loader/entries/ostree-3-otheros.conf
*: rename master to main in tests & examples
2021-05-07 17:42:37 +03:00
${CMD_PREFIX} ostree admin deploy --not-as-default --os=otheros testos:testos/buildmain/x86_64-runtime
ostree-sysroot: make simple_write_deployment smarter This is a follow-up to https://github.com/ostreedev/ostree/pull/1097. We make simple_write_deployment smart enough so that it can be used for rpm-ostree's purposes. This is mostly an upstreaming of logic that already existed there. Notably we correctly append NOT_DEFAULT deployments *after* the booted deployment and we now support RETAIN_PENDING and RETAIN_ROLLBACK flags to have more granularity on deployment pruning. Expose these new flags on the CLI using new options (as well as expose the previously existing NOT_DEFAULT flag as --not-as-default). I couldn't add tests for --retain-pending because the merge deployment is always the topmost one. Though I did check that it worked in a VM. Closes: #1110 Approved by: cgwalters
2017-08-23 19:15:46 +03:00
assert_has_dir sysroot/boot/loader.0
assert_not_has_dir sysroot/boot/loader.1
deploy: Change BootLoaderSpec filenames so they can be used for sorting Currently the BLS snippets are named ostree-$ID-$VARIANT_ID-$index.conf, but the BLS config files are actually sorted by using the version field which is the inverse of the index. In most places, _ostree_sysroot_read_boot_loader_configs() is used to get the BLS files and this function already returns them sorted by the version field. The only place where the index trailing number is used is in the ostree-grub-generator script that lists the BLS files to populate the grub config file. But for some bootloaders the BLS filename is the criteria for sorting by taking the filename as a string version. So on these bootloaders the BLS entries will be listed in the reverse order. To avoid that, change the BLS snippets filename to have the version field instead of the index and also to have the version before deployment name. Make the filenames to be of the form ostree-$version-$ID-$VARIANT_ID.conf so the version is before the deployment name. Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Closes: #1654 Approved by: cgwalters
2018-06-27 17:45:43 +03:00
assert_has_file sysroot/boot/loader/entries/ostree-2-testos.conf
assert_has_file sysroot/boot/loader/entries/ostree-1-otheros.conf
ostree-sysroot: make simple_write_deployment smarter This is a follow-up to https://github.com/ostreedev/ostree/pull/1097. We make simple_write_deployment smart enough so that it can be used for rpm-ostree's purposes. This is mostly an upstreaming of logic that already existed there. Notably we correctly append NOT_DEFAULT deployments *after* the booted deployment and we now support RETAIN_PENDING and RETAIN_ROLLBACK flags to have more granularity on deployment pruning. Expose these new flags on the CLI using new options (as well as expose the previously existing NOT_DEFAULT flag as --not-as-default). I couldn't add tests for --retain-pending because the merge deployment is always the topmost one. Though I did check that it worked in a VM. Closes: #1110 Approved by: cgwalters
2017-08-23 19:15:46 +03:00
${CMD_PREFIX} ostree admin status
validate_bootloader
echo "ok deploy --not-as-default"
*: rename master to main in tests & examples
2021-05-07 17:42:37 +03:00
${CMD_PREFIX} ostree admin deploy --retain-rollback --os=otheros testos:testos/buildmain/x86_64-runtime
ostree-sysroot: make simple_write_deployment smarter This is a follow-up to https://github.com/ostreedev/ostree/pull/1097. We make simple_write_deployment smart enough so that it can be used for rpm-ostree's purposes. This is mostly an upstreaming of logic that already existed there. Notably we correctly append NOT_DEFAULT deployments *after* the booted deployment and we now support RETAIN_PENDING and RETAIN_ROLLBACK flags to have more granularity on deployment pruning. Expose these new flags on the CLI using new options (as well as expose the previously existing NOT_DEFAULT flag as --not-as-default). I couldn't add tests for --retain-pending because the merge deployment is always the topmost one. Though I did check that it worked in a VM. Closes: #1110 Approved by: cgwalters
2017-08-23 19:15:46 +03:00
assert_not_has_dir sysroot/boot/loader.0
assert_has_dir sysroot/boot/loader.1
deploy: Change BootLoaderSpec filenames so they can be used for sorting Currently the BLS snippets are named ostree-$ID-$VARIANT_ID-$index.conf, but the BLS config files are actually sorted by using the version field which is the inverse of the index. In most places, _ostree_sysroot_read_boot_loader_configs() is used to get the BLS files and this function already returns them sorted by the version field. The only place where the index trailing number is used is in the ostree-grub-generator script that lists the BLS files to populate the grub config file. But for some bootloaders the BLS filename is the criteria for sorting by taking the filename as a string version. So on these bootloaders the BLS entries will be listed in the reverse order. To avoid that, change the BLS snippets filename to have the version field instead of the index and also to have the version before deployment name. Make the filenames to be of the form ostree-$version-$ID-$VARIANT_ID.conf so the version is before the deployment name. Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Closes: #1654 Approved by: cgwalters
2018-06-27 17:45:43 +03:00
assert_has_file sysroot/boot/loader/entries/ostree-3-otheros.conf
assert_has_file sysroot/boot/loader/entries/ostree-2-testos.conf
assert_has_file sysroot/boot/loader/entries/ostree-1-otheros.conf
ostree-sysroot: make simple_write_deployment smarter This is a follow-up to https://github.com/ostreedev/ostree/pull/1097. We make simple_write_deployment smart enough so that it can be used for rpm-ostree's purposes. This is mostly an upstreaming of logic that already existed there. Notably we correctly append NOT_DEFAULT deployments *after* the booted deployment and we now support RETAIN_PENDING and RETAIN_ROLLBACK flags to have more granularity on deployment pruning. Expose these new flags on the CLI using new options (as well as expose the previously existing NOT_DEFAULT flag as --not-as-default). I couldn't add tests for --retain-pending because the merge deployment is always the topmost one. Though I did check that it worked in a VM. Closes: #1110 Approved by: cgwalters
2017-08-23 19:15:46 +03:00
${CMD_PREFIX} ostree admin status
validate_bootloader
echo "ok deploy --retain-rollback"
Add `admin set-default` A core underlying primitive in the C library is the ability to arbitrarily reorder bootloader entries. Let's expose the basic functionality here with the ability to pick an arbitrarily deployment for the next boot. Closes: https://github.com/ostreedev/ostree/issues/2965
2023-08-02 18:25:58 +03:00
${CMD_PREFIX} ostree admin status
assert_file_has_content sysroot/boot/loader/entries/ostree-3-otheros.conf "^title.*TestOS 42 1.0.10"
${CMD_PREFIX} ostree admin set-default 1
assert_file_has_content sysroot/boot/loader/entries/ostree-3-testos.conf "^title.*TestOS 42 1.0.10"
${CMD_PREFIX} ostree admin set-default 1
assert_file_has_content sysroot/boot/loader/entries/ostree-3-otheros.conf "^title.*TestOS 42 1.0.10"
echo "ok set-default"
[INCOMPATIBLE CHANGE] Implement new deployment model See https://wiki.gnome.org/OSTree/DeploymentModel2 This is a major rework of the on-disk filesystem layout, and the boot process. OSTree now explicitly supports upgrading kernels, and these upgrades are also atomic. The core concept of the new model is the "deployment list", which is an ordered list of bootable operating system trees. The deployment list is reflected in the bootloader configuration; which has a kernel argument that tells the initramfs (dracut) which operating system root to use. Invidiual notable changes that come along with this: 1) Operating systems should now come with their etc in usr/etc; OSTree will perform a 3-way merge at deployment time, and place etc in the actual root. This avoids the need for a bind mount, and is just a lot cleaner. 2) OSTree no longer bind mounts /root, /home, and /tmp. It is expected that the the OS/ has these as symbolic links into /var. At the moment, OSTree only supports managing syslinux; other bootloader backends will follow.
2013-06-29 19:45:53 +04:00
os_repository_new_commit
*: rename master to main in tests & examples
2021-05-07 17:42:37 +03:00
${CMD_PREFIX} ostree --repo=sysroot/ostree/repo pull-local --remote=testos testos-repo testos/buildmain/x86_64-runtime
newrev=$(${CMD_PREFIX} ostree --repo=sysroot/ostree/repo rev-parse testos:testos/buildmain/x86_64-runtime)
[INCOMPATIBLE CHANGE] Implement new deployment model See https://wiki.gnome.org/OSTree/DeploymentModel2 This is a major rework of the on-disk filesystem layout, and the boot process. OSTree now explicitly supports upgrading kernels, and these upgrades are also atomic. The core concept of the new model is the "deployment list", which is an ordered list of bootable operating system trees. The deployment list is reflected in the bootloader configuration; which has a kernel argument that tells the initramfs (dracut) which operating system root to use. Invidiual notable changes that come along with this: 1) Operating systems should now come with their etc in usr/etc; OSTree will perform a 3-way merge at deployment time, and place etc in the actual root. This avoids the need for a bind mount, and is just a lot cleaner. 2) OSTree no longer bind mounts /root, /home, and /tmp. It is expected that the the OS/ has these as symbolic links into /var. At the moment, OSTree only supports managing syslinux; other bootloader backends will follow.
2013-06-29 19:45:53 +04:00
export newrev
assert_not_streq ${rev} ${newrev}
*: rename master to main in tests & examples
2021-05-07 17:42:37 +03:00
${CMD_PREFIX} ostree admin deploy --os=testos testos:testos/buildmain/x86_64-runtime
[INCOMPATIBLE CHANGE] Implement new deployment model See https://wiki.gnome.org/OSTree/DeploymentModel2 This is a major rework of the on-disk filesystem layout, and the boot process. OSTree now explicitly supports upgrading kernels, and these upgrades are also atomic. The core concept of the new model is the "deployment list", which is an ordered list of bootable operating system trees. The deployment list is reflected in the bootloader configuration; which has a kernel argument that tells the initramfs (dracut) which operating system root to use. Invidiual notable changes that come along with this: 1) Operating systems should now come with their etc in usr/etc; OSTree will perform a 3-way merge at deployment time, and place etc in the actual root. This avoids the need for a bind mount, and is just a lot cleaner. 2) OSTree no longer bind mounts /root, /home, and /tmp. It is expected that the the OS/ has these as symbolic links into /var. At the moment, OSTree only supports managing syslinux; other bootloader backends will follow.
2013-06-29 19:45:53 +04:00
assert_file_has_content sysroot/ostree/deploy/testos/deploy/${newrev}.0/etc/os-release 'NAME=TestOS'
# New files in /usr/etc
assert_file_has_content sysroot/ostree/deploy/testos/deploy/${newrev}.0/etc/a-new-default-config-file "a new default config file"
assert_file_has_content sysroot/ostree/deploy/testos/deploy/${newrev}.0/etc/new-default-dir/moo "a new default dir and file"
# And persist /etc changes from before
ostree-sysroot: make simple_write_deployment smarter This is a follow-up to https://github.com/ostreedev/ostree/pull/1097. We make simple_write_deployment smart enough so that it can be used for rpm-ostree's purposes. This is mostly an upstreaming of logic that already existed there. Notably we correctly append NOT_DEFAULT deployments *after* the booted deployment and we now support RETAIN_PENDING and RETAIN_ROLLBACK flags to have more granularity on deployment pruning. Expose these new flags on the CLI using new options (as well as expose the previously existing NOT_DEFAULT flag as --not-as-default). I couldn't add tests for --retain-pending because the merge deployment is always the topmost one. Though I did check that it worked in a VM. Closes: #1110 Approved by: cgwalters
2017-08-23 19:15:46 +03:00
assert_not_has_file sysroot/ostree/deploy/testos/deploy/${rev}.4/etc/aconfigfile
tests: Export OSTREE_SYSROOT in setup_os_repository Eliminates the need for constantly passing --sysroot=sysroot, but also makes ostree place remote configs for sysroot/ostree/repo in sysroot/etc/ostree/remotes.d where they should have been all along.
2015-07-14 20:30:05 +03:00
${CMD_PREFIX} ostree admin status
tests: Add a crosscheck for syslinux bootloader config generation And actually wire this one up in admin-test.sh.
2015-05-28 03:08:44 +03:00
validate_bootloader
[INCOMPATIBLE CHANGE] Implement new deployment model See https://wiki.gnome.org/OSTree/DeploymentModel2 This is a major rework of the on-disk filesystem layout, and the boot process. OSTree now explicitly supports upgrading kernels, and these upgrades are also atomic. The core concept of the new model is the "deployment list", which is an ordered list of bootable operating system trees. The deployment list is reflected in the bootloader configuration; which has a kernel argument that tells the initramfs (dracut) which operating system root to use. Invidiual notable changes that come along with this: 1) Operating systems should now come with their etc in usr/etc; OSTree will perform a 3-way merge at deployment time, and place etc in the actual root. This avoids the need for a bind mount, and is just a lot cleaner. 2) OSTree no longer bind mounts /root, /home, and /tmp. It is expected that the the OS/ has these as symbolic links into /var. At the moment, OSTree only supports managing syslinux; other bootloader backends will follow.
2013-06-29 19:45:53 +04:00
echo "ok upgrade bare"
os_repository_new_commit
lib/sysroot: Add OSTREE_EX_STAGE_DEPLOYMENTS environment variable I feel like I'm drowning in a pile of experimental-but-almost-stable features... Anyways, since we made the feature opt-in in rpm-ostree in https://github.com/projectatomic/rpm-ostree/pull/1352 let's mirror that a bit here with an environment variable so people can play with it more easily. The tests needed some tweaks; specifically we need to reload the status fact after making changes. I'm still a bit uncertain about the Ansible-as-tests. But we add an upgrade test that uses the new environment variable. Closes: #1583 Approved by: jlebon
2018-05-04 00:29:06 +03:00
if env OSTREE_EX_STAGE_DEPLOYMENTS=1 ${CMD_PREFIX} ostree admin upgrade --os=testos 2>err.txt; then
fatal "staged when not booted"
fi
echo "ok upgrade failed when staged"
*: rename master to main in tests & examples
2021-05-07 17:42:37 +03:00
${CMD_PREFIX} ostree --repo=sysroot/ostree/repo remote add --set=gpg-verify=false testos file://$(pwd)/testos-repo testos/buildmain/x86_64-runtime
tests: Export OSTREE_SYSROOT in setup_os_repository Eliminates the need for constantly passing --sysroot=sysroot, but also makes ostree place remote configs for sysroot/ostree/repo in sysroot/etc/ostree/remotes.d where they should have been all along.
2015-07-14 20:30:05 +03:00
${CMD_PREFIX} ostree admin upgrade --os=testos
admin: Add an "undeploy" command Otherwise it's really easy to keep accumulating deployments. Also, we may want to run this after rebooting, so we're back down to one operating system.
2013-07-23 17:19:24 +04:00
origrev=${rev}
[INCOMPATIBLE CHANGE] Implement new deployment model See https://wiki.gnome.org/OSTree/DeploymentModel2 This is a major rework of the on-disk filesystem layout, and the boot process. OSTree now explicitly supports upgrading kernels, and these upgrades are also atomic. The core concept of the new model is the "deployment list", which is an ordered list of bootable operating system trees. The deployment list is reflected in the bootloader configuration; which has a kernel argument that tells the initramfs (dracut) which operating system root to use. Invidiual notable changes that come along with this: 1) Operating systems should now come with their etc in usr/etc; OSTree will perform a 3-way merge at deployment time, and place etc in the actual root. This avoids the need for a bind mount, and is just a lot cleaner. 2) OSTree no longer bind mounts /root, /home, and /tmp. It is expected that the the OS/ has these as symbolic links into /var. At the moment, OSTree only supports managing syslinux; other bootloader backends will follow.
2013-06-29 19:45:53 +04:00
rev=${newrev}
*: rename master to main in tests & examples
2021-05-07 17:42:37 +03:00
newrev=$(${CMD_PREFIX} ostree --repo=sysroot/ostree/repo rev-parse testos/buildmain/x86_64-runtime)
[INCOMPATIBLE CHANGE] Implement new deployment model See https://wiki.gnome.org/OSTree/DeploymentModel2 This is a major rework of the on-disk filesystem layout, and the boot process. OSTree now explicitly supports upgrading kernels, and these upgrades are also atomic. The core concept of the new model is the "deployment list", which is an ordered list of bootable operating system trees. The deployment list is reflected in the bootloader configuration; which has a kernel argument that tells the initramfs (dracut) which operating system root to use. Invidiual notable changes that come along with this: 1) Operating systems should now come with their etc in usr/etc; OSTree will perform a 3-way merge at deployment time, and place etc in the actual root. This avoids the need for a bind mount, and is just a lot cleaner. 2) OSTree no longer bind mounts /root, /home, and /tmp. It is expected that the the OS/ has these as symbolic links into /var. At the moment, OSTree only supports managing syslinux; other bootloader backends will follow.
2013-06-29 19:45:53 +04:00
assert_not_streq ${rev} ${newrev}
assert_file_has_content sysroot/ostree/deploy/testos/deploy/${newrev}.0/etc/os-release 'NAME=TestOS'
tests: Export OSTREE_SYSROOT in setup_os_repository Eliminates the need for constantly passing --sysroot=sysroot, but also makes ostree place remote configs for sysroot/ostree/repo in sysroot/etc/ostree/remotes.d where they should have been all along.
2015-07-14 20:30:05 +03:00
${CMD_PREFIX} ostree admin status
tests: Add a crosscheck for syslinux bootloader config generation And actually wire this one up in admin-test.sh.
2015-05-28 03:08:44 +03:00
validate_bootloader
repo: Port -refs.c to openat() I'd like to incrementally convert all of `ostree-repo*.c` to fd-relative usage, so that we can sanely introduce `ostree_repo_new_at()` which doesn't involve GFile. This one is medium risk, but passes the test suite.
2016-01-27 05:34:31 +03:00
${CMD_PREFIX} ostree --repo=sysroot/ostree/repo refs testos:testos > reftest.txt
*: rename master to main in tests & examples
2021-05-07 17:42:37 +03:00
assert_file_has_content reftest.txt testos:buildmain/x86_64-runtime
[INCOMPATIBLE CHANGE] Implement new deployment model See https://wiki.gnome.org/OSTree/DeploymentModel2 This is a major rework of the on-disk filesystem layout, and the boot process. OSTree now explicitly supports upgrading kernels, and these upgrades are also atomic. The core concept of the new model is the "deployment list", which is an ordered list of bootable operating system trees. The deployment list is reflected in the bootloader configuration; which has a kernel argument that tells the initramfs (dracut) which operating system root to use. Invidiual notable changes that come along with this: 1) Operating systems should now come with their etc in usr/etc; OSTree will perform a 3-way merge at deployment time, and place etc in the actual root. This avoids the need for a bind mount, and is just a lot cleaner. 2) OSTree no longer bind mounts /root, /home, and /tmp. It is expected that the the OS/ has these as symbolic links into /var. At the moment, OSTree only supports managing syslinux; other bootloader backends will follow.
2013-06-29 19:45:53 +04:00
echo "ok upgrade"
admin: Add an "undeploy" command Otherwise it's really easy to keep accumulating deployments. Also, we may want to run this after rebooting, so we're back down to one operating system.
2013-07-23 17:19:24 +04:00
tests: Export OSTREE_SYSROOT in setup_os_repository Eliminates the need for constantly passing --sysroot=sysroot, but also makes ostree place remote configs for sysroot/ostree/repo in sysroot/etc/ostree/remotes.d where they should have been all along.
2015-07-14 20:30:05 +03:00
originfile=$(${CMD_PREFIX} ostree admin --print-current-dir).origin
admin: Add set-origin command See projectatomic/rpm-ostree#42 for rationale. There are two high level use cases: - If the OS comes unconfigured, this is a way to point it at a repo of your choice. - To switch between repositories while keeping the same branch easily.
2015-01-16 21:07:26 +03:00
cp ${originfile} saved-origin
tests: Export OSTREE_SYSROOT in setup_os_repository Eliminates the need for constantly passing --sysroot=sysroot, but also makes ostree place remote configs for sysroot/ostree/repo in sysroot/etc/ostree/remotes.d where they should have been all along.
2015-07-14 20:30:05 +03:00
${CMD_PREFIX} ostree admin set-origin --index=0 bacon --set=gpg-verify=false http://tasty.com
*: rename master to main in tests & examples
2021-05-07 17:42:37 +03:00
assert_file_has_content "${originfile}" "bacon:testos/buildmain/x86_64-runtime"
tests: enforce ${CMD_PREFIX} on all ostree processes Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
2015-03-03 15:13:54 +03:00
${CMD_PREFIX} ostree --repo=sysroot/ostree/repo remote list -u > remotes.txt
tests: Escape periods when appropriate Don't match any character in a regular expression when we only want to match a period. Closes: #1834 Approved by: rfairley
2019-04-02 05:01:49 +03:00
assert_file_has_content remotes.txt 'bacon.*http://tasty\.com'
admin: Add set-origin command See projectatomic/rpm-ostree#42 for rationale. There are two high level use cases: - If the OS comes unconfigured, this is a way to point it at a repo of your choice. - To switch between repositories while keeping the same branch easily.
2015-01-16 21:07:26 +03:00
cp saved-origin ${originfile}
tests: Add a crosscheck for syslinux bootloader config generation And actually wire this one up in admin-test.sh.
2015-05-28 03:08:44 +03:00
validate_bootloader
admin: Add set-origin command See projectatomic/rpm-ostree#42 for rationale. There are two high level use cases: - If the OS comes unconfigured, this is a way to point it at a repo of your choice. - To switch between repositories while keeping the same branch easily.
2015-01-16 21:07:26 +03:00
echo "ok set-origin"
sysroot: Support more arbitrary deployment changes This commit changes the sysroot API so that one can create arbitrary new deployment checkouts, then commit them as one step. This is to enable things like an automatic bisection tool which say create 50 deployments at once, then when done clean them up. This also moves some printfs from the library into src/ostree.
2013-09-17 06:37:00 +04:00
assert_file_has_content sysroot/ostree/deploy/testos/deploy/${rev}.0/etc/os-release 'NAME=TestOS'
admin: Add an "undeploy" command Otherwise it's really easy to keep accumulating deployments. Also, we may want to run this after rebooting, so we're back down to one operating system.
2013-07-23 17:19:24 +04:00
assert_file_has_content sysroot/ostree/deploy/testos/deploy/${newrev}.0/etc/os-release 'NAME=TestOS'
tests: Export OSTREE_SYSROOT in setup_os_repository Eliminates the need for constantly passing --sysroot=sysroot, but also makes ostree place remote configs for sysroot/ostree/repo in sysroot/etc/ostree/remotes.d where they should have been all along.
2015-07-14 20:30:05 +03:00
${CMD_PREFIX} ostree admin undeploy 1
admin: Add an "undeploy" command Otherwise it's really easy to keep accumulating deployments. Also, we may want to run this after rebooting, so we're back down to one operating system.
2013-07-23 17:19:24 +04:00
assert_file_has_content sysroot/ostree/deploy/testos/deploy/${newrev}.0/etc/os-release 'NAME=TestOS'
sysroot: Support more arbitrary deployment changes This commit changes the sysroot API so that one can create arbitrary new deployment checkouts, then commit them as one step. This is to enable things like an automatic bisection tool which say create 50 deployments at once, then when done clean them up. This also moves some printfs from the library into src/ostree.
2013-09-17 06:37:00 +04:00
assert_not_has_dir sysroot/ostree/deploy/testos/deploy/${rev}.0
admin: Add an "undeploy" command Otherwise it's really easy to keep accumulating deployments. Also, we may want to run this after rebooting, so we're back down to one operating system.
2013-07-23 17:19:24 +04:00
tests: Export OSTREE_SYSROOT in setup_os_repository Eliminates the need for constantly passing --sysroot=sysroot, but also makes ostree place remote configs for sysroot/ostree/repo in sysroot/etc/ostree/remotes.d where they should have been all along.
2015-07-14 20:30:05 +03:00
${CMD_PREFIX} ostree admin undeploy 0
admin: Add an "undeploy" command Otherwise it's really easy to keep accumulating deployments. Also, we may want to run this after rebooting, so we're back down to one operating system.
2013-07-23 17:19:24 +04:00
assert_not_has_dir sysroot/ostree/deploy/testos/deploy/${newrev}.0
tests: Export OSTREE_SYSROOT in setup_os_repository Eliminates the need for constantly passing --sysroot=sysroot, but also makes ostree place remote configs for sysroot/ostree/repo in sysroot/etc/ostree/remotes.d where they should have been all along.
2015-07-14 20:30:05 +03:00
${CMD_PREFIX} ostree admin status
tests: Add a crosscheck for syslinux bootloader config generation And actually wire this one up in admin-test.sh.
2015-05-28 03:08:44 +03:00
validate_bootloader
admin: Add an "undeploy" command Otherwise it's really easy to keep accumulating deployments. Also, we may want to run this after rebooting, so we're back down to one operating system.
2013-07-23 17:19:24 +04:00
echo "ok undeploy"
sysroot: Error out on deploy --os=<unknown> which has not been initialized We should hard require "ostree admin os-init foo" before letting deployments go there; it's too easy to typo the argument.
2014-01-09 03:29:05 +04:00
*: rename master to main in tests & examples
2021-05-07 17:42:37 +03:00
if ${CMD_PREFIX} ostree admin deploy --os=unknown testos:testos/buildmain/x86_64-runtime; then
sysroot: Error out on deploy --os=<unknown> which has not been initialized We should hard require "ostree admin os-init foo" before letting deployments go there; it's too easy to typo the argument.
2014-01-09 03:29:05 +04:00
assert_not_reached "Unexpected successful deploy of unknown OS"
fi
echo "ok deploy with unknown OS"
deploy: Also honor multiply-specified kernel args with existing config If we deployed a new tree inside an existing OS, inheriting kernel args, we need to use append() instead of replace() to avoid collapsing multiply specified kernel arguments like console=/dev/foo console=/dev/bar. Reported-by: Dusty Mabe <dusty@dustymabe.com>
2014-08-03 22:32:52 +04:00
*: rename master to main in tests & examples
2021-05-07 17:42:37 +03:00
${CMD_PREFIX} ostree admin deploy --os=testos --karg-append=console=/dev/foo --karg-append=console=/dev/bar testos:testos/buildmain/x86_64-runtime
${CMD_PREFIX} ostree admin deploy --os=testos testos:testos/buildmain/x86_64-runtime
deploy: Change BootLoaderSpec filenames so they can be used for sorting Currently the BLS snippets are named ostree-$ID-$VARIANT_ID-$index.conf, but the BLS config files are actually sorted by using the version field which is the inverse of the index. In most places, _ostree_sysroot_read_boot_loader_configs() is used to get the BLS files and this function already returns them sorted by the version field. The only place where the index trailing number is used is in the ostree-grub-generator script that lists the BLS files to populate the grub config file. But for some bootloaders the BLS filename is the criteria for sorting by taking the filename as a string version. So on these bootloaders the BLS entries will be listed in the reverse order. To avoid that, change the BLS snippets filename to have the version field instead of the index and also to have the version before deployment name. Make the filenames to be of the form ostree-$version-$ID-$VARIANT_ID.conf so the version is before the deployment name. Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Closes: #1654 Approved by: cgwalters
2018-06-27 17:45:43 +03:00
assert_file_has_content sysroot/boot/loader/entries/ostree-4-testos.conf 'console=/dev/foo.*console=/dev/bar'
tests: Add a crosscheck for syslinux bootloader config generation And actually wire this one up in admin-test.sh.
2015-05-28 03:08:44 +03:00
validate_bootloader
deploy: Also honor multiply-specified kernel args with existing config If we deployed a new tree inside an existing OS, inheriting kernel args, we need to use append() instead of replace() to avoid collapsing multiply specified kernel arguments like console=/dev/foo console=/dev/bar. Reported-by: Dusty Mabe <dusty@dustymabe.com>
2014-08-03 22:32:52 +04:00
echo "ok deploy with multiple kernel args"
*: rename master to main in tests & examples
2021-05-07 17:42:37 +03:00
origrev=$(${CMD_PREFIX} ostree --repo=sysroot/ostree/repo rev-parse testos/buildmain/x86_64-runtime)
deploy: Also honor multiply-specified kernel args with existing config If we deployed a new tree inside an existing OS, inheriting kernel args, we need to use append() instead of replace() to avoid collapsing multiply specified kernel arguments like console=/dev/foo console=/dev/bar. Reported-by: Dusty Mabe <dusty@dustymabe.com>
2014-08-03 22:32:52 +04:00
os_repository_new_commit 0 "test upgrade multiple kernel args"
tests: Export OSTREE_SYSROOT in setup_os_repository Eliminates the need for constantly passing --sysroot=sysroot, but also makes ostree place remote configs for sysroot/ostree/repo in sysroot/etc/ostree/remotes.d where they should have been all along.
2015-07-14 20:30:05 +03:00
${CMD_PREFIX} ostree admin upgrade --os=testos
*: rename master to main in tests & examples
2021-05-07 17:42:37 +03:00
newrev=$(${CMD_PREFIX} ostree --repo=sysroot/ostree/repo rev-parse testos/buildmain/x86_64-runtime)
deploy: Also honor multiply-specified kernel args with existing config If we deployed a new tree inside an existing OS, inheriting kernel args, we need to use append() instead of replace() to avoid collapsing multiply specified kernel arguments like console=/dev/foo console=/dev/bar. Reported-by: Dusty Mabe <dusty@dustymabe.com>
2014-08-03 22:32:52 +04:00
assert_not_streq ${origrev} ${newrev}
deploy: Change BootLoaderSpec filenames so they can be used for sorting Currently the BLS snippets are named ostree-$ID-$VARIANT_ID-$index.conf, but the BLS config files are actually sorted by using the version field which is the inverse of the index. In most places, _ostree_sysroot_read_boot_loader_configs() is used to get the BLS files and this function already returns them sorted by the version field. The only place where the index trailing number is used is in the ostree-grub-generator script that lists the BLS files to populate the grub config file. But for some bootloaders the BLS filename is the criteria for sorting by taking the filename as a string version. So on these bootloaders the BLS entries will be listed in the reverse order. To avoid that, change the BLS snippets filename to have the version field instead of the index and also to have the version before deployment name. Make the filenames to be of the form ostree-$version-$ID-$VARIANT_ID.conf so the version is before the deployment name. Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Closes: #1654 Approved by: cgwalters
2018-06-27 17:45:43 +03:00
assert_file_has_content sysroot/boot/loader/entries/ostree-4-testos.conf 'console=/dev/foo.*console=/dev/bar'
tests: Add a crosscheck for syslinux bootloader config generation And actually wire this one up in admin-test.sh.
2015-05-28 03:08:44 +03:00
validate_bootloader
deploy: Also honor multiply-specified kernel args with existing config If we deployed a new tree inside an existing OS, inheriting kernel args, we need to use append() instead of replace() to avoid collapsing multiply specified kernel arguments like console=/dev/foo console=/dev/bar. Reported-by: Dusty Mabe <dusty@dustymabe.com>
2014-08-03 22:32:52 +04:00
echo "ok upgrade with multiple kernel args"
upgrade: Add --override-commit=CHECKSUM option Adds an entry to the origin file to force the OstreeSysrootUpgrader to pull and deploy the given checksum. [origin] override-commit=CHECKSUM If the option is not given, any such entry is explicitly removed from the origin file to ensure we upgrade to the latest available commit.
2015-10-06 18:33:18 +03:00
lib/deploy: Don't include version twice in bootmenu title In Silverblue right now, the boot menu title looks like this: Fedora 29.20190301.0 (Workstation Edition) 29.20190301.0 (ostree) This is because RPM-OSTree's `mutate-os-release` feature is enabled, which injects the OSTree version string directly into `VERSION` and `PRETTY_NAME`. So appending the version string again is a bit redundant. Let's just do a simple substring check here before adding the version to the title. Closes: #1829 Approved by: cgwalters
2019-03-01 17:16:55 +03:00
os_repository_new_commit
${CMD_PREFIX} ostree admin upgrade --os=testos
lib/bootconfig-parser: Always include deployment index in BLS title If there are different deployments for the same commit version, the BLS snippets will have the same title fields (but different version fields): $ grep title * ostree-1-testos.conf:title TestOS 42 20190902.0 (ostree) ostree-2-testos.conf:title TestOS 42 20190902.0 (ostree) ostree-3-testos.conf:title TestOS 42 20190902.0 (ostree) But bootloaders could expect the title field to be unique for BLS files. For example, the zipl bootloader used in the s390x architecture uses the field to name the boot sections that are created from the BLS snippets. So two BLS snippets having the same title would lead to zipl failing to create the IPL boot sections because they would have duplicated names: $ zipl Using config file '/etc/zipl.conf' Using BLS config file '/boot/loader/entries/ostree-3-testos.conf' Using BLS config file '/boot/loader/entries/ostree-2-testos.conf' Using BLS config file '/boot/loader/entries/ostree-1-testos.conf' Error: Config file '/etc/zipl.conf': Line 0: section name 'TestOS 42 20190902.0 (ostree)' already specified Avoid this by always including the deployment index along with the commit version in the title field, so this will be unique even if there are BLS files for deployments that use the same commit version: $ grep title * ostree-1-testos.conf:title TestOS 42 20190902.0 (ostree:2) ostree-2-testos.conf:title TestOS 42 20190902.0 (ostree:1) ostree-3-testos.conf:title TestOS 42 20190902.0 (ostree:0) $ zipl Using config file '/etc/zipl.conf' Using BLS config file '/boot/loader/entries/ostree-3-testos.conf' Using BLS config file '/boot/loader/entries/ostree-2-testos.conf' Using BLS config file '/boot/loader/entries/ostree-1-testos.conf' Building bootmap in '/boot' Building menu 'zipl-automatic-menu' Adding #1: IPL section 'TestOS 42 20190902.0 (ostree:0)' (default) Adding #2: IPL section 'TestOS 42 20190902.0 (ostree:1)' Adding #3: IPL section 'TestOS 42 20190902.0 (ostree:2)' Preparing boot device: dasda (0120). Done. Closes: #1911 Approved by: cgwalters
2019-09-02 12:36:12 +03:00
assert_file_has_content sysroot/boot/loader/entries/ostree-4-testos.conf "^title TestOS 42 ${version} (ostree:testos:0)$"
*: rename master to main in tests & examples
2021-05-07 17:42:37 +03:00
os_repository_new_commit 0 0 testos/buildmain/x86_64-runtime 42
lib/deploy: Don't include version twice in bootmenu title In Silverblue right now, the boot menu title looks like this: Fedora 29.20190301.0 (Workstation Edition) 29.20190301.0 (ostree) This is because RPM-OSTree's `mutate-os-release` feature is enabled, which injects the OSTree version string directly into `VERSION` and `PRETTY_NAME`. So appending the version string again is a bit redundant. Let's just do a simple substring check here before adding the version to the title. Closes: #1829 Approved by: cgwalters
2019-03-01 17:16:55 +03:00
${CMD_PREFIX} ostree admin upgrade --os=testos
lib/bootconfig-parser: Always include deployment index in BLS title If there are different deployments for the same commit version, the BLS snippets will have the same title fields (but different version fields): $ grep title * ostree-1-testos.conf:title TestOS 42 20190902.0 (ostree) ostree-2-testos.conf:title TestOS 42 20190902.0 (ostree) ostree-3-testos.conf:title TestOS 42 20190902.0 (ostree) But bootloaders could expect the title field to be unique for BLS files. For example, the zipl bootloader used in the s390x architecture uses the field to name the boot sections that are created from the BLS snippets. So two BLS snippets having the same title would lead to zipl failing to create the IPL boot sections because they would have duplicated names: $ zipl Using config file '/etc/zipl.conf' Using BLS config file '/boot/loader/entries/ostree-3-testos.conf' Using BLS config file '/boot/loader/entries/ostree-2-testos.conf' Using BLS config file '/boot/loader/entries/ostree-1-testos.conf' Error: Config file '/etc/zipl.conf': Line 0: section name 'TestOS 42 20190902.0 (ostree)' already specified Avoid this by always including the deployment index along with the commit version in the title field, so this will be unique even if there are BLS files for deployments that use the same commit version: $ grep title * ostree-1-testos.conf:title TestOS 42 20190902.0 (ostree:2) ostree-2-testos.conf:title TestOS 42 20190902.0 (ostree:1) ostree-3-testos.conf:title TestOS 42 20190902.0 (ostree:0) $ zipl Using config file '/etc/zipl.conf' Using BLS config file '/boot/loader/entries/ostree-3-testos.conf' Using BLS config file '/boot/loader/entries/ostree-2-testos.conf' Using BLS config file '/boot/loader/entries/ostree-1-testos.conf' Building bootmap in '/boot' Building menu 'zipl-automatic-menu' Adding #1: IPL section 'TestOS 42 20190902.0 (ostree:0)' (default) Adding #2: IPL section 'TestOS 42 20190902.0 (ostree:1)' Adding #3: IPL section 'TestOS 42 20190902.0 (ostree:2)' Preparing boot device: dasda (0120). Done. Closes: #1911 Approved by: cgwalters
2019-09-02 12:36:12 +03:00
assert_file_has_content sysroot/boot/loader/entries/ostree-4-testos.conf "^title TestOS 42 (ostree:testos:0)$"
lib/deploy: Don't include version twice in bootmenu title In Silverblue right now, the boot menu title looks like this: Fedora 29.20190301.0 (Workstation Edition) 29.20190301.0 (ostree) This is because RPM-OSTree's `mutate-os-release` feature is enabled, which injects the OSTree version string directly into `VERSION` and `PRETTY_NAME`. So appending the version string again is a bit redundant. Let's just do a simple substring check here before adding the version to the title. Closes: #1829 Approved by: cgwalters
2019-03-01 17:16:55 +03:00
echo "ok no duplicate version strings in title"
upgrade: Add --override-commit=CHECKSUM option Adds an entry to the origin file to force the OstreeSysrootUpgrader to pull and deploy the given checksum. [origin] override-commit=CHECKSUM If the option is not given, any such entry is explicitly removed from the origin file to ensure we upgrade to the latest available commit.
2015-10-06 18:33:18 +03:00
# Test upgrade with and without --override-commit
# See https://github.com/GNOME/ostree/pull/147
tests/admin-test: Ensure that commits are 1s apart Otherwise the new check we added there to verify that upgrading without `--allow-downgrade` fails itself fails. See: https://github.com/ostreedev/ostree/pull/2099#issuecomment-629805840
2020-05-20 17:45:45 +03:00
sleep 1
os_repository_new_commit
tests/admin-test: Fix --allow-downgrade check We were doing a check to verify that `ostree admin upgrade` wouldn't accept a downgrade without `--allow-downgrade`. However, there's no guarantee that the commit it's upgrading from is older than HEAD^ (what we're upgrading to). Specifically, if the test runs fast enough, the timestamps could be equal, since the lowest resolution is seconds. Rework the test so that we first upgrade to HEAD, which we're sure is at least 1 second apart from HEAD^, and *then* check that downgrade protection is enforced. We also can't use `rev-parse testos/buildmaster/x86_64-runtime` as a way to know what commit the host is sitting on since the ref might've gone ahead. Instead, just use `ostree admin status | head -n1`. (I played with using the `ostree/I/J/K` refs, but those depend on what the boot/subbootversion is and can easily change if we change previous tests).
2020-05-20 19:37:44 +03:00
# upgrade to the latest
${CMD_PREFIX} ostree admin upgrade --os=testos
*: rename master to main in tests & examples
2021-05-07 17:42:37 +03:00
head_rev=$(${CMD_PREFIX} ostree rev-parse --repo=sysroot/ostree/repo testos/buildmain/x86_64-runtime)
prev_rev=$(${CMD_PREFIX} ostree rev-parse --repo=sysroot/ostree/repo testos/buildmain/x86_64-runtime^)
upgrade: Add --override-commit=CHECKSUM option Adds an entry to the origin file to force the OstreeSysrootUpgrader to pull and deploy the given checksum. [origin] override-commit=CHECKSUM If the option is not given, any such entry is explicitly removed from the origin file to ensure we upgrade to the latest available commit.
2015-10-06 18:33:18 +03:00
assert_not_streq ${head_rev} ${prev_rev}
tests/admin-test: Fix --allow-downgrade check We were doing a check to verify that `ostree admin upgrade` wouldn't accept a downgrade without `--allow-downgrade`. However, there's no guarantee that the commit it's upgrading from is older than HEAD^ (what we're upgrading to). Specifically, if the test runs fast enough, the timestamps could be equal, since the lowest resolution is seconds. Rework the test so that we first upgrade to HEAD, which we're sure is at least 1 second apart from HEAD^, and *then* check that downgrade protection is enforced. We also can't use `rev-parse testos/buildmaster/x86_64-runtime` as a way to know what commit the host is sitting on since the ref might've gone ahead. Instead, just use `ostree admin status | head -n1`. (I played with using the `ostree/I/J/K` refs, but those depend on what the boot/subbootversion is and can easily change if we change previous tests).
2020-05-20 19:37:44 +03:00
# Don't use `ostree admin status | head -n 1` directly here because `head`
# exiting early might cause SIGPIPE to ostree, which with `set -euo pipefail`
# will cause us to exit. See: https://github.com/ostreedev/ostree/pull/2110.
${CMD_PREFIX} ostree admin status > status-out.txt
head -n 1 < status-out.txt > status.txt
assert_file_has_content status.txt ".* testos ${head_rev}.*"
# now, check that we can't downgrade to an older commit without --allow-downgrade
lib/upgrader: Pull with `timestamp-check-from-rev` For the same reason as https://github.com/coreos/rpm-ostree/pull/2094. What we care most about is that the new commit we pull is newer than the one we're currently sitting on, not necessarily that it's newer than the branch itself, which it might not be if e.g. we're trying to deploy a commit older than the tip but still newer than the deployment (via `--override-commit`).
2020-05-14 22:05:45 +03:00
if ${CMD_PREFIX} ostree admin upgrade --os=testos --override-commit=${prev_rev} 2> err.txt; then
admin-test: Show err.txt on unexpected failure In a CI run I think one of these `ostree show` commands is failing. While that output would be useful, the actual `err.txt` usually has what we want too.
2020-05-20 18:57:10 +03:00
cat err.txt
lib/upgrader: Pull with `timestamp-check-from-rev` For the same reason as https://github.com/coreos/rpm-ostree/pull/2094. What we care most about is that the new commit we pull is newer than the one we're currently sitting on, not necessarily that it's newer than the branch itself, which it might not be if e.g. we're trying to deploy a commit older than the tip but still newer than the deployment (via `--override-commit`).
2020-05-14 22:05:45 +03:00
fatal "downgraded without --allow-downgrade?"
fi
assert_file_has_content err.txt "Upgrade.*is chronologically older"
upgrade: Add --override-commit=CHECKSUM option Adds an entry to the origin file to force the OstreeSysrootUpgrader to pull and deploy the given checksum. [origin] override-commit=CHECKSUM If the option is not given, any such entry is explicitly removed from the origin file to ensure we upgrade to the latest available commit.
2015-10-06 18:33:18 +03:00
${CMD_PREFIX} ostree admin upgrade --os=testos --override-commit=${prev_rev} --allow-downgrade
tests/admin-test: Fix --allow-downgrade check We were doing a check to verify that `ostree admin upgrade` wouldn't accept a downgrade without `--allow-downgrade`. However, there's no guarantee that the commit it's upgrading from is older than HEAD^ (what we're upgrading to). Specifically, if the test runs fast enough, the timestamps could be equal, since the lowest resolution is seconds. Rework the test so that we first upgrade to HEAD, which we're sure is at least 1 second apart from HEAD^, and *then* check that downgrade protection is enforced. We also can't use `rev-parse testos/buildmaster/x86_64-runtime` as a way to know what commit the host is sitting on since the ref might've gone ahead. Instead, just use `ostree admin status | head -n1`. (I played with using the `ostree/I/J/K` refs, but those depend on what the boot/subbootversion is and can easily change if we change previous tests).
2020-05-20 19:37:44 +03:00
${CMD_PREFIX} ostree admin status > status-out.txt
head -n 1 < status-out.txt > status.txt
assert_file_has_content status.txt ".* testos ${prev_rev}.*"
upgrade: Add --override-commit=CHECKSUM option Adds an entry to the origin file to force the OstreeSysrootUpgrader to pull and deploy the given checksum. [origin] override-commit=CHECKSUM If the option is not given, any such entry is explicitly removed from the origin file to ensure we upgrade to the latest available commit.
2015-10-06 18:33:18 +03:00
${CMD_PREFIX} ostree admin upgrade --os=testos
tests/admin-test: Fix --allow-downgrade check We were doing a check to verify that `ostree admin upgrade` wouldn't accept a downgrade without `--allow-downgrade`. However, there's no guarantee that the commit it's upgrading from is older than HEAD^ (what we're upgrading to). Specifically, if the test runs fast enough, the timestamps could be equal, since the lowest resolution is seconds. Rework the test so that we first upgrade to HEAD, which we're sure is at least 1 second apart from HEAD^, and *then* check that downgrade protection is enforced. We also can't use `rev-parse testos/buildmaster/x86_64-runtime` as a way to know what commit the host is sitting on since the ref might've gone ahead. Instead, just use `ostree admin status | head -n1`. (I played with using the `ostree/I/J/K` refs, but those depend on what the boot/subbootversion is and can easily change if we change previous tests).
2020-05-20 19:37:44 +03:00
${CMD_PREFIX} ostree admin status > status-out.txt
head -n 1 < status-out.txt > status.txt
assert_file_has_content status.txt ".* testos ${head_rev}.*"
upgrade: Add --override-commit=CHECKSUM option Adds an entry to the origin file to force the OstreeSysrootUpgrader to pull and deploy the given checksum. [origin] override-commit=CHECKSUM If the option is not given, any such entry is explicitly removed from the origin file to ensure we upgrade to the latest available commit.
2015-10-06 18:33:18 +03:00
echo "ok upgrade with and without override-commit"
Add a notion of "physical" sysroot, use for remote writing (Note this PR was reverted in <https://github.com/ostreedev/ostree/pull/902>; this version should be better) Using `${sysroot}` to mean the physical storage root: We don't want to write to `${sysroot}/etc/ostree/remotes.d`, since nothing will read it, and really `${sysroot}` should just have `/ostree` (ideally). Today the Anaconda rpmostree code ends up writing there. Fix this by adding a notion of "physical" sysroot. We determine whether the path is physical by checking for `/sysroot`, which exists in deployment roots (and there shouldn't be a `${sysroot}/sysroot`). In order to unit test this, I added a `--sysroot` argument to `remote add`. However, doing this better would require reworking the command line parsing for the `remote` argument to support specifying `--repo` or `--sysroot`, and I didn't quite want to do that yet in this patch. This second iteration of this patch fixes the bug we hit the first time; embarassingly enough I broke `ostree remote list` finding system remotes. The fix is to have `ostree_repo_open()` figure out whether it's the same as `/ostree/repo` for now. Down the line...we might consider having the `ostree remote` command line itself instatiate an `OstreeSysroot` by default, but this maximizes compatibility; we just have to pay a small cost that `ostree` usage outside of that case like `ostree static-delta` in a releng Jenkins job or whatever will do this `stat()` too. Closes: https://github.com/ostreedev/ostree/issues/892 Closes: #1008 Approved by: mbarnes
2017-05-30 21:07:13 +03:00
lib/upgrader: Pull with `timestamp-check-from-rev` For the same reason as https://github.com/coreos/rpm-ostree/pull/2094. What we care most about is that the new commit we pull is newer than the one we're currently sitting on, not necessarily that it's newer than the branch itself, which it might not be if e.g. we're trying to deploy a commit older than the tip but still newer than the deployment (via `--override-commit`).
2020-05-14 22:05:45 +03:00
# check that we can still upgrade to a rev that's not the tip of the branch but
# that's still newer than the deployment
sleep 1
os_repository_new_commit
sleep 1
os_repository_new_commit
*: rename master to main in tests & examples
2021-05-07 17:42:37 +03:00
${CMD_PREFIX} ostree pull --repo=sysroot/ostree/repo --commit-metadata-only --depth=-1 testos:testos/buildmain/x86_64-runtime
curr_rev=$(${CMD_PREFIX} ostree rev-parse --repo=sysroot/ostree/repo testos/buildmain/x86_64-runtime)
prev_rev=$(${CMD_PREFIX} ostree rev-parse --repo=sysroot/ostree/repo testos/buildmain/x86_64-runtime^)
lib/upgrader: Pull with `timestamp-check-from-rev` For the same reason as https://github.com/coreos/rpm-ostree/pull/2094. What we care most about is that the new commit we pull is newer than the one we're currently sitting on, not necessarily that it's newer than the branch itself, which it might not be if e.g. we're trying to deploy a commit older than the tip but still newer than the deployment (via `--override-commit`).
2020-05-14 22:05:45 +03:00
${CMD_PREFIX} ostree admin upgrade --os=testos --override-commit=${prev_rev}
echo "ok upgrade to newer version older than branch tip"
core: Add standard SOURCE_TITLE metadata key This is a freeform string useful to track/display when a commit is "derived" from some other format. For example, in the rpm-ostree test we make a `vmcheck` ref that conceptually overlays the default ref like `fedora-atomic:fedora/26/x86_64/atomic-host`. My current patch sets the source title to e.g. "Dev overlay on fedora-atomic:fedora/26/x86_64/atomic-host". Another case I'm working on now is importing OCI images to use as host images. For that case, the source title is With this patch we could then set the original OCI image name + tag as the source name, like: "oci:cgwalters/demo-custom-fedora-atomic-host:26". Closes: #1296 Approved by: jlebon
2017-10-19 21:28:02 +03:00
${CMD_PREFIX} ostree --repo=${test_tmpdir}/testos-repo commit --add-metadata-string "version=${version}" \
*: rename master to main in tests & examples
2021-05-07 17:42:37 +03:00
--add-metadata-string 'ostree.source-title=libtest os_repository_new_commit()' -b testos/buildmain/x86_64-runtime \
core: Add standard SOURCE_TITLE metadata key This is a freeform string useful to track/display when a commit is "derived" from some other format. For example, in the rpm-ostree test we make a `vmcheck` ref that conceptually overlays the default ref like `fedora-atomic:fedora/26/x86_64/atomic-host`. My current patch sets the source title to e.g. "Dev overlay on fedora-atomic:fedora/26/x86_64/atomic-host". Another case I'm working on now is importing OCI images to use as host images. For that case, the source title is With this patch we could then set the original OCI image name + tag as the source name, like: "oci:cgwalters/demo-custom-fedora-atomic-host:26". Closes: #1296 Approved by: jlebon
2017-10-19 21:28:02 +03:00
-s "Build" --tree=dir=${test_tmpdir}/osdata
${CMD_PREFIX} ostree admin upgrade --os=testos
${CMD_PREFIX} ostree admin status | tee status.txt
assert_file_has_content_literal status.txt '`- libtest os_repository_new_commit()'
echo "ok source title"
Add a notion of "physical" sysroot, use for remote writing (Note this PR was reverted in <https://github.com/ostreedev/ostree/pull/902>; this version should be better) Using `${sysroot}` to mean the physical storage root: We don't want to write to `${sysroot}/etc/ostree/remotes.d`, since nothing will read it, and really `${sysroot}` should just have `/ostree` (ideally). Today the Anaconda rpmostree code ends up writing there. Fix this by adding a notion of "physical" sysroot. We determine whether the path is physical by checking for `/sysroot`, which exists in deployment roots (and there shouldn't be a `${sysroot}/sysroot`). In order to unit test this, I added a `--sysroot` argument to `remote add`. However, doing this better would require reworking the command line parsing for the `remote` argument to support specifying `--repo` or `--sysroot`, and I didn't quite want to do that yet in this patch. This second iteration of this patch fixes the bug we hit the first time; embarassingly enough I broke `ostree remote list` finding system remotes. The fix is to have `ostree_repo_open()` figure out whether it's the same as `/ostree/repo` for now. Down the line...we might consider having the `ostree remote` command line itself instatiate an `OstreeSysroot` by default, but this maximizes compatibility; we just have to pay a small cost that `ostree` usage outside of that case like `ostree static-delta` in a releng Jenkins job or whatever will do this `stat()` too. Closes: https://github.com/ostreedev/ostree/issues/892 Closes: #1008 Approved by: mbarnes
2017-05-30 21:07:13 +03:00
deployment=$(${CMD_PREFIX} ostree admin --sysroot=sysroot --print-current-dir)
${CMD_PREFIX} ostree --sysroot=sysroot remote add --set=gpg-verify=false remote-test-physical file://$(pwd)/testos-repo
assert_not_has_file ${deployment}/etc/ostree/remotes.d/remote-test-physical.conf testos-repo
assert_file_has_content sysroot/ostree/repo/config remote-test-physical
echo "ok remote add physical sysroot"
# Now a hack...symlink ${deployment}/sysroot to the sysroot in lieu of a bind
# mount which we can't do in unit tests.
ln -sr sysroot ${deployment}/sysroot
ln -s sysroot/ostree ${deployment}/ostree
${CMD_PREFIX} ostree --sysroot=${deployment} remote add --set=gpg-verify=false remote-test-nonphysical file://$(pwd)/testos-repo
assert_not_file_has_content sysroot/ostree/repo/config remote-test-nonphysical
assert_file_has_content ${deployment}/etc/ostree/remotes.d/remote-test-nonphysical.conf testos-repo
echo "ok remote add nonphysical sysroot"
lib/deploy: Use a FIFREEZE/FITHAW cycle for /boot See: http://marc.info/?l=linux-fsdevel&m=149520244919284&w=2 XFS doesn't flush the journal on `syncfs()`. GRUB doesn't know how to follow the XFS journal, so if the filesystem is in a dirty state (possible with xfs `/boot`, extremely likely with `/`, if the journaled data includes content for `/boot`, the system may be unbootable if a system crash occurs. Fix this by doing a `FIFREEZE`+`FITHAW` cycle. Now, most people probably would have replaced the `syncfs()` invocation with those two ioctls. But this would have become (I believe) the *only* place in libostree where we weren't safe against interruption. The failure mode would be ugly; nothing else would be able to write to the filesystem until manual intervention. The real fix here I think is to land an atomic `FIFREEZETHAW` ioctl in the kernel. I might try a patch. In the meantime though, let's jump through some hoops and set up a "watchdog" child process that acts as a fallback unfreezer. Closes: https://github.com/ostreedev/ostree/issues/876 Closes: #1049 Approved by: jlebon
2017-08-03 05:07:26 +03:00
repo: Add add-remotes-config-dir option This option allows a repo to explicitly opt out of adding new remotes in a remotes configuration directory. This currently defaults to true for system repos and false for non-system repos to maintain legacy behavior that non-system repos don't add remotes in a configuration directory. That would be problematic for flatpak, which specifies a remotes config dir but adds remotes in ways that are incompatible with it. So, what this really does is allow system repos to control whether they want to add remotes in the config dir or not. That's important if your flatpak repo is the system repo like at Endless. Closes: #1134 Closes: #1155 Approved by: cgwalters
2017-09-08 18:18:10 +03:00
# Test that setting add-remotes-config-dir to false adds a remote in the
# config file rather than the remotes config dir even though this is a
# "system" repo.
${CMD_PREFIX} ostree --repo=sysroot/ostree/repo config set core.add-remotes-config-dir false
${CMD_PREFIX} ostree --sysroot=${deployment} remote add --set=gpg-verify=false remote-test-config-dir file://$(pwd)/testos-repo
assert_not_has_file ${deployment}/etc/ostree/remotes.d/remote-test-config-dir.conf testos-repo
assert_file_has_content sysroot/ostree/repo/config remote-test-config-dir
echo "ok remote add nonphysical sysroot add-remotes-config-dir false"
lib/deploy: Use a FIFREEZE/FITHAW cycle for /boot See: http://marc.info/?l=linux-fsdevel&m=149520244919284&w=2 XFS doesn't flush the journal on `syncfs()`. GRUB doesn't know how to follow the XFS journal, so if the filesystem is in a dirty state (possible with xfs `/boot`, extremely likely with `/`, if the journaled data includes content for `/boot`, the system may be unbootable if a system crash occurs. Fix this by doing a `FIFREEZE`+`FITHAW` cycle. Now, most people probably would have replaced the `syncfs()` invocation with those two ioctls. But this would have become (I believe) the *only* place in libostree where we weren't safe against interruption. The failure mode would be ugly; nothing else would be able to write to the filesystem until manual intervention. The real fix here I think is to land an atomic `FIFREEZETHAW` ioctl in the kernel. I might try a patch. In the meantime though, let's jump through some hoops and set up a "watchdog" child process that acts as a fallback unfreezer. Closes: https://github.com/ostreedev/ostree/issues/876 Closes: #1049 Approved by: jlebon
2017-08-03 05:07:26 +03:00
if env OSTREE_SYSROOT_DEBUG="${OSTREE_SYSROOT_DEBUG},test-fifreeze" \
*: rename master to main in tests & examples
2021-05-07 17:42:37 +03:00
${CMD_PREFIX} ostree admin deploy --os=testos testos:testos/buildmain/x86_64-runtime 2>err.txt; then
lib/deploy: Use a FIFREEZE/FITHAW cycle for /boot See: http://marc.info/?l=linux-fsdevel&m=149520244919284&w=2 XFS doesn't flush the journal on `syncfs()`. GRUB doesn't know how to follow the XFS journal, so if the filesystem is in a dirty state (possible with xfs `/boot`, extremely likely with `/`, if the journaled data includes content for `/boot`, the system may be unbootable if a system crash occurs. Fix this by doing a `FIFREEZE`+`FITHAW` cycle. Now, most people probably would have replaced the `syncfs()` invocation with those two ioctls. But this would have become (I believe) the *only* place in libostree where we weren't safe against interruption. The failure mode would be ugly; nothing else would be able to write to the filesystem until manual intervention. The real fix here I think is to land an atomic `FIFREEZETHAW` ioctl in the kernel. I might try a patch. In the meantime though, let's jump through some hoops and set up a "watchdog" child process that acts as a fallback unfreezer. Closes: https://github.com/ostreedev/ostree/issues/876 Closes: #1049 Approved by: jlebon
2017-08-03 05:07:26 +03:00
fatal "fifreeze-test exited successfully?"
fi
assert_file_has_content err.txt "fifreeze watchdog was run"
assert_file_has_content err.txt "During fsfreeze-thaw: aborting due to test-fifreeze"
echo "ok fifreeze test"
Reference in New Issue Copy Permalink