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. |
|
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 |
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! |
|
⛔ 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.shandgf-set-platformwill read this.create_disk.shwill also save a JSON version for the relevant architecture to/boot/coreos/platforms.jsonfor coreos-installer.We'll need to post advance warning to coreos-status before landing this.