keremet/rpm-ostree
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity
170095bd60
rpm-ostree/tests/compose/test-boot-location-modules.sh

27 lines
878 B
Bash
Raw Normal View History

compose: Add `boot-location: modules` And this (for now at least) completes the epic journey of the "where's the kernel"? With this it's found solely in `/usr/lib/modules/$kver`. There are a few reasons to do this; most prominent is that it avoids duplicating the content as the locations may have different SELinux labels. Closes: #1773 Approved by: jlebon
2019-03-07 03:36:44 +03:00
#!/bin/bash
set -xeuo pipefail
tests/compose: Target FCOS 31, move off of PAPR Again, a lot going on here, but essentially, we adapt the compose tests to run either privileged or fully unprivileged via supermin, just like cosa. I actually got more than halfway through this initially using `cosa build` directly for testing. But in the end, we simply need more flexibility than that. We want to be able to manipulate exactly how rpm-ostree is called, and cosa is very opinionated about this (and may also change from under us in the future). (Another big difference for example is that cosa doesn't care about non-unified mode, whereas we *need* to have coverage for this until we fully kill it.) Really, the most important bit we want from there is the unprivileged-via-supermin bits. So we copy and adapt that here. One obvious improvement then is sharing this code more easily (e.g. a `cosa runasroot` or something?) However, we still use the FCOS manifest (frozen at a specific tag). It's a realistic example, and because of the lockfiles and pool, we get good reproducibility.
2019-12-22 01:42:09 +03:00
dn=$(cd "$(dirname "$0")" && pwd)
# shellcheck source=libcomposetest.sh
. "${dn}/libcomposetest.sh"
compose: Add `boot-location: modules` And this (for now at least) completes the epic journey of the "where's the kernel"? With this it's found solely in `/usr/lib/modules/$kver`. There are a few reasons to do this; most prominent is that it avoids duplicating the content as the locations may have different SELinux labels. Closes: #1773 Approved by: jlebon
2019-03-07 03:36:44 +03:00
tests/compose: Target FCOS 31, move off of PAPR Again, a lot going on here, but essentially, we adapt the compose tests to run either privileged or fully unprivileged via supermin, just like cosa. I actually got more than halfway through this initially using `cosa build` directly for testing. But in the end, we simply need more flexibility than that. We want to be able to manipulate exactly how rpm-ostree is called, and cosa is very opinionated about this (and may also change from under us in the future). (Another big difference for example is that cosa doesn't care about non-unified mode, whereas we *need* to have coverage for this until we fully kill it.) Really, the most important bit we want from there is the unprivileged-via-supermin bits. So we copy and adapt that here. One obvious improvement then is sharing this code more easily (e.g. a `cosa runasroot` or something?) However, we still use the FCOS manifest (frozen at a specific tag). It's a realistic example, and because of the lockfiles and pool, we get good reproducibility.
2019-12-22 01:42:09 +03:00
treefile_set boot-location '"modules"'
compose: Add `boot-location: modules` And this (for now at least) completes the epic journey of the "where's the kernel"? With this it's found solely in `/usr/lib/modules/$kver`. There are a few reasons to do this; most prominent is that it avoids duplicating the content as the locations may have different SELinux labels. Closes: #1773 Approved by: jlebon
2019-03-07 03:36:44 +03:00
runcompose
echo "ok compose"
# Nothing in /boot (but it should exist)
tests/compose: Target FCOS 31, move off of PAPR Again, a lot going on here, but essentially, we adapt the compose tests to run either privileged or fully unprivileged via supermin, just like cosa. I actually got more than halfway through this initially using `cosa build` directly for testing. But in the end, we simply need more flexibility than that. We want to be able to manipulate exactly how rpm-ostree is called, and cosa is very opinionated about this (and may also change from under us in the future). (Another big difference for example is that cosa doesn't care about non-unified mode, whereas we *need* to have coverage for this until we fully kill it.) Really, the most important bit we want from there is the unprivileged-via-supermin bits. So we copy and adapt that here. One obvious improvement then is sharing this code more easily (e.g. a `cosa runasroot` or something?) However, we still use the FCOS manifest (frozen at a specific tag). It's a realistic example, and because of the lockfiles and pool, we get good reproducibility.
2019-12-22 01:42:09 +03:00
ostree --repo="${repo}" ls -R "${treeref}" /boot > bootls.txt
compose: Add `boot-location: modules` And this (for now at least) completes the epic journey of the "where's the kernel"? With this it's found solely in `/usr/lib/modules/$kver`. There are a few reasons to do this; most prominent is that it avoids duplicating the content as the locations may have different SELinux labels. Closes: #1773 Approved by: jlebon
2019-03-07 03:36:44 +03:00
cat >bootls-expected.txt <<EOF
d00755 0 0 0 /boot
EOF
diff -u bootls{-expected,}.txt
# Verify /usr/lib/ostree-boot
tests/compose: Target FCOS 31, move off of PAPR Again, a lot going on here, but essentially, we adapt the compose tests to run either privileged or fully unprivileged via supermin, just like cosa. I actually got more than halfway through this initially using `cosa build` directly for testing. But in the end, we simply need more flexibility than that. We want to be able to manipulate exactly how rpm-ostree is called, and cosa is very opinionated about this (and may also change from under us in the future). (Another big difference for example is that cosa doesn't care about non-unified mode, whereas we *need* to have coverage for this until we fully kill it.) Really, the most important bit we want from there is the unprivileged-via-supermin bits. So we copy and adapt that here. One obvious improvement then is sharing this code more easily (e.g. a `cosa runasroot` or something?) However, we still use the FCOS manifest (frozen at a specific tag). It's a realistic example, and because of the lockfiles and pool, we get good reproducibility.
2019-12-22 01:42:09 +03:00
ostree --repo="${repo}" ls -R "${treeref}" /usr/lib/ostree-boot > bootls.txt
compose: Add `boot-location: modules` And this (for now at least) completes the epic journey of the "where's the kernel"? With this it's found solely in `/usr/lib/modules/$kver`. There are a few reasons to do this; most prominent is that it avoids duplicating the content as the locations may have different SELinux labels. Closes: #1773 Approved by: jlebon
2019-03-07 03:36:44 +03:00
assert_not_file_has_content bootls.txt vmlinuz-
assert_not_file_has_content bootls.txt initramfs-
# And use the kver to find the kernel in /usr/lib/modules
tests/compose: Target FCOS 31, move off of PAPR Again, a lot going on here, but essentially, we adapt the compose tests to run either privileged or fully unprivileged via supermin, just like cosa. I actually got more than halfway through this initially using `cosa build` directly for testing. But in the end, we simply need more flexibility than that. We want to be able to manipulate exactly how rpm-ostree is called, and cosa is very opinionated about this (and may also change from under us in the future). (Another big difference for example is that cosa doesn't care about non-unified mode, whereas we *need* to have coverage for this until we fully kill it.) Really, the most important bit we want from there is the unprivileged-via-supermin bits. So we copy and adapt that here. One obvious improvement then is sharing this code more easily (e.g. a `cosa runasroot` or something?) However, we still use the FCOS manifest (frozen at a specific tag). It's a realistic example, and because of the lockfiles and pool, we get good reproducibility.
2019-12-22 01:42:09 +03:00
ostree --repo="${repo}" ls -R "${treeref}" /usr/lib/modules > modules-lsr.txt
compose: Add `boot-location: modules` And this (for now at least) completes the epic journey of the "where's the kernel"? With this it's found solely in `/usr/lib/modules/$kver`. There are a few reasons to do this; most prominent is that it avoids duplicating the content as the locations may have different SELinux labels. Closes: #1773 Approved by: jlebon
2019-03-07 03:36:44 +03:00
assert_file_has_content modules-lsr.txt '/vmlinuz$'
assert_file_has_content modules-lsr.txt '/initramfs.img$'
echo "ok boot location modules"
Reference in New Issue Copy Permalink