keremet/rpm-ostree
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity
0a96a181c0
rpm-ostree/tests/vmcheck/test-override-kernel.sh

72 lines
2.7 KiB
Bash
Raw Normal View History

core: Set installonly to ensure we only have one kernel The goal here is to support `override replace kernel.x86_64.rpm`. There's a whole lot of logic in libdnf to support having multiple kernel packages installed. AIUI, that was implemented because: 1) The kernel is the biggest source of regressions 2) It'd be quite noticeable if all of your kernel modules were deleted Of course point 2) applies to a lot of userspace too...that's something rpm-ostree fixes of course. Anyways, in some testing all we need to do really is just turn that logic off unconditionally. Closes: https://github.com/projectatomic/rpm-ostree/issues/946 Closes: #1228 Approved by: jlebon
2018-01-28 23:16:22 +03:00
#!/bin/bash
#
# Copyright (C) 2017 Red Hat, Inc.
#
# 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
. ${commondir}/libtest.sh
. ${commondir}/libvm.sh
set -x
osid=$(vm_cmd grep -E '^ID=' /etc/os-release)
if test "${osid}" != 'ID=fedora'; then
echo "ok skip on OS ID=${osid}"
exit 0
fi
vmcheck: Adapt test-override-kernel.sh This is one of the tests right now that assumes it's running on f29. We might be sort of in this awkward dual path for a while where we want tests to run on both f29 (i.e. FAH) and f30 (i.e. FCOS). Closes: #1900 Approved by: cgwalters
2019-09-06 22:34:11 +03:00
versionid=$(vm_cmd grep -E '^VERSION_ID=' /etc/os-release)
versionid=${versionid:11} # trim off VERSION_ID=
core: Set installonly to ensure we only have one kernel The goal here is to support `override replace kernel.x86_64.rpm`. There's a whole lot of logic in libdnf to support having multiple kernel packages installed. AIUI, that was implemented because: 1) The kernel is the biggest source of regressions 2) It'd be quite noticeable if all of your kernel modules were deleted Of course point 2) applies to a lot of userspace too...that's something rpm-ostree fixes of course. Anyways, in some testing all we need to do really is just turn that logic off unconditionally. Closes: https://github.com/projectatomic/rpm-ostree/issues/946 Closes: #1228 Approved by: jlebon
2018-01-28 23:16:22 +03:00
# Test that we can override the kernel. For ease of testing
vmcheck: Adapt test-override-kernel.sh This is one of the tests right now that assumes it's running on f29. We might be sort of in this awkward dual path for a while where we want tests to run on both f29 (i.e. FAH) and f30 (i.e. FCOS). Closes: #1900 Approved by: cgwalters
2019-09-06 22:34:11 +03:00
# I just picked the "gold" F29/30 kernel.
core: Set installonly to ensure we only have one kernel The goal here is to support `override replace kernel.x86_64.rpm`. There's a whole lot of logic in libdnf to support having multiple kernel packages installed. AIUI, that was implemented because: 1) The kernel is the biggest source of regressions 2) It'd be quite noticeable if all of your kernel modules were deleted Of course point 2) applies to a lot of userspace too...that's something rpm-ostree fixes of course. Anyways, in some testing all we need to do really is just turn that logic off unconditionally. Closes: https://github.com/projectatomic/rpm-ostree/issues/946 Closes: #1228 Approved by: jlebon
2018-01-28 23:16:22 +03:00
current=$(vm_get_booted_csum)
vm_cmd rpm-ostree db list "${current}" > current-dblist.txt
vmcheck: Adapt test-override-kernel.sh This is one of the tests right now that assumes it's running on f29. We might be sort of in this awkward dual path for a while where we want tests to run on both f29 (i.e. FAH) and f30 (i.e. FCOS). Closes: #1900 Approved by: cgwalters
2019-09-06 22:34:11 +03:00
case $versionid in
Rework vmcheck to use `kola spawn`, move off of PAPR There's a lot going on here, but essentially: 1. We change the `vmcheck` model so that it always operates on an immutable base image. It takes that image and dynamically launches a separate VM for each test using `kola spawn`. This means we can drop a lot of hacks around re-using the same VMs. 2. Following from 1., `vmoverlay` now takes as input a base image, overlays the built rpm-ostree bits, then creates a new base image. Of course, we don't have to do this in CI, because we build FCOS with the freshly built RPMs (so it uses `SKIP_VMOVERLAY=1`). `vmoverlay` then will be more for the developer case where one doesn't want to iterate via `cosa build` to test rpm-ostree changes. I say "will" because the functionality doesn't exist yet; I'd like to enhance `cosa dev-overlay` to do this. (Note `vmsync` should still works just as before too.) 3. `vmcheck` can be run without building the tree first, as `tests/vmcheck.sh`. The `make vmcheck` target still exists though for finger compatibility and better meshing with `vmoverlay` in the developer case. What's really nice about using kola spawn is that it takes care of a lot of things for us, such as the qemu command, journal and console gathering, and SSH. Similarly to the compose testsuites, we're using parallel here to run multiple vmcheck tests at once. (On developer laptops, we cap parallelism at `$(nproc) - 1`).
2019-12-13 20:23:41 +03:00
31) kernel_release=5.3.7-301.fc31.x86_64;;
vmcheck: Adapt test-override-kernel.sh This is one of the tests right now that assumes it's running on f29. We might be sort of in this awkward dual path for a while where we want tests to run on both f29 (i.e. FAH) and f30 (i.e. FCOS). Closes: #1900 Approved by: cgwalters
2019-09-06 22:34:11 +03:00
*) assert_not_reached "Unsupported Fedora version: $versionid";;
esac
ci: Bump to f29 Better late than never! Closes: #1787 Approved by: cgwalters
2019-03-15 17:00:52 +03:00
assert_not_file_has_content current-dblist.txt $kernel_release
tests/vmcheck: Adapt to kernel v5.0 Closes: #1810 Approved by: jlebon
2019-04-04 18:33:19 +03:00
grep -E '^ kernel-5' current-dblist.txt | sed -e 's,^ *,,' > orig-kernel.txt
core: Set installonly to ensure we only have one kernel The goal here is to support `override replace kernel.x86_64.rpm`. There's a whole lot of logic in libdnf to support having multiple kernel packages installed. AIUI, that was implemented because: 1) The kernel is the biggest source of regressions 2) It'd be quite noticeable if all of your kernel modules were deleted Of course point 2) applies to a lot of userspace too...that's something rpm-ostree fixes of course. Anyways, in some testing all we need to do really is just turn that logic off unconditionally. Closes: https://github.com/projectatomic/rpm-ostree/issues/946 Closes: #1228 Approved by: jlebon
2018-01-28 23:16:22 +03:00
assert_streq "$(wc -l < orig-kernel.txt)" "1"
orig_kernel=$(cat orig-kernel.txt)
vmcheck: Adapt test-override-kernel.sh This is one of the tests right now that assumes it's running on f29. We might be sort of in this awkward dual path for a while where we want tests to run on both f29 (i.e. FAH) and f30 (i.e. FCOS). Closes: #1900 Approved by: cgwalters
2019-09-06 22:34:11 +03:00
URL_ROOT="https://dl.fedoraproject.org/pub/fedora/linux/releases/$versionid/Everything/x86_64/os/Packages/k"
app: Add support for passing URLs to RPMs This teaches the client to fetch packages from URLs directly so that one doesn't have to `curl` first and then install. Supported anywhere package filenames are allowed (notably: `install` and `override replace`). One neat things about this is that we download the file into an `O_TMPFILE` and then pass on ownership of that fd directly to the daemon. So at no point are the packages actually laying visible on the system. (Assuming the filesystem supports `O_TMPFILE` that is). This adds direct linking to libcurl and openssl, two libraries which we were already pulling in indirectly. Closes: #1508 Approved by: cgwalters
2018-08-18 00:34:02 +03:00
vm_rpmostree override replace \
ci: Bump to f29 Better late than never! Closes: #1787 Approved by: cgwalters
2019-03-15 17:00:52 +03:00
"$URL_ROOT/kernel{,-core,-modules{,-extra}}-$kernel_release.rpm"
core: Set installonly to ensure we only have one kernel The goal here is to support `override replace kernel.x86_64.rpm`. There's a whole lot of logic in libdnf to support having multiple kernel packages installed. AIUI, that was implemented because: 1) The kernel is the biggest source of regressions 2) It'd be quite noticeable if all of your kernel modules were deleted Of course point 2) applies to a lot of userspace too...that's something rpm-ostree fixes of course. Anyways, in some testing all we need to do really is just turn that logic off unconditionally. Closes: https://github.com/projectatomic/rpm-ostree/issues/946 Closes: #1228 Approved by: jlebon
2018-01-28 23:16:22 +03:00
new=$(vm_get_pending_csum)
vm_cmd rpm-ostree db list "${new}" > new-dblist.txt
ci: Bump to f29 Better late than never! Closes: #1787 Approved by: cgwalters
2019-03-15 17:00:52 +03:00
assert_file_has_content_literal new-dblist.txt $kernel_release
core: Set installonly to ensure we only have one kernel The goal here is to support `override replace kernel.x86_64.rpm`. There's a whole lot of logic in libdnf to support having multiple kernel packages installed. AIUI, that was implemented because: 1) The kernel is the biggest source of regressions 2) It'd be quite noticeable if all of your kernel modules were deleted Of course point 2) applies to a lot of userspace too...that's something rpm-ostree fixes of course. Anyways, in some testing all we need to do really is just turn that logic off unconditionally. Closes: https://github.com/projectatomic/rpm-ostree/issues/946 Closes: #1228 Approved by: jlebon
2018-01-28 23:16:22 +03:00
if grep -q -F -e "${orig_kernel}" new-dblist.txt; then
fatal "Found kernel: ${line}"
fi
core: Finish implementing `override replace ./kernel*.x86_64.rpm Previously we merged: #1228 AKA 12dc565b00638182664bc21cd90ff12d49ac2e5a My recollection is that was working on it the background, while doing something else, and I clearly didn't get to the point of testing it "for real". There are many interlocking issues here to make this work. For example, the "remove RPM" logic needs special handling for the kernel, because we also inject content into `/usr/lib/ostree-boot` and also generate the initramfs, etc. The architecture I chose is to have the core *detect* when a kernel is changed, and also call into the kernel processing code when removing a kernel package. But the logic for doing kernel reinstallation client-side is best alongside the initramfs generation logic which already existed in the sysroot upgrader. I extended the test suite to cover what was failing before, and I tested this interactively. But I'm uncertain about adding a test for actually *booting* into the GA kernel as it's quite possible some bits in userspace rely on a newer kernel. Fixing this properly really wants some infrastructure to better "re-version" an existing package without changing its content. Closes: https://github.com/projectatomic/rpm-ostree/issues/1334 Closes: #1346 Approved by: jlebon
2018-04-23 19:59:57 +03:00
newroot=$(vm_get_deployment_root 0)
vm_cmd find ${newroot}/usr/lib/modules -maxdepth 1 -type d > modules-dirs.txt
assert_streq "$(wc -l < modules-dirs.txt)" "2"
ci: Bump to f29 Better late than never! Closes: #1787 Approved by: cgwalters
2019-03-15 17:00:52 +03:00
assert_file_has_content_literal modules-dirs.txt $kernel_release
core: Finish implementing `override replace ./kernel*.x86_64.rpm Previously we merged: #1228 AKA 12dc565b00638182664bc21cd90ff12d49ac2e5a My recollection is that was working on it the background, while doing something else, and I clearly didn't get to the point of testing it "for real". There are many interlocking issues here to make this work. For example, the "remove RPM" logic needs special handling for the kernel, because we also inject content into `/usr/lib/ostree-boot` and also generate the initramfs, etc. The architecture I chose is to have the core *detect* when a kernel is changed, and also call into the kernel processing code when removing a kernel package. But the logic for doing kernel reinstallation client-side is best alongside the initramfs generation logic which already existed in the sysroot upgrader. I extended the test suite to cover what was failing before, and I tested this interactively. But I'm uncertain about adding a test for actually *booting* into the GA kernel as it's quite possible some bits in userspace rely on a newer kernel. Fixing this properly really wants some infrastructure to better "re-version" an existing package without changing its content. Closes: https://github.com/projectatomic/rpm-ostree/issues/1334 Closes: #1346 Approved by: jlebon
2018-04-23 19:59:57 +03:00
core: Set installonly to ensure we only have one kernel The goal here is to support `override replace kernel.x86_64.rpm`. There's a whole lot of logic in libdnf to support having multiple kernel packages installed. AIUI, that was implemented because: 1) The kernel is the biggest source of regressions 2) It'd be quite noticeable if all of your kernel modules were deleted Of course point 2) applies to a lot of userspace too...that's something rpm-ostree fixes of course. Anyways, in some testing all we need to do really is just turn that logic off unconditionally. Closes: https://github.com/projectatomic/rpm-ostree/issues/946 Closes: #1228 Approved by: jlebon
2018-01-28 23:16:22 +03:00
echo "ok override kernel"
initramfs: Fix using local /etc when also replacing kernel Instead of basing our decision to use the local `/etc` on whether we're using `dracut --rebuild`, base it directly on a boolean parameter. This is relevant in the client-side when initramfs regeneration is requested as well as a kernel override. In such cases, we do want to use the local `/etc`, but we'd skip that path because we didn't also use `dracut --rebuild`. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1806588
2020-02-26 19:14:51 +03:00
# And check that we can regenerate the initramfs and include files from our /etc
vm_cmd touch /etc/foobar.conf
vm_rpmostree initramfs --enable --arg=-I --arg=/etc/foobar.conf
newroot=$(vm_get_deployment_root 0)
vm_cmd lsinitrd ${newroot}/usr/lib/modules/${kernel_release}/initramfs.img > lsinitrd.txt
assert_file_has_content_literal lsinitrd.txt etc/foobar.conf
echo "ok override kernel with custom initramfs args"
Reference in New Issue Copy Permalink