Add a bootupd section #203
Conversation
cgwalters
force-pushed
the
bootupd
branch
2 times, most recently
from
fdbf72a
to
7d47566
Compare
|
OK I also need to get coreos/bootupd#102 through the sausage factory before we merge this. |
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
Done though: I think at a high level right now it's only going to be a small subset of users that realize they might need this, and those users can probably wade through some of the upstream bootupd docs/code and or simply play with the CLI interactively. But it did motivate me to do the the above PR which fixes that UX problem anyways. |
Thanks for the fix (and the upstream fix). In general, if we think a use case is mainstream enough to be worth documenting, I think it's worth giving actionable advice. |
| # | ||
| ---- | ||
|
|
||
| .Example systemd unit to automate bootupd updates |
There was a problem hiding this comment.
Should we have a Note: somewhere around here to say that one may not actually want to update the bootloader automatically on every host update?
There was a problem hiding this comment.
Not sure what to say; either you update it automatically or you don't, right?
In the end I think this doc is on the edge for whether it should live here or in just in bootupd git as is today. I leaned towards here just to make it more official but if we're hesitating we can just do the latter and come back here when we have a more "final" decision on bootupd's defaults. |
|
Personally, I think having instructions for updating the bootloader manually would be good in the official docs. 👍 The part I'm not sure about is the automatic updating systemd service. Feels like we should flesh out how we feel about that ourselves before providing a copy-paste example for enabling it? |
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
Let's describe the status quo. Co-authored-by: Benjamin Gilbert <bgilbert@backtick.net> Co-authored-by: Timothée Ravier <travier@redhat.com>
|
OK since FCOS33 is rolling out (which has the updated bootupd) this one should be finally good to go! |
Let's describe the status quo.