-
Notifications
You must be signed in to change notification settings - Fork 86
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support executing install to-filesystem
from host directly
#433
Comments
The command is documented here: https://containers.github.io/bootc/bootc-install.html#executing-bootc-install Nevertheless, if this is an entry point to bootable containers, it seems sufficiently complex to be a hurdle for adoption. |
My hope was that most people started from automation to do this, including spinning up the instance and injecting this data - that's what https://github.com/vrothberg/bootc-playground/tree/main/alongside does. Nevertheless, we absolutely could support |
install to-filesystem
from host directly
I was thinking about this more, and a way we could streamline this might just be having our container re-spawn itself instead with more mounts. Basically I bet we can boil this down to:
That would kill off the need for EDIT: Yep after a quick verification this causes the
Just...a tricky thing here is that in order to have ctrl-c work we'll want to bind the spawned systemd unit (and/or its spawned container) to the lifetime of the invoking image. (That said of course none of the install process is transactional so ctrl-c generally leaves things broken in the |
.oO(except, we could probably rework things such that we only blow away |
I'm curious to understand the technical reasons for needing to run bootc from inside the container/podman environment to begin with. My (admittedly limited) understanding is that when running If this specific scenario could be untangled from podman, it would simplify things a lot for how we do disk image building in bootc-image-builder. It would also make things simpler for integrating BIB functionality into the Image Builder service as well. |
In the bigger picture, one goal I have here with bootc is to keep the installation logic centralized as much as possible - to make the container image the "source of truth", the "center of gravity". If I want to change how the bootloader gets installed, I should be able to change the container image, not an external tool. I'd like the container to be an active participant in its installation, not an inert blob (as we were treating ostree before, and rpm...well, is a mix). This also helps ensure that "day 1" and "day 2" are the same. A notable pivot point here is e.g. "what version of mkfs.xfs is used"? I'd like that to default to coming from the container image. There are of course use cases for very small systems which may not want to ship those, and those systems can be installed not from the image itself - we clearly need to handle that. I think it's a question of defaults/emphasis. Running inside podman today of course means that "day 1" and "day 2" are different...but still, there's a whole lot of code that gets shared.
It already is, that's what |
That's perfectly understandable and I wouldn't want that principle to be violated or bent. I suppose the biggest issue here would be version and feature drift between the
This is indeed a big issue, one I ran into myself when setting up a filesystem on a Fedora host and installing a CentOS Stream 9 container to it. An ext4 filesystem created on Fedora wont boot on a C9S kernel unless the
I think it makes sense for a tool like bootc to expect certain things from its environment, but tying it to a specific container runtime is what I find strange. I understand that being able to make assumptions about the environment based on a known state (a known runtime) simplifies things greatly, but being able to set up an environment the same way without tying it to specific tooling means we can be more flexible with integrating things into our services. Actually, while writing this (and reading back through PRs and issues), I think I might be working under outdated information (or purely incorrect assumptions). I considered not posting this comment at all, or at least the last parts, since I'm almost certain now that I'm asking for something that already exists, but I'll keep it for future reference. |
Yes, but I'd also say that even if you use
It's fair, and in the general case we're not strictly tied to podman per se (one can make alternative runtimes that use the same libraries, and I believe it'd work when executed from cri-o, although the use cases for that are probably obscure). However...we are increasingly tied somewhat to podman when logically bound images are scoped in, and there's a strong need for us to converge and align things there (ref #20 ) so while we could relatively easily decouple things a bit from the container environment executing the install, at a pratical level there's still that tie. But yes: I suspect it would not be really hard for us to support being installed from docker for example - we can already fetch images from
Part of this does already exist in |
As someone who used the workflow of "install to-filesystem" to get a system compatible with bootable containers. I used the following command (successfully):
This command is not discoverable. I would have expected the to use the
bootc
command directly, or have a much simpler podman command.The text was updated successfully, but these errors were encountered: