Meego Wiki
Views

Image Configurations - KickStart Files

From MeeGo wiki
(Difference between revisions)
Jump to: navigation, search
(→Modify your .ks)
(→MeeGo Patterns)
Line 17: Line 17:
We suggest you to create .ks files by kickstarter tool with image-configurations pkg as a formal usage.
We suggest you to create .ks files by kickstarter tool with image-configurations pkg as a formal usage.
 +
 +
== Modify your .ks ==
 +
Developers may want to modify the .ks files to create their own custom images. Here are the main options and sections within the .ks file.
 +
 +
You can also find in-depth .ks option information here: http://fedoraproject.org/wiki/Anaconda/Kickstart#Chapter_2._Kickstart_Options
 +
 +
'''''Partition, Setup and Bootloader options'''''
 +
 +
''Example''
 +
 +
<pre>
 +
lang en_US.UTF-8
 +
keyboard us
 +
timezone --utc America/New_York
 +
auth --useshadow --enablemd5
 +
part / --size 1500 --ondisk sda --fstype=ext3
 +
rootpw meego
 +
xconfig --startxonboot
 +
bootloader --timeout=0 --append="quiet"
 +
desktop --autologinuser=meego  --defaultdesktop=xfce
 +
user --name meego  --groups audio,video --password meego
 +
</pre>
 +
 +
These are mostly self-explanatory and set up important things such as partition size, filesystem type, kernel paramters, etc.  You can change these depending on what your needs are.
 +
 +
'''''Repos'''''
 +
 +
This is where you can specify the yum repositories that you want MIC2 to search and pull your packages from which to make up your image.  You can add official Meego repos, other remote repos, or your own local repos on your dev machine.
 +
 +
''Example''
 +
 +
<pre>
 +
# This is a comment
 +
 +
# My first repo
 +
repo  --name=trunk  --baseurl=http://mytrunk.myrepo.com
 +
 +
# My second repo
 +
#repo  --name=<repo-name-2>  --baseurl=< url | local-repo-dir >
 +
</pre>
 +
 +
'''NOTE:''' --name of the repo can be any unique alphanumeric name you give your repo, it can be anything.  Just make sure you don't use the same name twice for any of the listed repos, remember they have to be unique.
 +
 +
To create a repo you can point to on your local developer machine, you can run the following command:
 +
 +
<pre>
 +
createrepo -d <local-dir>
 +
</pre>
 +
 +
Where 'local-dir' is a local directory on your machine that contains the rpms you want include in your local directory.
 +
 +
'''''Adding Packages and Package Groups'''''
 +
 +
''Example''
 +
 +
<pre>
 +
%packages
 +
 +
# Example adding pkg groups
 +
 +
@Core
 +
@X for Netbooks
 +
@Base
 +
@Development Tools
 +
@<my-PkgGroup1>
 +
@<my-PkgGroup2>
 +
 +
# Example adding individual pkgs
 +
 +
kernel-netbook
 +
xorg-x11-server-Xorg-setuid
 +
carrick
 +
xorg-x11-drv-evtouch
 +
<my-pkg-1>
 +
<my-pkg-2>
 +
%end
 +
 +
</pre>
 +
 +
This specifies exactly what packages will be included in your image.  Package groups can be specified with a "@" preceding it, as you can see from the examples above.  Package groups are defined in the 'repodata' section of a repo, under a 'comps*.xml' file.  Defined therein are package group names, and what packages are included in each package group.  The Meego package groups are standard, and cannot be changed.  You can, however, define your own package groups in your own non-Meego repos, if you are using those. 
 +
 +
Please see here for more info on defining package groups in repositories: TO-DO-LINK
 +
 +
You can also add individual package names to be included in the image as you can see from the second part in the above example.
 +
 +
'''''Important Note about how MIC2 picks a package when different versions are available'''''
 +
 +
A common problem is that, let's say, a packageA has more than one version residing in a repo(s) that your .ks is pointing to.
 +
 +
How will the MIC2 know which one to pick?
 +
 +
''Example''
 +
 +
There exists in the repo(s) these different versions of PackageA:
 +
 +
PackageA-1.0
 +
 +
PackageA-2.0
 +
 +
PackageA-3.0
 +
 +
 +
