Skip to content

Commit 6f44609

Browse files
committed
doc: introduce advanced bootc
Using the newly introduced advanced section move the `Containerfile` for installer setup into it. Also write down a new section of sources of configuration for `image-builder` when converting bootable containers. Signed-off-by: Simon de Vlieger <cmdr@supakeen.com>
1 parent 4f9e529 commit 6f44609

4 files changed

Lines changed: 348 additions & 37 deletions

File tree

doc/01-usage.md

Lines changed: 1 addition & 37 deletions
Original file line numberDiff line numberDiff line change
@@ -178,50 +178,14 @@ $ sudo image-builder build --bootc-ref localhost/anaconda:latest --bootc-build-r
178178

179179
#### `bootc-installer-payload-ref`
180180

181-
When `image-builder` builds an installer ISO there are two inputs. One is the installer (usually Anaconda) environment (passed as `--bootc-ref`) and the other is the bootable container that will be installed by the installer (passed as `--bootc-installer-payload-ref`). Both arguments are mandatory when building a `bootc-installer`.
181+
When `image-builder` builds an installer ISO there are two inputs. One is the installer (usually Anaconda) environment (passed as `--bootc-ref`) and the other is the bootable container that will be installed by the installer (passed as `--bootc-installer-payload-ref`). Both arguments are mandatory when building a `bootc-installer`. To do this you'll need to provide your own installer image. For information about building your own installers read the [advanced bootc section on installers](./20-advanced/20-bootc/10-installers.md).
182182

183183
```console
184184
$ sudo podman pull quay.io/centos-bootc/centos:stream10
185185
$ sudo image-builder build --bootc-ref localhost/anaconda:latest --bootc-installer-payload-ref quay.io/centos-bootc/centos:stream10 bootc-installer
186186
# ...
187187
```
188188

189-
Since there are no pre-provided installer container images at this moment, you can use a Containerfile similar to:
190-
191-
```Dockerfile
192-
FROM your-favorite-bootc-container:latest
193-
RUN dnf install -y \
194-
anaconda \
195-
anaconda-install-env-deps \
196-
anaconda-dracut \
197-
dracut-config-generic \
198-
dracut-network \
199-
net-tools \
200-
squashfs-tools \
201-
grub2-efi-x64-cdboot \
202-
python3-mako \
203-
lorax-templates-* \
204-
biosdevname \
205-
prefixdevname \
206-
&& dnf clean all
207-
208-
# On Fedora 42 this is necessary to get files in the right places
209-
# RUN dnf reinstall -y shim-x64
210-
211-
# On Fedora 43 and up this is necessary to get files in the right
212-
# places
213-
RUN mkdir -p /boot/efi && cp -ra /usr/lib/efi/*/*/EFI /boot/efi
214-
215-
# lorax wants to create a symlink in /mnt which points to /var/mnt
216-
# on bootc but /var/mnt does not exist on some images.
217-
#
218-
# If https://gitlab.com/fedora/bootc/base-images/-/merge_requests/294
219-
# gets merged this will be no longer needed
220-
RUN mkdir /var/mnt
221-
```
222-
223-
To produce your own Anaconda-based installer.
224-
225189
#### `bootc-default-fs`
226190

227191
During the build of an image from a bootable container `image-builder` has to determine a partition table to use. For bootable containers we want the source of truth to be the container itself. The container usually contains (some) configuration to let image build tools such as `image-builder` know what to do.
Lines changed: 298 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,298 @@
1+
# Sources of Configuration
2+
3+
In `bootc`-land it is preferred for the source of truth to be the container itself. For `image-builder` that means that certain instructions can be stored inside the container and will be used by `image-builder` when present. We get various bits and bobs from different places . This page describes what we get from where.
4+
5+
## `bootc print-config`
6+
7+
## Filesystem
8+
9+
`image-builder` will use several files with different purposes from the container filesystem if they exist. These files are expected to exist in the `/usr/lib/image-builder/bootc` directory.
10+
11+
For historical reasons `image-builder` will also see if these files exist in the `/usr/lib/bootc-image-builder` directory. The `/usr/lib/image-builder/bootc` directory has preference and any containers using the `/usr/lib/bootc-image-builder` path should be changed to use `/usr/lib/image-builder/bootc` instead.
12+
13+
### `disk.yaml`
14+
15+
A YAML file containing the partition layout to use when turning the container image into a disk image. The canonical location for this file is `/usr/lib/image-builder/bootc/disk.yaml`.
16+
17+
If present this will replace the base partition tables that `image-builder` uses during build. Blueprint customizations can be applied on top by end-users that want to modify their deployments.
18+
19+
A quick example that sets up a very default partition layout (BIOS boot, ESP, XBOOTLDR, and root partition) before explanation and more complex examples.
20+
21+
> [!WARNING]
22+
> *The BIOS boot partition is currently required by `bootupd`, hence we've included it here in every example. This might change in the future and be dependent on the container itself; see [this issue](https://github.com/coreos/bootupd/issues/1067).*
23+
24+
```yaml
25+
mount_configuration: "units"
26+
partition_table:
27+
type: "gpt"
28+
partitions:
29+
- size: "1 MiB"
30+
type: "21686148-6449-6e6F-744e-656564454649"
31+
bootable: true
32+
- size: "200 MiB"
33+
type: "c12a7328-f81f-11d2-ba4b-00a0c93ec93b"
34+
payload_type: "filesystem"
35+
payload:
36+
type: "vfat"
37+
mountpoint: "/boot/efi"
38+
label: "ESP"
39+
fstab_options: "defaults,uid=0,gid=0,umask=077,shortname=winnt"
40+
fstab_freq: 0
41+
fstab_passno: 2
42+
- size: "2 GiB"
43+
type: "bc13c2ff-59e6-4262-a352-b275fd6f7172"
44+
payload_type: "filesystem"
45+
payload:
46+
type: "ext4"
47+
label: "boot"
48+
mountpoint: "/boot"
49+
fstab_options: "defaults"
50+
fstab_freq: 0
51+
fstab_passno: 0
52+
- size: "4 GiB"
53+
type: "44479540-f297-41b2-9af7-d131d5f0458a"
54+
payload_type: "filesystem"
55+
payload:
56+
type: "ext4"
57+
label: "root"
58+
mountpoint: "/"
59+
fstab_options: "defaults"
60+
fstab_freq: 0
61+
fstab_passno: 0
62+
```
63+
64+
*The type UUIDs used in this example come from the [Discoverable Partitions Specification](https://uapi-group.org/specifications/specs/discoverable_partitions_specification/).*
65+
66+
`mount_configuration` is an enum and can hold the values `fstab`, `units`, or `none`. It dictates how the mountpoints are configured in the disk image. `fstab` will write an `/etc/fstab`, `units` will write systemd mount unit files, and `none` will do neither; leaving it up to tooling such as `systemd-gpt-auto-generator` to figure out what to mount where.
67+
68+
`partition_table` is an object with the following properties:
69+
70+
- `type`, an `enum` that can be `gpt` or `dos` and sets the partition table format to use.
71+
- `partitions`, a list of objects each of which represents a partition.
72+
73+
#### Partitions
74+
75+
Each partition can have the following properties:
76+
77+
- `size`, a string with units to set the size of the partition.
78+
- `type`, the partition type GPT UUID *or* DOS ID.
79+
80+
- `bootable`, an *optional* boolean indicating that this partition is legacy BIOS bootable (GPT) or active (DOS).
81+
- `uuid`, an *optional* string containing the partition UUID itself. Should be omitted and will be based on a PRNG, fixing this value can lead to issues trying to mount the same disk multiple times.
82+
- `label`, an *optional* `string` containing the partition name (**not** the filesystem label) for GPT.
83+
- `attrs`, an *optional* array of unsigned integers that set partition attribute flags for GPT.
84+
85+
- `payload_type`, an `enum` that contains one `filesystem`, `luks`, `lvm`, `btrfs`, `raw`. This field dictates what goes into the `payload` object that comes next.
86+
- `payload`, an object based on the value of `payload_type`. `payload_type`s and their `payload` contents are explained below.
87+
88+
##### Payloads
89+
90+
###### Filesystem
91+
92+
For a `payload_type: filesystem` the `payload` has the following properties:
93+
94+
- `type`
95+
- `mountpoint`, a `string` that tells where this partition should be mounted.
96+
97+
98+
- `label`, an *optional* `string` that contains the filesystem label.
99+
- `fstab_options`
100+
- `fstab_freq`
101+
- `fstab_passno`
102+
103+
Here's an example defining a few partition with XFS filesystem(s):
104+
105+
```
106+
mount_configuration: "units"
107+
partition_table:
108+
type: "gpt"
109+
partitions:
110+
- size: "1 MiB"
111+
type: "21686148-6449-6e6F-744e-656564454649"
112+
bootable: true
113+
- size: "200 MiB"
114+
type: "c12a7328-f81f-11d2-ba4b-00a0c93ec93b"
115+
payload_type: "filesystem"
116+
payload:
117+
type: "vfat"
118+
mountpoint: "/boot/efi"
119+
label: "ESP"
120+
fstab_options: "defaults,uid=0,gid=0,umask=077,shortname=winnt"
121+
fstab_freq: 0
122+
fstab_passno: 2
123+
- size: "2 GiB"
124+
type: "bc13c2ff-59e6-4262-a352-b275fd6f7172"
125+
payload_type: "filesystem"
126+
payload:
127+
type: "xfs"
128+
label: "boot"
129+
mountpoint: "/boot"
130+
- payload_type: "filesystem"
131+
payload:
132+
type: "xfs"
133+
label: "root"
134+
mountpoint: "/"
135+
```
136+
137+
###### LVM
138+
139+
> [!WARNING]
140+
> LVM configurations currently do not work with bootable containers in `image-builder`.
141+
142+
For a `payload_type: lvm` the `payload` has the following properties:
143+
144+
- `name`
145+
- `description`
146+
- `logical_volumes` a list of objects.
147+
148+
The `logical_volumes` objects have the following properties:
149+
150+
- `size`, a string with units to set the size of the partition.
151+
- `name`, a `string` with the name of the volume group.
152+
153+
- `payload_type`
154+
- `payload`
155+
156+
An example of using the `lvm` payload:
157+
158+
```
159+
mount_configuration: "fstab"
160+
partition_table:
161+
type: "gpt"
162+
partitions:
163+
- size: "1 MiB"
164+
bootable: true
165+
type: "21686148-6449-6e6F-744e-656564454649"
166+
- size: "200 MiB"
167+
type: "c12a7328-f81f-11d2-ba4b-00a0c93ec93b"
168+
payload_type: "filesystem"
169+
payload:
170+
type: "vfat"
171+
mountpoint: "/boot/efi"
172+
label: "ESP"
173+
fstab_options: "defaults,uid=0,gid=0,umask=077,shortname=winnt"
174+
fstab_freq: 0
175+
fstab_passno: 2
176+
- size: "2 GiB"
177+
type: "bc13c2ff-59e6-4262-a352-b275fd6f7172"
178+
payload_type: "filesystem"
179+
payload:
180+
type: "ext4"
181+
label: "boot"
182+
mountpoint: "/boot"
183+
fstab_options: "defaults"
184+
- size: "8 GiB"
185+
type: "44479540-f297-41b2-9af7-d131d5f0458a"
186+
payload_type: "lvm"
187+
payload:
188+
name: "systemVG"
189+
logical_volumes:
190+
- size: "4 GiB"
191+
name: "LVroot"
192+
payload_type: "filesystem"
193+
payload:
194+
type: "xfs"
195+
label: "root"
196+
mountpoint: "/"
197+
fstab_options: "defaults"
198+
```
199+
200+
*Note the nested payload to put a filesystem inside the `LVRoot` logical volume.*
201+
202+
###### btrfs
203+
204+
For a `payload_type: btrfs` the `payload` has the following properties:
205+
206+
- `subvolumes`, a list of objects.
207+
208+
The `subvolumes` objects have the following properties:
209+
210+
- `name`
211+
- `mountpoint`
212+
213+
An example of using the `btrfs` payload:
214+
215+
```yaml
216+
mount_configuration: "units"
217+
partition_table:
218+
type: "gpt"
219+
partitions:
220+
- size: "1 MiB"
221+
bootable: true
222+
type: "21686148-6449-6e6F-744e-656564454649"
223+
- size: "200 MiB"
224+
type: "c12a7328-f81f-11d2-ba4b-00a0c93ec93b"
225+
payload_type: "filesystem"
226+
payload:
227+
type: "vfat"
228+
mountpoint: "/boot/efi"
229+
label: "ESP"
230+
fstab_options: "defaults,uid=0,gid=0,umask=077,shortname=winnt"
231+
fstab_freq: 0
232+
fstab_passno: 2
233+
- size: "2 GiB"
234+
type: "bc13c2ff-59e6-4262-a352-b275fd6f7172"
235+
payload_type: "filesystem"
236+
payload:
237+
type: "ext4"
238+
label: "boot"
239+
mountpoint: "/boot"
240+
fstab_options: "defaults"
241+
fstab_freq: 0
242+
fstab_passno: 0
243+
- size: "4 GiB"
244+
type: "44479540-f297-41b2-9af7-d131d5f0458a"
245+
payload_type: "btrfs"
246+
payload:
247+
subvolumes:
248+
- name: "root"
249+
mountpoint: "/"
250+
- name: "home"
251+
mountpoint: "/home"
252+
- name: "var"
253+
mountpoint: "/var"
254+
```
255+
256+
*To use `btrfs` your container must set its configured root filesystem to `btrfs`, or it must be passed when `image-builder` is called.*
257+
258+
*To use `btrfs` your build host and container kernel must support `btrfs`.*
259+
260+
###### LUKS
261+
262+
Allows for setting up disk encryption with luks. Contains other payloads (filesystems).
263+
264+
For a `payload_type: luks` the `payload` has the following properties:
265+
266+
- `label`
267+
- `cipher`
268+
- `passphrase`
269+
- `pbkdf`
270+
- `clevis`
271+
272+
- `payload_type`
273+
- `payload`
274+
275+
An example of how you can use the `luks` payload.
276+
277+
```yaml
278+
279+
```
280+
281+
###### raw
282+
283+
For a `payload_type: raw` the `payload` has the following properties:
284+
285+
-
286+
287+
### `iso.yaml`
288+
289+
A YAML file containing instructions for constructing an ISO. This YAML file is only used for the `generic-iso` image type which makes as few assumptions as possible and thus needs extra instructions to tell it what to do. Read [more about the `generic-iso`](./10-installers.md) to see what you can do with this file.
290+
291+
```yaml
292+
label: "Fedora-bootc-Installer"
293+
grub2:
294+
entries:
295+
- name: "Install Fedora (bootc)"
296+
linux: "/images/pxeboot/vmlinuz inst.stage2=hd:LABEL=Fedora-bootc-Installer console=tty0 inst.text selinux=0"
297+
initrd: "/images/pxeboot/initrd.img"
298+
```
Lines changed: 45 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,45 @@
1+
# Advanced `bootc` Topics
2+
3+
## Installer
4+
5+
Since there are no pre-provided installer container images at this moment, you can use a Containerfile similar to:
6+
7+
```Dockerfile
8+
FROM your-favorite-bootc-container:latest
9+
RUN dnf install -y \
10+
anaconda \
11+
anaconda-install-env-deps \
12+
anaconda-dracut \
13+
dracut-config-generic \
14+
dracut-network \
15+
net-tools \
16+
squashfs-tools \
17+
grub2-efi-x64-cdboot \
18+
python3-mako \
19+
lorax-templates-* \
20+
biosdevname \
21+
prefixdevname \
22+
&& dnf clean all
23+
24+
# On Fedora 42 this is necessary to get files in the right places
25+
# RUN dnf reinstall -y shim-x64
26+
27+
# On Fedora 43 and up this is necessary to get files in the right
28+
# places
29+
RUN mkdir -p /boot/efi && cp -ra /usr/lib/efi/*/*/EFI /boot/efi
30+
31+
# lorax wants to create a symlink in /mnt which points to /var/mnt
32+
# on bootc but /var/mnt does not exist on some images.
33+
#
34+
# If https://gitlab.com/fedora/bootc/base-images/-/merge_requests/294
35+
# gets merged this will be no longer needed
36+
RUN mkdir /var/mnt
37+
```
38+
39+
To produce your own Anaconda-based installer that can be used in combination with the `bootc-installer-payload-ref` argument like so:
40+
41+
```
42+
$ sudo podman build -t localhost/anaconda -f Containerfile
43+
$ sudo image-builder build --bootc-ref localhost/anaconda:latest --bootc-installer-payload-ref quay.io/centos-bootc/centos-bootc:stream10 bootc-installer
44+
# ...
45+
```

0 commit comments

Comments
 (0)