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.
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>
I moved the code there; I plan to use open_dir_noxdev in
the tmpfiles code too which can't depend on lib/util.
Signed-off-by: Colin Walters <walters@verbum.org>
This code has been forked between bootupd and coreos-installer
and here. This is prep for having bootupd pull it from bootc's
git so we can deduplicate.
Signed-off-by: Colin Walters <walters@verbum.org>
The `install` and `switch` verbs supported passing an OSTree remote to
use to verify the embedded OSTree commit. This option in fact did not
function correctly and no verification was actually performace.
While it's possible someone was using this feature, it seems quite
unlikely since the UX is more geared towards native OCI signatures. As a
result, we have decided not to file a CVE for this.
And in fact, since we're planning to keep moving away from ostree,
instead of fixing this bug, just completely rip out support for passing
and OSTree remote.
Note this is distinct from the ostree-ext code, which still does support
signature verification of the embedded OSTree commit. E.g. Fedora
CoreOS is planning to make use of that until it can move to proper OCI
signatures.
While we're here, drop the negation around the container sigpolicy to
make it easier to follow the logic.
Signed-off-by: Jonathan Lebon <jonathan@jlebon.com>
If we encounter a mount point when attempting to
wipe a filesystem, then something has definitely gone
wrong. At the install phase we should only be operating
on a single physical filesystem.
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>
I consider `bootc install to-filesystem` support a key feature of bootc.
In theory today one can still set up a system directly with `ostree`
and we will continue to support that.
But things like logically bound images we do want to be initialized
from the start and that's with `bootc install to-filesystem`.
Maintaining the feature just has a logistical annoyance any
time one touches the install code as we often end up needing
to carefully `#[cfg(feature = "install")]` in many places
in an infectious way.
Also as we head towards enabling factory reset
https://github.com/containers/bootc/issues/404
we really do want some of the install code enabled there.
However, `to-disk` is much more of a "demo". I don't want
bootc to grow too much knowledge around block devices. Complex
setups (LVM, LUKS) etc. are the domain of external installers
and provisioning tools.
So the feature gate is now on that (which is still on by default).
We ended up with more `#[cfg(feature = "install-to-disk")]` than
I'd have liked, but some of that can be fixed subsequently.
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>
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>
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>
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>
Build on our new logic for bind mounting from the host mountns
to also drop the need for the `-v /:/target` in the alongside
install code.
Signed-off-by: Colin Walters <walters@verbum.org>
Now that we unconditionally mount /var/lib/containers, drop
the hacky fork-skopeo-in-host-mountns code.
Signed-off-by: Colin Walters <walters@verbum.org>
We're looking again at the ergonomics of `bootc install to-existing-root`.
This uses the "mounting into mount namespaces" from the new
mount API to automatically set up `/dev` and `/var/lib/containers`
if they weren't provided to `podman run`, which shrinks what's
needed a bit.
Closes: https://github.com/containers/bootc/issues/826
Signed-off-by: Colin Walters <walters@verbum.org>
The `warn_on_host_root` check was broken when we added support for
installing on already-ostree systems (but only for already-ostree
systems).
See https://github.com/containers/bootc/issues/907
The solution is to use the original user provided root_path for the fd
passed to warn_on_host_root, rather than the modified one, as that will
always match /proc/0/root's fsid (in ostree systems systemd is running
with the deployment root as its root, and this is what we have mounted
as /:/target)
Signed-off-by: Omer Tuchfeld <omer@tuchfeld.dev>
Partially solves #846
This adds a new `--bound-images` option to `bootc install` which will
allow the user to choose how they want to handle the retrieval of LBIs
into the target's container storage.
The existing behavior, which will stay the default, is `--bound-images
stored` which will resolve the LBIs and verify they exist in the
source's container storage before copying them into the target's
container storage.
The new behavior is `--bound-images pull` which will skip the resolution
step and directly pull the LBIs into the target's container storage.
The older `--skip-bound-images` option (previously hidden) is now
removed and replaced with the new (but still hidden) `--bound-images
skip` option.
Signed-off-by: Omer Tuchfeld <omer@tuchfeld.dev>
Signed-off-by: Colin Walters <walters@verbum.org>
As the comment says everything we do before
`prepare_install` is something we might do *twice* so let's
keep it as early as possible.
Looking at the history of this code (and its logical inputs)
I believe there's no reason for its placement in the middle
of this function other than just "stuff appeared
before it organically".
Yes, it means some argument validation will happen after the
re-exec but that's fine.
Signed-off-by: Colin Walters <walters@verbum.org>
In the install flow we juggle *three* file systems in general:
- The container/host root
- The physical root
- The deployment root
"rootfs" in theory could be any of those three. In the install code
it's the physical (target) root, so rename the variable
to clarify.
Signed-off-by: Colin Walters <walters@verbum.org>
In the install flow we have both `rootfs` and `rootfs_fd` which
hold the physical root. Using fd-relative accesses where we
can provides a lot of advantages, so switch most uses over
to the file descriptor.
Signed-off-by: Colin Walters <walters@verbum.org>
The extra cloning we were doing here looked odd to me. I think
this ends up being cleaner make the toplevel variable mutable
and replace it only in the circumstance we detect an ostree
deployment.
Signed-off-by: Colin Walters <walters@verbum.org>
Ironically our support for `--replace-mode=alongside` breaks
when we're targeting an already extant ostree host, because when
we first blow away the `/boot` directory, this means the ostree
stack loses its knowledge that we're in a booted deployment,
and will attempt to GC it...
8fa019bfa8
is a key part of the fix for that.
However, a notable improvement we can do here is to grow this
whole thing into a real "factory reset" mode, and this will
be a compelling answer to
https://github.com/coreos/fedora-coreos-tracker/issues/399
To implement this though we need to support configuring the
stateroot and not just hardcode `default`.
Signed-off-by: Omer Tuchfeld <omer@tuchfeld.dev>
Previously, the check to verify install to-filesystem is being run
within a container happened fairly late in prepare_install. This moves
the check up before some of the other container specific checks. Now,
the error should occur when trying a basic install to-filesystem
invocation, e.g. `bootc install to-filesystem /var/mnt`.
This also adds a test to verify the error occurs with minimal arguments
and adds host_is_container to the global state.
Signed-off-by: Chris Kyrouac <ckyrouac@redhat.com>
Part of https://github.com/containers/bootc/issues/879
Basically we want to be able to `bootc install` outside of
a container. For the same reasons actually that we already support
parsing kargs from an ostree commit (without materializing it
as a filesystem), just expose a small wrapper for that API
via `pub(crate)` and use it in between the "pull" and "deploy" phases.
We basically do the same thing on `bootc upgrade`.
- v2: Clean up the multiple copies of the kargs path into a `const`
Signed-off-by: Colin Walters <walters@verbum.org>
We have e2e tests for this today. On a related topic, unfortunately
the way bootc-image-builder sets up the container it runs bootc
in it doesn't mount selinuxfs, so we see SELinux as disabled
when it's not.
We should fix that, but it also avoids user confusion to
drop the warning here.
While we're here, change things so we more consistently
log the state computed.
Closes: https://github.com/containers/bootc/issues/419
Signed-off-by: Colin Walters <walters@verbum.org>
Solves #781
This commit replaces the `ostree admin os-init` CLI invocation with the
`sysroot.init_osname` API call. This is a more direct way to initialize
the stateroot.
Signed-off-by: Omer Tuchfeld <omer@tuchfeld.dev>
This commit makes it so that the `bootc install` stateroot will be
configurable (it defaults to `default`). For now this is a hidden CLI
option until we decide whether we want to commit to this API.
In the future we also want to make the stateroot of `bootc switch` be
configurable (https://github.com/containers/bootc/pull/617) so that
users can install an image to a new stateroot while they already have an
existing stateroot
Also removed the constant `STATEROOT_DEFAULT`, we're now simply taking
it from the `ostree_ext` crate
Signed-off-by: Omer Tuchfeld <omer@tuchfeld.dev>
In general the codebase is starting to get to the size
where some internal crates make sense. Let's start
with the inevitable catchall "utils" crate which
starts off just holding our helper traits for
subprocesses.
Signed-off-by: Colin Walters <walters@verbum.org>
Closes: https://github.com/containers/bootc/issues/721
- Initialize a containers-storage: instance at install time
(that defaults to empty)
- Open it at the same time we open the ostree repo/sysroot
- Change bound images to use this
We are *NOT* yet changing the base bootc image pull to use this.
That's an obvious next step (xref
https://github.com/containers/bootc/pull/215 ) but will come later.
Signed-off-by: Colin Walters <walters@verbum.org>
Unfortunately the interactions/workarounds here are going to grow, so make
a module to encapsulate them.
Signed-off-by: Colin Walters <walters@verbum.org>
