Mostly install time updates in this release; this
fixes Anaconda support, and also makes `bootc install to-existing-root`
significantly more ergonomic.
Signed-off-by: Colin Walters <walters@verbum.org>
While this has obscure use cases right now, we will need
to support it for the forseeable future, so just lift
its `hide=true` state so it's clear that it exists.
Update the generated man pages.
Signed-off-by: Colin Walters <walters@verbum.org>
Motivated by https://github.com/containers/bootc/issues/957
but probably not any kind of fix in reality. Our error handling here
was buggy. What we really should do is avoid `fork()` and do
an execve here, but that's a larger refactor.
- Close the other side of the socket in the forked child so
the parent doesn't hang indefinitely if the child dies
before sending
- Change the parent to return a clean error if the child
doesn't write anything instead of an `assert!`
- Check the exit code of the child
Signed-off-by: Colin Walters <walters@verbum.org>
We think this is unnecessary now; part of improving
the ergonomics of `bootc install` in general, but
especially with the `to-existing-root` path.
Once this lands, at some point later then we
can also remove it from all of the documentation.
But the most safe thing is to leave it in the
docs for a bit longer.
Closes: https://github.com/containers/bootc/issues/928
Signed-off-by: Colin Walters <walters@verbum.org>
Modified the error / root checking code a bit to better guide the user
towards the correct bootc invocation.
Issue BIFROST-552 [1]
```
[omer@hal9000 ~]$ podman run -it quay.io/otuchfel/bootc:comfy bootc install to-existing-root
ERROR Installing to filesystem: Querying root privilege: The container must be executed with full privileges (e.g. --privileged flag)
[omer@hal9000 ~]$ podman run -it --privileged quay.io/otuchfel/bootc:comfy bootc install to-existing-root
ERROR Installing to filesystem: This command must be run with the podman --pid=host flag
[omer@hal9000 ~]$ podman run -it --pid=host --privileged quay.io/otuchfel/bootc:comfy bootc install to-existing-root
ERROR Installing to filesystem: /proc/1 is owned by 65534, not zero; this command must be run in the root user namespace (e.g. not rootless podman)
[omer@hal9000 ~]$ sudo podman run -it --privileged --pid=host quay.io/otuchfel/bootc:comfy bootc install to-existing-root
Installing image: docker://quay.io/otuchfel/bootc:comfy
...
```
[1] https://issues.redhat.com/browse/BIFROST-552
Signed-off-by: Omer Tuchfeld <omer@tuchfeld.dev>
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>
This helps ensure our CI is covering our copy of ostree-ext, not
the one currently vendored in rpm-ostree.
Signed-off-by: Colin Walters <walters@verbum.org>
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>
It looks like the default `column1` became `column0` which
broke this. But really we don't need a table, we just need a list;
and piping to `from csv` was a weird way to go about splitting
lines into a list.
Change the assertion to just expect a list which simplifies
the code.
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>