MIC2 will pick the PackageA with the highest version number (PackageA-3.0 in this case).
 +
 +
There is one way to get around that, and that is to set the 'Epoch' version within a package .spec file. 
 +
 +
<pre>
 +
Example (works in both .spec and .yaml file)
 +
 +
Name: <name>
 +
Summary: <summary>
 +
Epoch: 1
 +
Version: <version>
 +
 +
</pre>
 +
 +
MIC2 will first look to compare the 'Epoch' version of the packages.  All Meego official packages do not include an 'Epoch' version, so if you set the 'Epoch' number within your .spec file to any positive integer, no matter if your package version is smaller, MIC2 will choose your package.
 +
 +
So back to our example.
 +
 +
''Example''
 +
 +
PackageA-1.0 (Epoch not set)
 +
 +
PackageA-2.0 (Epoch = 1)
 +
 +
PackageA-3.0 (Epoch not set)
 +
 +
MIC2 will choose PackageA-2.0 in this case.  And it follow that:
 +
 +
''Example''
 +
 +
PackageA-1.0 (Epoch=100)
 +
 +
PackageA-2.0 (Epoch = 1)
 +
 +
PackageA-3.0 (Epoch not set)
 +
 +
MIC2 will choose PackageA-1.0.
 +
 +
Remember that Meego packages will not have 'Epoch' set, so chances are that if you set 'Epoch' in your own package to any positive integer, it will be the one MIC2 chooses to pull down and include in an image.
 +
 +
'''''Removing Packages'''''
 +
 +
If you would like to make sure that a pkg is _not_ included, you can specify that with a '-' preceding the package name.
 +
 +
''Example''
 +
<pre>
 +
%packages
 +
 +
# Example pkg groups
 +
 +
@Core
 +
 +
# Example adding individual pkgs
 +
 +
kernel-netbook
 +
 +
# Example removing individual pkgs
 +
 +
-carrick
 +
-package-xyz
 +
 +
%end
 +
</pre>
 +
 +
with the above example, packages 'carrick' and 'package-xyz' will _not_ be included in the image.
 +
 +
'''Note:''' all packages that depend on the package you want to remove should also be removed, or else MIC2 will ignore your request to remove that package from an image. For example, if 'carrick' depends on 'package-xyz', and you specified only to remove 'package-xyz', and keep carrick, MIC2 will ignore the request to remove package-xyz (since carrick depends on it), and it includes both of these pgks in the image.
 +
 +
'''''Post scripts'''''
 +
 +
You can also specify post-scripts to be run after the image is installed.
 +
 +
''Example''
 +
<pre>
 +
%post
 +
 +
# Example - saving some space
 +
rm -f /boot/initrd*
 +
rm -f /core*
 +
 +
 +
# Example - Install working xorg.conf
 +
if [ -f /usr/share/my.conf ]; then
 +
    cp /usr/share/my.conf /etc/X11/xorg.conf
 +
fi
 +
 +
# Example - Tell alsa the correct audio card to use for your platform
 +
echo -e "options snd-hda-intel index=0\noptions snd-timbi2s index=1" > /etc/modp
 +
robe.d/alsa.conf
 +
 +
 +
%end
 +
</pre>
== MeeGo Patterns ==
== MeeGo Patterns ==

Revision as of 09:30, 6 July 2011

KickStart (.ks) configuration files are passed to MIC2 to create tailored images. KickStart files specify what repos to pull from, what packages to include, what post-scripts to run and what type of images to create.

For more details about the kickstart format, see http://fedoraproject.org/wiki/Anaconda/Kickstart.

Note that not all KickStart directives and options are supported for creating Meego images. MIC2 also adds some specific directives and options. More explained below

Contents

Official Meego .ks files

The official Meego .ks files are here:

Formal release: 

 http://repo.meego.com/MeeGo/releases/1.2.0/builddata/image-configs/

Weekly build: 

 http://repo.meego.com/MeeGo/builds/trunk/latest/builddata/image-configs/

You can download and use them as a base for the Meego images you create. Modify these .ks files as you wish to create tailored images.

We suggest you to create .ks files by kickstarter tool with image-configurations pkg as a formal usage.

Modify your .ks

Developers may want to modify the .ks files to create their own custom images. Here are the main options and sections within the .ks file.

