Skip to content

Commit 02d807a

Browse files
author
Andrew Jeddeloh
committed
doc: add distro integration doc
1 parent 0c1da80 commit 02d807a

File tree

1 file changed

+42
-0
lines changed

1 file changed

+42
-0
lines changed

doc/distro-integration.md

+42
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,42 @@
1+
# Distro Integration
2+
3+
Ignition is designed to be run from an initramfs, only on first boot. Parts of Ignition need to run before the rootfs is mounted and parts need to run after. Ignition requires systemd be running in the initramfs as well. This makes integration with distros somewhat complicated. As an example, the configuration for integrating Ignition with [Fedora CoreOS](fcos) can be found in the [ignition-dracut](ignition-dracut) repo.
4+
5+
## Boot ordering
6+
7+
This section assumes knowledge of the systemd initramfs configuration described by `bootup(7)`.
8+
9+
Ignition is split into four stages: `disks`, `mount`, `files` and `umount`. The disks stage handles configuration that needs to be applied before filesystems are mounted (e.g. partitioning). The mount stage handles mounting filesystems specified in the `storage.filesystems` section and the umount stage unmounts them. The files stage handles creating everything else.
10+
11+
Generally, a boot sequence when Ignition runs looks something like:
12+
13+
1) `basic.target` reached.
14+
1) Networking is started
15+
1) Ignition `disks` stage runs. This is where the config is fetched (and then cached). Since the root fs may change, this needs to occur before the root filesystem is mounted
16+
1) The root filesystem is mounted (this example will assume it is mounted at `/sysroot`)
17+
1) If the system requires special bind mounts for directories, those are mounted (e.g. ostree systems' /var)
18+
1) Ignition `mount` stage runs, creating any additional mountpoints. This needs to happen before the next step to ensure files created end up on the right filesystems.
19+
1) Any filesystem prepopulation occurs. This may be things like running systemd-sysusers and systemd-tmpfiles
20+
1) Ignition `files` stage runs
21+
1) Ignition `umount` stage runs
22+
1) Switch root
23+
24+
## Failure
25+
26+
If Ignition fails, the system should isolate to `emergency.target` and not proceed to switch root. Ignition should give the user the system they specified or system at all.
27+
28+
## The first boot is not special
29+
30+
Ignition has a `umount` stage to ensure that after Ignition runs the system continues booting as if it didn't. This is important to ensure the system will boot when Ignition does not run. Running Ignition should be a diversion in the initramfs, not a replacement.
31+
32+
## Base configs
33+
34+
Ignition supports supplying a "base config" that users' configs get merged into. This allows distros to do things like add default users or enable units. Distros should include a base config describing where any filesystems are mounted (e.g. if `/var` is a separate filesystem) to ensure that the `mount` stage mounts it and files are created where they should be.
35+
36+
## Link time overrides and features
37+
38+
Ignition has a handleful of link-time knobs. SELinux support can be enabled or disabled and the path of some helper utilities Ignition uses can be configured. See the [distro package][distro-package] for a complete list.
39+
40+
## Initramfs tools
41+
42+
See the [developer documentation][dev-doc] for a list of tools Ignition requires in the initramfs.

0 commit comments

Comments
 (0)