1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
|
CATALYST-SPEC(5)
================
:man source: catalyst {catalystversion}
:man manual: catalyst {catalystversion}
NAME
----
catalyst-spec - Catalyst build specification files
SYNOPSIS
--------
*catalyst* ['OPTIONS'] *-f* 'FILE'
DESCRIPTION
-----------
*catalyst(1)* reads the specification file given with *-f* on the
command line. The file contains keyword-argument pairs, one per line,
separated by a colon (`:`). Subsequent indented lines continue the
argument. Lines starting with `#` and empty lines are interpreted as
comments. For example:
---------------------------------
# Select the subarch
subarch: athlon-xp
boot/use:
-*
multicall
readline
ssl
---------------------------------
The possible keywords and their meanings are as follows:
Basic configuration
~~~~~~~~~~~~~~~~~~~
*subarch*::
The subarch can be any of the supported catalyst subarches (example:
`athlon-xp`). See the *SUPPORTED ARCHITECTURES* section for a list of
supported subarches.
*version_stamp*::
The version stamp is an identifier for the build. It can be anything,
but something date-like is recommended (example: `2006.1`).
*target*::
The target specifies what target we want catalyst to build (example:
`stage3`). Supported targets are:
include::targets.generated.txt[tabsize=4]
*rel_type*::
The `rel_type` defines what kind of build we are doing (example:
`default`). This is merely another identifier, but it useful for
allowing multiple concurrent builds. Usually, `default` will suffice.
*profile*::
This is the system profile to be used by catalyst to build this target
(example: `default/linux/x86/10.0/`). It is specified as a relative
path from `profiles` in your portdir snapshot
*snapshot_treeish*::
This specifies which snapshot to use for building this target
(example: `2006.1`).
*source_subpath*::
This specifies where the seed stage for this target comes from
(example: `default/stage3-x86-2006.1`). The path is relative to
`$storedir/builds`. The `rel_type` is also used as a path prefix for
the seed.
*portage_confdir*::
This is an optional directory containing portage configuration files
(example: `/etc/portage`). It follows the same syntax as
`/etc/portage` and should be consistent across all targets to minimize
problems.
*repos*::
This option specifies the location of the ebuild repositories that you would
like to have used when building this target. It takes a space-separated list
of directory names. (example: `/usr/local/portage`).
*keep_repos*::
This option specifies the names of ebuild repositories that you would like to
leave configured in the resulting build. It takes a space-separated list of
names. This only affects the configuration; the contents are never kept.
*pkgcache_path*::
This allows the optional directory containing the output packages for
catalyst (example: `/tmp/packages`). Mainly used as a way for
different spec files to access the same cache directory. Default
behavior for this location is to be autogenerated under `$storedir`
based on the spec file.
*kerncache_path*::
This allows the optional directory containing the output packages for
kernel builds (example: `/tmp/kernel`). Mainly used as a way for
different spec files to access the same cache directory. Default
behavior is for this location to be autogenerated under `$storedir`
based on the spec file.
*<target>/type*::
This option controls quite a bit of catalyst internals and sets up
several defaults. Each type behaves slightly differently and is
explained below.
`gentoo-release-minimal`;; This creates an official minimal InstallCD.
`gentoo-release-livecd`;; This creates an official LiveCD environment.
`generic-livecd`;; This should be used for all non-official media.
This setting is supported by the livecd targets.
*<target>/readme*::
This is for the README.txt on the root of the CD. For Gentoo
releases, we use a default README.txt, and this will be used on your
CD if you do not provide one yourself. We do not use this for the
official releases. This setting is supported by the livecd targets.
*update_seed*::
This is an optional setting supported by stage1 to tell catalyst if
it should update the seed stage or not (valid values: `yes no`).
*update_seed_command*::
This is an optional command to pass to emerge for updating the seed
stage (example: `--update dev-libs/mpfr dev-libs/mpc dev-libs/gmp`)
If not specified, catalyst will update gcc deps.
This setting requires enabling update_seed.
Compilation
~~~~~~~~~~~
These options are only available when building a stage1 or stage2
target and are all optional. These allow for emulating the changes
possible during a bootstrap. Some possible uses of these would be
building embedded stages requiring a different `CHOST` or building a
stage2 with NPTL support from a stage1 tarball that is built without
it. If left blank, then the catalyst defaults from `arch.py` are
used.
*chost*::
This option is used to change the CHOST from what is default in the
profile to whatever you specify (example: `i686-pc-linux-gnu`). This
is useful for building NPTL, for example.
*cflags*::
This option allows you to change the default `CFLAGS` that will be
used in building this stage (example: `-Os -pipe -fomit-frame-pointer
-mcpu=i686`). This really should remain generic, as putting
optimizations flags here will build a stage1 tarball that is no longer
generic.
*cxxflags*::
This is for setting the `CXXFLAGS` (example: `-Os -pipe
-fomit-frame-pointer -mcpu=i686`). Generally, this would be set to
the same as `CFLAGS`. In fact, it will mirror `CFLAGS` by default.
*ldflags*::
Setting this option sets `LDFLAGS` in `make.conf` in your stage
(example: `-Wl,-O1 -Wl,-z,now`). This would be useful for setting up
an embedded or hardened system.
Filesystem
~~~~~~~~~~
*livecd/fstype*::
The fstype is used to determine what sort of CD we should build. This
is used to set the type of loopback filesystem that we will use on our
CD. The only possible value is `squashfs`.
*livecd/fsops*::
The fsops are a list of optional parameters that can be passed to the
tool which will create the filesystem specified in *livecd/fstype*
*livecd/iso*::
This is the full path and filename to the ISO image that the
livecd-stage2 target will create (example:
`/tmp/installcd-x86-minimal.iso`).
*livecd/volid*::
This option sets the volume ID of the CD created (example: `Gentoo
Linux 2006.1 X86`).
Bootloader
~~~~~~~~~~
*livecd/cdtar*::
This is required for livecd-stage2 on all arches except amd64 and x86 which can autogenerate one
if USE=system-bootloader is set.
The cdtar is essentially the bootloader for the CD. It also holds the
main configuration for the bootloader.
Kernel and boot issues
~~~~~~~~~~~~~~~~~~~~~~
*boot/kernel*::
This option is used to specify the number of kernels to build and also
the labels that will be used by the CD bootloader to refer to each
kernel image (example: `gentoo`).
*boot/kernel/<label>/sources*::
This option tells catalyst which kernel sources to merge for this
kernel label (example: `gentoo-sources`). This can use normal portage
atoms to specify a specific version. `<label>` should match one of
the labels given to *boot/kernel*.
*boot/kernel/<label>/config*::
This option is the full path and filename to a kernel `.config` file
that is used by genkernel to compile the kernel this label applies to.
`<label>` should match one of the labels given to *boot/kernel*.
*boot/kernel/<label>/gk_kernargs*::
This option sets genkernel parameters on a per-kernel basis and
applies only to this kernel label. This can be used for building
options into only a single kernel, where compatibility may be an
issue. We do not use this on the official release media, but it
follows the same syntax as *stage4/gk_mainargs*. `<label>` should
match one of the labels given to *boot/kernel*.
*<target>/gk_mainargs*::
This is a set of arguments that will be passed to genkernel for all
kernels defined in this target (example: `--lvm --dmraid`). It is
useful for passing arguments to genkernel that are not otherwise
available via the stage4-stage2 spec file. This option is supported
by the `stage4` and `livecd` targets.
*boot/kernel/<label>/extraversion*::
This option appends an extension to the name of your kernel, as viewed
by a `uname -r`. This also affects any modules built under this
kernel label. This is useful for having two kernels using the same
sources to keep the modules from overwriting each other. We do not
use this on the official media. `<label>` should match one of the
labels given to *boot/kernel*.
*boot/kernel/<label>/console*::
This is only supported on with grub currently (x86, amd64, ia64, ppc,
sparc). This entry sets up the console boot parameters required for
sending the output to the appropriate console (example: `tty0 ttyS0`).
`<label>` should match one of the labels given to *boot/kernel*.
*<target>/modblacklist*::
This is for blacklisting modules from being hotplugged that are known
to cause problems (example: `8139cp`). Putting a module name here
will keep it from being auto-loaded, even if it is detected by
hotplug. This setting is supported by the `stage4` and `livecd`
targets.
*boot/kernel/<label>/use*::
This option sets the `USE` flags used to build the kernel and also any
packages which are defined under this kernel label (example: `pcmcia
usb -X`). These `USE` flags are additive from the default `USE` for
the specified profile. `<label>` should match one of the labels given
to *boot/kernel*.
*boot/kernel/<label>/packages*::
This option is for merging kernel-dependent packages and external
modules that are configured against this kernel label (example:
`pcmcia-cs speedtouch slmodem`). `<label>` should match one of the
labels given to *boot/kernel*.
*livecd/bootargs*::
This is a set of arguments that get passed to the bootloader for your
CD (example: `dokeymap`). It is used on the x86/amd64 release media
to enable keymap selection.
Netboot
~~~~~~~
*netboot/busybox_config*::
The netboot target builds busybox for its root filesystem. This
option is where you specify the full path and filename to your busybox
configuration (example: `/tmp/busybox.config`).
*netboot/builddate*::
Set the build date of the `<target>` (example: `20060107`).
Runlevels
~~~~~~~~~
*<target>/linuxrc*::
This option allows you to specify your own linuxrc script for
genkernel to use when building your CD. This is not checked for
functionality, so it is up to you to debug your own script. We do not
use one for the official release media. This option is supported by
the `stage4` and `livecd` targets.
*<target>/rcadd*::
This is for adding init scripts to runlevels. The syntax for the init
script is the script name, followed by a pipe, followed by the
runlevel in which you want the script to run. It looks like
`acpid|default` and is space delimited. We do not use this on the
official media, as catalyst sets up the runlevels correctly for us.
This setting is supported by the `stage4` and `livecd` targets.
*<target>/rcdel*::
This is for removing init script from runlevels. It is executed after
the defaults shipped with catalyst, so it is possible to remove the
defaults using this option. It can follow the same syntax as
*stage4/rcadd*, or you can leave the runlevel off to remove the script
from any runlevels detected. We do not use this on the official
media. This setting is supported by the `stage4` and `livecd` targets.
Packages
~~~~~~~~
*<target>/use*::
This is where you will build packages for updating a `stage3`. These
packages can be built with customized `USE` settings (example: `ipv6
socks5 fbcon ncurses readline ssl`). The settings here are additive
to the default `USE` configured by the profile. Leaving this blank
will default to the system use flags. It is very possible to cause
quite a few problems with these, so be careful with whatever `USE`
flags you add here. This is generally used for adding some
functionality that we do not want on by default for all Gentoo users,
but that we want on by default in our binaries. This setting is
supported by the `stage4` and `netboot` targets.
*<target>/packages*::
This is the set of packages that we will merge into the stage4 tarball
(example: `livecd-tools dhcpcd acpid apmd gentoo-sources coldplug
fxload irssi wpa_supplicant`). They will be built with the `USE`
flags configured above. These packages must not depend on a
configured kernel. If the package requires a configured kernel, then
it will be defined elsewhere. This setting is supported by the
`stage4`, and `netboot` targets.
*netboot/packages/<label>/files*::
This is where you tell catalyst which files from each package to copy
into the netboot image. `<label>` should match one of the labels
given to *netboot/packages*. For example:
netboot/packages/raidtools/files: /sbin/raidstart /sbin/mkraid
*netboot/extra_files*::
This is a list of any other files, not belonging to the above
packages, that you would wish to have copied into your netboot image
(example: `/lib/libresolv.so.2 /lib/libnss_compat.so.2`).
*livecd/depclean*::
This feature controls the depclean run after fsscript and before unmerge.
The default is unset, and will run emerge --depclean --with-bdeps=n which results
in the smallest possible livecd. For some use cases it may be nice to not run depclean at all,
or to keep build deps. For those cases, the following two special cases are available:
livecd/depclean: no
livecd/depclean: keepbdeps
This setting is only supported by the livecd target.
*<target>/unmerge*::
This is a list of packages that will be unmerged after all the kernels
have been built (example: `autoconf automake libtool m4 bison`).
There are no checks on these packages, so be careful what you add
here. They can potentially break your target. This setting is
supported by the `stage4` and `livecd` targets.
Miscellaneous
~~~~~~~~~~~~~
*<target>/fsscript*::
A fsscript is simply a shell script that is copied into the chroot of
the build after the kernel(s) and any external modules have been
compiled and is executed within the chroot. It can contain any
commands that are available via the packages installed by our stages
or by the packages installed during the stage4-stage1 build. We do
not use one for the official release media, so there will not be one
listed below. The syntax is simply the full path and filename to the
shell script that you wish to execute (example:
`/path/to/fsscript.sh`). The script is copied into the chroot by
catalyst automatically. This setting is supported by the `stage4` and
`livecd` targets.
*<target>/motd*::
This is for the message of the day. It is not required for release
media, as catalyst builds a default motd when the *<target>/type* is
set to one of the `gentoo-*` options. This setting overrides the
default motd even on official media. This setting is supported by the
`stage4` and `livecd` targets.
*<target>/root_overlay*::
This overlay is dropped onto the filesystem within the loop. This can
be used for such things as updating configuration files or adding
anything else you would want within your target filesystem. Files
added here are available when `docache` is used. We do not use this
on the official media. This setting is supported by the `stage4` and
`livecd` targets.
*livecd/overlay*::
This overlay is dropped onto the target filesystem and is outside any
loop which has been configured (example: `/tmp/overlay-minimal`).
This is typically used for adding the documentation, distfiles,
snapshots, and stages to the official media. These files will not be
available if `docache` is enabled, as they are outside the loop.
*<target>/users*::
This option is used to create non-root users on your target. It takes
a space separated list of user names. These users will be added to
the following groups: `users`, `wheel`, `audio`, `games`, `cdrom`, and
`usb`. If this is specified in your spec file, then the first user is
also the user used to start X. We do not use this on the release
media. This setting is supported by the `stage4` and `livecd` targets.
*<target>/empty*::
This option is used to empty the directories listed (example:
`/var/tmp /var/cache /var/db`). It is useful for getting rid of files
that don't belong to a particular package, or removing files from a
package that you wish to keep, but won't need the full functionality.
This setting is supported by the `stage4` and `livecd` targets.
*<target>/rm**::
This option tells catalyst to clean specific files from the filesystem
and is very useful in cleaning up stray files in `/etc` left over
after *stage4/unmerge* (example: `/lib/*.a /usr/lib/*.a`). This
setting is supported by the `stage4` and `livecd` targets.
FILES
-----
Example specfiles can be found in '/usr/share/doc/catalyst-{catalystversion}/examples'.
SUPPORTED ARCHITECTURES
-----------------------
The following table shows the list of supported architectures as well as
the list of valid strings for key 'subarch'.
include::subarches.generated.txt[tabsize=4]
BUGS
----
An up-to-date list of Catalyst bugs can always be found listed on the Gentoo
Linux bug-tracking system at 'https://bugs.gentoo.org'.
SEE ALSO
--------
*catalyst(1)*
*catalyst-config(5)*
|