Skip to content
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

Add install verb #1

Closed
cgwalters opened this issue Nov 30, 2022 · 1 comment · Fixed by #30
Closed

Add install verb #1

cgwalters opened this issue Nov 30, 2022 · 1 comment · Fixed by #30

Comments

@cgwalters
Copy link
Collaborator

cgwalters commented Nov 30, 2022

We should support something as straightforward as

$ bootc install quay.io/examplecorp/mycustomos:latest /dev/nvme0n1

This would:

  • Partition the disk in an opinionated way
  • Install the bootloader
  • Install the content from the container image

Partitioning

Obviously...there's a lot of tooling here. We should consider supporting at least Ignition as well as systemd-repart for nontrivial disk image setups.

Bootloader

For now, let's require that the target OS is setup using bootupd.

container image install

All the rest of the stuff (i.e. 99%) comes from the container image itself; we just need to call out to e.g. https://github.com/coreos/coreos-assembler/blob/d039e883059c48f2310572955682b9d25f4b6d61/src/create_disk.sh#L350

(Of course the steps above are also done in the example cosa code - we could hardcode some defaults, or probably better make it configurable in the image)

One idea here is to do a multi-stage fetch; we pull the container via e.g. podman (or actually instead, assume the UX is podman run --privileged quay.io/examplecorp/mycustomos:latest bootc install /dev/vda ? Then we can use something more like the deploy-from-self logic)

install --replace-booted-block-device

We could also support bootc install --replace-booted-block-device quay.io/examplecorp/mycustomos:latest which would implement this flow - basically, we:

  • Move the running code into RAM (systemd switch root? Or just replace pid1 entirely)
  • wipefs the booted block device
  • Run the same install logic over that block device

install --switch-root

It'd make sense to support systemctl switch-root to the new target rootfs, but without using the new kernel. (But, we should be really clear when we're in a kernel != root situation)

@cgwalters
Copy link
Collaborator Author

I want to xref here https://bugzilla.redhat.com/show_bug.cgi?id=2125655

cgwalters added a commit to cgwalters/bootc that referenced this issue Jun 16, 2024
This is definitely the containers#1 confusion many people have to start.

Signed-off-by: Colin Walters <walters@verbum.org>
cgwalters added a commit to cgwalters/bootc that referenced this issue Jun 16, 2024
This is definitely the containers#1 confusion many people have to start;
it's very understandable!  Because in theory we *could* have
a runtime and a larger role, but it was an explicit choice
not to do that.

Signed-off-by: Colin Walters <walters@verbum.org>
cgwalters added a commit to cgwalters/bootc that referenced this issue Jun 16, 2024
This is definitely the containers#1 confusion many people have to start;
it's very understandable!  Because in theory we *could* have
a runtime and a larger role, but it was an explicit choice
not to do that.

Signed-off-by: Colin Walters <walters@verbum.org>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant