-
Notifications
You must be signed in to change notification settings - Fork 21
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
Don't require adoption for FCOS #103
Comments
cgwalters
added a commit
to cgwalters/bootupd
that referenced
this issue
Nov 11, 2020
Came up in review in coreos/fedora-coreos-docs#203 Basically it's confusing to users that they need to understand the difference between `update` and `adopt-and-update`. From bootupd's perspective these are quite different things; the first case is a completely known quantity, the second isn't. However...we can be pretty confident that we can update systems that have a CoreOS aleph version (i.e. they were generated by coreos-assembler), since we haven't changed how the bootloader is installed there really much at all. This means that for now RHCOS 4.{1,2} bootimages that were generated via Anaconda will still require `adopt-and-update`, but detecting and validating that can come as a second phase. The high level logic here is that the status gains a new `confident: bool` flag (which corresponds right now to "have CoreOS aleph"). The client side looks at this and automatically bridges the `update` CLI to `adopt-and-update`. Closes: coreos#103
openshift-merge-robot
pushed a commit
that referenced
this issue
Nov 13, 2020
Came up in review in coreos/fedora-coreos-docs#203 Basically it's confusing to users that they need to understand the difference between `update` and `adopt-and-update`. From bootupd's perspective these are quite different things; the first case is a completely known quantity, the second isn't. However...we can be pretty confident that we can update systems that have a CoreOS aleph version (i.e. they were generated by coreos-assembler), since we haven't changed how the bootloader is installed there really much at all. This means that for now RHCOS 4.{1,2} bootimages that were generated via Anaconda will still require `adopt-and-update`, but detecting and validating that can come as a second phase. The high level logic here is that the status gains a new `confident: bool` flag (which corresponds right now to "have CoreOS aleph"). The client side looks at this and automatically bridges the `update` CLI to `adopt-and-update`. Closes: #103
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I think we should be confident enough in our process that
bootupctl update
should detect the FCOS case and update it transparently.The text was updated successfully, but these errors were encountered: