Kickstarter

Mer Kickstarter

External configurations

The "ExternalConfigs" keyword will tell kickstarter to look for additional YAML files to parse. Lists will be merged in order of inclusion, ie, if there is a key/value pair, the latest YAML file to be included (or the one having ExternalConfigs and that key), will specify the final value corresponding to the key. When lists are merged, later yaml file contents always will be first in the list, earlier ones appended.

"ExternalConfigs" should be accompanied with a list of directories.

Example:

  ExternalConfigs:
   - /usr/share/kickstarts/mer-core
   - /usr/share/kickstarts/n900-hard

Declarations

There are two types of objects in a kickstarter file, one is declarations and one is configurations.

Declarations are sets of descriptions which has a name. These cannot inherit from each other.

Configurations are what is actually getting made into kickstart files, has to have a name and a filename.

Example:

   Foo:
      Kernel: kernel-foobar

   Configurations:
        - Name: Mer Core for foobar
          FileName: mer-core-foobar
          Inherits:
            -  Foo
          Groups: 
            - Mer Core

Configurations

The "Configurations" keyword is a list, specifies which kickstart files should be generated, see example above

Inheritance

Example:

   Inherits:
      - foo
      - bar

This keyword can be used within configurations, to list what declarations to inherit from. This basically merges the declarations together, latter ones being prioritized over earlier, when merging lists, latter entries is earlier in the list than entries from earlier declarations.

Language

This keyword specifies the default locale used in the resulting image.

Example:

 Language: en_US.UTF-8

Keyboard

This keyword specifies the default keyboard layout used in the resulting image.

Example:

 Keyboard: us

Timezone

This keyword specifies the default timezone used in the resulting image.

Example:

 Timezone: UTC

or

 Timezone: Europe/Copenhagen

Partition setup - Part vs PartSize + FileSystem

There's two ways of laying out partitions with kickstarter. One is Part, which uses a partition layout file, and PartSize and Filesystem, which uses just one root partition, on which you indicate size and filesystem type.

Part

Partition layout is in order, first partition is first partition.

Layout:

  part [MOUNTPOINT] --size=SIZE_IN_MB --ondisk LIKELYDISKNAME --fstype=FSTYPE [--active]

mountpoint is where it gets mounted, likelydiskname is the probable name of the disk when it runs in the device. Fstype is file system type (btrfs, ext4, etc..), when there, --active means that the partition is flagged as bootable

Example:

  Part: foo/bar/part

This will load foo/bar/part file into the kickstart file

Example of partition file:

  part / --size=1800  --ondisk mmcblk0p --fstype=btrfs

  # This is not used currently. It is here because the /boot partition
  # needs to be the partition number 3 for the u-boot usage.
  part swap --size=192 --ondisk mmcblk0p --fstype=swap

  # This partition is made so that u-boot can find the kernel
  part /boot --size=64 --ondisk mmcblk0p --fstype=vfat

PartSize and Filesystem

This method creates just one root partition, with a certain size, and a certain file system. PartSize is always in megabyte.

Example:

 PartSize: 500
 FileSystem: ext4

Root user setup

To set the root password, use the "RootPass" keyword

Example:

 RootPass: rootme

Architecture

To indicate the architecture (RPM architecture) that your device is at most able to handle, use the Architecture keyword.

Example:

  Architecture: armv7nhl

Image creator options

If you'd like to pass more parameters to the image creator, you can use Mic2Options keyword.

Example:

  Mic2Options: --genchecksum

Boot loader settings

BootloaderTimeout

If your image has a bootloader, wait this many seconds before booting the standard option.

Example:

  BootloaderTimeout: 3

BootloaderAppend

Append these options to the kernel command line, if you have a image creator compatible boot loader

Example:

  BootloaderAppend: console=ttySAC0,115200

BootloaderOptions

If you have any additional options to the bootloader, use the BootloaderOptions keyword

Example:

  BootloaderOptions: --append "console=ttySAC0,115200"

Session launching

When a device starts up it will automatically start up a graphical session without a login prompt, to do this, it needs some information on what to start up and who to start it up as.

Desktop

This keyword indicates if there should be a desktop automatically starting and which one.

Packages can drop SESSION files in /usr/share/xsessions. These contain misc information used in choosers and Exec= lines containing the session master process. The session filter is determined by taking the session.desktop filename and removing the extension; so a gnome.desktop session file describes the GNOME session.

Example:

  Desktop: X-NEMO

FIXME:

  This needs to be merged from Session: to Desktop: as Desktop is no longer valid as of uxlaunch 0.64

Initial user setup

Default user

This is the username that will be created and if automatic session startup is enabled, will be the user used.

Example:

  DefaultUser: mer

DefaultUserPass

This is the password for the default user.

Example:

  DefaultUserPass: rootme

Repository setup

Repositories specify where to pull packages from for inclusion in the image. There are two kinds, one that declares repositories (Repositories: keyword) and one that tells which repos to include (Repos:)

Repositories

Repositories has a name and a url associated, which is a RPM repository.

Example:

   Repositories: 
     - Name: mer-core
       Url: http://releases.merproject.org/releases/@BUILD_ID@/builds/@ARCH@/packages

Options =

In a configuration or declaration, you can select the default configuration of repository:

Example:

   RepositoryOptions:  --save --debuginfo --source

Repos

In a configuration or declaration, you can list what repositories to source packages from.

Example:

   Repos:
      - mer-core
        Options: --save

Package selection

PackageArgs

It is possible to decide how your packages should be installed. The only option currently available is --excludedocs which avoids installing files that are marked as documentation, in order to save space.

Example:

   PackageArgs: --excludedocs

Groups

This keyword implies what sets of packages, called package groups, are included in your image.

Example:

    Groups:
     - Mer Core
     - Mer Xorg basic drivers

Kernel

This keyword implies that this particular package should be installed into the image. It is a shorthand for manually adding it to ExtraPackages.

Example:

     Kernel: kernel-adaptation-n900

ExtraPackages

This keyword implies that these extra packages should be installed into the image.

Example:

     ExtraPackages:
      - vim
      - nano
      - emacs

RemovePackages

This keyword implies that these packages should not be included in the image, despite if they're included in package groups.

Example:

      RemovePackages:
       - bash
       - coreutils

Post installation scripts

To allow flexibility, it is possible to indicate scripts that should be run after the installation.

Within target post-installation scripts

It is possible to list scripts that should be run after installation is done, inside the installation target.

Example:

    PostScripts:
       - scripts/rpm-rebuilddb

This will run the scripts/rpm-rebuilddb script within the target

Outside target post-installation scripts

It is also possible to list scripts that should be run outside the target, within the file system that is doing the installation. This is useful for some cases.

Example:

    PostScripts:
       - scripts/extract-kernel
   

This will run the scripts/extract-kernel script after installation.

The IMG_NAME environment will be the name of the image, and INSTALL_ROOT the directory the image is in, when running these scripts