(→Modify your .ks) |
(→Kickstarter) |
||
| Line 229: | Line 229: | ||
== Kickstarter == | == Kickstarter == | ||
| - | Kickstarter is a tool for create kickstart files to build meego images | + | Kickstarter is a tool for create kickstart files to build meego images. |
| + | |||
| + | You can download it here: http://repo.meego.com/MeeGo/tools/repos/meego/trunk/noarch/ | ||
Example: | Example: | ||
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 |
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.
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
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. 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
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.
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 example.
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
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.
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.
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 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 is a tool for create kickstart files to build meego images.
You can download it here: http://repo.meego.com/MeeGo/tools/repos/meego/trunk/noarch/
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.
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