You can also find in-depth .ks option information here: http://fedoraproject.org/wiki/Anaconda/Kickstart#Chapter_2._Kickstart_Options

Partition, Setup and Bootloader options

Example 

lang en_US.UTF-8
keyboard us
timezone --utc America/New_York
auth --useshadow --enablemd5
part / --size 1500 --ondisk sda --fstype=ext3
rootpw meego
xconfig --startxonboot
bootloader --timeout=0 --append="quiet"
desktop --autologinuser=meego  --defaultdesktop=xfce
user --name meego  --groups audio,video --password meego

These are mostly self-explanatory and set up important things such as partition size, filesystem type, kernel paramters, etc. You can change these depending on what your needs are.

Repos

This is where you can specify the yum repositories that you want MIC2 to search and pull your packages from which to make up your image. You can add official Meego repos, other remote repos, or your own local repos on your dev machine.

Example 

# This is a comment

# My first repo
repo   --name=trunk  --baseurl=http://mytrunk.myrepo.com

# My second repo
#repo   --name=<repo-name-2>  --baseurl=< url | local-repo-dir >

NOTE: --name of the repo can be any unique alphanumeric name you give your repo, it can be anything. Just make sure you don't use the same name twice for any of the listed repos, remember they have to be unique.

To create a repo you can point to on your local developer machine, you can run the following command: 

createrepo -d <local-dir>

Where 'local-dir' is a local directory on your machine that contains the rpms you want include in your local directory.

Adding Packages and Package Groups

Example 

%packages

# Example adding pkg groups

@Core
@X for Netbooks
@Base
@Development Tools
@<my-PkgGroup1>
@<my-PkgGroup2>

# Example adding individual pkgs

kernel-netbook
xorg-x11-server-Xorg-setuid
carrick
xorg-x11-drv-evtouch
<my-pkg-1>
<my-pkg-2>
%end

This specifies exactly what packages will be included in your image. Package groups can be specified with a "@" preceding it, as you can see from the examples above. Package groups are defined in the 'repodata' section of a repo, under a 'comps*.xml' file. Defined therein are package group names, and what packages are included in each package group. The Meego package groups are standard, and cannot be changed. You can, however, define your own package groups in your own non-Meego repos, if you are using those.

Please see here for more info on defining package groups in repositories: TO-DO-LINK

You can also add individual package names to be included in the image as you can see from the second part in the above example.

Important Note about how MIC2 picks a package when different versions are available

A common problem is that, let's say, a packageA has more than one version residing in a repo(s) that your .ks is pointing to.

How will the MIC2 know which one to pick?

Example

There exists in the repo(s) these different versions of PackageA:

PackageA-1.0

PackageA-2.0

PackageA-3.0


MIC2 will pick the PackageA with the highest version number (PackageA-3.0 in this case).

There is one way to get around that, and that is to set the 'Epoch' version within a package .spec file. 

Example (works in both .spec and .yaml file)

Name: <name>
Summary: <summary>
Epoch: 1
Version: <version>

MIC2 will first look to compare the 'Epoch' version of the packages. All Meego official packages do not include an 'Epoch' version, so if you set the 'Epoch' number within your .spec file to any positive integer, no matter if your package version is smaller, MIC2 will choose your package.

So back to our example.

Example

PackageA-1.0 (Epoch not set)

PackageA-2.0 (Epoch = 1)

PackageA-3.0 (Epoch not set)

MIC2 will choose PackageA-2.0 in this case. And it follow that:

Example

PackageA-1.0 (Epoch=100)

PackageA-2.0 (Epoch = 1)

PackageA-3.0 (Epoch not set)

MIC2 will choose PackageA-1.0.

Remember that Meego packages will not have 'Epoch' set, so chances are that if you set 'Epoch' in your own package to any positive integer, it will be the one MIC2 chooses to pull down and include in an image.

Removing Packages

If you would like to make sure that a pkg is _not_ included, you can specify that with a '-' preceding the package name.

Example 

%packages

# Example pkg groups

@Core

# Example adding individual pkgs

kernel-netbook

# Example removing individual pkgs

-carrick
-package-xyz

%end

with the above example, packages 'carrick' and 'package-xyz' will _not_ be included in the image.

