Fixes https://github.com/coreos/bootupd/issues/551
Get hints by https://github.com/coreos/bootupd/issues/551#issuecomment-2124477922,
and copy the comment here:
Basically we detect if we're running in systemd; if we're not,
we re-exec ourselves via systemd-run. Then we can just directly
run code in what is now the daemon.
I think an important aspect of this is that we retain something
like `--unit bootupd` which acts as a lock - only one unit with
that name can run at a time to avoid two concurrent invocations
breaking things.
In https://github.com/osbuild/osbuild/pull/1475 we are updating
aleph version to have more information and some of the fields
are changing slightly. Notably here `imgid` is no longer going to
be populated and `build` -> `version` now. Let's make these tweaks
and also just drop any fields from the definition here that we
aren't using to tolerate changes better.
The fact that we're a systemd unit is mostly an implementation
detail so that we get a natural locking mechanism and
can reuse systemd sandboxing.
If you have the software installed, we want the socket to be
enabled.
Having to work through adding this into presets is just
compounding pain for shipping it in multiple places.
Instead, install a static symlink.
Trying to boot FCOS-Fedora-32 is not sustainable; it turns
out that the recent update to coreos-assembler which passes
a newer Ignition config version broke the adoption test.
In the end, the adopt workflow was really a hack and I'd like
to slowly deprecate it.
In general, most people should be reprovisioning nodes anyways.
Once they do that, they'll pick up the updated shim/grub naturally.
Closes: https://github.com/coreos/bootupd/issues/193
When we switched to a split buildroot/cosa containers, this
broke. We can just delete this line because the code-under-test is in
`overrides/rootfs`, so doing `rm overrides/rpm/*` won't remove it.
This is copied/adapted from rpm-ostree. I'm mainly doing
this to prove out adding another GH repo using the nested
virt support.
As part of this, add the "standard" `tests/kolainst` directory
that just copies in our un-installed tests.
This is a middle ground between:
1) Parse arbitrary text output from `bootupctl status`; this could
change at any time.
2) Parse JSON from `bootupctl status --json`; parsing this requires
knowlege of bootupd and the JSON format still isn't 100% fixed
in stone either.
Projects like https://github.com/openshift/machine-config-operator/
will basically want a flow that just allows them to check for
outstanding updates and apply them one node at a time.
Came up in review in https://github.com/coreos/fedora-coreos-docs/pull/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: https://github.com/coreos/bootupd/issues/103
Since bootupd 0.1.1 shipped in FCOS stable
we need to support updating it, as well as
"pre-bootupd" systems and bootupd 0.2 systems.
I tested this manually; not yet adding an e2e yet for
this because our test suite is already really
expensive and the unit test covers most of it.
Closes: https://github.com/coreos/bootupd/issues/91
So far we've supported updating systems that we installed,
but we also need to handle updating at least older CoreOS
systems.
This shares a lot of similarity with `update`; the biggest
difference is that we aren't sure which files we should
be managing. So given a pending update, we only replace
files that exist in that update.
Closes: https://github.com/coreos/bootupd/issues/38
For now let's address concerns over how we represent
the operating system by dropping them from the status
JSON. Instead detect CoreOS specifically client side
too and print the aleph there.
There's no reason for us to ever parse unknown fields
in status JSON, so let's deny it.
Related, we do want tooling to parse `bootupctl status --json`, so let's
add a test to validate we're not unexpectedly breaking it.
This is prep for work on "adoption":
https://github.com/coreos/bootupd/issues/38
In order to (as safely as possible) take over management
of a system *not installed via bootupd* we want to gather
as much information as we can.
For example, we can use the imgid as the "version" of the
current bootloader data.
I noticed we were missing `kebab-case` on a few structs (but
it doesn't matter since none of them have a name that would change).
To ensure we don't regress on parsing old file formats, add a JSON
file from a current system and test loading it.
There's no reason to sit there taking up RAM just because
someone did `bootupctl status`. Properly implementing
exit-on-idle really requires an event loop (e.g. `tokio`)
but that'd be a large change.
For now let's just exit when a client disconnects. However,
this quickly broke the test suite which does a lot of
commands in a row.
Tweak the systemd unit to allow more restarts, and also
add a few strategic sleeps.
Closes: https://github.com/coreos/bootupd/issues/43
This reworks the CLI options parser to branch the inner logic
to accommodate two entrypoints, `bootupd` and `bootupctl`, into
a single multicall binary.
Let's add support for checking the on-disk state. This helps
cross-check our implementation and is also useful for administrators
(ref `ostree fsck`, `rpm -V` etc).
There's no good reason to have version numbers be optional.
They're essential for human understanding of things.
We still use a timestamp around for total ordering.
Rework the model to more precisely keep track of "upgradable".
Similar to the previous move of `status`, return a structure
from the daemon and render it on the client. This actually
moves more logic for updating to the client too; the IPC request
updates just one component, and the client iterates over all
installed components to update.
This way we also better return "partial" status.
The way we were just serializing a `String` from daemon → client
was rather...crude. Instead have the daemon return a serialized
status object which we print on the client end.
A good way to look at what we need is something much like
systemd's `bootctl` except for shim/grub2.
It's not as nice for admins to explicitly type
`/usr/libexec/bootupd`, plus it intermixes options
with things they shouldn't use.
Move the "backend" options to a hidden `backend` verb for now.
The previous code ended up being fairly wrong in various ways.
It was trying to be too abstract - let's keep *some* level
of abstraction but just implement EFI for now.
Among other changes, this now correctly works when inserted
into the rpm-ostree flow and also the coreos-assembler flow.
