The Mer Wiki now uses your Mer user account and password (create account on https://bugs.merproject.org/)

Kickstarter

From Mer Wiki
(Difference between revisions)
Jump to: navigation, search
(move to category kickstart)
 
(25 intermediate revisions by 2 users not shown)
Line 4: Line 4:
  
 
== External configurations ==
 
== 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 ==
 
== Configurations ==
 +
 +
The "Configurations" keyword is a list, specifies which kickstart files should be generated, see example above
  
 
== Inheritance ==
 
== 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 ==
 
== Language ==
 +
 +
This keyword specifies the default locale used in the resulting image.
 +
 +
Example:
 +
  Language: en_US.UTF-8
  
 
== Keyboard ==
 
== Keyboard ==
 +
 +
This keyword specifies the default keyboard layout used in the resulting image.
 +
 +
Example:
 +
 +
  Keyboard: us
  
 
== Timezone ==
 
== 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 ==
 
== 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 ==
 
== Root user setup ==
 +
 +
To set the root password, use the "RootPass" keyword
 +
 +
Example:
 +
 +
  RootPass: rootme
  
 
== Architecture ==
 
== 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 ==
 
== 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 ==
 
== Boot loader settings ==
  
 
=== BootloaderTimeout ===
 
=== BootloaderTimeout ===
 +
 +
If your image has a bootloader, wait this many seconds before booting the standard option.
 +
 +
Example:
 +
  BootloaderTimeout: 3
  
 
=== BootloaderAppend ===
 
=== BootloaderAppend ===
 +
 +
Append these options to the kernel command line, if you have a image creator compatible boot loader
 +
 +
Example:
 +
  BootloaderAppend: console=ttySAC0,115200
  
 
=== BootloaderOptions ===
 
=== BootloaderOptions ===
 +
 +
If you have any additional options to the bootloader, use the BootloaderOptions keyword
 +
 +
Example:
 +
  BootloaderOptions: --append "console=ttySAC0,115200"
  
 
== Session launching ==
 
== Session launching ==
  
−
=== Default user ===
+
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
  
−
=== Default desktop ===
 
  
−
=== Session ===
 
  
 
== Initial user setup ==
 
== Initial user setup ==
  
−
=== DefaultUser ===
+
=== 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 ===
 
=== DefaultUserPass ===
 +
 +
This is the password for the default user.
 +
 +
Example:
 +
  DefaultUserPass: rootme
  
 
== Repository setup ==
 
== 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 ===
  
−
==== Options ====
+
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
 +
 
 +
Note that the following macros are valid only in the Url: value and are expanded during the configuration generation phase:
 +
 
 +
; @ARCH@
 +
: Replaced with the value of "RepositoryArchitecture" if present, otherwise the value of "Architecture" is used
 +
; @RELEASE@
 +
: Replaced with the value of "Baseline"
 +
 
 +
As an extra-special hack:
 +
 
 +
; @BUILD_ID@
 +
: if mic/mic2 is run using the --release=RID then this is replaced with that value. (Yes @BUILD_ID@ = release ... you didn't expect common sense or consistency did you?)
 +
 
 +
=== Options ===
 +
 
 +
In a configuration or declaration, you can select the default configuration of repository:
 +
 
 +
Example:
 +
    RepositoryOptions:  --save --debuginfo --source
  
−
=== SaveRepos ===
 
  
 
=== Repos ===  
 
=== Repos ===  
 +
 +
In a configuration or declaration, you can list what repositories to source packages from.
 +
 +
Example:
 +
    Repos:
 +
      - mer-core
 +
        Options: --save
  
 
== Package selection ==
 
== Package selection ==
  
 
=== PackageArgs ===
 
=== 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 ===
 
=== 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 ===
 
=== 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 ===
 
=== ExtraPackages ===
 +
 +
This keyword implies that these extra packages should be installed into the image.
 +
 +
Example:
 +
      ExtraPackages:
 +
      - vim
 +
      - nano
 +
      - emacs
  
 
=== RemovePackages ===
 
=== 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 ==
 
== Post installation scripts ==
 +
 +
To allow flexibility, it is possible to indicate scripts that should be run after the installation.
  
 
=== Within target post-installation scripts ===
 
=== 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 ===
 
=== 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:
 +
    NoChrootScripts:
 +
        - 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
 +
 +
 +
== Comments ==
 +
 +
The kickstarter yaml files permit comment lines using # at the start of a line.
 +
 +
[[Category:Kickstart]]

Latest revision as of 20:40, 18 February 2012

Contents

[edit] Mer Kickstarter

[edit] YAML

[edit] 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

[edit] 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

[edit] Configurations

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

[edit] 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.

[edit] Language

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

Example: 

 Language: en_US.UTF-8

[edit] Keyboard

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

Example: 

 Keyboard: us

[edit] Timezone

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

Example: 

 Timezone: UTC

or 

 Timezone: Europe/Copenhagen

[edit] 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.

[edit] 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

[edit] 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

[edit] Root user setup

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

Example: 

 RootPass: rootme

[edit] Architecture

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

Example: 

  Architecture: armv7nhl

[edit] Image creator options

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

Example: 

  Mic2Options: --genchecksum

[edit] Boot loader settings

[edit] BootloaderTimeout

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

Example: 

  BootloaderTimeout: 3

[edit] BootloaderAppend

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

Example: 

  BootloaderAppend: console=ttySAC0,115200

[edit] BootloaderOptions

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

Example: 

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

[edit] 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.

[edit] 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


[edit] Initial user setup

[edit] 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

[edit] DefaultUserPass

This is the password for the default user.

Example: 

  DefaultUserPass: rootme

[edit] 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:)

[edit] 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

Note that the following macros are valid only in the Url: value and are expanded during the configuration generation phase:

@ARCH@
Replaced with the value of "RepositoryArchitecture" if present, otherwise the value of "Architecture" is used
@RELEASE@
Replaced with the value of "Baseline"

As an extra-special hack:

@BUILD_ID@
if mic/mic2 is run using the --release=RID then this is replaced with that value. (Yes @BUILD_ID@ = release ... you didn't expect common sense or consistency did you?)

[edit] Options

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

Example: 

   RepositoryOptions:  --save --debuginfo --source


[edit] Repos

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

Example: 

   Repos:
      - mer-core
        Options: --save

[edit] Package selection

[edit] 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

[edit] Groups

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

Example: 

    Groups:
     - Mer Core
     - Mer Xorg basic drivers

[edit] 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

[edit] ExtraPackages

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

Example: 

     ExtraPackages:
      - vim
      - nano
      - emacs

[edit] 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


[edit] Post installation scripts

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

[edit] 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

[edit] 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: 

    NoChrootScripts:
       - 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


[edit] Comments

The kickstarter yaml files permit comment lines using # at the start of a line.

Retrieved from "https://wiki.merproject.org/wiki/index.php?title=Kickstarter&oldid=1015"
Personal tools