containers / bootc

Boot and upgrade via container images

Home Page:https://containers.github.io/bootc/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Add `bootc apply-live`

cgwalters opened this issue · comments

This is probably mainly draining the logic from rpm-ostree into ostree-ext, then re-using it here.

But...a whole lot of suddenly OS-specific issues come to the fore. For example, should we try to distinguish between "new content" and "changes"?

This one also relates to #165

I know at least some people have also been asking for an "apply live by default" mode. Note that there's a super tricky detail of that in that if there's kernel changes in the new root, we must in general do something like keep /usr/lib/modules/$kver mounted/copied into the running root.

This one also relates to #165

I know at least some people have also been asking for an "apply live by default" mode. Note that there's a super tricky detail of that in that if there's kernel changes in the new root, we must in general do something like keep /usr/lib/modules/$kver mounted/copied into the running root.

Could we bind mount /usr/lib/modules somewhere else like /run/booted-kernel-modules during the initial boot, and then have the kernel also look for modules there? Then we don't have to mess with trying to union the new and old modules dirs?

Could we use the same logic as the DNF needs-restarting plugin? This gives hints whether processes, services or the whole system needs a restart to account for the changes. And this would keep us close to DNF.

It might also be nice to have a --dry-run option to know before applying a change whether it will require a process / service / system restart. It would also be interesting to have the ability to use the same logic to compare two images out of band, e.g. in a CI/CD pipeline.