On ostree systems, the boot directory already has our desired format, we
should only remove the bootupd-state.json file to avoid bootupctl
complaining about it already existing.
The motivation is that this will preserve the boot entry for the
original deployment, allowing the user to boot into it if they want to.
This also makes sure `ostree admin status` continues working - since if
we're in a booted ostree system but `ostree` can't find its physically
(through boot entries) it complains.
This is just irrelevant noise; nanoseconds never matter for container
builds. Motivated by just making this look visually nicer.
In the future I'd like to look at rendering this how e.g. systemd
does it also including a "; 1 day ago" humantime suffix.
Signed-off-by: Colin Walters <walters@verbum.org>
The previous change here was a no-op for two reasons:
- It's actually usr/etc at this point
- We were operating on the wrong rootfs
Fixes: 57bd0dc983
Signed-off-by: Colin Walters <walters@verbum.org>
Since podman needs to be installed at the start of the flow, let's add a
prompt so the user doesn't get surprised by the podman install
automatically running when simply testing the command.
Signed-off-by: ckyrouac <ckyrouac@redhat.com>
This splits the `podman pull <image>` and the
`podman ... bootc install to-existing` command to prepare for
future features that will require inspecting the image before
constructing the bootc install command.
Signed-off-by: ckyrouac <ckyrouac@redhat.com>
Basically I want to get Anaconda to run this, then we
can perform arbitrary fixups on whatever it did
between the install and reboot without changing Anaconda's
code.
This also applies to user `%post` scripts for example;
maybe those break the bootloader entries in /boot;
we have the opportunity to catch such things here.
Or we may choose to start forcibly relabeling the target
`/etc`.
Signed-off-by: Colin Walters <walters@verbum.org>
This took me some thinking and experimenting. Basically we want:
- Hard deny some warnings (this is covered by the Cargo.toml
workspace.lints.rust)
- Gate merging to main in CI on an exact set of warnings we
want to forbid, but *without* also using a blanket
-Dwarning deny policy because that could break our build
when the compiler revs.
- A corollary to the previous: allow developing locally
without killing the build just because
you have an unused import or some dead code (for example).
So we don't want to add `dead_code = deny` into the Cargo.toml.
- Be able to easily reproduce locally what CI is gating on
in an efficient way.
We already had `make validate-rust` which was intending to navigate
this, but what was missing was the "deny extended set of warnings"
so we got code committed to git main which hit `unused_imports`.
Clippy upstream docs recommend the `RUSTFLAGS = -Dwarnings`
approach in e.g.
https://doc.rust-lang.org/clippy/continuous_integration/github_actions.html
but again I think this is a problem because it can break with
updated Rust/clippy versions (unless you pin on those, but that
becomes a pain in and of itself).
The problem also with doing `RUSTFLAGS = -Dwarnings` *locally*
is it blows out the cargo cache.
So here's the solution I came to: We run `cargo clippy -A clippy:all`,
and then deny some specific clippy lints *and* the core Rust
warnings we want (`unused_imports` type things) at this stage.
The advantage is this doesn't blow out the main Cargo cache,
and I can easily reproduce locally exactly what CI would gate on.
Also while we're here, add `make fix-rust` which is a handy
way to use the existing `clippy --fix` to locally fix things
like unused imports as well as other machine-applicable
things that are in e.g. `clippy::suspicious`.
Signed-off-by: Colin Walters <walters@verbum.org>
This provides stricter parsing (e.g. fails when the authorized_keys file
contains invalid content), and is groundwork for removing the command
field from keys.
Signed-off-by: ckyrouac <ckyrouac@redhat.com>
Way back in rpm-ostree's original code here, it always assumed
that it owned The Build.
But in a container-native flow we may have a chain of builds
across an organization and want to generate tmpfiles.d entries
multiple times.
When we do this, we can't just blow away the existing `/usr/lib/tmpfiles.d/bootc-generated.conf`.
Teach the tmpfiles code to have "generations" - we pick a new
file name like `bootc-generated-0.conf`, `bootc-generated-1.conf`
etc.
Also, change the generation code to return a struct with more
info about what it did, which will be used in the linting code.
Signed-off-by: Colin Walters <walters@verbum.org>
Prior to this, the prompt to select users other that root would result
in an error. Now, all ssh keys will be gathered into a single file
and passed to bootc install to-existing-root --root-ssh-authorized-keys.
Signed-off-by: ckyrouac <ckyrouac@redhat.com>
We have two patterns to initialize a lint:
- Bare struct init
- A helper function
This changes to just one path: A helper function, plus setters
for the optional fields.
Prep for adding a new lint option, which would otherwise
require changes to everything using the bare struct init.
Signed-off-by: Colin Walters <walters@verbum.org>
This used to work and I'm not exactly sure what changed. For some reason
`with_env_filter` needs to be at the end of the chain for the RUST_LOG
env var parsing to work.
Signed-off-by: ckyrouac <ckyrouac@redhat.com>