Note: all packages that depend on the package you want to remove should also be removed, or else MIC2 will ignore your request to remove that package from an image. For example, if 'carrick' depends on 'package-xyz', and you specified only to remove 'package-xyz', and keep carrick, MIC2 will ignore the request to remove package-xyz (since carrick depends on it), and it includes both of these pgks in the image.

Post scripts

You can also specify post-scripts to be run after the image is installed.

Example 

%post

# Example - saving some space
rm -f /boot/initrd*
rm -f /core*


# Example - Install working xorg.conf
if [ -f /usr/share/my.conf ]; then
    cp /usr/share/my.conf /etc/X11/xorg.conf
fi

# Example - Tell alsa the correct audio card to use for your platform
echo -e "options snd-hda-intel index=0\noptions snd-timbi2s index=1" > /etc/modp
robe.d/alsa.conf


%end

MeeGo Patterns

MeeGo use image-configurations package to create .ks files with command line tool 'kickstarter'.

The organization of image-configurations: 

 configuration.yaml -- default and platform generic configs, also point to external platform path, it's the entrance for kickstart.
 repos.yaml         -- a list of repositories to be used in the kickstart files

 core               -- path for image-configs under 'core' platform 
 compliance         -- path for image-configs under 'compliance' platform 
 ivi                -- path for image-configs under 'ivi' platform 
 handset            -- path for image-configs under 'handset' platform 
 netbook            -- path for image-configs under 'netbook' platform 
 tablet             -- path for image-configs under 'tablet' platform 

 custom/part        -- store partition definition
 custom/scripts     -- store postscripts definition

Kickstarter

Kickstarter is a tool for create kickstart files to build meego images

Example: 

 kickstarter  --configs configurations.yaml --repos repos.yaml

Configuration file: 

 The "configuration.yaml" file here is an example only, for meego kickstart files,
 consult the image-configurations package.

 This file has the definition of configurations. The Configurations inherit 
 from platforms first then from the DEFAULT section. The image configurations
 override the all other settings (in DEFAULT and platform sections).

Repo file: 

 This file contains a list of repositories to be used in the kickstart files.

Kickstart from image-configurations

It's strongly recommended to create .ks files by kickstarter from image-configurations. The followings are how does image-configurations manage those parts in .ks files.

This configurations.yaml file has a generic definition of configurations. The Configurations inherit from platforms first then from the DEFAULT section. The image configurations override all other settings (in DEFAULT and platform sections).

Basically all common options should go to the DEFAULT section. If an options is related to a specific platform, then that option should be added to the platform section. Try to keep platforms clean and very generic, if needed, create a new platform section and use it when many options for a new platform are common.

Detail for the keywords

"Name": description of the configuration file 

 Name: MeeGo Netbook/Nettop

"Schedule": When should this image be generated: 

 # *: always
 # 0: Monday
 # 1: Tuesday
 # ...
 # If no schedule keyword is present, then image will not be created

 Schedule: "*"

"Active": if this image is active 

 Active: True

"Platform": Inherit from platform 

 Platform: NETBOOK

"Part": Partition specific configs 

 Part: qemu
 
 # Part are stored in custom/part and referenced by part name

"Kernel": Based kernel 

 Kernel: kernel-adaptation-mrst

"Architecture": Based architecture 

 Architecture: ia32

"Mic2Options": MIC2 options to be used when creating this image 

 Mic2Options: "-f livecd"

"Desktop": Desktop type 

 Desktop: None

"Timezone" 

 Timezone: America/New_York

"FileName": The name of the configuration file 

 FileName: netbook-ia32

"Groups": package groups 

 Groups:
    - MeeGo Netbook Desktop
    - MeeGo Core
    - Printing
    - Games

"ExtraPackages": Additional packages that are not part of any group 

 ExtraPackages:
    - chromium
    - adobe-release
    - flash-plugin

"Repos": Repos to use in addition to default repos, those are define in the repos.yaml file 

 Repos:
    - adobe

"PostScripts": Post-scripts to be run after the image is installed 

 PostScripts:
    - meegotouch-n900
    - bootchart
    - fstab-n900
    - arch-armv7hl
 
 # post-scripts are stored in custom/scripts and referenced by post-scripts name
Retrieved from "http://wiki.meego.com/Image_Configurations_-_KickStart_Files"
Personal tools