-
Notifications
You must be signed in to change notification settings - Fork 159
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add platform-specific console configuration metadata #1181
Conversation
I know this depends on the backend implementation, but.. any chance we could or should use yaml here (supports comments), which may be quite useful in the future help add context for why a platform might need particular kernel arguments. |
YAML precludes the use of |
I may have missed this, but it seems odd to ship things in the OS that we're not actually using at runtime. We've been using For |
We don't strictly need it in You're right that we don't strictly need JSON in cosa, and coreos-installer could parse YAML if we want. But for a machine-readable API it seems like JSON would be a better choice? |
Not a fan of having them in both How about having them as YAML files under a new |
yay for YAML (at least in the most recent upload) Any chance we can link to as much information as possible about why each platform/arch gets these values? platform documentation would be the most appropriate, but discovered knowledge (like investigation/discussion in GH issue comments) would also suffice. Basically it would be really nice in the future to know where to fish for similar information if we need to. |
Added comments, and a flag to disable the new behavior on x86_64 until a migration period has been announced. Ready for review. |
Thanks so much for adding the context links. That will be really really helpful in the future. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM - will try to test later today
ok one final question. I went through and built without I understand that you said this file doesn't affect the Note I'm specifically testing on |
The coreos/coreos-assembler#2400 includes code specifically to ensure that invocation of QEMU images through kola will not be affected by this change. |
yeah - considering we have |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
This is a workaround to get console=ttyS0,115200n8 into the aarch64 AWS image. It does so by applying the following patch to gf-platformid: ```diff diff --git a/usr/lib/coreos-assembler/gf-platformid b/usr/lib/coreos-assembler/gf-platformid index 2912b322c..36d089651 100755 --- a/usr/lib/coreos-assembler/gf-platformid +++ b/usr/lib/coreos-assembler/gf-platformid @@ -46,7 +46,11 @@ blscfg_path=$(coreos_gf glob-expand /boot/loader/entries/ostree-*.conf) coreos_gf download "${blscfg_path}" "${tmpd}"/bls.conf # Remove any platformid currently there sed -i -e 's, ignition.platform.id=[a-zA-Z0-9]*,,g' "${tmpd}"/bls.conf -sed -i -e 's,^\(options .*\),\1 ignition.platform.id='"${platformid}"',' "${tmpd}"/bls.conf +if [ "${platformid}" == 'aws' ]; then + sed -i -e 's|^\(options .*\)|\1 ignition.platform.id='"${platformid}"' console=ttyS0,115200n8|' "${tmpd}"/bls.conf +else + sed -i -e 's,^\(options .*\),\1 ignition.platform.id='"${platformid}"',' "${tmpd}"/bls.conf +fi coreos_gf upload "${tmpd}"/bls.conf "${blscfg_path}" if [ "$basearch" = "s390x" ] ; then ``` Once coreos/fedora-coreos-config#1181 and coreos/coreos-assembler#2400 land then we won't need this any longer. This implements a fix for coreos/fedora-coreos-tracker#920
This is a workaround to get console=ttyS0,115200n8 into the aarch64 AWS image. It does so by applying the following patch to gf-platformid: ```diff diff --git a/usr/lib/coreos-assembler/gf-platformid b/usr/lib/coreos-assembler/gf-platformid index 2912b322c..36d089651 100755 --- a/usr/lib/coreos-assembler/gf-platformid +++ b/usr/lib/coreos-assembler/gf-platformid @@ -46,7 +46,11 @@ blscfg_path=$(coreos_gf glob-expand /boot/loader/entries/ostree-*.conf) coreos_gf download "${blscfg_path}" "${tmpd}"/bls.conf # Remove any platformid currently there sed -i -e 's, ignition.platform.id=[a-zA-Z0-9]*,,g' "${tmpd}"/bls.conf -sed -i -e 's,^\(options .*\),\1 ignition.platform.id='"${platformid}"',' "${tmpd}"/bls.conf +if [ "${platformid}" == 'aws' ]; then + sed -i -e 's|^\(options .*\)|\1 ignition.platform.id='"${platformid}"' console=ttyS0,115200n8|' "${tmpd}"/bls.conf +else + sed -i -e 's,^\(options .*\),\1 ignition.platform.id='"${platformid}"',' "${tmpd}"/bls.conf +fi coreos_gf upload "${tmpd}"/bls.conf "${blscfg_path}" if [ "$basearch" = "s390x" ] ; then ``` Once coreos/fedora-coreos-config#1181 and coreos/coreos-assembler#2400 land then we won't need this any longer. This implements a fix for coreos/fedora-coreos-tracker#920
This is a workaround to get console=ttyS0,115200n8 into the aarch64 AWS image. It does so by applying the following patch to gf-platformid: ```diff diff --git a/usr/lib/coreos-assembler/gf-platformid b/usr/lib/coreos-assembler/gf-platformid index 2912b322c..36d089651 100755 --- a/usr/lib/coreos-assembler/gf-platformid +++ b/usr/lib/coreos-assembler/gf-platformid @@ -46,7 +46,11 @@ blscfg_path=$(coreos_gf glob-expand /boot/loader/entries/ostree-*.conf) coreos_gf download "${blscfg_path}" "${tmpd}"/bls.conf # Remove any platformid currently there sed -i -e 's, ignition.platform.id=[a-zA-Z0-9]*,,g' "${tmpd}"/bls.conf -sed -i -e 's,^\(options .*\),\1 ignition.platform.id='"${platformid}"',' "${tmpd}"/bls.conf +if [ "${platformid}" == 'aws' ]; then + sed -i -e 's|^\(options .*\)|\1 ignition.platform.id='"${platformid}"' console=ttyS0,115200n8|' "${tmpd}"/bls.conf +else + sed -i -e 's,^\(options .*\),\1 ignition.platform.id='"${platformid}"',' "${tmpd}"/bls.conf +fi coreos_gf upload "${tmpd}"/bls.conf "${blscfg_path}" if [ "$basearch" = "s390x" ] ; then ``` Once coreos/fedora-coreos-config#1181 and coreos/coreos-assembler#2400 land then we won't need this any longer. This implements a fix for coreos/fedora-coreos-tracker#920
These tests have never run successfully on s390x. Skip them for now and investigate wether or not they can be adapted for s390x. Signed-off-by: Jan Schintag <jan.schintag@de.ibm.com>
SELinux denials are causing some issues and we need to have them looked at. See coreos/fedora-coreos-tracker#1097
Since we're re-enabling `branched` we need these to apply there too.
Can not reproduce `coreos.boot-mirror.luks` failed issue locally with rawhide after running 20 times, remove from denylist to see if it happens. See coreos/fedora-coreos-tracker#1092
We're going to rebase RHCOS 4.11, which picks up a new NM, and the new case is actually the same. BTW, minor rant here: We really need to stop defaulting to writing conditionals that do `if is_fcos() {} else if is_rhcos() {}` because about 70% of the time, this is actually trying to test "RHEL 8" versus "Fedora". And in this case, what we want to dispatch on is the RHEL8 minor version. Or even the NetworkManager version. Anyways for now, because we haven't updated the `redhat-release-coreos` package because doing so is painful, dispatch on the OCP version.
As mentioned in coreos/fedora-coreos-tracker#1209, due to upstream changes, our current mechanism for testing if RANDOM_TRUST_CPU is enabled is no longer valid. Lets instead check the kernel config file to get the same information. fixes: coreos/fedora-coreos-tracker#1209
…hide" This reverts commit 13b9560. coreos/fedora-coreos-tracker#1209 has been fixed by #1764. We can once again enable this test on rawhide.
We're seeing a weird failure there. Let's denylist it for now while it is investigated. See coreos/fedora-coreos-tracker#1215
Upstream NM started adding a readme-ifcfg-rh.txt file to explain and encourage people to use keyfiles instead. This file doesn't do anything, but breaks our logic that tries to determine if the user provided networking config to the machine. This file was added upstream in https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/commit/96d7362
Add a check to the no-default-initramfs-net-propagation test to make sure there aren't any unknown files in /etc/sysconfig/network-scripts/. This will allow us to drop the a corresponding test from mantle/kola [1]. [1] https://github.com/coreos/coreos-assembler/blob/5ee768b7ea069c08a7fa0b5b36dbb03bc9cd19ee/mantle/kola/tests/coretest/core.go#L251-L264
Added a kola test. |
cosa create_disk.sh and gf-set-platform will read this. create_disk.sh will also save a JSON version for the relevant architecture to /boot/coreos/platforms.json for coreos-installer.
Updated! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
⛔ The |
Today's lesson: if a PR's head branch is renamed through the GitHub UI, GitHub closes the PR rather than following the rename. 😞 Continuation in #1781. |
coreos-assembler
create_disk.sh
andgf-set-platform
will read this.create_disk.sh
will also save a JSON version for the relevant architecture to/boot/coreos/platforms.json
for coreos-installer.We'll need to post advance warning to coreos-status before landing this.