├── .github ├── dependabot.yml └── workflows │ ├── ci.yml │ └── pages.yml ├── .gitignore ├── CONTRIBUTING.md ├── Gemfile ├── Gemfile.lock ├── LICENSE ├── README.md ├── _config.yml ├── how-does-it-work.md ├── index.md ├── projects.md └── what-needs-work.md /.github/dependabot.yml: -------------------------------------------------------------------------------- 1 | version: 2 2 | updates: 3 | - package-ecosystem: bundler 4 | directory: / 5 | schedule: 6 | interval: daily 7 | allow: 8 | - dependency-type: direct 9 | -------------------------------------------------------------------------------- /.github/workflows/ci.yml: -------------------------------------------------------------------------------- 1 | name: CI 2 | 3 | on: 4 | push: 5 | branches: ["main"] 6 | pull_request: 7 | 8 | jobs: 9 | # Build job 10 | build: 11 | runs-on: ubuntu-latest 12 | steps: 13 | - name: Checkout 14 | uses: actions/checkout@v3 15 | - name: Setup Ruby 16 | uses: ruby/setup-ruby@v1 17 | with: 18 | ruby-version: '3.1' # Not needed with a .ruby-version file 19 | bundler-cache: true # runs 'bundle install' and caches installed gems automatically 20 | cache-version: 0 # Increment this number if you need to re-download cached gems 21 | - name: Build with Jekyll 22 | run: bundle exec jekyll build 23 | -------------------------------------------------------------------------------- /.github/workflows/pages.yml: -------------------------------------------------------------------------------- 1 | # This workflow uses actions that are not certified by GitHub. 2 | # They are provided by a third-party and are governed by 3 | # separate terms of service, privacy policy, and support 4 | # documentation. 5 | 6 | # Sample workflow for building and deploying a Jekyll site to GitHub Pages 7 | name: Deploy Jekyll site to Pages 8 | 9 | on: 10 | push: 11 | branches: ["main"] 12 | 13 | # Allows you to run this workflow manually from the Actions tab 14 | workflow_dispatch: 15 | 16 | # Sets permissions of the GITHUB_TOKEN to allow deployment to GitHub Pages 17 | permissions: 18 | contents: read 19 | pages: write 20 | id-token: write 21 | 22 | # Allow one concurrent deployment 23 | concurrency: 24 | group: "pages" 25 | cancel-in-progress: true 26 | 27 | jobs: 28 | # Build job 29 | build: 30 | runs-on: ubuntu-latest 31 | steps: 32 | - name: Checkout 33 | uses: actions/checkout@v3 34 | - name: Setup Ruby 35 | uses: ruby/setup-ruby@v1 36 | with: 37 | ruby-version: '3.1' # Not needed with a .ruby-version file 38 | bundler-cache: true # runs 'bundle install' and caches installed gems automatically 39 | cache-version: 0 # Increment this number if you need to re-download cached gems 40 | - name: Setup Pages 41 | id: pages 42 | uses: actions/configure-pages@v3 43 | - name: Build with Jekyll 44 | # Outputs to the './_site' directory by default 45 | run: bundle exec jekyll build --baseurl "${{ steps.pages.outputs.base_path }}" 46 | env: 47 | JEKYLL_ENV: production 48 | - name: Upload artifact 49 | # Automatically uploads an artifact from the './_site' directory by default 50 | uses: actions/upload-pages-artifact@v1 51 | 52 | # Deployment job 53 | deploy: 54 | environment: 55 | name: github-pages 56 | url: ${{ steps.deployment.outputs.page_url }} 57 | runs-on: ubuntu-latest 58 | needs: build 59 | steps: 60 | - name: Deploy to GitHub Pages 61 | id: deployment 62 | uses: actions/deploy-pages@v2 63 | -------------------------------------------------------------------------------- /.gitignore: -------------------------------------------------------------------------------- 1 | # Ignore the default location of the built site, and caches and metadata generated by Jekyll 2 | _site/ 3 | .sass-cache/ 4 | .jekyll-cache/ 5 | .jekyll-metadata 6 | 7 | # Ignore folders generated by Bundler 8 | .bundle/ 9 | vendor/ 10 | -------------------------------------------------------------------------------- /CONTRIBUTING.md: -------------------------------------------------------------------------------- 1 | # Developer Certificate of Origin 2 | 3 | Add a ```Signed-off-by``` line to commit messages to indicate that you 4 | certify that you wrote or otherwise hav ethe right to submit the code that 5 | you are contributing to the project. 6 | 7 | Here is the [full text of the DCO](https://developercertificate.org/) 8 | 9 | Contributors sign-off that they adhere to these requirements by adding a 10 | ```Signed-off-by``` line to commit messages. 11 | 12 | This is my commit message 13 | 14 | Signed-off-by: Random J Developer 15 | 16 | Git even has a -s command line option to append this automatically to your commit message: 17 | 18 | $ git commit -s -m 'This is my commit message' 19 | 20 | 21 | -------------------------------------------------------------------------------- /Gemfile: -------------------------------------------------------------------------------- 1 | source 'https://rubygems.org' 2 | 3 | gem "jekyll", "~> 4.3.3" # installed by `gem jekyll` 4 | # gem "webrick" # required when using Ruby >= 3 and Jekyll <= 4.2.2 5 | 6 | gem "just-the-docs", "0.8.2" # pinned to the current release 7 | # gem "just-the-docs" # always download the latest release 8 | -------------------------------------------------------------------------------- /Gemfile.lock: -------------------------------------------------------------------------------- 1 | GEM 2 | remote: https://rubygems.org/ 3 | specs: 4 | addressable (2.8.6) 5 | public_suffix (>= 2.0.2, < 6.0) 6 | colorator (1.1.0) 7 | concurrent-ruby (1.2.3) 8 | em-websocket (0.5.3) 9 | eventmachine (>= 0.12.9) 10 | http_parser.rb (~> 0) 11 | eventmachine (1.2.7) 12 | ffi (1.16.3) 13 | forwardable-extended (2.6.0) 14 | google-protobuf (4.26.1-arm64-darwin) 15 | rake (>= 13) 16 | google-protobuf (4.26.1-x86_64-linux) 17 | rake (>= 13) 18 | http_parser.rb (0.8.0) 19 | i18n (1.14.4) 20 | concurrent-ruby (~> 1.0) 21 | jekyll (4.3.3) 22 | addressable (~> 2.4) 23 | colorator (~> 1.0) 24 | em-websocket (~> 0.5) 25 | i18n (~> 1.0) 26 | jekyll-sass-converter (>= 2.0, < 4.0) 27 | jekyll-watch (~> 2.0) 28 | kramdown (~> 2.3, >= 2.3.1) 29 | kramdown-parser-gfm (~> 1.0) 30 | liquid (~> 4.0) 31 | mercenary (>= 0.3.6, < 0.5) 32 | pathutil (~> 0.9) 33 | rouge (>= 3.0, < 5.0) 34 | safe_yaml (~> 1.0) 35 | terminal-table (>= 1.8, < 4.0) 36 | webrick (~> 1.7) 37 | jekyll-include-cache (0.2.1) 38 | jekyll (>= 3.7, < 5.0) 39 | jekyll-sass-converter (3.0.0) 40 | sass-embedded (~> 1.54) 41 | jekyll-seo-tag (2.8.0) 42 | jekyll (>= 3.8, < 5.0) 43 | jekyll-watch (2.2.1) 44 | listen (~> 3.0) 45 | just-the-docs (0.8.2) 46 | jekyll (>= 3.8.5) 47 | jekyll-include-cache 48 | jekyll-seo-tag (>= 2.0) 49 | rake (>= 12.3.1) 50 | kramdown (2.4.0) 51 | rexml 52 | kramdown-parser-gfm (1.1.0) 53 | kramdown (~> 2.0) 54 | liquid (4.0.4) 55 | listen (3.9.0) 56 | rb-fsevent (~> 0.10, >= 0.10.3) 57 | rb-inotify (~> 0.9, >= 0.9.10) 58 | mercenary (0.4.0) 59 | pathutil (0.16.2) 60 | forwardable-extended (~> 2.6) 61 | public_suffix (5.0.4) 62 | rake (13.1.0) 63 | rb-fsevent (0.11.2) 64 | rb-inotify (0.10.1) 65 | ffi (~> 1.0) 66 | rexml (3.2.6) 67 | rouge (4.2.1) 68 | safe_yaml (1.0.5) 69 | sass-embedded (1.72.0-arm64-darwin) 70 | google-protobuf (>= 3.25, < 5.0) 71 | sass-embedded (1.72.0-x86_64-linux-gnu) 72 | google-protobuf (>= 3.25, < 5.0) 73 | terminal-table (3.0.2) 74 | unicode-display_width (>= 1.1.1, < 3) 75 | unicode-display_width (2.5.0) 76 | webrick (1.8.1) 77 | 78 | PLATFORMS 79 | arm64-darwin-23 80 | x86_64-linux 81 | 82 | DEPENDENCIES 83 | jekyll (~> 4.3.3) 84 | just-the-docs (= 0.8.2) 85 | 86 | BUNDLED WITH 87 | 2.3.26 88 | -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- 1 | Apache License 2 | Version 2.0, January 2004 3 | http://www.apache.org/licenses/ 4 | 5 | TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION 6 | 7 | 1. Definitions. 8 | 9 | "License" shall mean the terms and conditions for use, reproduction, 10 | and distribution as defined by Sections 1 through 9 of this document. 11 | 12 | "Licensor" shall mean the copyright owner or entity authorized by 13 | the copyright owner that is granting the License. 14 | 15 | "Legal Entity" shall mean the union of the acting entity and all 16 | other entities that control, are controlled by, or are under common 17 | control with that entity. For the purposes of this definition, 18 | "control" means (i) the power, direct or indirect, to cause the 19 | direction or management of such entity, whether by contract or 20 | otherwise, or (ii) ownership of fifty percent (50%) or more of the 21 | outstanding shares, or (iii) beneficial ownership of such entity. 22 | 23 | "You" (or "Your") shall mean an individual or Legal Entity 24 | exercising permissions granted by this License. 25 | 26 | "Source" form shall mean the preferred form for making modifications, 27 | including but not limited to software source code, documentation 28 | source, and configuration files. 29 | 30 | "Object" form shall mean any form resulting from mechanical 31 | transformation or translation of a Source form, including but 32 | not limited to compiled object code, generated documentation, 33 | and conversions to other media types. 34 | 35 | "Work" shall mean the work of authorship, whether in Source or 36 | Object form, made available under the License, as indicated by a 37 | copyright notice that is included in or attached to the work 38 | (an example is provided in the Appendix below). 39 | 40 | "Derivative Works" shall mean any work, whether in Source or Object 41 | form, that is based on (or derived from) the Work and for which the 42 | editorial revisions, annotations, elaborations, or other modifications 43 | represent, as a whole, an original work of authorship. For the purposes 44 | of this License, Derivative Works shall not include works that remain 45 | separable from, or merely link (or bind by name) to the interfaces of, 46 | the Work and Derivative Works thereof. 47 | 48 | "Contribution" shall mean any work of authorship, including 49 | the original version of the Work and any modifications or additions 50 | to that Work or Derivative Works thereof, that is intentionally 51 | submitted to Licensor for inclusion in the Work by the copyright owner 52 | or by an individual or Legal Entity authorized to submit on behalf of 53 | the copyright owner. For the purposes of this definition, "submitted" 54 | means any form of electronic, verbal, or written communication sent 55 | to the Licensor or its representatives, including but not limited to 56 | communication on electronic mailing lists, source code control systems, 57 | and issue tracking systems that are managed by, or on behalf of, the 58 | Licensor for the purpose of discussing and improving the Work, but 59 | excluding communication that is conspicuously marked or otherwise 60 | designated in writing by the copyright owner as "Not a Contribution." 61 | 62 | "Contributor" shall mean Licensor and any individual or Legal Entity 63 | on behalf of whom a Contribution has been received by Licensor and 64 | subsequently incorporated within the Work. 65 | 66 | 2. Grant of Copyright License. Subject to the terms and conditions of 67 | this License, each Contributor hereby grants to You a perpetual, 68 | worldwide, non-exclusive, no-charge, royalty-free, irrevocable 69 | copyright license to reproduce, prepare Derivative Works of, 70 | publicly display, publicly perform, sublicense, and distribute the 71 | Work and such Derivative Works in Source or Object form. 72 | 73 | 3. Grant of Patent License. Subject to the terms and conditions of 74 | this License, each Contributor hereby grants to You a perpetual, 75 | worldwide, non-exclusive, no-charge, royalty-free, irrevocable 76 | (except as stated in this section) patent license to make, have made, 77 | use, offer to sell, sell, import, and otherwise transfer the Work, 78 | where such license applies only to those patent claims licensable 79 | by such Contributor that are necessarily infringed by their 80 | Contribution(s) alone or by combination of their Contribution(s) 81 | with the Work to which such Contribution(s) was submitted. If You 82 | institute patent litigation against any entity (including a 83 | cross-claim or counterclaim in a lawsuit) alleging that the Work 84 | or a Contribution incorporated within the Work constitutes direct 85 | or contributory patent infringement, then any patent licenses 86 | granted to You under this License for that Work shall terminate 87 | as of the date such litigation is filed. 88 | 89 | 4. Redistribution. You may reproduce and distribute copies of the 90 | Work or Derivative Works thereof in any medium, with or without 91 | modifications, and in Source or Object form, provided that You 92 | meet the following conditions: 93 | 94 | (a) You must give any other recipients of the Work or 95 | Derivative Works a copy of this License; and 96 | 97 | (b) You must cause any modified files to carry prominent notices 98 | stating that You changed the files; and 99 | 100 | (c) You must retain, in the Source form of any Derivative Works 101 | that You distribute, all copyright, patent, trademark, and 102 | attribution notices from the Source form of the Work, 103 | excluding those notices that do not pertain to any part of 104 | the Derivative Works; and 105 | 106 | (d) If the Work includes a "NOTICE" text file as part of its 107 | distribution, then any Derivative Works that You distribute must 108 | include a readable copy of the attribution notices contained 109 | within such NOTICE file, excluding those notices that do not 110 | pertain to any part of the Derivative Works, in at least one 111 | of the following places: within a NOTICE text file distributed 112 | as part of the Derivative Works; within the Source form or 113 | documentation, if provided along with the Derivative Works; or, 114 | within a display generated by the Derivative Works, if and 115 | wherever such third-party notices normally appear. The contents 116 | of the NOTICE file are for informational purposes only and 117 | do not modify the License. You may add Your own attribution 118 | notices within Derivative Works that You distribute, alongside 119 | or as an addendum to the NOTICE text from the Work, provided 120 | that such additional attribution notices cannot be construed 121 | as modifying the License. 122 | 123 | You may add Your own copyright statement to Your modifications and 124 | may provide additional or different license terms and conditions 125 | for use, reproduction, or distribution of Your modifications, or 126 | for any such Derivative Works as a whole, provided Your use, 127 | reproduction, and distribution of the Work otherwise complies with 128 | the conditions stated in this License. 129 | 130 | 5. Submission of Contributions. Unless You explicitly state otherwise, 131 | any Contribution intentionally submitted for inclusion in the Work 132 | by You to the Licensor shall be under the terms and conditions of 133 | this License, without any additional terms or conditions. 134 | Notwithstanding the above, nothing herein shall supersede or modify 135 | the terms of any separate license agreement you may have executed 136 | with Licensor regarding such Contributions. 137 | 138 | 6. Trademarks. This License does not grant permission to use the trade 139 | names, trademarks, service marks, or product names of the Licensor, 140 | except as required for reasonable and customary use in describing the 141 | origin of the Work and reproducing the content of the NOTICE file. 142 | 143 | 7. Disclaimer of Warranty. Unless required by applicable law or 144 | agreed to in writing, Licensor provides the Work (and each 145 | Contributor provides its Contributions) on an "AS IS" BASIS, 146 | WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or 147 | implied, including, without limitation, any warranties or conditions 148 | of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A 149 | PARTICULAR PURPOSE. You are solely responsible for determining the 150 | appropriateness of using or redistributing the Work and assume any 151 | risks associated with Your exercise of permissions under this License. 152 | 153 | 8. Limitation of Liability. In no event and under no legal theory, 154 | whether in tort (including negligence), contract, or otherwise, 155 | unless required by applicable law (such as deliberate and grossly 156 | negligent acts) or agreed to in writing, shall any Contributor be 157 | liable to You for damages, including any direct, indirect, special, 158 | incidental, or consequential damages of any character arising as a 159 | result of this License or out of the use or inability to use the 160 | Work (including but not limited to damages for loss of goodwill, 161 | work stoppage, computer failure or malfunction, or any and all 162 | other commercial damages or losses), even if such Contributor 163 | has been advised of the possibility of such damages. 164 | 165 | 9. Accepting Warranty or Additional Liability. While redistributing 166 | the Work or Derivative Works thereof, You may choose to offer, 167 | and charge a fee for, acceptance of support, warranty, indemnity, 168 | or other liability obligations and/or rights consistent with this 169 | License. However, in accepting such obligations, You may act only 170 | on Your own behalf and on Your sole responsibility, not on behalf 171 | of any other Contributor, and only if You agree to indemnify, 172 | defend, and hold each Contributor harmless for any liability 173 | incurred by, or claims asserted against, such Contributor by reason 174 | of your accepting any such warranty or additional liability. 175 | 176 | END OF TERMS AND CONDITIONS 177 | 178 | APPENDIX: How to apply the Apache License to your work. 179 | 180 | To apply the Apache License to your work, attach the following 181 | boilerplate notice, with the fields enclosed by brackets "[]" 182 | replaced with your own identifying information. (Don't include 183 | the brackets!) The text should be enclosed in the appropriate 184 | comment syntax for the file format. We also recommend that a 185 | file or class name and description of purpose be included on the 186 | same "printed page" as the copyright notice for easier 187 | identification within third-party archives. 188 | 189 | Copyright [yyyy] [name of copyright owner] 190 | 191 | Licensed under the Apache License, Version 2.0 (the "License"); 192 | you may not use this file except in compliance with the License. 193 | You may obtain a copy of the License at 194 | 195 | http://www.apache.org/licenses/LICENSE-2.0 196 | 197 | Unless required by applicable law or agreed to in writing, software 198 | distributed under the License is distributed on an "AS IS" BASIS, 199 | WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. 200 | See the License for the specific language governing permissions and 201 | limitations under the License. 202 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # containers.github.io/bootable 2 | 3 | This is the code for the website. 4 | 5 | ## Building 6 | 7 | The implementation uses [Jekyll](https://jekyllrb.com/) with Markdown 8 | and is published via Github pages. 9 | -------------------------------------------------------------------------------- /_config.yml: -------------------------------------------------------------------------------- 1 | title: Bootable Container Images 2 | description: Bootable container images 3 | theme: just-the-docs 4 | 5 | url: https://containers.github.io/bootable 6 | search_enabled: false 7 | 8 | aux_links: 9 | Contribute to these pages: https://github.com/containers/bootable 10 | -------------------------------------------------------------------------------- /how-does-it-work.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: How does it work? 3 | layout: page 4 | --- 5 | 6 | ## How do bootable container images work? 7 | 8 | Any OCI container build pipeline can be used to (re)build the container images from that system definition in version control build pipelines, tested, and pushed to a typical OCI container registry. 9 | In order to be bootable, these container images include their own Linux kernel and a system manager, usually [systemd](https://systemd.io/). 10 | The resulting image is an OCI image in every way. 11 | In fact it can be started as a typical container in [podman](http://podman.io/) or [Docker](https://www.docker.com/), without booting it, but of course without running the included kernel. 12 | 13 | The [bootc tool](https://github.com/containers/bootc) applies a container image as an update on an already running Linux system. 14 | The contents are written to the existing filesystem, switching out the /usr and /boot directories of the Linux system. 15 | One then reboots into the new behavior of the system. 16 | The new kernel in the bootable container image must of course support the filesystem, and storage devices on the system. 17 | 18 | Using the boot loader it is possible to switch back to the previous operating system image, thus enabling rollback to the previous behavior of the system. 19 | Using this methodology, it’s expected to be able to start with a stock Linux system, and completely change the behavior of that system using the new bootable container image, and then iterate as with further images. 20 | 21 | By default, such systems automatically update themselves when a new version of their bootable container image is tagged in the container registry. 22 | 23 | Per system state and data are set up in /etc and /var per system, and are usually not affected by updates to the bootable container image. 24 | This includes things like passwords, SSH keys, home directories. 25 | These things can arrive on the system in the typical way, such as local configuration, cloud-init, or via management tools like Ansible. 26 | 27 | It is recommended to have the container image content be read only at runtime for both the operating system and application containers. 28 | It will be possible and supported to use a local overlay file system as well as a commit process to enable debugging. However, changes to the local overlay would not persist across reboots without further action. 29 | 30 | It is recommended that general purpose bootable containers ship with at least a minimal installation tool that can execute from the container itself and write to a block device, similar to a “self-extracting zip file”. 31 | However it must also be a first class operation to generate disk images (ISO, qcow2, etc) from bootable containers for general purpose operating systems. 32 | Disk images should include just content derived from the input image, plus “bootstrap secrets” or similar where necessary. 33 | It should be a rare operation to need to consider the initial disk image contents to understand the state of the system. 34 | 35 | Stock disk images should be provided by Linux distributions for exactly this use case. 36 | Users are encouraged to then update that system with their own bootable container image. 37 | 38 | 39 | -------------------------------------------------------------------------------- /index.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: Goals 3 | layout: home 4 | --- 5 | 6 | ## Image Based Linux with Bootable Container Images 7 | 8 | Over the last decade, [OCI containers](https://specs.opencontainers.org/image-spec/) have become a de facto way to deploy a complete functioning Linux user space as an application. 9 | A large set of practices and tooling have evolved around them. 10 | Bootable containers are a modern opinionated way of deploying, configuring and managing image based Linux systems. 11 | 12 | Our goals are: 13 | 14 | 1. Use standard container practices and tooling, such as the [OCI standard](https://specs.opencontainers.org/image-spec/), layering, container registries, [signing](https://docs.sigstore.dev/cosign/signing/signing_with_containers/), testing, and GitOps workflows to build Linux systems. 15 | 16 | 1. Container images describe the operating system behavior as a prebuilt predefined unit, rather than defined as a set of fine grained packages during deployment. 17 | There is a strong bias toward having the full system definition committed to version control, including a list of components, application files, and system configuration. 18 | This bias leads to a composable operating system that can be iterated upon quickly. 19 | 20 | 1. The system updates atomically. 21 | It is robust to power outages or software failures during updates. 22 | The system either uses the contents of the old system, or the new image; Never some combination of both. 23 | 24 | 1. The operating system should self-update when new images are available, as system source of truth should default to a remote registry. 25 | Updates can be delayed or scheduled. 26 | This default behavior can be adapted or controlled by a larger management system. 27 | 28 | 1. If an update does not function correctly it is possible to roll back to the container image previously functioning before the update, or to any previously bootable version in the registry. 29 | 30 | 1. State (including per-machine configuration) is preserved across updates. 31 | State is written to specific writable directories on the system, by default these are /etc and /var. 32 | 33 | 1. It should always be possible to factory reset back to the known built behavior of the system, by discarding all state (and per machine configuration) not present in the container image. 34 | 35 | 1. It should be supported to create a cryptographic trust chain that runs from the hardware, through the boot loader, through the operating system all the way to the applications ensures that only the expected code is run, and the contents of the operating system and applications have not been changed unexpectedly. 36 | If something has been changed, or changes at runtime unexpectedly, the system can alert or stop. 37 | The builder of the images can sign the images with keys that are under their own control, or of course build images and deploy systems without a trust chain. But, it also continues to be supported by system builders to create "unlocked" systems where the end user can make local unsigned changes. 38 | 39 | 1. Updates are the quintessential operation for deploying bootable containers. 40 | It is tempting to include any and all system deployment information in a bootable container artifacts, definitions or images. 41 | Only configuration and deployment choices that can be successfully deployed via a new container image update to an existing system, or via a factory reset, are those that belong in the bootable container definitions or images. 42 | A canonical example is disk partition layout: this attribute of a deployment cannot be changed via an updated container image, and thus is the responsibility of an installer or infrastructure providing the system, rather than bootable containers. 43 | -------------------------------------------------------------------------------- /projects.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: Projects involved 3 | layout: page 4 | --- 5 | 6 | ## What are the projects involved or related? 7 | 8 | The bootc tooling and project are the nexus of a lot of the functionality that enable containers to be used to deploy Linux systems: 9 | 10 | * [bootc documentation](https://bootc-dev.github.io/bootc/) 11 | * [bootc on Github](https://github.com/bootc-dev/bootc) 12 | 13 | Obviously all the usual container tooling should be used to build images, such as [Podman](http://podman.io/), [Docker](https://www.docker.com/), [Quay](https://quay.io/), [Docker Hub](https://hub.docker.com/), and so on. 14 | The Image Builder project can be used to convert bootable container images to disk images when necessary: 15 | 16 | * [bootc-image-builder on Github](https://github.com/osbuild/bootc-image-builder) 17 | 18 | Packages and software should use the various standards that together work toward making an immutable and hermetic. Each of these work toward the same principles that make software behave better bootable contianers and containers in general. 19 | 20 | * [UAPI: Linux Userspace API Group](https://uapi-group.org/) 21 | * [Config file specification](https://uapi-group.org/specifications/specs/configuration_files_specification/), contribute to [Particle OS](https://0pointer.net/blog/fitting-everything-together.html) 22 | * Use [systemd-sysusers](https://www.freedesktop.org/software/systemd/man/latest/systemd-sysusers.html) or [DynamicUser=yes](https://0pointer.net/blog/dynamic-users-with-systemd.html) 23 | * RPM packaging: Move from `%post` to systemd units 24 | 25 | The composefs, overlayfs, fs-verity and UKI provide the basic technology to pursue the trust chain work. 26 | 27 | * [composefs on Github](https://github.com/containers/composefs) 28 | * [overlayfs documentation](https://www.kernel.org/doc/Documentation/filesystems/overlayfs.txt) 29 | * [fs-verity documentation](https://www.kernel.org/doc/html/next/filesystems/fsverity.html) 30 | * [UKI specification](https://github.com/uapi-group/specifications/blob/main/specs/unified_kernel_image.md) 31 | 32 | Podman Desktop can be used to get started with bootable container images: 33 | 34 | * [Podman Desktop bootc extension](https://github.com/containers/podman-desktop-extension-bootc) 35 | 36 | The Universal Blue project is pursuing this today via a variety of images: 37 | 38 | * [Universal Blue](https://universal-blue.org/) 39 | * [Bazzite](https://bazzite.gg), [Aurora](https://getaurora.dev), [Bluefin](https://projectbluefin.io/), and [uCore](https://github.com/ublue-os/ucore) 40 | 41 | There are proposals in Fedora to implement bootable container images as an image mode for the operating system. 42 | 43 | * [Fedora bootc images](https://docs.fedoraproject.org/en-US/bootc) 44 | * [Fedora change proposal](https://fedoraproject.org/wiki/Changes/OstreeNativeContainerStable) 45 | * [Fedora change Sysusers](https://fedoraproject.org/wiki/Changes/SystemdSysusers) 46 | * [Fedora change zstd:chunked](https://fedoraproject.org/wiki/Changes/zstd:chunked) 47 | -------------------------------------------------------------------------------- /what-needs-work.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: What needs work? 3 | layout: page 4 | --- 5 | 6 | ## What needs work? 7 | 8 | Broadly there are several areas where we haven’t yet reached our [goals](mission.md), and where you can help: 9 | 10 | * At present, bootable container images must be built from a specific base image despite it being a goal to use standard base images. 11 | 12 | * At present, we can only update a bootc enabled system with a bootable container image. It is not yet possible to use “bootc update” on a stock Linux system. 13 | 14 | * When using “bootc install” to update a non-bootc Linux system, it is not possible to roll back to that previous behavior. 15 | 16 | * The cryptographic trust chain is possible based on composefs, overlayfs, fsverity and UKI use to mount both application containers and the operating system bootable container images. However a working complete trust chain from hardware through to the app containers is not yet implemented. 17 | 18 | * When rebooting these image based Linux systems, all transient changes made to the optional overlay are lost. 19 | This would be confusing to a developer or someone trying to adopt these images. 20 | The behavior is different from the behavior of containers, where you can make changes to a running container, stop and start that container without losing those local changes. 21 | 22 | * Currently the tooling and the base images are limited to using RPM components in the container images. (See: [https://github.com/coreos/bootupd/issues/468]) 23 | --------------------------------------------------------------------------------