ostree/tests/admin-test.sh

376 lines
18 KiB
Bash
Raw Normal View History

# This file is to be sourced, not executed
# Copyright (C) 2011,2014 Colin Walters <walters@verbum.org>
#
# SPDX-License-Identifier: LGPL-2.0+
#
# 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
# License along with this library; if not, write to the
# Free Software Foundation, Inc., 59 Temple Place - Suite 330,
# Boston, MA 02111-1307, USA.
set -euo pipefail
echo "1..$((28 + ${extra_admin_tests:-0}))"
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"
function validate_bootloader() {
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 -
}
# 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
}
orig_mtime=$(stat -c '%.Y' sysroot/ostree/deploy)
${CMD_PREFIX} ostree --repo=sysroot/ostree/repo pull-local --remote=testos testos-repo testos/buildmaster/x86_64-runtime
rev=$(${CMD_PREFIX} ostree --repo=sysroot/ostree/repo rev-parse testos/buildmaster/x86_64-runtime)
export rev
# This initial deployment gets kicked off with some kernel arguments
${CMD_PREFIX} ostree admin deploy --karg=root=LABEL=MOO --karg=quiet --os=testos testos:testos/buildmaster/x86_64-runtime
new_mtime=$(stat -c '%.Y' sysroot/ostree/deploy)
assert_not_streq "${orig_mtime}" "${new_mtime}"
${CMD_PREFIX} ostree admin status | tee status.txt
assert_not_file_has_content status.txt "pending"
assert_not_file_has_content status.txt "rollback"
validate_bootloader
echo "ok deploy command"
${CMD_PREFIX} ostree admin --print-current-dir > curdir
assert_file_has_content curdir ^`pwd`/sysroot/ostree/deploy/testos/deploy/${rev}\.0$
echo "ok --print-current-dir"
# Test layout of bootloader config and refs
assert_not_has_dir sysroot/boot/loader.0
assert_has_dir sysroot/boot/loader.1
assert_has_dir sysroot/ostree/boot.1.1
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'
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'
assert_ostree_deployment_refs 1/1/0
${CMD_PREFIX} ostree admin status
echo "ok layout"
if ${CMD_PREFIX} ostree admin deploy --stage --os=testos testos:testos/buildmaster/x86_64-runtime 2>err.txt; then
fatal "staged when not booted"
fi
assert_file_has_content_literal err.txt "Cannot stage a deployment when not currently booted into an OSTree system"
echo "ok staging does not work when not booted"
orig_mtime=$(stat -c '%.Y' sysroot/ostree/deploy)
${CMD_PREFIX} ostree admin deploy --os=testos testos:testos/buildmaster/x86_64-runtime
new_mtime=$(stat -c '%.Y' sysroot/ostree/deploy)
assert_not_streq "${orig_mtime}" "${new_mtime}"
# 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
assert_file_has_content sysroot/boot/loader/entries/ostree-2-testos.conf 'options.* root=LABEL=MOO'
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'
assert_ostree_deployment_refs 0/1/{0,1}
${CMD_PREFIX} ostree admin status
validate_bootloader
echo "ok second deploy"
${CMD_PREFIX} ostree admin deploy --os=testos testos:testos/buildmaster/x86_64-runtime
# 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
assert_ostree_deployment_refs 0/0/{0,1}
${CMD_PREFIX} ostree admin status
validate_bootloader
echo "ok third deploy (swap)"
${CMD_PREFIX} ostree admin os-init otheros
${CMD_PREFIX} ostree admin deploy --os=otheros testos/buildmaster/x86_64-runtime
assert_not_has_dir sysroot/boot/loader.0
assert_has_dir sysroot/boot/loader.1
assert_has_file sysroot/boot/loader/entries/ostree-2-testos.conf
assert_has_file sysroot/boot/loader/entries/ostree-3-otheros.conf
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'
assert_ostree_deployment_refs 1/1/{0,1,2}
${CMD_PREFIX} ostree admin status
validate_bootloader
echo "ok independent deploy"
${CMD_PREFIX} ostree admin deploy --retain --os=testos testos:testos/buildmaster/x86_64-runtime
assert_has_dir sysroot/boot/loader.0
assert_not_has_dir sysroot/boot/loader.1
assert_has_file sysroot/boot/loader/entries/ostree-4-testos.conf
assert_file_has_content sysroot/ostree/deploy/testos/deploy/${rev}.2/etc/os-release 'NAME=TestOS'
assert_has_file sysroot/boot/loader/entries/ostree-2-testos.conf
assert_file_has_content sysroot/ostree/deploy/testos/deploy/${rev}.3/etc/os-release 'NAME=TestOS'
${CMD_PREFIX} ostree admin status
assert_ostree_deployment_refs 0/1/{0,1,2,3}
validate_bootloader
echo "ok fourth deploy (retain)"
echo "a new local config file" > sysroot/ostree/deploy/testos/deploy/${rev}.3/etc/a-new-config-file
rm -r sysroot/ostree/deploy/testos/deploy/${rev}.3/etc/testdirectory
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
${CMD_PREFIX} ostree admin deploy --retain --os=testos testos:testos/buildmaster/x86_64-runtime
assert_not_has_dir sysroot/boot/loader.0
assert_has_dir sysroot/boot/loader.1
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
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
${CMD_PREFIX} ostree admin status
validate_bootloader
echo "ok deploy with modified /etc"
# 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
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
${CMD_PREFIX} ostree admin deploy --not-as-default --os=otheros testos:testos/buildmaster/x86_64-runtime
assert_has_dir sysroot/boot/loader.0
assert_not_has_dir sysroot/boot/loader.1
assert_has_file sysroot/boot/loader/entries/ostree-2-testos.conf
assert_has_file sysroot/boot/loader/entries/ostree-1-otheros.conf
${CMD_PREFIX} ostree admin status
validate_bootloader
echo "ok deploy --not-as-default"
${CMD_PREFIX} ostree admin deploy --retain-rollback --os=otheros testos:testos/buildmaster/x86_64-runtime
assert_not_has_dir sysroot/boot/loader.0
assert_has_dir sysroot/boot/loader.1
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
${CMD_PREFIX} ostree admin status
validate_bootloader
echo "ok deploy --retain-rollback"
os_repository_new_commit
${CMD_PREFIX} ostree --repo=sysroot/ostree/repo pull-local --remote=testos testos-repo testos/buildmaster/x86_64-runtime
newrev=$(${CMD_PREFIX} ostree --repo=sysroot/ostree/repo rev-parse testos:testos/buildmaster/x86_64-runtime)
export newrev
assert_not_streq ${rev} ${newrev}
${CMD_PREFIX} ostree admin deploy --os=testos testos:testos/buildmaster/x86_64-runtime
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
assert_not_has_file sysroot/ostree/deploy/testos/deploy/${rev}.4/etc/aconfigfile
${CMD_PREFIX} ostree admin status
validate_bootloader
echo "ok upgrade bare"
os_repository_new_commit
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"
${CMD_PREFIX} ostree --repo=sysroot/ostree/repo remote add --set=gpg-verify=false testos file://$(pwd)/testos-repo testos/buildmaster/x86_64-runtime
${CMD_PREFIX} ostree admin upgrade --os=testos
origrev=${rev}
rev=${newrev}
newrev=$(${CMD_PREFIX} ostree --repo=sysroot/ostree/repo rev-parse testos/buildmaster/x86_64-runtime)
assert_not_streq ${rev} ${newrev}
assert_file_has_content sysroot/ostree/deploy/testos/deploy/${newrev}.0/etc/os-release 'NAME=TestOS'
${CMD_PREFIX} ostree admin status
validate_bootloader
${CMD_PREFIX} ostree --repo=sysroot/ostree/repo refs testos:testos > reftest.txt
assert_file_has_content reftest.txt testos:buildmaster/x86_64-runtime
echo "ok upgrade"
originfile=$(${CMD_PREFIX} ostree admin --print-current-dir).origin
cp ${originfile} saved-origin
${CMD_PREFIX} ostree admin set-origin --index=0 bacon --set=gpg-verify=false http://tasty.com
assert_file_has_content "${originfile}" "bacon:testos/buildmaster/x86_64-runtime"
${CMD_PREFIX} ostree --repo=sysroot/ostree/repo remote list -u > remotes.txt
assert_file_has_content remotes.txt 'bacon.*http://tasty\.com'
cp saved-origin ${originfile}
validate_bootloader
echo "ok set-origin"
assert_file_has_content sysroot/ostree/deploy/testos/deploy/${rev}.0/etc/os-release 'NAME=TestOS'
assert_file_has_content sysroot/ostree/deploy/testos/deploy/${newrev}.0/etc/os-release 'NAME=TestOS'
${CMD_PREFIX} ostree admin undeploy 1
assert_file_has_content sysroot/ostree/deploy/testos/deploy/${newrev}.0/etc/os-release 'NAME=TestOS'
assert_not_has_dir sysroot/ostree/deploy/testos/deploy/${rev}.0
${CMD_PREFIX} ostree admin undeploy 0
assert_not_has_dir sysroot/ostree/deploy/testos/deploy/${newrev}.0
${CMD_PREFIX} ostree admin status
validate_bootloader
echo "ok undeploy"
if ${CMD_PREFIX} ostree admin deploy --os=unknown testos:testos/buildmaster/x86_64-runtime; then
assert_not_reached "Unexpected successful deploy of unknown OS"
fi
echo "ok deploy with unknown OS"
${CMD_PREFIX} ostree admin deploy --os=testos --karg-append=console=/dev/foo --karg-append=console=/dev/bar testos:testos/buildmaster/x86_64-runtime
${CMD_PREFIX} ostree admin deploy --os=testos testos:testos/buildmaster/x86_64-runtime
assert_file_has_content sysroot/boot/loader/entries/ostree-4-testos.conf 'console=/dev/foo.*console=/dev/bar'
validate_bootloader
echo "ok deploy with multiple kernel args"
origrev=$(${CMD_PREFIX} ostree --repo=sysroot/ostree/repo rev-parse testos/buildmaster/x86_64-runtime)
os_repository_new_commit 0 "test upgrade multiple kernel args"
${CMD_PREFIX} ostree admin upgrade --os=testos
newrev=$(${CMD_PREFIX} ostree --repo=sysroot/ostree/repo rev-parse testos/buildmaster/x86_64-runtime)
assert_not_streq ${origrev} ${newrev}
assert_file_has_content sysroot/boot/loader/entries/ostree-4-testos.conf 'console=/dev/foo.*console=/dev/bar'
validate_bootloader
echo "ok upgrade with multiple kernel args"
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)$"
os_repository_new_commit 0 0 testos/buildmaster/x86_64-runtime 42
${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)$"
echo "ok no duplicate version strings in title"
# Test upgrade with and without --override-commit
# See https://github.com/GNOME/ostree/pull/147
sleep 1
os_repository_new_commit
${CMD_PREFIX} ostree pull --repo=sysroot/ostree/repo --commit-metadata-only --depth=-1 testos:testos/buildmaster/x86_64-runtime
head_rev=$(${CMD_PREFIX} ostree rev-parse --repo=sysroot/ostree/repo testos/buildmaster/x86_64-runtime)
prev_rev=$(${CMD_PREFIX} ostree rev-parse --repo=sysroot/ostree/repo testos/buildmaster/x86_64-runtime^^^^)
assert_not_streq ${head_rev} ${prev_rev}
# check that we can't "upgrade" to an older commit without --allow-downgrade
if ${CMD_PREFIX} ostree admin upgrade --os=testos --override-commit=${prev_rev} 2> err.txt; then
cat err.txt
fatal "downgraded without --allow-downgrade?"
fi
assert_file_has_content err.txt "Upgrade.*is chronologically older"
${CMD_PREFIX} ostree admin upgrade --os=testos --override-commit=${prev_rev} --allow-downgrade
curr_rev=$(${CMD_PREFIX} ostree rev-parse --repo=sysroot/ostree/repo testos/buildmaster/x86_64-runtime)
assert_streq ${curr_rev} ${prev_rev}
${CMD_PREFIX} ostree admin upgrade --os=testos
curr_rev=$(${CMD_PREFIX} ostree rev-parse --repo=sysroot/ostree/repo testos/buildmaster/x86_64-runtime)
assert_streq ${curr_rev} ${head_rev}
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
# 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
${CMD_PREFIX} ostree pull --repo=sysroot/ostree/repo --commit-metadata-only --depth=-1 testos:testos/buildmaster/x86_64-runtime
curr_rev=$(${CMD_PREFIX} ostree rev-parse --repo=sysroot/ostree/repo testos/buildmaster/x86_64-runtime)
prev_rev=$(${CMD_PREFIX} ostree rev-parse --repo=sysroot/ostree/repo testos/buildmaster/x86_64-runtime^)
${CMD_PREFIX} ostree admin upgrade --os=testos --override-commit=${prev_rev}
echo "ok upgrade to newer version older than branch tip"
${CMD_PREFIX} ostree --repo=${test_tmpdir}/testos-repo commit --add-metadata-string "version=${version}" \
--add-metadata-string 'ostree.source-title=libtest os_repository_new_commit()' -b testos/buildmaster/x86_64-runtime \
-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"
# 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"
if env OSTREE_SYSROOT_DEBUG="${OSTREE_SYSROOT_DEBUG},test-fifreeze" \
${CMD_PREFIX} ostree admin deploy --os=testos testos:testos/buildmaster/x86_64-runtime 2>err.txt; then
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"