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>
In the case where we already emitted an object into the tar stream,
we wouldn't previously set the file type and size into the tar
header structure that we passed into the hardlink emission function.
This would cause an error when accessing the (logically) uninitialized `size()`.
Fix the writer function to always set the file type and size unconditionally,
and also rework the consumer side to make the logic even clearer.
Signed-off-by: Colin Walters <walters@verbum.org>
Not totally sure how this got through CI, but the most recent
two PRs semantically conflicted. Update the new code
to use the new glib prelude import.
Signed-off-by: Colin Walters <walters@verbum.org>
This is effectively an internals command for us to aid
debugging.
At some point it may make sense to expose this
at the bootc level too.
Signed-off-by: Colin Walters <walters@verbum.org>
This is aiming to fix https://github.com/coreos/rpm-ostree/issues/5251
Basically we can't re-invoke the calling process if we aren't
actually bootc.
(There are solutions that make this work, but what we'll hopefully
do shortly is propagate the logic to older streams to have
bootc take over the handling anyways)
Signed-off-by: Colin Walters <walters@verbum.org>
We really want this for https://github.com/coreos/rpm-ostree/pull/5222
to be able to rebuild images from their container-synthesized rootfs.
Really, the only xattr we don't want to emit in to the tar stream
is security.selinux for now.
Eventually we should try to switch to putting that into the tar
stream too, but it needs more validation.
Signed-off-by: Colin Walters <walters@verbum.org>
Right now when using OSTree remote verification, there's no indication
that the OSTree commit was successfully verified.
Capture the return string from `OstreeRepo.signature_verify_commit_data`
and return it as part of the public `LayeredImageState` object.
We could return a more structured signature object here, but this is
sufficient for our purposes for now and saves clients from having to
regenerate similar looking text.
In the `ostree container` CLI, print this verification text.
Signed-off-by: Jonathan Lebon <jonathan@jlebon.com>
A lot of technical debt here. A long time ago I added this hacky bit
to inject var/tmp is the container stream even if it wasn't in the
ostree commit.
Today things shipped by `rpm-ostree compose image` like FCOS
don't have `var/tmp` in the commit.
But then more recently we started shipping `/var/tmp`
in base images directly.
Now I'm working on https://github.com/coreos/rpm-ostree/issues/5221
where we're rechunking from a rootfs that does have var/tmp
and that ends up in the ostree commit.
The path comparison here was wrong because the tar stream we
generate has the paths start with `./` and a literal comparison
doesn't match `./var/tmp` != `var/tmp`.
Add a canonicalization helper and use it for this.
Signed-off-by: Colin Walters <walters@verbum.org>
Followup to 40af5a67b1
now that some other PRs have merged this one would be less
conflict-fest.
This is a general best practice; specifically motivated by
handling test-specific imports.
Signed-off-by: Colin Walters <walters@verbum.org>
This adds a generic "progress" infrastructure for granular
incremental notifications of downloading in particular, but
we may extend this to other generic tasks in the future too.
Signed-off-by: Antheas Kapenekakis <git@antheas.dev>
Signed-off-by: Colin Walters <walters@verbum.org>
The test code in the fixture module is a bit confusing, as it
arbitrarily gives some files in /etc a label and others another.
Add a comment to clarify this is on purpose.
Signed-off-by: Omer Tuchfeld <omer@tuchfeld.dev>
In almost all children we fork, we want the child to reliably
exit if we do (e.g. especially if we panic). The Linux
PR_SET_PDEATHSIG is just great for this.
Signed-off-by: Colin Walters <walters@verbum.org>
I was looking at our vendoring set and while it's not actually
relevant I found myself wondering why we had *three* versions
of `windows-sys`. Having that many crate versions is often a signal
that there's an unmaintained dependency.
And indeed, `terminal_size` is no longer cool. The "in" crowd
has moved on to newer, hipper things. Life moves fast, we need
to keep up.
(OK but yes also this drops some manual column printing code
we had which is also a win)
Signed-off-by: Colin Walters <walters@verbum.org>
When bootc was created, it started to become a superset of ostree;
in particular things like `/usr/lib/bootc/kargs.d` and logically
bound images.
However...Anaconda today is still invoking `ostree container image deploy`.
Main fix
--------
When bootc takes over the `/usr/libexec/ostree/ext/ostree-container`
entrypoint, make the existing `ostree container image deploy` CLI actually
just call back into bootc to fix things up. No additional work required other
than getting an updated bootc in the Anaconda ISO.
Old Anaconda ISOs
-----------------
But, a further problem here is that Anaconda is only updated once
per OS major+minor - e.g. there won't be an update to it for the lifetime
of RHEL 9.5 or Fedora 41. We want the ability to ship new
features and bugfixes in those OSes (especially RHEL9.5).
So given that we have a newer bootc in the target container, we can
do this:
```
%post --erroronfail
bootc install ensure-completion
%end
```
And will fix things up. Of course there's fun $details here...the
way Anaconda implements `%post` is via a hand-augmented `chroot`
i.e. a degenerate container, and we need to escape that and
fix some things up (such as a missing cgroupfs mount).
Summmary
--------
- With a newer bootc in the ISO, everything just works
- For older ISOs, one can add the `%post` above as a workaround.
Implementation details: Cross-linking bootc and ostree-rs-ext
-------------------------------------------------------------
This whole thing is very confusing because now, the linkage
between bootc and ostree-rs-ext is bidirectional. In the case
of `bootc install to-filesystem`, we end up calling into ostree-rs-ext,
and we *must not* recurse back into bootc, because at least for
kernel arguments we might end up applying them *twice*. We do
this by passing a CLI argument.
The second problem is the crate-level dependency; right now they're
independent crates so we can't have ostree-rs-ext actually
call into bootc directly, as convenient as that would be. So we
end up forking ourselves as a subprocess. But that's not too bad
because we need to carry a subprocess-based entrypoint *anyways*
for the Anaconda `%post` case.
Implementation details: /etc/resolv.conf
----------------------------------------
There's some surprising stuff going on in how Anaconda handles
`/etc/resolv.conf` in the target root that I got burned by. In
Fedora it's trying to query if systemd-resolved is enabled in
the target or something?
I ended up writing some code to just try to paper over this
to ensure we have networking in the `%post` where we need
it to fetch LBIs.
Signed-off-by: Colin Walters <walters@verbum.org>
When I was working on some column printing code
with Unicode I got bit by using `str::len`...and
digging in I found that clippy actually just
merged a lint to go the *other* way; more in
the link in the code.
Turning on a lint showed one place that should
have been using `chars().count()` and one that
should have been validating ASCII. Fix those.
Signed-off-by: Colin Walters <walters@verbum.org>
A sticking point keeping ostree in the picture here for
containers was SELinux handling. When we started this
effort I'd feared rewriting.
But recently we changed things such that we label derived images
using the policy from the final root.
This is a relatively small change in code size and complexity,
that allows us to import images that don't have "ostree stuff"
in them at all, i.e. there's no `/ostree/repo/objects`.
The advantage here is that this significantly simplifies
constructing base images.
The main disadvantage today for people who build images
this way is that we end up re-labeling and re-checksumming all objects.
But, the real fix for that in the future will be for us to
rework things such that we support `security.selinux` for example
as native xattrs in the tar stream.
Signed-off-by: Colin Walters <walters@verbum.org>
