-
Notifications
You must be signed in to change notification settings - Fork 59
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
aleph file extra attributes gives bootupctl status error #1724
Comments
Ouch, good catch. (How did you notice this BTW?) I was confused at first by the bootupd error here (there's only one So basically this means that anyone who installed on those specific versions will not be able to use bootupd to update their bootloader. We could ship a systemd unit to fix those nodes, though OTOH the number of nodes that installed on any specific version is quite low and the workaround is trivial. But definitely not opposed. |
I logged in to our Mostly just chance.
Yep. I'm responsible for that code :)
Correct. Those versions were available as "latest" for a month because we skipped the mid december release. I think we should ship a systemd unit to fix it for a few reasons:
|
Good point, agreed. |
This causes bootupctl to fails while parsing the file. The extra field was introduced in coreos/coreos-assembler@c2d37f4 then quickly reverted in coreos/coreos-assembler#3686 Still, a couple of builds (39.20231204.1.0 and 39.20231204.2.1) went out with the change. Fixing this will allow bootupctl to function properly on nodes deployed with this version. This jq filter is idempotent so it's safe to run on all nodes. This should be removed after the next barrier release. Fixes coreos/fedora-coreos-tracker#1724
This causes bootupctl to fails while parsing the file. The extra field was introduced in coreos/coreos-assembler@c2d37f4 then quickly reverted in coreos/coreos-assembler#3686 Still, a couple of builds (39.20231204.1.0 and 39.20231204.2.1) went out with the change. Fixing this will allow bootupctl to function properly on nodes deployed with this version. This jq filter is idempotent so it's safe to run on all nodes. This should be removed after the next barrier release. Fixes coreos/fedora-coreos-tracker#1724
This causes bootupctl to fails while parsing the file. The extra field was introduced in coreos/coreos-assembler@c2d37f4 then quickly reverted in coreos/coreos-assembler#3686 Still, a couple of builds (39.20231204.1.0 and 39.20231204.2.1) went out with the change. Fixing this will allow bootupctl to function properly on nodes deployed with this version. This jq filter is idempotent so it's safe to run on all nodes. This should be removed after the next barrier release. Fixes coreos/fedora-coreos-tracker#1724
This causes bootupctl to fails while parsing the file. The extra field was introduced in coreos/coreos-assembler@c2d37f4 then quickly reverted in coreos/coreos-assembler#3686 Still, a couple of builds (39.20231204.1.0 and 39.20231204.2.1) went out with the change. Fixing this will allow bootupctl to function properly on nodes deployed with this version. This jq filter is idempotent so it's safe to run on all nodes. This should be removed after the next barrier release. Fixes coreos/fedora-coreos-tracker#1724
This causes bootupctl to fails while parsing the file. The extra field was introduced in coreos/coreos-assembler@c2d37f4 then quickly reverted in coreos/coreos-assembler#3686 Still, a couple of builds (39.20231204.1.0 and 39.20231204.2.1) went out with the change. Fixing this will allow bootupctl to function properly on nodes deployed with this version. This jq filter is idempotent so it's safe to run on all nodes. This should be removed after the next barrier release. Fixes coreos/fedora-coreos-tracker#1724
This causes bootupctl to fails while parsing the file. The extra field was introduced in coreos/coreos-assembler@c2d37f4 then quickly reverted in coreos/coreos-assembler#3686 Still, a couple of builds (39.20231204.1.0 and 39.20231204.2.1) went out with the change. Fixing this will allow bootupctl to function properly on nodes deployed with this version. This jq filter is idempotent so it's safe to run on all nodes. This should be removed after the next barrier release. Fixes coreos/fedora-coreos-tracker#1724
This causes bootupctl to fails while parsing the file. The extra field was introduced in coreos/coreos-assembler@c2d37f4 then quickly reverted in coreos/coreos-assembler#3686 Still, a couple of builds (39.20231204.1.0 and 39.20231204.2.1) went out with the change. Fixing this will allow bootupctl to function properly on nodes deployed with this version. This jq filter is idempotent so it's safe to run on all nodes. This should be removed after the next barrier release. Fixes coreos/fedora-coreos-tracker#1724
This causes bootupctl to fails while parsing the file. The extra field was introduced in coreos/coreos-assembler@c2d37f4 then quickly reverted in coreos/coreos-assembler#3686 Still, a couple of builds (39.20231204.1.0 and 39.20231204.2.1) went out with the change. Fixing this will allow bootupctl to function properly on nodes deployed with this version. This jq filter is idempotent so it's safe to run on all nodes. This should be removed after the next barrier release. Fixes coreos/fedora-coreos-tracker#1724
This causes bootupctl to fails while parsing the file. The extra field was introduced in coreos/coreos-assembler@c2d37f4 then quickly reverted in coreos/coreos-assembler#3686 Still, a couple of builds (39.20231204.1.0 and 39.20231204.2.1) went out with the change. Fixing this will allow bootupctl to function properly on nodes deployed with this version. This jq filter is idempotent so it's safe to run on all nodes. This should be removed after the next barrier release. Fixes coreos/fedora-coreos-tracker#1724
This causes bootupctl to fails while parsing the file. The extra field was introduced in coreos/coreos-assembler@c2d37f4 then quickly reverted in coreos/coreos-assembler#3686 Still, a couple of builds (39.20231204.1.0 and 39.20231204.2.1) went out with the change. Fixing this will allow bootupctl to function properly on nodes deployed with this version. This jq filter is idempotent so it's safe to run on all nodes. This should be removed after the next barrier release. Fixes coreos/fedora-coreos-tracker#1724
Due to an ordering mishap, some builds have both a `version` and a `build` field. This causes bootupctl to fail while parsing the file. Detect this case, and fix the aleph if necessary by removing the `build` field. This should be removed after the next barrier release. Fixes: coreos/fedora-coreos-tracker#1724
Due to an ordering mishap, some builds have both a `version` and a `build` field. This causes bootupctl to fail while parsing the file. Detect this case, and fix the aleph if necessary by removing the `build` field. This should be removed after the next barrier release. Fixes: coreos/fedora-coreos-tracker#1724
Due to an ordering mishap, some builds have both a `version` and a `build` field. This causes bootupctl to fail while parsing the file. Detect this case, and fix the aleph if necessary by removing the `build` field. This should be removed after the next barrier release. Fixes: coreos/fedora-coreos-tracker#1724 Co-authored-by: Jonathan Lebon <jonathan@jlebon.com>
Due to an ordering mishap, some builds have both a `version` and a `build` field. This causes bootupctl to fail while parsing the file. Detect this case, and fix the aleph if necessary by removing the `build` field. This should be removed after the next barrier release. Fixes: coreos/fedora-coreos-tracker#1724 Co-authored-by: Jonathan Lebon <jonathan@jlebon.com>
The fix for this went into testing stream release |
The fix for this went into |
There is some history here, but the aleph file for a specific release of Fedora CoreOS on the
testing
andnext
streams had an extra field in the aleph file:As far as I can tell this only affected one release of
next
andtesting
:next
testing
stable
We halted the
20231217
releases because we detected this problem:We reverted the original change that caused this behavior in coreos/coreos-assembler#3686
I guess I had thought that the problematic commit hadn't actually gone into any releases but apparently it had gone out in the previous set of
testing
andnext
releases (39.20231204.2.1
and39.20231204.1.0
).The text was updated successfully, but these errors were encountered: